5 ms·

This doesn't seem like a complete list, what about modules? (I.E. import/export) which is (at least for me) the most interesting thing in es6 that needs to be i

This doesn't seem like a complete list, what about modules? (I.E. import/export) which is (at least for me) the most interesting thing in es6 that needs to be implemented in node.

k__ 11y ago
As far as I know only the module "syntax" is part of ES2015 (ES6). The rest isn't finished right now.
- stymaar 11y ago
  The syntax and semantic are both finalized. Wath's remain open is the browser's module loader specification (https://whatwg.github.io/loader/ https://whatwg.github.io/loader/).
eyko 11y ago
Modules were removed from the kangax test suite for reasons explained here: https://github.com/kangax/compat-table/issues/316 https://github.com/kangax/compat-table/issues/316
- Illniyar 11y ago
  I'm not sure I understand the reasons, is it mainly because the loader spec isn't finished yet?
Touche 11y ago
Why do you think it's important that they implement import/export? Node already has a module system that works well. Support import/export is much more important in Browsers which has no module system.
- ihsw 11y ago
  Because this one is superior. Why do we have cars if we can all walk just fine?
  - Touche 11y ago
    In what way is it superior?
    - edwinjm 11y ago
      For one, CommonJS doesn't work well in the browser.
      - tracker1 11y ago
        Browserify and Webpack bundling seems to work pretty well. I agree that getting ES6 modules in the browser will be nice, in the end, I see it working in practice a lot like it's implemented in Babel, to work with CJS modules.
  - overcast 11y ago
    To be fair, most people should not be owning/driving cars. Walking is completely reasonable in dense cities, and yet they persist.
- jnbiche 11y ago
  >Why do you think it's important that they implement import/export? For compatibility. Everyone is moving toward ES6 modules, so if you write your app in CommonJS now, you'll likely have to re-factor it into ES6 modules in the future. Not a deal-breaker, but it's certainly needed (and it sounds like Node devs are well aware of this).
  - Touche 11y ago
    I think you're mistaken, CommonJS is not going away, Node is not going to deprecate CommonJS modules, there is too much code that depends on it.
    - jnbiche 11y ago
      That's true, but more and more code will be written using es6 modules (since people want to write the same code on both the frontend and backend). But yes, you're correct that it will be years before CommonJS is removed, if ever. Although I could see it being tagged as deprecated in the next few years. I personally would have been totally fine with CommonJS on the frontend, as a longtime browserify user. Almost wish that had happened simply to avoid the transition to another module system for the Node ecosystem. But es6 modules do have certain advantages for the frontend, like making tree-shaking easy.
      - kalms 11y ago
        Tree shaking?
        jnbiche 11y ago
        Dead code elimination (more or less). Important for making browser JavaScript as small as possible.
        colordrops 11y ago
        Static analysis to exclude unused imports in a bundle.
- jahewson 11y ago
  Node's module system has numerous drawbacks. It's a clever hack but having a native module system with proper imports and exports, and which is amenable to static analysis is a huge improvement. It's probably been the biggest productivity boon for me of any of the ES6 features.
- Kequc 11y ago
  Typescript treats import and export as first class citizens. When using it in my scripts it pulls in not only the module but also typings for that module as well. Of course; Typescript compiles in such a way that Node understands what was intended, it would be nice to compile to ES6 directly. Typescript is ES6 with types. A small change, essentially ignoring types, would require so little processing that it could probably be done live as if it were reading pure ES6. I think that's within the realm of possibility but would require Node to understand ES6 in its entirety.
z3t4 11y ago
There's a huge philosophical difference between require and import/include. The main technical difference is that require is scoped! Philosophically require is a object. While import is a bunch of code. The Node community deliberately do not want code includes. We want you to make reusable modules instead. Copy all your include files and the include files of your include files into one file. Then you will also see the problem.
- Illniyar 11y ago
  Once the browsers (and therefor v8) will implement the module and loader specs, node.js will have import/exports. Comparability with javascript (and browsers) is more important then the community's dislike of imports (if there is such a thing), so I'm not sure if that is relevant here.

This doesn't seem like a complete list, what about modules? (I.E. import/export) which is (at least for me) the most interesting thing in es6 that needs to be implemented in node.

k__ 11y ago

As far as I know only the module "syntax" is part of ES2015 (ES6). The rest isn't finished right now.

stymaar 11y ago
The syntax and semantic are both finalized. Wath's remain open is the browser's module loader specification (https://whatwg.github.io/loader/ https://whatwg.github.io/loader/).

eyko 11y ago

Modules were removed from the kangax test suite for reasons explained here: https://github.com/kangax/compat-table/issues/316 https://github.com/kangax/compat-table/issues/316

Illniyar 11y ago
I'm not sure I understand the reasons, is it mainly because the loader spec isn't finished yet?

Touche 11y ago

Why do you think it's important that they implement import/export? Node already has a module system that works well. Support import/export is much more important in Browsers which has no module system.

ihsw 11y ago
Because this one is superior. Why do we have cars if we can all walk just fine?
- Touche 11y ago
  In what way is it superior?
  - edwinjm 11y ago
    For one, CommonJS doesn't work well in the browser.
    - tracker1 11y ago
      Browserify and Webpack bundling seems to work pretty well. I agree that getting ES6 modules in the browser will be nice, in the end, I see it working in practice a lot like it's implemented in Babel, to work with CJS modules.
- overcast 11y ago
  To be fair, most people should not be owning/driving cars. Walking is completely reasonable in dense cities, and yet they persist.
jnbiche 11y ago
>Why do you think it's important that they implement import/export? For compatibility. Everyone is moving toward ES6 modules, so if you write your app in CommonJS now, you'll likely have to re-factor it into ES6 modules in the future. Not a deal-breaker, but it's certainly needed (and it sounds like Node devs are well aware of this).
- Touche 11y ago
  I think you're mistaken, CommonJS is not going away, Node is not going to deprecate CommonJS modules, there is too much code that depends on it.
  - jnbiche 11y ago
    That's true, but more and more code will be written using es6 modules (since people want to write the same code on both the frontend and backend). But yes, you're correct that it will be years before CommonJS is removed, if ever. Although I could see it being tagged as deprecated in the next few years. I personally would have been totally fine with CommonJS on the frontend, as a longtime browserify user. Almost wish that had happened simply to avoid the transition to another module system for the Node ecosystem. But es6 modules do have certain advantages for the frontend, like making tree-shaking easy.
    - kalms 11y ago
      Tree shaking?
      - jnbiche 11y ago
        Dead code elimination (more or less). Important for making browser JavaScript as small as possible.
      - colordrops 11y ago
        Static analysis to exclude unused imports in a bundle.
jahewson 11y ago
Node's module system has numerous drawbacks. It's a clever hack but having a native module system with proper imports and exports, and which is amenable to static analysis is a huge improvement. It's probably been the biggest productivity boon for me of any of the ES6 features.
Kequc 11y ago
Typescript treats import and export as first class citizens. When using it in my scripts it pulls in not only the module but also typings for that module as well. Of course; Typescript compiles in such a way that Node understands what was intended, it would be nice to compile to ES6 directly. Typescript is ES6 with types. A small change, essentially ignoring types, would require so little processing that it could probably be done live as if it were reading pure ES6. I think that's within the realm of possibility but would require Node to understand ES6 in its entirety.

z3t4 11y ago

There's a huge philosophical difference between require and import/include. The main technical difference is that require is scoped! Philosophically require is a object. While import is a bunch of code. The Node community deliberately do not want code includes. We want you to make reusable modules instead. Copy all your include files and the include files of your include files into one file. Then you will also see the problem.

Illniyar 11y ago
Once the browsers (and therefor v8) will implement the module and loader specs, node.js will have import/exports. Comparability with javascript (and browsers) is more important then the community's dislike of imports (if there is such a thing), so I'm not sure if that is relevant here.