zenparsing at gmail.com
Wed Jul 2 05:38:56 PDT 2014
> 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
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".
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss