To start things off, I have basically no javascript experience and I am trying to modify a pre-existing .js file used in my office to quickly open up several web pages from one file. It is really helpful in a quick start, and though it was written by a different person who is, unfortunately, no longer around to maintain the file, I have been able to keep it up to date with the changes that happen around here.
The downside is that the script exclusively opens the pages in IE, and there are a couple of links that I want to convert to opening in Chrome instead as they run much more efficiently there. So far I haven't been able to find the right way to code it, nor the right sort of variables/definitions to use. The original script is as follows (page addresses removed, of course, minus the last one to provide reference);
var navOpenInBackgroundTab = 0x1000;
var oIE = new ActiveXObject("InternetExplorer.Application");
oIE.Navigate2("http://[address]", navOpenInBackgroundTab);
oIE.Navigate2("http://www.carfax.com/", navOpenInBackgroundTab);
oIE.Visible = true;
this section edited to update on issue progress
The .js file being used is a stand alone file resting on the windows desktop and is not being run within or embedded as a part of any html environment, and calls on using Active X objects to function. It has no user interaction other than your basic .exe style double click and it runs. Thanks to your assistance and suggestions so far it has been established that Active X does not connect/utilise Chrome unless an additional plugin is downloaded (ActiveXobject). I have been unable to clarify if this plugin allows chrome to utilize activex within the environment (IE; a web authoring tool), or if it allows activex itself to call on chrome as a valid object. However it is nonviable as a solution due to admin restrictions in my situation.
My question is now one of alternative ways I can target a link to chrome, such as through old-fasioned html coding or a javascript version thereof that would let me call a link and set a target without using axtiveX. Is this possible/does code exist that can be used within the same .js file without mucking things up? (preferrably something that can be done in one or two lines. I don't have the skill to be writing my own libraries. ... Also, I am lazy. ¬_¬)
I'm quite sure that you get the same result by calling window.open("website url", "_blank") multiple times, using Chrome.
It might give a warning that the page is trying to open other pages, but since it is from a "trusted source", you can disable this warning and it'll not annoy you anymore.
I have the following app.js file:
https://gist.github.com/manifestinteractive/393a4aae0c4ed4fb6bc2
When I look at files I am loading statically in the public folder via the operating system, they look correct, however, if I go to view them via the browser as intended for delivery through node express engine, the contents are duplicated. Basically, it is taking the file and appending it to itself, which of course breaks the javascript.
Anyone know why this would be happening? Suck a weird bug and I can't for the life of me put my finger on the cause.
For the record, I have tried looking everywhere for a solution. I've just not seen anyone talk about it. A quick test shows that I can manually change the JavaScript file at the source, and refresh the code in the browser, and it will reflect the changes correctly, but it will still be displayed twice.
Thought it might be some weird issue where maybe I had multiple instances of Node running or something, as that MIGHT explain it... but nothing :(
If I find what it is, I will follow up with the issue immediately, but for the time being, I am likely just doing something stupid someone here might yell at me for... and I would gladly welcome it :)
Meteor adds a unique hash query parameter to the end of all the script files returned. Which is great except when it comes to debugging. If I set breakpoints in a file I change I have to re-add those breakpoints. Very annoying because I usually have breakpoints in the file I change. I don't mind having to disable caching and force a page refresh to get the new version of the code in cases like this.
If there is another way to preserve breakpoints, this would also solve my problem
There are a number of solutions for debugging.
As well as being able to use console.log() you can try http://observatoryjs.com for very detailed live insight into your app.
Many people also use https://github.com/node-inspector/node-inspector for server side debugging.
To specifically address your question, though, well there is not much you can do about that.
Well I had lots of scripts so what I did is that I combined all of them into one script file, which contains files like Jquery library too.
But now the problem is that it has stopped working, I don't know why did this happen.
What I did is that I took every script copied and pasted it and then I gave some space under it by pressing enter a few times and then I used to paste other script, I was told this was the method to combine scripts but now the scripts don't work.
Here is the link to combined scripts http://files.cryoffalcon.com/bloghuts/uncompressed/BlogHuts%20UNCOMPRESSED.js
And the link to a live example is http://bloghutsbeta.blogspot.com/
ANSWER/SOLUTION:
Earlier I was using an older version of Jquery I think 1.5 now I changed it to latest 1.7 and that was the reason that everything stopped working. It had nothing to do with combination. I am using all scripts combined and everything is working fine But why is older version better than New that is a new question for me
First, I'd suggest you move the jquery library links out to the main page. Have one file for all of your javascript, and include the other stuff on separate lines.
Whether or not you do that, though, your problem is almost certainly some sort of unclosed bracket or semicolon missing or something similar. Javascript often reacts to stuf like that by throwing its hands up in the air and giving up. The way to fix it is to go through your file and pick a function that is not currently working, but that is easy to test for functionality. Then comment out everything else, and test to see if the function works. If not, fix the function until it does work. Then, one piece at a time, uncomment each of the other blocks, again testing to see if the initial function works. If uncommenting a block causes the thing to stop working, then that's the block that you need to fix. Depending on how long your blocks are, you may need to do this in tiers
First, don't do that with jQuery, ever. You're almost always better off pointing your script src to a public CDN somewhere.
Second, what you're trying to do is very brittle, and probably not worth troubleshooting. If you have that many JS files, you really need to use a module library (I like require.js) to give your project some structure and make it more manageable. Most libraries like this will include some sort of utility to combine and minifi your scripts safely.
This will take some work on your part to get things setup, but it should prove well worth it in the long run!
I have noticed that the place of scripts is not irrelevant, if script refers to some div below, it may not work, not sure about rules perhaps my messy code assign some other value later. So I am asking general guide-lines to design the structure in Javascript code. What is the order for example to the parts such as CSS, Divs and Scripts?
My personal bias is that good code should be easy to read from the bottom to the top. So, for example, a browser could have browse() script at the bottom to start browsing and the rest junkies that it uses to to top in logical order, so after browse() its above script should be something that the browse() uses. Field values should be defined at the top, I think things like CSS and divs -- rude analogy I know. But if user's browser is slow, the script may not execute at all and the code seems to be non-working. Dilemma between practicability and readability.
Please, define terms, such as top-to-bottom coding and bottom-to-top coding, and show the structure.
In head, put CSS, then scripts in order of usage and in body Divs.
Example if you use jQuery and have a .js file that uses jQuery code, it's adviced to import the jQuery files before your .js
Personally I try to avoid putting scripts in the body and rarely face such issues as scripts not finding divs below.
Usually I try and place scripts that manipulate DOM on the bottom of the page, it solves the problem of not finding the DOM elements before a page is fully loaded.
However, libraries (such as jQuery) should go in <head>.
You can consider the entirety of the page, JavaScript, CSS, and HTML, as a combination "top to bottom" generic program, where later code can reference earlier code. Because when the page loads, it simply starts "executing" or interpreting "code" as it sees it. Most of the time, that "code" is simply definitions (like JS vars or functions), and placement of elements (like DIVs).
However, if you have JS that actually runs during load, that is code, that is outside of a function definition, then it's going to only "see" things that exist before the code is executed. So, in that sense, the whole thing is simply one long program, with the HTML as a meta-language building a DOM as the HTML is interpreted by the browser.
Obviously there are techniques to run code at certain points, like page load, etc., and that's where the libraries like JQuery come in to to expose those event points and make them easy to use.
But fundamentally, it's a top down script, like pretty much anything else.
I try not to have excessive script block ins my code at all. I call all external scripts in the head or just before body close in the case of some api inclusion (addthis for example). All inline scripting goes in a single block at the just before the close of the body tag as well.
RequireJS - Outsourcing Script Loading
I have found RequireJS particularly useful for JavaScript application development. In my case I'm dealing with tens of JavaScript files (modules) but I'm sure it will come in handy in other cases as well.
The library handles a lot of boring stuff for you. All you need to do is to set up some files (main.js, build options), state module dependencies and you are good to go. It includes a build system so you can easily get a debug or production build (minified) done.
On Application Structure
I like to code "top-down". The idea is that higher levels of an application should be really loosely defined. You shouldn't see actual algorithms used for solving some specific problems there. The highest level should be just about wiring parts of an app together. The lower levels solve more specific problems till you get to concrete implementations.
This is a fairly standard, layered approach to application development. You probably won't need something like this for casual scripting. It's still a good idea to apply in practice as it helps you to compose your scripts better. You can use the idea on closure level even to make the code easier to read.
On Functions
It might help to read "function" as "to" (Logo concept :) ). I think a well-written function reads like a recipe (to "drawLine" you must do this and that using these parameters...).
I know this might not be exactly pertinent to the question but I thought it might be a fun idea to mention. Perhaps it will help you to see functions differently and help you to structure your JavaScript code that way.
On Elements Not Ready
Considering elements not ready and script loading... you might be better off defining your code at a "document ready" handler. This is fairly standard thing to do.
If you use RequireJS or a similar library you probably don't have to worry about this. They handle this particular issue for you.
The style sheets go first and scripts go later. The reason for this is scripts are "blocking", meaning that while the browser is downloading JavaScript, it will not download anything else - not style sheets, nor images.
Browsers will only download so many resources at one time, and will block all other loads until this number of resources free up. IE8 actually will download quite a few at a time, as many as 18 or more. Firefox and Safari will download 6 at a time, but IE6&7 will only download one script or two non-scripts at one time. The thing to keep in mind is these resources are not free, and scripts are different.
A good rule of thumb is to put your style sheets in the head and your JavaScript at the very bottom of the body. Of course JS libraries give you some sort of "on DOM ready" to attach to. You can use this, and most devs do, but there are side effects:
IE occasionally barfs on the DOM-loaded hack. Rare, but it's happened to me.
Your page will be frozen until your scripts load if they are in the head. If you have too many scripts, that can make your page look slow and non-responsive.
If your JavaScript is all at the end of the page, you'll never need to worry if stuff is loaded or a DOM node is available. And the page will be rendered and styled while your JavaScript is loading and calculating.
Finally, keep your resources to an absolute minimum. If you have more than two scripts and two style sheets, your page is not as fast as it could be. Images too - make full use of image sprites. There should only be a handful of images unless you are dealing with thumbnails or something like that.
K-I-S-S is my dogma. When my code does not work, it starts usually to work when I kill non-intrinsic code.
Some good things are covered in replies such as mwilcox and prodigitalson.
No unnecessary pictures and no excessive script blocks. Actually, some people seems to have working-JS-code of over 500 000 lines, example with Gmail.
I have no idea how they do it but it hints to be critical about the replies here! Further replies could cover how to design massive JS code like of the size 100 000 lines, for the time being.
Exceptions
libraries and analytics scripts are an exeption and go to the beginning (if needed at all). Due to this kind of messy things, you may see why the term structure become confusing. But to craft some sort of structure, it would look something like:
CSS
Divs
scripts at the end