Modules, Concatenation, and Better Solutions

James Burke jrburke at gmail.com
Tue Oct 16 15:48:32 PDT 2012


On Tue, Oct 16, 2012 at 2:58 PM, David Herman <dherman at mozilla.com> wrote:
> prints "a" then "b" then "main". That's clearly a problem for simple concatenation. On the one hand, the point of eager execution was to make the execution model simple and consistent with corresponding IIFE code. On the other hand, executing external modules by need is good for usually (except in some cases with cyclic dependencies) ensuring that the module you're importing from is fully initialized by the time you import from it.

In earlier versions of requirejs, I used to eagerly evaluate define()
calls as they were encountered, trying to duplicate the IIFE feel.

This caused a problem for concatenation: some build scenarios build in
all the modules used for a page into one JS script. However, only half
the modules may be used for the first "screen render", with the second
half of the modules for a second "screen render" that is triggered by
a user action. The secondary set of modules can have global state
changes, like CSS/style changes.

By eagerly evaluating the modules as they were encountered in the
built script, the page would have unwanted style changes applied
during the first screen render when they should have been held until
the second set of module use for the second render.

By switching to "evaluate module factory functions by need" in
requirejs, it gained the following benefits:

* concat code executes closer to the order in non-concat form.
* delaying work that does not need to be done up front. If
optimizations like delayed function parsing (like v8 does?) extended
to modules, even parse time could be avoided.
* modules can be concatenated in an order that does not strictly match
the linearized dependency chain (the benefit Patrick Mueller mentions
earlier in the thread).

James


More information about the es-discuss mailing list