>> On Fri, Mar 30, 2012 at 3:25 PM, James Burke <jrbu...@gmail.com> wrote:
>> [snip]
>> The module_loaders API has a way to do a runtime module registration, but as
>> I understand it, it means that a consumer of my library then needs to then
>> use the System.load() API to get a hold of it.
My understanding was that this is not necessarily true. For example - in the
syntax of the current API design on the wiki:
// app.html
<script src='backbone.js'></script>
<script src='app.js></script>
// backbone.js
System.set("backbone", {
something: 42
});
//app.js
import something from "backbone"
console.log(something);
The ES6 module syntax and static binding of app.js still works correctly,
because backbone.js has been fully executed and has added itself to the module
instance table before app.js is compiled (which is the point where the static
binding is established). There are restrictions here of course, due to the
need for the dependent modules to have been made available before compilation
of the ES6 code.
At least in cases like the above though, libraries can continue to work on
non-ES6 browsers, and feature-detect ES6 module loaders to register into the
ES6 loader so that later processed modules (typically app code) can use ES6
syntax if desired. Moreover, it ought to in principle be possible to build AMD
(or other current module API)-compliant shims over the ES6 module definition
API that allow existing modules to be used as-is, and still consumed with ES6
module syntax.
FWIW - I asked about a few similar scenarios related to module loaders interop
in [0].
Luke
[0] https://mail.mozilla.org/pipermail/es-discuss/2011-November/018457.html
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
