ModuleImport

[Kevin Smith]

>
>
> But it's neither simple nor solid. It's overtly complicated to support
> features that shouldn't be there.
>

I have to disagree here.  If we drop default imports, then we can describe
the module system like this:

"Variables can be exported by name.  Variables can be imported by name."

It doesn't get any more simple than that.  What I mean by solid is that it
has good coverage of the edge cases, meaning primarily cyclic dependencies.


> Sorry in advance for the tone of this message, it is quite negative.
>

I didn't perceive this as negative.  I think it's quite constructive to
uncover all of the arguments.


> * Massive amount of existing modules.
> * Existing large-scale user-bases.
>

We've already taken a look at the technical side of interoperability with
old-style modules, and there's no problem there.  What remains, I suppose,
is a sociological argument.  More on that later.


> * Node has stated that the core will always be CommonJS, meaning that on
> node, in order to use ES6 modules, you'll have to be using two different
> module systems which doesn't sound like a thing that people would do unless
> there's proven benefits.
>

If users want Node core to be exposed as ES6 modules, then the Node
developers will provide it.  It's not some ideological battle - it's about
whatever is good for the platform.  Regarding two module systems at the
same time: more later.

* Completely dynamic. Now, I know there are people that think that this
> isn't not good, but it is. It gives you a lot of power when debugging
> things or playing around with new things (something I haven't seen
> discussed re:modules on this list). One of the greatest things in JS is
> that instead of reading the usually poor documentation, let alone the code,
> of something you want to use you can just load it up in node or the
> developer tools and play around with it. With node, you require() something
> in the repl and you see immediately what it exports. (...edit...) This is
> simply not possible with ES6 modules without a massive boilerplate
> spaghetti with async stuff.
>

You're right, but I don't think we need "objects-as-modules" to address
this.  We want a blocking load API for these situations:

1.  Any REPL  (strong)
2.  Server-only programs which don't care about async loading and don't
want the complications (weaker)

In es6now, I provide a `loadModule` function for loading "ES6" modules
synchronously in the REPL.  I think Node would want to provide a
synchronous loading method as part of the so-called module meta object.
 That API needs eyes, BTW.


> Given all this, how are we supposed to convince people to use this stuff?
> These concerns are not something that can be fixed later either, they're
> fundamental to the current design.
>

I don't see any technical problem here.  So let's look at the sociological
argument:

ES6 modules are different from Node/AMD modules, and seem to be at odds
philosophically.  Since Node/AMD modules already have established user
bases, and important members of the Node community are critical, ES6
modules won't be successful at penetrating the "market".

Counter-argument:

Take a look at this package:  https://github.com/zenparsing/zen-sh . It's
an experimental ES6 package which allows you to open up a shell and execute
commands using tagged template strings.  I use it at work to automate git
tasks.  It's awesome (but very rough).  It's completely installable using
NPM, today.  I encourage anyone to try it out (you'll need to install es6now
<https://github.com/zenparsing/es6now> first, though).

It exports a single thing, but that thing is given a name.  It is set up to
work with both `require` and `import`.

Now, the sociological argument says that because it's written as an ES6
module the community will reject this package.  Does that sound plausible
to you?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140702/1cb7b3b4/attachment.html>