HTML5 Boilerplate Page-specific Javascript Placement

Question

Question

If you use a single javascript file to hold all scripts, where do you put scripts that are for just one page?

Background

This may be a matter of opinion or "best practice" but I'm interested in others' opinions:

I'm using the html5 Boilerplate on a project. They recommend you place all javascript in a single file script.js for speed and consistency. Seems reasonable.

However, I have a bit of geolocation script that's only relevant to a single page, and not others. Should I break convention and just put this script on the page below my calls to the javascript libraries it depends on? Just put calls to the relevant functions (located in the script.js) file, below the links to the libraries they depend on?

Thanks!

Acyl

Recomend to read about AMD pattern, and use requireJS, you can async-load scripts that are relevant only for one page and keep almost the code in the same file using their optimization project. – Standardize

Answer 1

The good folks at html5 boilerplate recommend putting all of your javascript in script.js so that the browser will only have to load that one file (along with the others that h5bp uses) and to allow caching of that file.

The idea is not to get caught up in the "recommended" way, and to think about things related to your own applications.

• This geolocation file is only going to be used on this one page, right? It will never be used anywhere else.
• The script.js file will be used on multiple pages.

Well, then it wouldn't make sense to put a "whole script" that will only be needed on one page in the script.js file. You should make the file external and call it separately on the page that it is needed. This will keep you from bloating the script.js file for functionality that may never get used by that user.

However, if your "whole script" for the geolocation functionality is pretty small, then include it in script.js. If it doesn't add to the speed of the download for that file, then it makes sense to include it there.

The gist of all of this is, What is the best trade off for my application?

These things we know to be true:

• cached js files are good
• fewer files to download are good
• smaller files to download are good
• maintenance is important

Once you think of these things in terms of your application, the decision making becomes a bit easier. And remember, decisions that trade off milliseconds are not going to make much of a difference in your user's "perception" of how fast your page is.

Dieter

Thanks for your extended and thoughtful response here. Good explanation of the tradeoffs and thought process. – Acyl

Answer 2

The browser will only download the .js files once (unless something is happening to discourage the browser from caching). So if you expect all of your users to hit the one page that uses geolocation sometime during their session, then you might as well give it to them early. If you expect maybe a tiny percent of your users to eventually hit the geolocation page, then maybe you might want to split them.

Declinate

Answer 3

Split it out into a separate .js file so that it can be cached. Then reference both external .js files from your page.

Mcmahan

Answer 4

I think you should put it in a separate file. Putting all the scripts in one single file could cause unexpected behavior and conflicts. I like to have one script file for the javascript that all pages will use containing plugins, helper functions, formatting functions etc. And then create one separate js file for everything that is relevant just for each page.

If you still want to have just one js file in the browser you could take advantage of one of those utilities that combine multiple js files into one.

Molder