>
> Open questions:
>
> * how to fallback? ideally, we will need a way to detect modules support,
> equivalent to <noscript> in semantic.
>

Is there much interest in a fallback option?  I would think that the
typical web shop would have little to no interest in dual-delivering both
proper modules and transpiled modules.

(It seems to me that the logical next step is to get the front-end
community to normalize authoring JS in ES6 modules and transpiling for
delivery on the web.  We're not there yet, unfortunately.)


> * we need to reserve some resolution rules to support mappings and hooks
> in the future (e.g.: `import foo from "foo/mod.js"` will not work because
> `foo` will require loader configs or hooks to be defined, while `import foo
> from “./foo/mod.js”` and `import foo from “//cdn.com/foo/mod.js”`
> <http://cdn.com/foo/mod.js”> will work just fine).
>

Those rules sound good to me.  What's the open question?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141223/459d04e7/attachment.html>

> Open questions:
>
> * how to fallback? ideally, we will need a way to detect modules support,
> equivalent to <noscript> in semantic.
>

Is there much interest in a fallback option?  I would think that the
typical web shop would have little to no interest in dual-delivering both
proper modules and transpiled modules.

(It seems to me that the logical next step is to get the front-end
community to normalize authoring JS in ES6 modules and transpiling for
delivery on the web.  We're not there yet, unfortunately.)


> * we need to reserve some resolution rules to support mappings and hooks
> in the future (e.g.: `import foo from "foo/mod.js"` will not work because
> `foo` will require loader configs or hooks to be defined, while `import foo
> from “./foo/mod.js”` and `import foo from “//cdn.com/foo/mod.js”`
> will work just fine).
>

Those rules sound good to me.  What's the open question?