On Thu, Dec 18, 2014 at 6:13 PM, caridy <caridy at gmail.com> wrote:
> What does this means?
>
> * no loader (if you need on-demand loading, you can insert script tags with
> type=module, similar to what we do today for scripts)
> * no hooks or settings (if you need more advanced features, you will have to
> deal with those manually)
>
> Open questions:
>
> * how to fallback? ideally, we will need a way to detect modules support,
> equivalent to <noscript> in semantic.
> * 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).

Also:

* How does dynamic loading work in a web worker? In general, how does
dynamic loading work when there is no DOM.
* module IDs should not be paths with .js values (see package/main
types of layout). Maybe that is what you meant by your second
question.

Perhaps the module tag is a DOM implementation detail that backs the
standardized API for dynamic loading, but seems odd to focus on that
backing detail first. I am sure there is more nuance though, perhaps
you were trying to give quick feedback, and if so, apologies for
reading too much into it.

James

Also:

* How does dynamic loading work in a web worker? In general, how does
dynamic loading work when there is no DOM.
* module IDs should not be paths with .js values (see package/main
types of layout). Maybe that is what you meant by your second
question.

Perhaps the module tag is a DOM implementation detail that backs the
standardized API for dynamic loading, but seems odd to focus on that
backing detail first. I am sure there is more nuance though, perhaps
you were trying to give quick feedback, and if so, apologies for
reading too much into it.