Simple Modules and Current Modules

Alex Russell alex at
Thu Nov 4 10:13:38 PDT 2010

On Nov 4, 2010, at 6:22 AM, Kris Zyp wrote:

> Hash: SHA1
> 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... 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 disagree. The design of the new system should not be predicated on what current practice looks like. We should use the entire available design space to construct the best module system for JavaScript possible. If that's incompatible with current code, that's OK.


> I believe it should be a requirement that harmony
> modules (or at least a subset of them) should be desugarable into ES5
> code, such that the desugared code is still a working module in
> harmony engines that support native modules. This provides a
> transition by allowing developers to start coding against a harmony
> module API very soon, using module loader shims for ES5 engines, and
> dropping them for future harmony-based native loaders. If harmony
> modules can only be written with new syntax, the harmony-based native
> module loaders can only be really used once harmony engines are
> available everywhere, which creates a much slower more painful transition.
> CommonJS modules are based on specifying dependencies using a
> require() call which synchronously returns an object providing a
> module exports. From the browser, asynchronous module loader is
> critical, which requires a module loader to determine dependencies
> prior to executing the module. This can be done by static analysis +
> evals, but this generally has performance issues and stack traces on
> eval's are miserable, so browser-focused developers have predominantly
> moved towards wrapping modules such that modules can be loaded
> dynamically via script tags. RequireJS has become a highly popular
> library for module loading, and is based on the CommonJS proposal [1]
> for script tag based modules. This has proposal has quickly reached
> broad adoption, with a node-based loader, a server side wrapper, and
> Dojo has even refactored its code-base in 1.6 to follow this format. I
> believe we have purposed to evolve the language advised by common
> patterns seen in the wild, and so this seems like a reasonable
> starting point for a desugaring of harmony simple modules.
> Another aspect of modules worth considering from practical module use
> in Dojo is that modules don't depend solely on other JavaScript
> modules. Modules depend on other resources like template files
> (HTML/text files), NLS bundles (set of JSON files selected based on
> locale), and possibly CSS files (Dojo doesn't actually support CSS as
> a dependency, partly because there isn't any good mechanism for
> determining when a CSS file is loaded due to the lack an onload event
> for stylesheets in Firefox, but we may in the future). Taking Dojo as
> an example, there are several ways that Dojo could achieve support for
> non-JavaScript resources as dependencies support:
> * Use synchronous loading of non-JavaScript resources. This is kind of
> disappointing since one of the goals of harmony simple modules is to
> enable easy async loading of dependencies.
> * Create our own ModuleLoader (extending the native one), adding
> support for special ids that we resolve on our own. Of course this
> defeats the goal of modules in being able to express their own
> dependencies. A module can't express a dependency on a different
> module loader (you can't load a module loader and then have it affect
> the loading of itself), so such modules are no longer really
> expressing their own dependencies any more than a plain script is that
> requires the developer to have out-of-band knowledge of scripts that
> must be loaded ahead of time.
> * Perform a second asynchronous loading of non-JavaScript modules
> after the JavaScript modules are loaded. Essentially you would lose
> parallelism and end up creating a module system on top of a module
> system, which is ugly.
> * Don't use harmony simple modules at all, stick with current
> JavaScript based module loaders. It would be rather unfortunate if
> such common use cases for developers completely away from the native
> module system.
> * The RequireJS solution is to use plugins (and Dojo is following that
> pattern). MRLs can use a plugin syntax has two parts (delimited by "!"
> in RequireJS), the first part indicating the module to use to resolve
> the MRL and the second part passed to the module that resolves it.
> Plugins can be specified that do things like text loading and locale
> sensitive loading.
> This isn't a rare problem. Developers with complex dependencies are
> exactly the target of simple modules. Ignoring their needs kind of
> misses the main developers that we are trying to help with simple
> modules. Handling very simple dependencies is relatively easy to do by
> hand, and developers with such systems are typically quite content
> with just script tags.
> Frankly, I think that trying to take on a module system for ES6, at
> least at this point, might not be wise. The harmony "simple modules"
> is already anything but simple, and it is still very incomplete and
> immature for real-world module needs. ES5 was a success because it
> backed down from large complicated new features and focused on small
> incremental changes that were desperately needed to compose important
> functionality. Maybe the same principle should be applied again. At
> least in the area of modules, if we focused on small composable
> feature(s) that are truly needed to build module systems on top of
> EcmaScript, we can introduce a much simpler addition, and ensure that
> we get it right, yet still provide the build blocks for modules with
> security. Namely, the true nugget from the module system is the
> ability to evaluate scripts with lexical scoping, and ensure a real
> filename is associated with the script (for real stack traces,
> debugging, etc). If ES6 simply had such API, it would be tremendous
> step forward for loading securable modules in EcmaScript, with minimal
> complexity cost, no new syntax, smooth transitioning, and the
> composibility to build real-life module systems. When considering the
> implementation cost of "simple modules" plus truly critical new
> features like proxies, weakmaps, and so on, the complexity adds up. A
> simple lexical scoping improved evaluation API could provide a much
> better return on our investment, at least for any near future edition.
> Anyway, I thought I would throw out these thoughts, if more formal
> proposals on anything would help, I'd be glad to put something together.
> [1]
> - -- 
> Kris Zyp
> SitePen
> (503) 806-1841
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla -
> iEYEARECAAYFAkzSs64ACgkQ9VpNnHc4zAwOdQCfaNxLlO0lprkKOe/zppq9OYB8
> omQAoI+6dHMyAoZlsFz4u95v6bU1yDhX
> =jdH3
> _______________________________________________
> es-discuss mailing list
> es-discuss at

Alex Russell
slightlyoff at
slightlyoff at
alex at BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723

More information about the es-discuss mailing list