Hacker News Reader

Hacker News

Comment by romanovcode | Hacker News Reader

Full thread

romanovcode

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

View on HN

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 ?

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`

Babel can transform async functions into Bluebird coroutines, so the best of both worlds - https://www.npmjs.com/package/babel-plugin-transform-async-t...

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

No I think those should work with async functions as it is literally just translating `async` -> `yield`, but worth investigating.

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.

Could you put a reference for the decorator/yield usage? Thanks

http://bluebirdjs.com/docs/api/promise.coroutine.html

Thanks, I will review it.

https://github.com/llambda/koa-boiler/blob/master/app.js#L75 is an example of Bluebird coroutines paired with Koa.

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.

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.

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

Does it still only run on Windows?

AFAIK linux and mac release is coming later this year and even then it won't have JIT support.

For now. The Linux branch of ChakraCore is under active development.

Disclaimer: working at Msft on ChakraCore

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.

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

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

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.

Besides, node doesn't implement language features, V8 does. Here's the relevant issue: https://bugs.chromium.org/p/v8/issues/detail?id=4483

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

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.

Multi precision numbers are going to be a long wait

It will probably take years for async/await to become part of Node.

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.

Reply on news.ycombinator.com