ES6 Modules
On Mon, Apr 8, 2013 at 2:43 PM, Rick Waldron <waldron.rick at gmail.com> wrote:
On Mon, Apr 8, 2013 at 9:37 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
So modules have not yet landed in ES6, but are planned. I also heard they will have a pretty dramatic impact on APIs. When is TC39 planning to bring that discussion here?
Can you be more specific?
I'd need to have specifics first and they're not in the ES6 draft.
What are your concerns?
I'd like to evaluate the impact of ES6 modules on web platform APIs. How we'll need to accommodate for them down the road.
We will have a final draft of ES6 by the end of the year.
There was also some hope that Dave and Sam would have time to start writing parts of the module spec before the next F2F meeting in May (which btw you should come to, it is in London, or at least join for dinner).
I'd need to have specifics first and they're not in the ES6 draft.
I'll try to start with some point I have in mind, others will complete as necessary.
From what I know, there are 2 parts:
As far as 1) the "import" semantics part might need some attention in relation to URLs and how they are resolved (relative to the JS resource url? document url?). There is probably a need for some module name resolution binding to hook with the Fetch algorithm for cases like:
import "http://www.mywebsite.com/myScript.js"
I don't think 2) will affect the platform; it's its own objects with their own semantics.
I'd like to evaluate the impact of ES6 modules on web platform APIs. How we'll need to accommodate for them down the road.
It might be interesting to start adding new APIs not as global properties or properties in navigator, but rather as built-in modules (I'm not entirely clear on how these are defined/listed/feature detected/what's the import syntax for them).
Maybe have WebIDL interpret any interface as a module or something of this kind in an attempt to steer JS devs away from globals. I imagine it might not be possible as I phrased it, but it feels worth investigating. All of that might have to wait until major browser makers all have some support for ES6 modules.
I have most certainly forgotten some points, but that can be a start. Anne, are there other points you anticipate could need some discussion?
On Mon, Apr 8, 2013 at 3:09 PM, Erik Arvidsson <erik.arvidsson at gmail.com> wrote:
We will have a final draft of ES6 by the end of the year.
Right, but is there a high-level sketch somewhere?
There was also some hope that Dave and Sam would have time to start writing parts of the module spec before the next F2F meeting in May (which btw you should come to, it is in London, or at least join for dinner).
Not that week unfortunately. I'll try to avoid a clash going forward.
It would be wonderful if module syntax and semantics were pinned down sooner rather than later. Until we have a standard, transcompilation remains bleeding-edge territory. And once we have something set, we can get past all the hand-wringing in the JS "community".
Right, but is there a high-level sketch somewhere?
There's the wiki, as David posted, but I don't think they reflect the current design. (I'm sure that the module loaders spec does not, anyway).
On Mon, Apr 8, 2013 at 10:15 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
On Mon, Apr 8, 2013 at 3:09 PM, Erik Arvidsson <erik.arvidsson at gmail.com> wrote:
We will have a final draft of ES6 by the end of the year.
Right, but is there a high-level sketch somewhere?
The March F2F presentation and meeting note are very thorough:
Notes: rwldrn/tc39-notes/blob/master/es6/2013-03/mar-12.md#42-modules
Slides (this will prompt to download a PDF) meetings:modules-march-2013.pdf
Use Case Worksheet: gist.github.com/wycats/51c96e3adcdb3a68cbc3
On Apr 8, 2013, at 7:15 AM, David Bruant wrote:
Le 08/04/2013 15:48, Anne van Kesteren a écrit :
On Mon, Apr 8, 2013 at 2:43 PM, Rick Waldron <waldron.rick at gmail.com> wrote:
On Mon, Apr 8, 2013 at 9:37 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
So modules have not yet landed in ES6, but are planned. I also heard they will have a pretty dramatic impact on APIs. When is TC39 planning to bring that discussion here? Can you be more specific? I'd need to have specifics first and they're not in the ES6 draft. I'll try to start with some point I have in mind, others will complete as necessary.
From what I know, there are 2 parts:
- module syntax [1]
- module loader API [2]
As far as 1) the "import" semantics part might need some attention in relation to URLs and how they are resolved (relative to the JS resource url? document url?). There is probably a need for some module name resolution binding to hook with the Fetch algorithm for cases like: import "www.mywebsite.com/myScript.js"
I don't think 2) will affect the platform; it's its own objects with their own semantics.
The browser platform will need to provide a default module loaders. It will be the responsibility of that loader to resolve module name strings as URLs, apply access policies, expose platform built-in modules, etc. The specification of this loader is going to have to be a collaborative effort between the browser and ECMAScript standards communities.
On Mon, Apr 8, 2013 at 4:23 PM, Rick Waldron <waldron.rick at gmail.com> wrote:
On Mon, Apr 8, 2013 at 10:15 AM, Anne van Kesteren <annevk at annevk.nl>wrote:
On Mon, Apr 8, 2013 at 3:09 PM, Erik Arvidsson <erik.arvidsson at gmail.com> wrote:
We will have a final draft of ES6 by the end of the year.
Right, but is there a high-level sketch somewhere?
The March F2F presentation and meeting note are very thorough:
Notes: rwldrn/tc39-notes/blob/master/es6/2013-03/mar-12.md#42-modules
Slides (this will prompt to download a PDF) meetings:modules-march-2013.pdf
Use Case Worksheet: gist.github.com/wycats/51c96e3adcdb3a68cbc3
Additionally, there's the old harmony draft: harmony:modules
On Mon, Apr 8, 2013 at 10:15 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
On Mon, Apr 8, 2013 at 3:09 PM, Erik Arvidsson <erik.arvidsson at gmail.com> wrote:
We will have a final draft of ES6 by the end of the year.
Right, but is there a high-level sketch somewhere?
The high-level sketch at harmony:modules is broadly correct. The details on some of the linked-to wiki pages, in particular the module loaders pipeline, is somewhat out of date. For more up-to-date info on those details, please see the material Rick linked to.
If you have specific questions, asking them here is probably best, or you can email specific people directly.
What in general are you thinking about for impact on other standards?
On Mon, Apr 8, 2013 at 11:26 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
What in general are you thinking about for impact on other standards?
I'm wondering how compatible the semantics are with what's going on today with e.g. <iframe> (considering the loader semantics). I'm
wondering how this will affect the definition of new platform APIs and new JavaScript APIs and what would be considered "idiomatic" given that this is completely different from anything we have today. And I'm wondering that if we segment all platform APIs in a say a hundred modules how many import statements the typical application will need to use.
Having modules makes a ton of sense, but bolting on modules to a large system that has none seems somewhat scary. Especially for it to be designed by a small group without much input from the rest of the system. I hope that makes sense.
Anne van Kesteren wrote:
I'm wondering how compatible the semantics are with what'sgoing on today with e.g.<iframe> (considering the loader semantics).
"Don't break the web" is our middle name -- er, names.
If there seems to be an incompatibility, it is a bug to fix.
On Tue, Apr 9, 2013 at 5:48 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
On Mon, Apr 8, 2013 at 11:26 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
What in general are you thinking about for impact on other standards?
Having modules makes a ton of sense, but bolting on modules to a large system that has none seems somewhat scary. Especially for it to be designed by a small group without much input from the rest of the system. I hope that makes sense.
First, I find this email very frustrating. Dave and I have been working on the current modules proposal since early 2010, and TC39 has been working on modules for ES6 longer than that. Modules were even in ES4 (RIP). We have done all this work in public, and there has been plenty of opportunity to comment. To the degree that there has not been much input (which I just don't think is true) this is ultimately the responsibility of people to provide input. This is a very late moment to be bringing up fundamental concerns.
Second, your email suggests the bringing modularity to JS programming is somehow optional. This is not the case. Even if we were to abandon our responsibility to help programmers better structure their JS programs, modularity has already come in the form of node modules, AMD modules, and many other systems. The web platform will need to deal with modules regardless of what TC39 does.
Now, on your specific concerns:
I'm wondering how compatible the semantics are with what's going on today with e.g. <iframe> (considering the loader semantics).
If you're thinking of sandboxed <iframe>s in particular, our hope is
that we can define this sort of behavior in terms of the loader API. This is the approach that Alex has been talking about for a while, and I think loaders give us much better facilities to do this for aspects of the web platform like <iframe>. And as Brendan said, if there are
any incompatibilities, that's a bug that will get fixed. We take backwards compatibility just as seriously as the rest of the platform.
I'm wondering how this will affect the definition of new platform APIs and new JavaScript APIs and what would be considered "idiomatic" given that this is completely different from anything we have today.
Obviously, existing platform APIs will need to stay as they are. New APIs will hopefully be made available as modules, so that ES6 programmers can use them that way. Of course, the module loader API provides a simple method to get objects that programmers can use without using any new syntax either.
And I'm wondering that if we segment all platform APIs in a say a hundred modules how many import statements the typical application will need to use.
Ultimately, how many modules the platform defines is up to the platform API designers. But node programs seem to work quite well with lots of small modules. If the platform has 100 different sets of APIs, then 100 modules seems reasonable. Presumably few files will need to import all of them.
On Tue, Apr 9, 2013 at 2:53 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
First, I find this email very frustrating. Dave and I have been working on the current modules proposal since early 2010, and TC39 has been working on modules for ES6 longer than that. Modules were even in ES4 (RIP). We have done all this work in public, and there has been plenty of opportunity to comment. To the degree that there has not been much input (which I just don't think is true) this is ultimately the responsibility of people to provide input. This is a very late moment to be bringing up fundamental concerns.
All I'm saying is that you cannot expect everyone at the W3C/WHATWG side to be paying attention to this. I know you want to, but I have not seen it happening. It seems to me there's not much of a problem with modules (apart from maybe some fetching specifics which I emailed separately about), but a little bit more coordination on www.w3.org/Search/Mail/Public/search?type-index=public-script-coord&index-type=t&keywords=module&search=Search&resultsperpage=50 would be good I think. Especially when it will effect long term how certain things are to be done. All I want here is more shared understanding.
Despite your frustration, I'm thankful for the replies.
Anne van Kesteren wrote:
On Tue, Apr 9, 2013 at 2:53 PM, Sam Tobin-Hochstadt<samth at ccs.neu.edu> wrote:
First, I find this email very frustrating. Dave and I have been working on the current modules proposal since early 2010, and TC39 has been working on modules for ES6 longer than that. Modules were even in ES4 (RIP). We have done all this work in public, and there has been plenty of opportunity to comment. To the degree that there has not been much input (which I just don't think is true) this is ultimately the responsibility of people to provide input. This is a very late moment to be bringing up fundamental concerns.
All I'm saying is that you cannot expect everyone at the W3C/WHATWG side to be paying attention to this.
You didn't say that, rather something about "bolting on... scary... small group... without input...." That wasn't particularly helpful, especially as the "small group" of designers is a virtue, and the "without input" is false. But moving right along:
I know you want to, but I have not seen it happening.
First, this cuts both ways. Do you really want to get into the times even in the modern era, even in the last three years, when a W3C/WHATWG (the two are diverging again) piece of spec-work was done without consulting with es-discuss or any such group, resulting in a less than ideal JS API? I am not going to throw that stone, it's not my point. I'm asking you to refrain as well.
Second, there is a list, public-script-coord at w3.org, cc'ed here, where this thread started, and which has existed all along, precisely to improve let's say "DOM"/"JS" coordination and API quality. We've used it from the es-discuss side. If it should have been used for something to do with modules, there's still time. Getting on with specifics beats back-biting about water under the bridge. Loaders can do a lot; thanks for your specific feedback on that API.
And third:
It seems to me there's not much of a problem with modules (apart from maybe some fetching specifics which I emailed separately about),
Well never mind then! :-|
What are we talking about, concretely? Implying that there was lack of input, or that Sam expected that "everyone" working on another big hunk of standards to pay attention, isn't helpful. People from the W3C/WHATWG side of the house have been participating. Two of your just-elected-to-W3C-TAG peers, Yehuda and Alex, are on TC39.
but a little bit more coordination on www.w3.org/Search/Mail/Public/search?type-index=public-script-coord&index-type=t&keywords=module&search=Search&resultsperpage=50 would be good I think. Especially when it will effect long term how certain things are to be done. All I want here is more shared understanding.
I believe you, but your "scary..." etc. words conveyed the opposite, frankly.
So things seem "ok", kind of -- judging from what you wrote here. Onward!
cc es-discuss
On Mon, Apr 8, 2013 at 9:37 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
Can you be more specific?
What are your concerns?