Re: [HTML Imports]: what scope to run in
On Sat, Nov 23, 2013 at 1:51 AM, Jonas Sicking wrote: > One thing that we did discuss but that I think we never reached a > conclusion on was if imported HTML documents need to block > tags in the main document. Otherwise there's a risk that named modules > introduced by the imported HTML document won't be known at the time > when name resolution happens in the main document. Whether this is a > problem or not depends on now this name resolution works. I think this > is still an outstanding question to resolve. Some further thoughts. ES6 modules does not have a way for sub-modules to add additional names. Only top-level elements can introduce new named modules. Following that logic, a HTML-imported document should not be allowed to introduce additional names. I.e. they can use elements, but those elements should not be able to add new named modules. Only the top-level HTML document should be able to use to introduce names. If we do that, then that might reduce the race-problems around names that we were discussing. / Jonas
Re: [HTML Imports]: what scope to run in
On Sat, Nov 23, 2013 at 1:51 AM, Jonas Sicking wrote: > > > It would technically be possible to define that
Re: [HTML Imports]: what scope to run in
On Mon, Nov 18, 2013 at 4:14 PM, Jonas Sicking wrote: > At the very least, I would like to see a way to write your > HTML-importable document as a module. So that it runs in a separate > global and that the caller can access exported symbols and grab the > ones that it wants. We had a brain-storming session about this today and I offered to write up the conclusions. Confusion was abound about how various details of ES6 modules work, in part because not all corner cases have been nailed down yet, or at least have been nailed down so recently that the message hadn't reached everyone yet. Our conclusion was as follows: We want HTML imports to use the same mechanisms for dealing with name collisions and module reuse as much as possible. ES6 currently allows importing modules using both URLs and names. When a names (rather than URLs) are used, there is a risk of collisions. Specifically when a document imports two ES6 modules, A and B, both expect a module named "apple" to be available, but expect that the name "apple" maps to two completely different libraries. To resolve this ES6 uses a hook which is given enough context as to allow the the name "apple" to map to two different modules in A and in B. We concluded that as long as ES6 only allows referring to module names added higher up in the original document there is no race condition. (In hindsight it's unclear to me that this was still a requirement once we got to the end of the discussion). We concluded that ES6 needs to use different names when referring to a module by URL vs. by name. Otherwise it would be impossible for the HTML prescanner to fire off network requests eagerly which is important for performance. This does not seem to require changes to ES6, but it does require consideration when defining how the built-in resolver hook in browsers should behave. We should make it a recommendation that HTML pages use elements rather than
Re: [HTML Imports]: what scope to run in
On Wed, Nov 20, 2013 at 7:34 PM, Ryosuke Niwa wrote: > On Nov 21, 2013, at 10:41 AM, Hajime Morrita wrote: > > Seems like almost everyone agrees that we need better way to > > modularize JavaScript, and ES6 modules are one of the most promising > > way to go. And we also agree (I think) that we need a way to connect > > ES6 modules and the browser. > > > > What we don't consent to is what is the best way to do it. One option > > is to introduce new primitive like jorendorff's element. > > People are also seeing that HTML imports could be another option. So > > the conversation could be about which is better, or whether we need > > both or not. > > This is a nice summary. > > > * Given above, HTML imports introduces an indirection with
Re: [HTML Imports]: what scope to run in
On Nov 21, 2013, at 10:41 AM, Hajime Morrita wrote: > Seems like almost everyone agrees that we need better way to > modularize JavaScript, and ES6 modules are one of the most promising > way to go. And we also agree (I think) that we need a way to connect > ES6 modules and the browser. > > What we don't consent to is what is the best way to do it. One option > is to introduce new primitive like jorendorff's element. > People are also seeing that HTML imports could be another option. So > the conversation could be about which is better, or whether we need > both or not. This is a nice summary. > * Given above, HTML imports introduces an indirection with
Re: [HTML Imports]: what scope to run in
I'd frame the problem in a slightly different way.
Seems like almost everyone agrees that we need better way to
modularize JavaScript, and ES6 modules are one of the most promising
way to go. And we also agree (I think) that we need a way to connect
ES6 modules and the browser.
What we don't consent to is what is the best way to do it. One option
is to introduce new primitive like jorendorff's element.
People are also seeing that HTML imports could be another option. So
the conversation could be about which is better, or whether we need
both or not.
If you just want to namespace the script, HTML Imports might be overkill because
* An import is HTML and HTML isn't JS developer friendly in some
cases. Think about editor integration for example. Application
developers will prefer .js rather than .html as the container of their
code.
* Given above, HTML imports introduces an indirection with
>> >>
>> >> Once imported, in script:
>> >> new $('mylib').import.MyCommentElement;
>> >> $('mylib').import.doStuff(12);
>> >>
>> >> or
>> >>
>> >> In markup:
>> >>
>> >>
>> >> Once imported, in script:
>> >> new MyCommentElement;
>> >> doStuff(12);
>> >>
>> >>
>> >> How about this?
>> >>
>> >> In the host document:
>> >>
>> >>