Karolis Narkevičius karolis.n at
Mon Jun 30 12:59:25 PDT 2014

It's not just about interoperability. It's also about enabling the pattern
that proved itself to work quite well - module as a function, module as a
class, module as a function with named exports attached in one "namespace".

I suppose if that pattern is not explicitly supported it might be just fine
since perhaps we'll discover better patterns. And if not, we'll be able to
just always use 1 named export and do

import {fs} from "fs";
import {moment} from "moment";
import {$} from "jquery";
// etc.

In fact, doesn't being able to import things like above make es6 modules
already interoperable with CJS?

On Mon, Jun 30, 2014 at 8:00 PM, Kevin Smith <zenparsing at> wrote:

>> What's not clear is the advantage of module bindings form for modules.
>>  When the world of possibilities opens up, what specific things will I see
>> there?
> I think I'm following you now.  So let's pose the question like this:
> Let's posit that there are no default export or import forms, otherwise
> the current *syntax* is the same.  Now, we have two semantic options that
> we can attach to that syntax:
> 1.  Modules are just regular objects with getters.  The import
> declarations just get properties from those objects at runtime.
> 2.  Modules are a collection of named bindings.  Those bindings are
> resolved at compile-time.
> Now, since the syntax is the same, our ability to do offline static
> analysis is the same.  So what are the differences between these two
> semantics?
> (All of this has been gone over before, of course...)
> Advantages of 1:
> - None?
> Advantages of 2:
> - Good support for circular dependencies
> - Mutable bindings
> - Compile-time optimizations for "module.member" expressions
> The advantage of 1 only appears if we allow module object overwriting.
>  Those advantages are:
> - Auto-renaming the import (questionable)
> - Smoother interoperability with CommonJS modules.
> On the other hand, module object overwriting disables our ability to do
> offline static analysis.
> So I think the only forceful argument if favor of option 1 (i.e. modules
> are regular objects with getters) is interoperability, and only if we allow
> export overwriting.
> The interoperability question is therefore of central importance.
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list