bruant.d at gmail.com
Mon Apr 8 07:15:01 PDT 2013
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
From what I know, there are 2 parts:
1) module syntax 
2) module loader API 
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:
I don't think 2) will affect the platform; it's its own objects with
their own semantics.
>> 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.
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?
More information about the es-discuss