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.
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.
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.
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.
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`
Thanks for commenting on that, I didn't think about those issues. I'll research on how much impact could have on performance.
In the other hand I believe syntax is not the only difference. I'm not full time js dev, but after a quick search, I found Domenic pointing 4 differences here https://esdiscuss.org/topic/does-async-await-solve-a-real-pr...
These seem to be mostly about undecorated generators. 3. Is a legit difference but it is actually a syntax error to do yield 1 + yield 2. So that is fixable in a backward compatible way.
Worth considering the es2015-node5 preset instead. It will only transpile the features that are not already in node 5.x. The standard es2015 preset transpiles lots of APIs that are already natively available in node 5.
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.
This is not true. Some platforms, such as Clojure, are usually very stable once released, and there is rarely the need for point releases, as the code was stabilized during the alpha/rc periods.
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.
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.
> 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 ?
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.
46 comments
[ 3.8 ms ] story [ 108 ms ] threadThis article is also years old. While it seems to be updated recently I wonder how accurate it still is.
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
We'll have to wait for ES2017 at the earliest for async to arrive.
[0]http://www.2ality.com/2016/01/ecmascript-2016.html
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.
https://github.com/nodejs/node-chakracore
Disclaimer: working at Msft on ChakraCore
npm install --save babel-core babel-loader babel-polyfill babel-preset-es2015 babel-preset-stage-0
Adding this to entry point file
and having a .babelrc with these presets: Then you can transpile with babel-cli ( sudo npm install -g babel-cli if you don't have it yet) 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 ?
1. https://github.com/petkaantonov/bluebird/issues/1014
[0] https://github.com/nodejs/node/pull/5123
People won't use x.y.0 so they build in a bug to push to x.y.1 afterwards
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.
The Node/npm ecosystem does still feel a bit wobbly as an application platform, though, kind of like Ruby was five years ago...
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=...
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.
Does this mean that it can now open a real shell (like iTerm) and execute a script ? or I misunderstood ?
This addition when set to true, will do the wrapping for you in a cross-platform manor.
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.
iTerm is not a shell. bash, zsh, fish, etc are shells. iTerm is a terminal program that opens a shell.