0

I have a web site with several web pages. Each page requires some JavaScript: i.e. different JavaScript for different pages, which some JavaScript that's common to every page.

Some of the JavaScript is long (e.g. 4000 lines of code). I coded the JavaScript using the basic Module Export pattern described in Adequately Good's JavaScript Module Pattern: In-Depth article.

Anyway, now I'm thinking of using a JavaScript minifier to:

  • Combine several the JavaScript source files into one
  • Include that same, single JavaScript source file on every web page

I hope that doing this would solve two problems:

  • At design time, it's easy to reuse existing JavaScript modules (because the existing modules must be designed as reusable modules, included on and therefore available on every web page)
  • At run-time, it's performant: because the user's browser (which includes mobile browsers) only has one JS source file to download; and that file is presumably already cached in the browser when it loads a second or a third web page (i.e. any page except the first).

Is this a reasonable thing to do? Is it normal, or is it a WTF thing to do? Are there disadvantages I should consider, and are they significant?

I hesitate because it implies code being loaded into a page, which isn't required by that page. OTOH that's probably what happens when you load any 3rd-party JavaScript library (i.e. you load the whole library but don't use all its functionality).

Improve this question

3 Answers 3

Reset to default
1

I have seen this done very well (single page application) and done very poorly(reloading pages take up to 15 seconds sometimes). Please consider partial page loading and a single page application approach for performance if you wish to optimize the JavaScript for every page in a single file that loads for each page. This will allow you to load all the JavaScript and then just blow away and re-write the DOM based on script interactions. The JavaScript loads the first time with partial page load for user perception, but then all the other page navigations are quick since all the code is pre-loaded from the JavaScript on initial page load.

  • Single Page Application
  • Partial Page Loading: I didn't find a good link for partial page loads, but basically you load the views but have other views inside those that you don't load, so the screen starts with headers/footers/some content with images and sections, then post-page load javascript is fired to replace DOM portions with additional content like embedded tables or other more time intensive actions. Thus it appears to the user the page is loaded, but it finishes while they are reading and moving the mouse around without reloading the full page.
Improve this answer
7
  • You wrote "If this is the case" ... if what is the case? Also you wrote, "I have seen this done very well and done very poorly" ... can you identify what the difference is or the criteria for judging, how could I assess whether I'm doing it well or poorly?
    – ChrisW
    Apr 20, 2017 at 20:31
  • @ChrisW updated, sorry for confusion. Please let me know if anything else is confusing and I'll clarify.
    – mutt
    Apr 20, 2017 at 20:34
  • Do you know why reloading a page might take 15 seconds if it's done poorly? Am I wrong to assume that in a traditional multipage site, a single JS file will be cached by the browser across page loads (assuming I specify cache-control:public,max-age=31536000 in the response header for the file)? Might something in particular make it expensive to reload and reinterpret the JS code in the file, even if it's cached?
    – ChrisW
    Apr 20, 2017 at 20:39
  • It's various depending on the content so harder to say as each app is unique. Definitely seen excessive javascript files slow the load down as it requests from the server on page load and comes back. Especially when you are utilizing alot of libraries like angular, bootstrap, jquery, D3 and then have your own custom one that has every function in it you are calling aside from the third party ones. It takes some time on loading from the server. Locking in your cache is application specific so if you got that route make sure you don't need to refresh it for any reason.
    – mutt
    Apr 20, 2017 at 20:50
  • I have seen conflicts with stale data and good javascript files and then calls to force the page refresh again to fix the stale data issue resulting in the slower performance that was trying to be avoided in the first place. Consistency on the approach is key and should rectify the situation, although the single page design matches the full javascript load idea approach specifically so mentioned it. Takes the browser page load out of the picture entirely and just replaces DOM with new content from the server.
    – mutt
    Apr 20, 2017 at 20:53
1

I hesitate because it implies code being loaded into a page, which isn't required by that page.

Unless it's ridiculously large, I would treat it like any other library where you don't use all the functions on any given page (as you yourself mention). i.e. go ahead.

One thing to look out for: make sure that your 'library' doesn't conflict with other libraries/ functions that are available on the page.

Improve this answer
0

tl;dr

1) Make conrete goals

2) Measure first before you implement

3) Measure after implementation, whether you achieved the goals

From the level of detail you present here, it is hard to tell, what exactly your problem is and whether the solution you try to implement indeed solves that problem.

What is your current pain point? Without knowing that, one needs a good working glassball to help you - mine is just broken.

Combine several the JavaScript source files into one

Under some circumstances, this might be a good thing to do. Depending on your target device and/or your target network.

  • If you are doing mobile, you have the advantage that, when the file is already in the browser's cache a second request under flaky - mobile is most of the time flaky - network conditions comes for free. So it might be a good idea to concatenate and minify your javascript. On the other hand, page load time may increase if you receive at first load a big chunk of JS which has first to be downloaded (over a perhaps slow and flaky connection) and then interpreted for the first use of the site. Without concrete numbers it is hard to judge whether that is acceptable for you ( or your users) or not.

  • Say, you are aiming for desktop users - although mobile is on the rise, this is not an unusual target - with a reliable 50 Mbps connection, the question may be legitimate to ask, what are the expected benefits from your strategy?

  • On top: if you are developing an intranet solution, the question about minification is harder to answer.

Another strategy could be, including only a skeleton of functionality at first load and dynamically retrieve additional JS as needed.

There are many solutions to many problems.

Include that same, single JavaScript source file on every web page

This could or could not be a valid option.

At design time, it's easy to reuse existing JavaScript modules (because the existing modules must be designed as reusable modules, included on and therefore available on every web page)

Modularity is a nice thing and with a codebase consisting of 4k LOC it is the most obvious thing to do to keep a sane mental state.

At run-time, it's performant: because the user's browser (which includes mobile browsers) only has one JS source file to download; and that file is presumably already cached in the browser when it loads a second or a third web page (i.e. any page except the first

That is somehow a valid point. If a script is interpreted for the first time, the interpreter produces cache data and is able to reuse these information to deliver a faster user experience on later visits.

On the other hand: this holds even for multiple JS files. Once they are loaded, they are also cached.

Is this a reasonable thing to do? Is it normal, or is it a WTF thing to do? Are there disadvantages I should consider, and are they significant?

As long as you do not provide further details, the answer to that is: maybe (not).

I hesitate because it implies code being loaded into a page, which isn't required by that page.

So what? It is your application. As long as you achieve your goals with the design, who cares? You are in charge.

Improve this answer
4
  • My current pain point is that one of my existing JS files is 4000 lines long and encapsulates 20 modules. I want to reuse some of those modules on a new page (plus new code for the new page). I could do that by adding new code to the existing JS file (but the file is already long), or by removing the reusable modules into some other file from which they could be reused (which may increase the number of files and therefore hurt performance); and moving modules from one file to another means editing working code which is risky (better if it were designed from scratch as reusable source modules).
    – ChrisW
    Apr 21, 2017 at 10:12
  • So I'm thinking of rewriting some of those existing monolithic JS files as reusable modules, and introducing a bundler (i.e. a tool which combines several source files into one) and minifier into the build process -- possibly Browserify or the Google Closure Compiler. If I do that, I wonder whether to build one JS which I will use for every page, or whether to build different JS for each page. The latter is a bit more design-intensive (but I suppose not much), and in this question I'm asking whether the former is a sane and a better-runtime-performance thing to do.
    – ChrisW
    Apr 21, 2017 at 10:16
  • Depending on your target device and/or your target network. I want to optimize for mobile devices (phones and tablets) used outdoors (e.g. cellular not WiFi). Measure first before you implement I don't really want to implement both solutions and then test both to see which is better. I want to guess which solution is good, use theory to discard any bad solution before implementing it (hence this question), implement that one solution, and then stick with it (and not also implement the other solution) unless there's some evident problem.
    – ChrisW
    Apr 21, 2017 at 10:24
  • If the code works now and splitting the monolith is dangerous, why not simply add just the code you need? On the other hand if you are looking for maintainability, it would perhaps make sense to splut the monolith up. Better suffer now than later. It should be really easy to test before and after concat and minify. I see no problem in that. I unserstand your basic idea of "doing it right", but there is no orthodox way to go. There are always tradeoffs to make.
    – Thomas Junk
    Apr 21, 2017 at 10:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.