samth at ccs.neu.edu
Tue Apr 9 06:53:32 PDT 2013
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.
> wondering how this will affect the definition of new platform APIs and
> 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.
More information about the es-discuss