> > > 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?
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
