Should DDC target ES6 async / wait?

[vsmenon]

V8 support landed in Chrome stable:

Chrome async functions

[vsmenon]

Related to #27315 - the JS await returns a Promise.

[vsmenon]

Looks like Chrome has nice support for debugging as well:

https://twitter.com/addyosmani/status/740155716401565696

@jmesserly @jacob314 do you guys think it's worth targeting this? Not clear when it'll show in other browsers.

[matanlurey]

Since DDC is only targeting ES6, is this safe to do?

Could teams use Babel (or similar) to properly target ES5?

[jmesserly]

Since DDC is only targeting ES6, is this safe to do?

DDC is targeting whatever is supported in browsers, we're not locked in forever to the features that happened to be in ES6 (nor can we use all things in ES6 until they're supported).

Originally "browsers" meant mainly Chrome as we were replacing Dartium which was Chrome only. I don't know if at this point, we've expanded the definition of browsers. My impression is that they browsers are all pretty close together on ES support these days, though.

[jmesserly]

@jmesserly @jacob314 do you guys think it's worth targeting this? Not clear when it'll show in other browsers.

Do we think there's a big debugging benefit to Dart? When source maps are on I'm not sure users will know the difference. async/await is pretty much just a bit of syntactic sugar on top of generators, which we're already using.

[vsmenon]

Do we think there's a big debugging benefit to Dart?

From the twitter video, I think it would primarily be "step over" support in the debugger across await calls.

[kasperpeulen]

@matanlurey babel compiles down async festures to es5 code indeed

[vsmenon]

@jmesserly - if you're still looking at Node support for our tests, check out:

http://v8project.blogspot.com/2016/12/v8-nodejs.html

I.e. ,the async/await/bleeding edge bits at the bottom.

(The new dev tools support looks promising too!) V8's also added perf improvements:

http://v8project.blogspot.com/2017/02/v8-release-57.html

[jmesserly]

it may be worth seeing if #27315 can be done easily; if so that makes the code a bit cleaner (can just "await e") otherwise we'll need to do some promise->future and future->promise conversions.

[vsmenon]

Do we think there's a big debugging benefit to Dart? When source maps are on I'm not sure users will know the difference. async/await is pretty much just a bit of syntactic sugar on top of generators, which we're already using.

Actually, it looks like you're right - we're getting nice async/await stepping for free in Chrome 60 (canary right now). :-)

[jmesserly]

Yay! That's great news!

[jmesserly]

Current status:

Ideally we'd reconcile Future/Promise first (see #27315), as noted above. But we don't have to block on that. We're already using an adapter (from a JS generator to a Dart Future), so adapting from a Promise to a Future should be doable.

It would be easier to fix this after we switch to Kernel backend, so we don't have to implement it twice.

[Markzipan]

I have a really old CL that uses JS async/await + future/promise adapters. However, it results in some pretty annoying timing issues. Consider the following example:

import 'dart:async';

Future f() async {}

main() {
  scheduleMicrotask(() => scheduleMicrotask(() => print("third")));
  Future(() => null).then((_) => print("fourth"));
  f().then((_) => print("first"));
  scheduleMicrotask(() => print("second"));
}

Using JS promises, we get

second
third
first
fourth

Dart executes futures synchronously until the first asynchronous action (e.g., await). However, even though JS does something similar with its promises, the fact that Dart maintains an in-memory microtask queue separate from JS's means that f is starved until after the entire microtask queue is emptied. The microtask queue has no idea that JS promises are waiting to be executed (at least in my naive implementation).

[grouma]

Note that this change would help us to provide zero-cost async stack traces in Chrome:
https://docs.google.com/document/d/13Sy_kBIJGP0XT34V1CV3nkWya4TwYx9L3Yv45LdGB6Q/edit

With those, we likely can resolve:
dart-lang/test#1031