9

Question 1:

Why do I need to asynchrously load my JavaScript files in a web page? I can see the rationale for it on the server side, but if I know all the files I need to load in the client, why shouldn't I concatenate all my source files into 1 file and load that on page load? Is the first initial page load so important that future operations may be slowed down due to latency in retrieving every JS file?

Question 2:

Assuming the answer to question 1 is that I need to load JS files separately:

AMD loads each JS file asynchrously, CommonJS loads synchronously. CJS is required for server-side loading (that's how Node.js works, if I'm not mistaken). AMD seems to be a better fit for the client. Thus, the only reason to use CJS in the client is to share code with the server.

Is there a way to make AMD and CJS play nicely, so that client JS files can be loaded asynchronously but still have CJS syntax?

(What exactly does require.js do? I cannot for the life of me read between the lines on their website.)

Oliver Zheng
  • 7,831
  • 8
  • 53
  • 59

3 Answers3

3

You do not "need" to load javascript files asynchronously or via some custom loader. Here are some reasons when asynchronous loading or custom loading might provide a benefit:

  • When the javascript file is not normally needed and you might want to load it upon demand rather than all the time
  • When the javascript file is not needed for initial page display and you want to maximize the speed of first display for your page
  • When you want to control the timing of exactly when the javascript file is loaded
  • When you are deciding, based upon some condition, whether to load the javascript file or not (for example, if loading from a CDN failed, you might load from a backup location)
  • When you want script loading to proceed in parallel with other things rather than serialized one after another

If you don't need any of these benefits or some other benefit provided by programmatic loading, then you can just use the normal <script> tags and let them load synchronously.

jfriend00
  • 683,504
  • 96
  • 985
  • 979
  • Is this still true? – Jitendra Vyas Dec 15 '16 at 14:30
  • @JitendraVyas - Yes, it's pretty much all true. Browsers now have the `defer` and `async` attributes for the script tag (which you can read about [here](http://stackoverflow.com/questions/10808109/script-tag-async-defer/10808243#10808243)) which give you some control over the timing of just a plain script tag without using a loader, but there are still cases for all of the above that use a loader. – jfriend00 Dec 15 '16 at 16:27
3

Part of the issue with just concatenating the file isn't the time spent downloading, it's the time spent compiling on every page.

If you've got a 20,000 line file, and you only need 600 of those lines to get everything up and running (assuming that everything is written to be modular and asynchronous, using any pattern at all for managing the resources), then you're going to save yourself what might be half a second or more, if you serve the core program and extend as-needed (or on a delayed timer, serving large chunks of functionality which are closely related to one another).

The overall time spent downloading is higher.
The overall number of HTTP connections used is higher.
But the time required to make the page visible to the user is lower.
The time required to add base-functionality to the page is lower.
Then extra functionality can be streamed in, either after the load and initialization, or just-in-time, as-requested by the user, and in both cases, as long as the code you've streamed in is focused on doing that one thing, and isn't calling for a half-dozen other dependencies, the time between the request and the addition of the functionality is going to be minimal.

RequireJS uses a promise system, basically.

It allows you to declare dependencies up front, and hand in the code (as a callback) to be implemented, after all of its dependencies are handled.
If those dependencies have any dependencies, then they won't be initialized until their dependencies are loaded.
If you just want it loaded and order isn't important, then you don't need to give it dependencies.

The overall moral is, if you've got a system where all of your files are small, the overall weight of JS on the page is very small, you only needed a few hundred lines to do everything you wanted on the page... ...plus, you know where all of your dependencies are, you have a system on the server to make sure they're in the right order, et cetera (plus you've got great documentation, or you're the only one who touches this code, and you live inside of it, day to day)... ...then there's nothing at all wrong with doing what you're doing.

You might not see any difference at all, if the compile time is outweighed by the number of HTTP requests you make. But for overall applications which are tens (or hundreds) of thousands of lines long, where only a fraction of that functionality is needed on any one page, there can be big savings in terms of perceived time between when the page loads, and when the app is "ready" for basic interaction by the user.

Norguard
  • 26,167
  • 5
  • 41
  • 49
3

If you want to load your entire javascript source for every page, sure, compile it into one file. If you load different code based on what actions the user takes, or based on what page has been loaded, use AMD loaded modules. The other alternative would be to list a bunch of script tags, which of course would only be loaded one at a time and could take a while.

AMD is not a specific library, it is actually a standard for loading javascript modules that most of the loaders you mentioned use. This means they all use similar syntax for defining and loading modules. They are considering making AMD part of the ECMA script spec. The usefulness of it is that you can also define dependencies, so if your code requires jQuery to run, you can list this as a dependency, and it will be loaded into your modules namespace.

define( [ 'jquery' ], function ( $ ) {
    // use jquery in here without clouding up the global namespace

    return {}; // return your module for use in a different module or whatever
};

In this example, the code in the defined module will not be run until the jquery module has been downloaded. It will then inject the jquery module directly into your newly defined module as an argument $.

You can now keep your code neatly organized into files which contain modules. None of your modules will cloud up the global namespace. All of your dependencies will be sure to have been loaded before your module runs (no loading race condition bugs for dependent pieces of code).

Another advantage is you can set up your loader to use different paths for the same module, so you can define the path for the jquery module to be 'https://ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js' in one spot in your code even though it may be used in almost every module. Now when I need to update my jquery version to 1.8.3, I can simply change the path in one spot in my code, and it will use this path for every module that uses jquery as a dependency. This can also be useful for easy switching when testing when you are using module stubs, or debug versions of certain modules.

Now this is not necessarily needed for tiny projects. The bigger your project gets however, the more sense this type of loading starts to make.

dqhendricks
  • 19,030
  • 11
  • 50
  • 83