> 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
