Simple Modules and Current Modules
wes at page.ca
Fri Nov 5 07:14:38 PDT 2010
On Thu, Nov 4, 2010 Kris Zyp wrote:
> I've been meaning to make some comments about simple modules and in
> last minute with Brendan, he noted that he wanted to work with
> CommonJS to make it really good, so...
Hi, Kris! I saw the same MWB and thought, "Hey, it would be great to have
some interaction with TC-39 et al" but never thought to post here. Thanks
for taking the initiative!
Incidentally -- if there are es-discuss participants interested in
interacting with CommonJS on a more limited basis (reading the mailing list
is a lot like drinking from a firehose this quarter) -- feel free to propose
something. I'll volunteer to act as a coordinator/organizer if required.
> I think one of the key needs
> that seems to be unaddressed from the current simple modules proposal
> is the need to have a feasible transition from today's modules to
> native modules.
I agree in principle, but I don't necessarily agree that we need to maintain
exactly the same semantics, nor that ES-Harmony modules need to be shimmable
into ES5. I believe that machine-translation of modules will be sufficient,
provided that the machine translation can reasonably be written without
implementing a full ECMAScript parser.... and heck, even if a full parser is
necessary, we could probably leverage Narcissus or something.
This means that we don't need to worry about ES-Harmony module syntax so
much as the semantics. The module semantics are fairly well understood;
modules are independent units of code which provide exports when asked to do
so. If Harmony modules do this, and introduce only syntax relating to the
edges of the module system (exports, module definition, module load, import)
then I think we'll be okay for machine translation.
Additionally, we have found with CommonJS that current ECMAScript syntax is
simply insufficient, in particular with respect to scope chain pollution,
dependency resolution and asynchronous module loading. The proposed Harmony
primitives should allow a more robust system.
CommonJS modules are based on specifying dependencies using a
> require() call which synchronously returns an object providing a
> module exports.
As you know, there is work underway at CommonJS to try and repair this
deficiency. The require() function, while adequate for blocking-friendly
insufficient for the browser environment.
Require in CommonJS Modules/1.1 performs three main tasks:
1. Dereference the hidden module memo and return the exports object
2. Load the module
3. Initialize the module (compile it)
Work underway decouples these requirements. In particular, module loading
is delegated to a browser-friendly API which invokes a callback when the
module is ready -- this includes loading its dependencies. Require() will
still dereference the module memo, maintaining compatibility with
Modules/1.1 module code bodies.
This work requires changing the syntax of the module declaration away from a
free-form group of ECMAScript expressions bounded by a file to a group of
ECMAScript expressions bounded by a function. This function groups the
module's dependency list and the module's factory function together as a
unit - making the dependency list available to the ECMAScript host
environment without invoking the module's factory function... nor parsing
the module's source code.
It may also be possible to decouple initialization of the module from the
require() function, allowing module loaders to eagerly compile modules. This
would allow a bit better separation of module-system from runtime-code, but
I fear that lazy exports evaluation may be too ingrained in the CommonJS
idiom at this point. This problem occurs because modules in CommonJS are
more than just a collection of exports; invoking a module's factory function
can have observable side-effects, such as the binary module which alters
(Note to non-CommonJS observers -- there is no guarantee that the work I am
describing (I have been calling it "Modules/2.0") will be recommended by the
group; It is subject to a vote, and changing the module format in
incompatible way will be a long uphill battle)
> RequireJS has become a highly popular
> library for module loading, and is based on the CommonJS proposal 
> for script tag based modules.
The footnote might not be clear to this group - RequireJS does not actually
run CommonJS modules, although it is straightforward to refactor a CommonJS
module into the format used by RequireJS.
The difficulties encountered with RequireJS's implementation led directly to
the recent innovations around the CommonJS module format.
The RequireJS folks initially advocated changing the module format to allow
modules to be written in a such a way that they could be loaded directly (no
server-side component) via DOM SCRIPT tag injection. Discussion around this
issue led to the realization that module loading and robust dependency
resolution without regard to the environment's concurrency module was a
bigger problem; a nice bonus is that all these problems have a strong
> Another aspect of modules worth considering from practical module use
This is a really excellent point -- one which I had not previously
considered. I'm not sure that an ECMAScript module system is the right
place to solve it, however.
Is it likely that the W3C will give us DOM events that can notify us of
resource availability any time in the near future?
I also don't think extending the native module loader to load non-script
resources is such a bad thing, although clearly assistance from the DOM will
be required to, say, load a style sheet as part of a module. Your comments
about module-system bootstrapping are on point, thoug
Wesley W. Garland
Director, Product Development
+1 613 542 2787 x 102
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss