Modules, Concatenation, and Better Solutions
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
> (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
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
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss