Hacker News Reader

Comment by jonpaul | Hacker News Reader

The problem with introducing new keywords and doing this in a backwards incompatible way, is that we'll be running with three module systems for years: CommonJS, AMD, and ES6. As far as I can tell, and please correct me if I'm wrong, it looks like ES6 modules aren't solving any new problem that CommonJS did not solve. Browserify does an excellent job of bringing CommonJS to the browser and it's gaining a lot of momentum. With ES6 now pushed back until June 2015... I'm not sure what to think anymore.

View on HN

It adds a lot of stuff, and I think this site is going to add more explanation about that. I'm not fully qualified to go into everything, but off the top of my head:

* The dependencies are static, so you can't do stuff like `if(Math.random() < .5) { require('foo') } else { require('bar') }`. That is a good thing. A lot of people at this point agree that a statically analyzable dependency graph is a huge win.

* Bindings are truly exported. If you exported `const foo = 5`, imported it in another module, and tried to change it, you would get a static error. Semantics and identity of bindings carry over. This also means they are mutable; if the module exporting `foo` changes it everyone else will see it too.

* A fleshed out module loader API, which is seriously lacking in node

There are other advantages too. The simplistic approach of CommonJS works, but long-term it's not the best solution for the wide use-cases of JavaScript.

EDIT: and this will be backwards-compatible. I don't know all the details but this can be implemented in a browser today without breaking things (I know people on the teams working on this)

> The simplistic approach of CommonJS works, but long-term it's not the best solution for the wide use-cases of JavaScript.

Could you elaborate on this point a little more? I've worked on Node.js projects varying greatly in size, and even on the larger ones I've yet to feel encumbered the CommonJS module system.

By "wide use-cases" he means the Web and server. CJS doesn't work well on the web. ES6 modules were designed from the start to support both.

This is a common strawman, with several examples to disprove it:

- https://github.com/cujojs/curl - https://github.com/montagejs/mr - https://github.com/substack/wreq

to support CommonJS in the browser you either 1) require that it is wrapped (and therefore isn't really CommonJS) or 2) you XHR it, wrap it yourself, and eval. That's it's possible to work around the problem doesn't discount that it "doesn't work well" in browsers.

The ES6 module system could still use ES6 inspired syntax. (Or even TypeScript's syntax, e.g. import x = require("x");).

> The dependencies are static, so you can't do stuff like `if(Math.random() < .5) { require('foo') } else { require('bar') }`. That is a good thing. A lot of people at this point agree that a statically analyzable dependency graph is a huge win.

yeah but the 80% solution of loading them both statically but only executing them when the require is run works ridiculously well in practice.

ES6 modules are actually a nice combination of the asynchronicity of AMD (really required in a browser) and the code clarity of commonJS, so it's not really the case that it's not solving anything that commonJS doesn't solve. It also deals with circular dependencies better than CommonJS.

On top of that, module loaders provide hooks, so it's quite possible to use a module loader (e.g. System.JS) that can load commonjs or amd modules.

Browserify is brilliant, and if I couldn't use es6 I'd be using it, but I'm pretty excited about es6 modules.

Won't people use a pre-processor for ES6 modules, like they do for CommonJS and AMD? Otherwise, it'd be a lot of HTTP requests. So you wouldn't have to wait for browser support to start using ES6 modules.

And Node?

Probably. This is indeed how I see most es6 development going for a while, but many servers already support SPDY which allows the server to push things into the clients cache that it knows they will need. This basically removes the need for bundling, while keeping the advantages of separate files.

This. I can't imagine, except maybe in a development mode, where I would want all of these different modules loading at different times especially if they're loading later rather than referencing the script in the HTML's HEAD.

I'm sort of assuming it can be ignored for now. Like you said, it doesn't add anything, but also doesn't preclude anything that we can do today, so it seems like a wash.

Check out webpack

Reply on news.ycombinator.com