Compared to using promises directly, not only can async and await make code more readable for developers — they enable some interesting optimizations in JavaScript engines, too! This write-up is about one such optimization involving stack traces for asynchronous code.

The fundamental difference between await and vanilla promises is that await X() suspends execution of the current function, while promise.then(X) continues execution of the current function after adding the X call to the callback chain. In the context of stack traces, this difference is pretty significant.

When a promise chain (desugared or not) throws an unhandled exception at any point, the JavaScript engine displays an error message and (hopefully) a useful stack trace. As a developer, you expect this regardless of whether you use vanilla promises or async and await.

Vanilla promises

Imagine a scenario where a function c is called when a call to an asynchronous function b resolves:

const a = () => {
	b().then(() => c());
};

When a is called, the following happens synchronously:

• b is called and returns a promise that will resolve at some point in the future.
• The .then callback (which is effectively calling c()) is added to the callback chain (or, in V8 lingo: […] is added as a resolve handler).

After that, we’re done executing the code in the body of function a. a is never suspended, and the context is gone by the time the asynchronous call to b resolves. Imagine what happens if b (or c) asynchronously throws an exception. The stack trace should include a, since that’s where b (or c) was called from, right? How is that possible now that we have no reference to a anymore?

To make it work, the JavaScript engine needs to do something in addition to the above steps: it captures and stores the stack trace within a while it still has the chance. In V8, the stack trace is attached to the promise that b returns. When the promise fulfills, the stack trace is passed on so that c can use it as needed.

Capturing the stack trace takes time (i.e. degrades performance); storing these stack traces requires memory.

async/await

Here’s the same program, written using async/await instead of vanilla promises:

const a = async () => {
	await b();
	c();
};

With await, we can restore the call chain even if we do not collect the stack trace at the await call. This is possible because a is suspended, waiting for b to resolve. If b throws an exception, the stack trace can be reconstructed on-demand in this manner. If c throws an exception, the stack trace can be constructed just like it would be for a synchronous function, because we’re still within a when that happens.

Recommendations

Like most ECMAScript features that are seemingly “just syntax sugar”, async/await is more than that.

Enable JavaScript engines to handle stack traces in a more performant and memory-efficient manner by following these recommendations:

• Prefer async/await over desugared promises.
• Use @babel/preset-env to avoid transpiling async/await unnecessarily.

Although V8 doesn’t implement this optimization yet, following this advice ensures optimal performance once we (or other JavaScript engines) do.

In general, don’t transpile code unless you absolutely need to! For example, all modern browsers that support service workers also support async/await. Consequently, there is no need to transpile your service worker–specific code down to vanilla promises. The same argument applies to browsers with JavaScript modules support. For more information, see Philip’s blog post on deploying ES2015+ code in production today.