simple modules

Brendan Eich brendan at
Sat Jan 30 09:09:05 PST 2010

On Jan 29, 2010, at 6:50 PM, Allen Wirfs-Brock wrote:

> David and Sam, well done!
> Lots of nits to pick and ideas to discuss but this makes it very  
> clear how a simple "static" (or 2nd class) module system could  
> nicely integrate into ECMAScript.

I wanted to mention that "second class" is not a bad thing, since  
modules are static (source-level, prior to loading and compilation)  
segregations of code with generally or mostly static dependencies.

Also, Sam and Dave's proposal reflects second class modules as  
objects, so there is no iron curtain between second and first class --  
but crucially, the system is static if you don't reflect a module as  
an object, which makes it easier to use for common module chores.

Even the first-class alternative needs special forms such as import  
"..." so that static analysis can arrange to prefetch needed  
resources. This makes for tension between the static and dynamic  
"poles", since an import in a deeply-nested if-then chain, at least in  
the browser, must still have its module prefetched unconditionally to  
avoid violating the run-to-completion execution model.

Of course, one can use XMLHttpRequest and a safe eval, or (let's hope)  
a cleaner dynamic import function, in either a first- or second-class  
system. But this seems to be an exceptional case, and the import ["A",  
"B", ...] form in Sam&Dave's proposal covers the common fail-over/ 
fallback use-case without requiring random logic driving dynamic import.

Another observation: first-class-only modules tend to fall into the  
first-class functions gravity well. We saw this in presentations from  
Kris and Ihab at the TC39 meeting, with the |module point(x, y) {...}|  
example, which closely resembled a named function expression. Nothing  
wrong with module as lexical scope special form, but if it makes a  
module constructor function, then it to some extent duplicates function.

We already have first-class functions, but so far we have had to rely  
on the <script> tag, eval of XHR-loaded code, pre-deployment  
translation tools, and other extraordinary measures in lieu of an  
integrated module system. This is the way things are, for better or  
worse. But it need not dictate how first-class (first-class-only) an  
integrated system should be.

That JS developers have to "make do" via a combination of first-class  
functions and dynamic loading methods, however important to support  
downrev browsers, should not  preclude static module systems from  
being explored. Good to see this second-class module system  
exploration, at last.


More information about the es-discuss mailing list