top | item 11180283

Node 5.7.0 (stable) released

161 points| 56k | 10 years ago |nodejs.org

46 comments

order
[+] TheAceOfHearts|10 years ago|reply
One of the performance improvements [0] is pretty crazy! Up to an 18,000% performance increase.

[0] https://github.com/nodejs/node/pull/5123

[+] kenOfYugen|10 years ago|reply
Great news! Node.js could greatly benefit from more reimplementations of its native modules. I had implemented the `fs.readdir` module in C and saw some good performance gains (it was a hackish experiment I did some time ago and can't remember numbers).

The `http` module is said to be outperformed by `eshttp` [1] by a factor of 2 times, which is written in pure JavaScript.

There is also `node-lwan` [2], an experiment in using `lwan` [3] in place of the built in `http` module. Since its the most performant web server in JSON serialization, according to techempower.com benchmarks [4], performance gains are to be expected.

[1] https://github.com/iefserge/eshttp [2] https://github.com/raadad/node-lwan [3] http://lwan.ws/ [4] https://www.techempower.com/benchmarks/#section=data-r12&hw=...

[+] glossyscr|10 years ago|reply
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|10 years ago|reply
It is amazing isn't it? I'm so happy I switched. I love this community and the things they are doing.
[+] romanovcode|10 years ago|reply
Still waiting for async/await. Also doing multi-precision numbers by default would be nice.
[+] alfonsodev|10 years ago|reply
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?

Is there any other way to get async/await today ?

[+] aikah|10 years ago|reply
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.

[+] secoif|10 years ago|reply
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 2. V8 needs to implement: 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 4. Also Node API needs to become promises-compatible, which is god-knows how long away: https://github.com/nodejs/promises
[+] pluma|10 years ago|reply
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

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

[+] cwmma|10 years ago|reply
Multi precision numbers are going to be a long wait
[+] oweiler|10 years ago|reply
It will probably take years for async/await to become part of Node.
[+] hakcermani|10 years ago|reply
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.
[+] audessuscest|10 years ago|reply
> 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|10 years ago|reply
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.

[+] joshmanders|10 years ago|reply
> 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.

[+] s_kilk|10 years ago|reply
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.