JavaScript async/await fiddling

I’ve been fiddling with using ECMAScript 2015 (“ES6”) in rewriting some internals for ogv.js, both in order to make use of the Promise pattern for asynchronous code (to reduce “callback hell”) and to get cleaner-looking code with the newer class definitions, arrow functions, etc.

To do that, I’ll need to use babel to convert the code to the older ES5 version to run in older browsers like Internet Explorer and old Safari releases… so why not go one step farther and use new language features like asynchronous functions that are pretty solidly specced but still being implemented natively?

Not yet 100% sure; I like the slightly cleaner code I can get, but we’ll see how it functions once translated…

Here’s an example of an in-progress function from my buffering HTTP streaming abstraction, currently being rewritten to use Promises and support a more flexible internal API that’ll be friendlier to the demuxers and seek operations.

I have three versions of the function: one using provisional ES2017 async/await, one using ES2015 Promises directly, and one written in ES5 assuming a polyfill of ES2015’s Promise class. See the full files or the highlights of ES2017 vs ES2015:

The first big difference is that we don’t have to start with the “new Promise((resolve,reject) => {…})” wrapper. Declaring the function as async is enough.

Then we do some synchronous setup which is the same:

Now things get different, as we perform one or two asynchronous sub-operations:

In my opinion the async/await code is cleaner:

First it doesn’t have as much extra “line noise” from parentheses and arrows.

Second, I can use a try/finally block to do the final state change only once instead of on both .then() and .catch(). Many promise libraries will provide an .always() or something but it’s not standard.

Third, I don’t have to mentally think about what the “intermittent return” means in the .then() handler after the triggerDownload call:

Here, returning a promise means that that function gets executed before moving on to the next .then() handler and resolving the outer promise, whereas not returning anything means immediate resolution of the outer promise. It ain’t clear to me without thinking about it every time I see it…

Whereas the async/await version:

makes it clear with the “await” keyword what’s going on.

Updated: I managed to get babel up and running; here’s a github gist with expanded versions after translation to ES5. The ES5 original is unchanged; the ES2015 promise version is very slightly more verbose, and the ES2017 version becomes a state machine monstrosity. 😉 Not sure if this is ideal, but it should preserve the semantics desired.

2 thoughts on “JavaScript async/await fiddling”

  1. async/await is awesome, honestly. I’ve been using in for my server-side test framework (also using Babel) and it makes code a _lot_ more readable, especially when you have lots of operations in sequence. This test suite:

    https://github.com/eloquence/lib.reviews/blob/master/tests/3-integration-signed-in.js

    Runs a lot of tests concurrently, but using async/await, operations that depend on each other can be clearly and intuitively understood. The Babel transpilation is a bit of a pain, but for client-side code it’s worth it anyway given the other cool ES2015 features that you’ll get in a cross-browser compatible way (computed property names and similar syntactic shortcuts are just really nice, and I find the class syntax a lot more readable when OOP patterns are appropriate).

  2. Does Babel support source maps when transpiling ES2017 to “state machine” code? If you can debug the ES2017 code directly, the generated code shouldn’t matter much, as long as the performance is ok.

Comments are closed.