Keeping JavaScript Completely Separate

There are multiple reasons for keeping your JavaScript code out of the global namespace and with the entire script in its own separate file.

1. By keeping your code completely separate you can ensure that the possibility of clashes with other scripts that might be added to the same page is reduced to almost zero. While an id or class used to allow the script to actually interact with the web page has to be global, by removing everything else from global scope you ensure that the only possibility of clashes is where two scripts try to interact with the same id or class - where a clash would be inevitable regardless (if one script tries to move the content of the div up and another tries to move it down then there is no way to avoid them cancelling each other out).

2. Modern JavaScript identifies itself by adding a "use strict"; command at the top of the script. This ensures that browsers that understand the difference between modern and historical JavaScript treat the code properly (such as enforcing that all variables be defined) and makes it easier to detect many common simple coding errors. If you use modern JavaScript in global scope then all of the JavaScript in the page must be written to modern standards and any third party scripts written using historical JavaScript will fail to run. By taking your script out of global scope you can apply "use strict"; to your code without it applying to other scripts on the page that are outside of your control.

3. Some browsers pollute the global namespace with additional variables. For example Internet Explorer adds global variables that point to each element in the page that has an id or name. Since you can't tell whether a variable is pointing to an id or to a name this makes the variables rather useless when you need to specifically access an id. Also since these variables only exist in some browsers you can't use them anyway as they will not exist in some browsers and you can't control which browser your visitors use. The existence of these proprietary variables can also break scripts - they worked on browsers that follow the standards but fail when used in browsers that add these variables because of variable name clashes. By moving your code out of the global namespace you can avoid browsers creating their own non-standard variables that clash with your script.

4. Your script will be more portable if it isn't in the global namespace. With your entire script in an external file the most that you need to do in order to use it with a new web page is to attach the script to the bottom of the page and add the id or class to the elements in the page you want it to interact with. If you use global variables then they could potentially clash with something else in the new page. Even worse would be if part of your code were separate from the rest (such as being embedded in the HTML) where you'd then need to replicate that part of the code in each page you add the script to instead of the script being self contained.

5. A completely self contained script is more user friendly. For anyone with JavaScript turned off (for whatever reason), Having your entire script external to the page means that they don't waste time downloading any JavaScript (which isn't going to run anyway).

6. Prevent even the possibility of code injection into your page. With the entire JavaScript in an external file you can turn on the HTTP security header that will disable the running of any JavaScript that is embedded directly in the web page. This prevents JavaScript from running when it is either embedded inside a script tag inside of the web page itself or where it is jumbled with the HTML. Only scripts in completely separate files will be allowed to run. (Unfortunately some advertising scripts still use antiquated iframe code with JavaScript directly embedded into the HTML they are inserting into the iframe and even though the security setting is being set for the main page it also gets applied to the iframe preventing the ad from displaying - such ad providers are preventing us from applying these security measures to pages where we want their ads to appear).


This article written by Stephen Chapman, Felgall Pty Ltd.

go to top

FaceBook Follow
Twitter Follow