Modules, Concatenation, and Better Solutions

Kevin Smith khs4473 at gmail.com
Wed Oct 17 06:15:47 PDT 2012


> I see two coherent alternatives:
>
> (a) execute inline modules by need (i.e., on first import) rather than
> eagerly
> (b) execute external modules "transactionally", trying to order them by
> dependency so that imported modules have fully initialized before the code
> that depends on them runs
>

I think we should also consider :

(c) remove easy and transparent concatability from the list of design goals.

Why do we want to concat modules?  I can think of two reasons:

1.  To reduce the number of HTTP requests.
2.  To distribute a program as a single file.

Now, transpilers targeting ES<6 will have to wrap each "separate file"
module in a factory function anyway, so order-of-execution is no problem
for them.  Ergo, the current module design presents no concat problems for
ES<6 targets.

What about ES6 targets?  Do we really need to concat for ES6 targets?

Concating source files has always been a suboptimal solution to the
multiple request problem anyway.  It's not as cringe-inducing as image
sprites, but it's up there.  As David Bruant mentioned, a design goal for
HTTP 2 is to make such spriting unnecessary.  Will HTTP 2 permeate before
ES6..?

The obvious solution to (2) from above is to distribute programs as zip
files.  A crazy idea:  what if browsers natively supported loading modules
from zip files?

Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121017/70d65db5/attachment.html>


More information about the es-discuss mailing list