ModuleImport

Jussi Kalliokoski jussi.kalliokoski at gmail.com
Wed Jul 2 15:11:36 PDT 2014


On Wed, Jul 2, 2014 at 3:38 PM, Kevin Smith <zenparsing at gmail.com> wrote:

>
>> 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."
>

FWIW, I don't have a problem with dropping / deferring default exports,
although my personal ideal is that like functions, modules should do one
thing and thus export one thing, but having no default exports doesn't
prevent exporting just one thing.


>
> 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.
>

The complexity is in having multiple different ways of doing one thing and
introducing new kind of bindings to the language that didn't exist before
to support those edge cases.


>
>
>> 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.
>

Happy to hear!


>
>> * 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.
>

But depending on how you load the modules (i.e. syntax or Loader API) the
module might end up being an object anyway so it's just confusing if it
sometimes is and sometimes isn't.


> 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.
>

The term "module meta object" and simple design don't go hand in hand.


> That API needs eyes, BTW.
>

Thanks for the reference, I'll take a look at it after having a good
night's sleep first. :)


>
>
>> 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?
>

No of course not, but why would anyone introduce more complexity to their
project to do what you did? Experimental curiosity is probably your case,
but the only other reason I can think of is sadism, deliberately
fragmenting the platform. In that example, you're using two module systems
at the same time for exactly zero benefit.

Now, we can take the stance that node is a market that we don't need to
penetrate, but that is a potentially dangerous stance to take, since the
trend and interest in using the same code on the server and the client
seems to just keep climbing, we risk making things like browserify the path
of least resistance to that goal, since for a not-very-insignificant period
people will have to use transpilers for ES6 modules as well.

- Jussi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140703/d4a0f0c3/attachment-0001.html>


More information about the es-discuss mailing list