On Mon, Jan 16, 2012 at 9:44 PM, John J Barton <johnjbar...@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. James _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
