4 ms·

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

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)

notduncansmith 12y ago
> 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.
- Touche 12y ago
  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.
  - domenicd 12y ago
    This is a common strawman, with several examples to disprove it: - https://github.com/cujojs/curl https://github.com/cujojs/curl - https://github.com/montagejs/mr https://github.com/montagejs/mr - https://github.com/substack/wreq https://github.com/substack/wreq
    - Touche 12y ago
      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.
cwmma 12y ago
> 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.
nawitus 12y ago
The ES6 module system could still use ES6 inspired syntax. (Or even TypeScript's syntax, e.g. import x = require("x");).

notduncansmith 12y ago

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

Touche 12y ago
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.
- domenicd 12y ago
  This is a common strawman, with several examples to disprove it: - https://github.com/cujojs/curl https://github.com/cujojs/curl - https://github.com/montagejs/mr https://github.com/montagejs/mr - https://github.com/substack/wreq https://github.com/substack/wreq
  - Touche 12y ago
    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.

cwmma 12y ago

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

nawitus 12y ago

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