Comments on Meeting Notes

Brendan Eich brendan at
Tue Dec 4 11:40:09 PST 2012

David Herman wrote:
>> In general, I would like to see more updates and more convergence regarding the modules specification, as many of us are now aiming at a (seemingly) wildly moving target.
> Well, the standard isn't out yet, so to some degree this is part of the process. But I take the blame for this stuff not happening sooner. I am actively working on modules, and trying to nail this all down as soon as possible.

I would like to defend Dave against Kevin's "wildly". Sam's writeup from 
the minutes gives the history:

STH: Yes, that was the way, but there was a realization that much of the 
earlier approach was flawed and these updates lead to revisions.

One important use case for modules is to configure module references, so 
that libraries can import jQuery (for example), and get the appropriate 
version of jQuery specified by the page. Further, it's desirable to be 
able to use different code for the same library name in different 
context. Originally, the modules proposal managed this via lexical 
scope, as follows:

module M1 {
   module jquery = "jquery.js";
   module something = "something_that_uses_jquery.js"

module M2 {
   module jquery = "zepto.js";
   module something_else = "something_else_that_uses_jquery.js"

However, this has two major problems:
Inheriting scope across references to external files is potentially 
confusing, and disliked by a number of people
Once we decided to share instances of the same module, the "parent 
scope" of a module is no longer well-defined

Therefore, we abandoned the idea of inheriting scope across external 
references.  However, this had two consequences that we did not 
immediately appreciate.  First, we no longer had a method for managing 
this configuration between module names and source code.  Second, scoped 
module names no longer had nearly as much use as originally.

Thus, Dave and I revisited the design, abandoning the use of lexical 
scope for managing module names, and introducing module names that could 
be configured on a per-Loader basis.


Now, there's no "wildness" here (things too a while, OTOH). The main 
trajectory is from second class modules with lexical scope and no 
memoization of shared instance by MRL, to memoization for sharing, to 
lose the nested lexical scope when modules are not inlined, to more 
manageable module names that actually match existing practice pretty well.

(Oh, and we gave up on lexical-only all the way up, and kept the global 
object as top scope, but (separate from modules _per se_) with a new, 
single lexical contour populated by script elements based on 
let/const/class/module bindings.)

That the default loader knows about pathnames and ".js" is a good thing 
in my view. You want something else, write another loader.


More information about the es-discuss mailing list