5 ms·

Node 5.7.0 (stable) released

161 points by 56k 11y ago

romanovcode 11y ago
Still waiting for async/await. Also doing multi-precision numbers by default would be nice.
- oweiler 11y ago
  It will probably take years for async/await to become part of Node.
- ChrisAntaki 11y ago
  I would love an async/await feature. Though generators have been added, and they are currently optimization killers in V8: https://github.com/petkaantonov/bluebird/wiki/Optimization-killers https://github.com/petkaantonov/bluebird/wiki/Optimization-k...
  - igl 11y ago
    That's always the case for new language features. ES5 stuff was slow in the beginning and it took a while for v8 to catch up. This shouldn't be a reason for not using these new features. This article is also years old. While it seems to be updated recently I wonder how accurate it still is.
- pluma 11y ago
  async/await isn't part of any standard yet. It's a stage 3 proposal at this time, which means it may not even land in ES 2016: https://github.com/tc39/ecma262 https://github.com/tc39/ecma262 The last thing we want is native support for pre-standard features. As long as it's not in a spec (or draft at least), it's sci-fi. Besides, node doesn't implement language features, V8 does. Here's the relevant issue: https://bugs.chromium.org/p/v8/issues/detail?id=4483 https://bugs.chromium.org/p/v8/issues/detail?id=4483
  - _dominic 11y ago
    ES2016 is already finished, it only has array.includes and the exponentiation operator[0]. We'll have to wait for ES2017 at the earliest for async to arrive. [0]http://www.2ality.com/2016/01/ecmascript-2016.html http://www.2ality.com/2016/01/ecmascript-2016.html
    - pluma 11y ago
      Thanks for pointing that out. I haven't been following the releases that closely. But it's good to see that after the kitchen sink nature of ES2015 the yearly releases following it are a lot more incremental than revolutionary.
- aikah 11y ago
  async/await is not in the ECMA spec. It a proposal, like Object.observe(which was discarded) And remember one thing, Nodejs maintainers DO NOT control V8, the javascript engine powering it, they are entirely dependent on what the V8 team at Google does. So you'll have to wait a long time and even so there is absolutely no guarantee async/away will ever make it to the spec. Same deal for decorators, developers shouldn't depend on non ECMA features. Even worse, the final proposal might be totally different from the current Babel/whatever implementation. V8 doesn't even implement 100% of ES6, yet.
  - vdaniuk 11y ago
    Microsoft's Chakra engine is available as an alternative backend for node (windows only at the moment) and has native support of async/await. https://github.com/nodejs/node-chakracore https://github.com/nodejs/node-chakracore
    - iends 11y ago
      Does it still only run on Windows?
      - vdaniuk 11y ago
        AFAIK linux and mac release is coming later this year and even then it won't have JIT support.
      - hiteshk_msft 11y ago
        For now. The Linux branch of ChakraCore is under active development. Disclaimer: working at Msft on ChakraCore
  - ilkkao 11y ago
    Stage 4 requires two working implementations. V8 could be the second one. No feature can reach stage 4 if it would be this strict as you describe.
- secoif 11y ago
  Yeah this is a long way off and lots of things need to happen before node can even consider this… 1. TC39 needs to get async functions to stage 4: https://github.com/tc39/ecma262/blob/master/README.md https://github.com/tc39/ecma262/blob/master/README.md 2. V8 needs to implement: https://github.com/nodejs/promises/issues/4 https://github.com/nodejs/promises/issues/4 3. Node then needs to use this updated V8, and to be able to use this reliably, this V8 will need to reach an LTS release: https://github.com/nodejs/LTS/blob/master/schedule.png https://github.com/nodejs/LTS/blob/master/schedule.png 4. Also Node API needs to become promises-compatible, which is god-knows how long away: https://github.com/nodejs/promises https://github.com/nodejs/promises
- alfonsodev 11y ago
  I started to use async/await because react-native and now I can't live without it. In nodejs you can have it: npm install --save babel-core babel-loader babel-polyfill babel-preset-es2015 babel-preset-stage-0 Adding this to entry point file require("babel-core/register"); require("babel-polyfill"); and having a .babelrc with these presets: { "presets": ["es2015", "stage-0"] } Then you can transpile with babel-cli ( sudo npm install -g babel-cli if you don't have it yet) babel app.js -o transpiled_app.js Make sure you have npm version 3, or it become too slow to initialise. as @vdaniuk mention Chackra supports it, but did anyone tried this https://github.com/nodejs/node-chakracore https://github.com/nodejs/node-chakracore? Is there any other way to get async/await today ?
  - esailija 11y ago
    coroutines with generators are more powerful (cancellation, automatic resource cleanup when the generator terminates etc) and have worked for a long time out of the box. The only difference is that you write `yield` instead of `await` and `decorator(function*` instead of `async function`
    - phpnode 11y ago
      Babel can transform async functions into Bluebird coroutines, so the best of both worlds - https://www.npmjs.com/package/babel-plugin-transform-async-to-module-method https://www.npmjs.com/package/babel-plugin-transform-async-t...
      - esailija 11y ago
        Yes but with this you lose the powerful features I just mentioned: automatic resource cleanup[1], cancellation, yield handlers.. don't you? 1. https://github.com/petkaantonov/bluebird/issues/1014 https://github.com/petkaantonov/bluebird/issues/1014
        phpnode 11y ago
        No I think those should work with async functions as it is literally just translating `async` -> `yield`, but worth investigating.
- cwmma 11y ago
  Multi precision numbers are going to be a long wait
- hakcermani 11y ago
  If you are eager to start using it look at Typescript 1.7 - which transpiles to ES6. I have started trying it out on a side project.
TheAceOfHearts 11y ago
One of the performance improvements [0] is pretty crazy! Up to an 18,000% performance increase. [0] https://github.com/nodejs/node/pull/5123 https://github.com/nodejs/node/pull/5123
- btd 11y ago
  Yes, but it breaks some cases. I'd recommend to wait 5.7.1 (https://github.com/nodejs/node/issues/5400 https://github.com/nodejs/node/issues/5400)
  - amelius 11y ago
    Probably an ignorant question but this makes me wonder: how can they release when their tests don't pass?
    - johnchristopher 11y ago
      Break early, break often :-).
    - k__ 11y ago
      Maybe psychology... People won't use x.y.0 so they build in a bug to push to x.y.1 afterwards
    - mc808 11y ago
      I haven't been following, but it looks like the tests were passing and they just didn't have tests to prevent these issues that came up.
  - samcheng 11y ago
    This is exactly why I've stayed away from this stack wherever possible!
    - jzwinck 11y ago
      I hope you stay away from GCC as well, which for example broke C++ in 4.7.0 and fixed it in 4.7.2. Any new major release is bound to break something for someone. Prudence suggests adopting a major release only after a few months. This applies to all platforms.
glossyscr 11y ago
I am happy that there is Node. I'm still mind blown every single day about the Node community—for me it's the fastest evolving dev ecosystem which is at the same time high performant and robust.
- joshmanders 11y ago
  It is amazing isn't it? I'm so happy I switched. I love this community and the things they are doing.
audessuscest 11y ago
> child_process: spawn() and spawnSync() now support a 'shell' option to allow for optional execution of the given command inside a shell. If set to true, cmd.exe will be used on Windows and /bin/sh elsewhere. A path to a custom shell can also be passed to override these defaults. On Windows, this option allows .bat. and .cmd files to be executed with spawn() and spawnSync(). (Colin Ihrig) #4598 Does this mean that it can now open a real shell (like iTerm) and execute a script ? or I misunderstood ?
- jamescun 11y ago
  Sadly not. When calling spawn[Sync]() in prior versions the command would be executed directly as a child of the node process. If you wanted to use any features like piping, automatic environment variable interpolation or backgrounding etc; you had to manually wrap your command with a system shell like bash(sh). This addition when set to true, will do the wrapping for you in a cross-platform manor.
  - audessuscest 11y ago
    Thanks for the clarification
- s_kilk 11y ago
  This actually works even today: child_process.exec('open -a Terminal.app') I'm pretty sure you can pass a script arg to the application too, but I haven't done it in a while.
- joshmanders 11y ago
  > Does this mean that it can now open a real shell (like iTerm) iTerm is not a shell. bash, zsh, fish, etc are shells. iTerm is a terminal program that opens a shell.

161 points by 56k 11y ago

romanovcode 11y ago

Still waiting for async/await. Also doing multi-precision numbers by default would be nice.

oweiler 11y ago
It will probably take years for async/await to become part of Node.
ChrisAntaki 11y ago
I would love an async/await feature. Though generators have been added, and they are currently optimization killers in V8: https://github.com/petkaantonov/bluebird/wiki/Optimization-killers https://github.com/petkaantonov/bluebird/wiki/Optimization-k...
- igl 11y ago
  That's always the case for new language features. ES5 stuff was slow in the beginning and it took a while for v8 to catch up. This shouldn't be a reason for not using these new features. This article is also years old. While it seems to be updated recently I wonder how accurate it still is.
pluma 11y ago
async/await isn't part of any standard yet. It's a stage 3 proposal at this time, which means it may not even land in ES 2016: https://github.com/tc39/ecma262 https://github.com/tc39/ecma262 The last thing we want is native support for pre-standard features. As long as it's not in a spec (or draft at least), it's sci-fi. Besides, node doesn't implement language features, V8 does. Here's the relevant issue: https://bugs.chromium.org/p/v8/issues/detail?id=4483 https://bugs.chromium.org/p/v8/issues/detail?id=4483
- _dominic 11y ago
  ES2016 is already finished, it only has array.includes and the exponentiation operator[0]. We'll have to wait for ES2017 at the earliest for async to arrive. [0]http://www.2ality.com/2016/01/ecmascript-2016.html http://www.2ality.com/2016/01/ecmascript-2016.html
  - pluma 11y ago
    Thanks for pointing that out. I haven't been following the releases that closely. But it's good to see that after the kitchen sink nature of ES2015 the yearly releases following it are a lot more incremental than revolutionary.
aikah 11y ago
async/await is not in the ECMA spec. It a proposal, like Object.observe(which was discarded) And remember one thing, Nodejs maintainers DO NOT control V8, the javascript engine powering it, they are entirely dependent on what the V8 team at Google does. So you'll have to wait a long time and even so there is absolutely no guarantee async/away will ever make it to the spec. Same deal for decorators, developers shouldn't depend on non ECMA features. Even worse, the final proposal might be totally different from the current Babel/whatever implementation. V8 doesn't even implement 100% of ES6, yet.
- vdaniuk 11y ago
  Microsoft's Chakra engine is available as an alternative backend for node (windows only at the moment) and has native support of async/await. https://github.com/nodejs/node-chakracore https://github.com/nodejs/node-chakracore
  - iends 11y ago
    Does it still only run on Windows?
    - vdaniuk 11y ago
      AFAIK linux and mac release is coming later this year and even then it won't have JIT support.
    - hiteshk_msft 11y ago
      For now. The Linux branch of ChakraCore is under active development. Disclaimer: working at Msft on ChakraCore
- ilkkao 11y ago
  Stage 4 requires two working implementations. V8 could be the second one. No feature can reach stage 4 if it would be this strict as you describe.
secoif 11y ago
Yeah this is a long way off and lots of things need to happen before node can even consider this… 1. TC39 needs to get async functions to stage 4: https://github.com/tc39/ecma262/blob/master/README.md https://github.com/tc39/ecma262/blob/master/README.md 2. V8 needs to implement: https://github.com/nodejs/promises/issues/4 https://github.com/nodejs/promises/issues/4 3. Node then needs to use this updated V8, and to be able to use this reliably, this V8 will need to reach an LTS release: https://github.com/nodejs/LTS/blob/master/schedule.png https://github.com/nodejs/LTS/blob/master/schedule.png 4. Also Node API needs to become promises-compatible, which is god-knows how long away: https://github.com/nodejs/promises https://github.com/nodejs/promises
alfonsodev 11y ago
I started to use async/await because react-native and now I can't live without it. In nodejs you can have it: npm install --save babel-core babel-loader babel-polyfill babel-preset-es2015 babel-preset-stage-0 Adding this to entry point file require("babel-core/register"); require("babel-polyfill"); and having a .babelrc with these presets: { "presets": ["es2015", "stage-0"] } Then you can transpile with babel-cli ( sudo npm install -g babel-cli if you don't have it yet) babel app.js -o transpiled_app.js Make sure you have npm version 3, or it become too slow to initialise. as @vdaniuk mention Chackra supports it, but did anyone tried this https://github.com/nodejs/node-chakracore https://github.com/nodejs/node-chakracore? Is there any other way to get async/await today ?
- esailija 11y ago
  coroutines with generators are more powerful (cancellation, automatic resource cleanup when the generator terminates etc) and have worked for a long time out of the box. The only difference is that you write `yield` instead of `await` and `decorator(function*` instead of `async function`
  - phpnode 11y ago
    Babel can transform async functions into Bluebird coroutines, so the best of both worlds - https://www.npmjs.com/package/babel-plugin-transform-async-to-module-method https://www.npmjs.com/package/babel-plugin-transform-async-t...
    - esailija 11y ago
      Yes but with this you lose the powerful features I just mentioned: automatic resource cleanup[1], cancellation, yield handlers.. don't you? 1. https://github.com/petkaantonov/bluebird/issues/1014 https://github.com/petkaantonov/bluebird/issues/1014
      - phpnode 11y ago
        No I think those should work with async functions as it is literally just translating `async` -> `yield`, but worth investigating.
cwmma 11y ago
Multi precision numbers are going to be a long wait
hakcermani 11y ago
If you are eager to start using it look at Typescript 1.7 - which transpiles to ES6. I have started trying it out on a side project.

TheAceOfHearts 11y ago

One of the performance improvements [0] is pretty crazy! Up to an 18,000% performance increase. [0] https://github.com/nodejs/node/pull/5123 https://github.com/nodejs/node/pull/5123

btd 11y ago
Yes, but it breaks some cases. I'd recommend to wait 5.7.1 (https://github.com/nodejs/node/issues/5400 https://github.com/nodejs/node/issues/5400)
- amelius 11y ago
  Probably an ignorant question but this makes me wonder: how can they release when their tests don't pass?
  - johnchristopher 11y ago
    Break early, break often :-).
  - k__ 11y ago
    Maybe psychology... People won't use x.y.0 so they build in a bug to push to x.y.1 afterwards
  - mc808 11y ago
    I haven't been following, but it looks like the tests were passing and they just didn't have tests to prevent these issues that came up.
- samcheng 11y ago
  This is exactly why I've stayed away from this stack wherever possible!
  - jzwinck 11y ago
    I hope you stay away from GCC as well, which for example broke C++ in 4.7.0 and fixed it in 4.7.2. Any new major release is bound to break something for someone. Prudence suggests adopting a major release only after a few months. This applies to all platforms.

glossyscr 11y ago

I am happy that there is Node. I'm still mind blown every single day about the Node community—for me it's the fastest evolving dev ecosystem which is at the same time high performant and robust.

joshmanders 11y ago
It is amazing isn't it? I'm so happy I switched. I love this community and the things they are doing.

audessuscest 11y ago

> child_process: spawn() and spawnSync() now support a 'shell' option to allow for optional execution of the given command inside a shell. If set to true, cmd.exe will be used on Windows and /bin/sh elsewhere. A path to a custom shell can also be passed to override these defaults. On Windows, this option allows .bat. and .cmd files to be executed with spawn() and spawnSync(). (Colin Ihrig) #4598 Does this mean that it can now open a real shell (like iTerm) and execute a script ? or I misunderstood ?

jamescun 11y ago
Sadly not. When calling spawn[Sync]() in prior versions the command would be executed directly as a child of the node process. If you wanted to use any features like piping, automatic environment variable interpolation or backgrounding etc; you had to manually wrap your command with a system shell like bash(sh). This addition when set to true, will do the wrapping for you in a cross-platform manor.
- audessuscest 11y ago
  Thanks for the clarification
s_kilk 11y ago
This actually works even today: child_process.exec('open -a Terminal.app') I'm pretty sure you can pass a script arg to the application too, but I haven't done it in a while.
joshmanders 11y ago
> Does this mean that it can now open a real shell (like iTerm) iTerm is not a shell. bash, zsh, fish, etc are shells. iTerm is a terminal program that opens a shell.