Harmony modules feedback

James Burke jrburke at gmail.com
Mon Jan 16 22:06:37 PST 2012

On Mon, Jan 16, 2012 at 9:44 PM, John J Barton
<johnjbarton at johnjbarton.com> wrote:
> Doesn't "Script-loader" make about as much sense as literal "XML HTTP
> Request"? Imagine how impoverished our Web App world would be if it had
> turned out that Ajax only supported valid XML.
> Shouldn't the API
> in http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders be split
> into one layer that takes URL -> buffers and another that takes buffers ->
> modules?  Then clever folks can do clever things with and between the two
> layers.

There are two things:

It would be nice to set up a module that can be used to resolve some
types of "module"/resource IDs that are not just a simple static
script request. This should be possible without having to have a
bootstrap script that sets up a resolver in a script file -- if I need
a specific bootstrap script before loading any modules, this does not
give the harmony infrastructure much of an advantage over what can be
done today in AMD, as far as initial developer setup. This would help
with the async callback nesting needed otherwise. Note that the
resolved resource may not be a transformed piece of text, but an image
or a CSS file that is attached to the DOM and loaded. It could also be
a resource assembled from a few text resources, like an i18n bundle.

Second, having something like node's vm module would be nice for text
targets. Or maybe it is like you mention, it gets called on completion
of the text fetch, and allows transforms, then execute and have it
interpreted as a module, optionally in a sandbox. But that starts to
feel like it is drifting from the desired compile time attributes
currently specified for harmony modules. Maybe not though, maybe the
compiling waits for those transforms to complete. Although ideally the
transformers are modules.


More information about the es-discuss mailing list