Simple Modules and Current Modules
alex at dojotoolkit.org
Thu Nov 4 10:13:38 PDT 2010
On Nov 4, 2010, at 6:22 AM, Kris Zyp wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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 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 
> 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
> 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
> 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.
> 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
> 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.
>  http://wiki.commonjs.org/wiki/Modules/AsynchronousDefinition
> - --
> Kris Zyp
> (503) 806-1841
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> -----END PGP SIGNATURE-----
> es-discuss mailing list
> es-discuss at mozilla.org
slightlyoff at google.com
slightlyoff at chromium.org
alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
More information about the es-discuss