inline...

> On Dec 19, 2014, at 3:21 PM, James Burke <jrburke at gmail.com> wrote:
> 
> 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.

think about this as nodejs without NPM and core modules, where we can only do `require(‘./path/to/something.js’)` and `require(‘/full/path/to/something/else.js’)`, and we can evolve from there. The web worker is definitely in our radar, we just don’t have a solution for it without the loader implementation (same for realms).

> * 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.

As for the module IDs, yeah, we need some metadata to resolve module IDs, that metadata is probably just custom loader configurations (phase two of our proposal).

> 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.

Yeah, the idea is to get engines (V8 maybe) to implement what is spec’d in ES6 today, and get a very basic implementation of <script type=module>. Remember, the goal is to get this out there asap to start gathering feedback from the community, and this seems to be the minimum requirements.

The part that we need some help is the fallback mechanism (the <noscript> equivalent feature), we need to find a compelling solution for that.

/caridy

inline...

> * How does dynamic loading work in a web worker? In general, how does
> dynamic loading work when there is no DOM.

think about this as nodejs without NPM and core modules, where we can only do `require(‘./path/to/something.js’)` and `require(‘/full/path/to/something/else.js’)`, and we can evolve from there. The web worker is definitely in our radar, we just don’t have a solution for it without the loader implementation (same for realms).

> * 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.

As for the module IDs, yeah, we need some metadata to resolve module IDs, that metadata is probably just custom loader configurations (phase two of our proposal).

> 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.

Yeah, the idea is to get engines (V8 maybe) to implement what is spec’d in ES6 today, and get a very basic implementation of <script type=module>. Remember, the goal is to get this out there asap to start gathering feedback from the community, and this seems to be the minimum requirements.

The part that we need some help is the fallback mechanism (the <noscript> equivalent feature), we need to find a compelling solution for that.