Async Functions: Browser Support, Features, Limitations

What are async functions?

Async functions are JavaScript functions declared with the async keyword. They always return a Promise, automatically wrap return values in Promise.resolve, and let you pause execution at await expressions. The TC39 committee added them so that Promise-based code reads top to bottom instead of as a chain of .then() callbacks.

Which browsers support async functions?

Async functions ship by default in every modern browser engine. Internet Explorer never added the syntax, and a few mobile browsers needed several major versions to catch up to their desktop counterparts.

What are the key features of async functions?

Async functions add a small set of language features on top of Promises. Each one trades a chain of .then() and .catch() calls for cleaner top-to-bottom code.

• Implicit Promise return: An async function always returns a Promise. A plain return value is wrapped in Promise.resolve, and a thrown error becomes a Promise.reject, so callers can always chain .then or await the result.
• The await keyword: Inside an async function, await pauses execution until the awaited Promise settles. The function then resumes with the resolved value or rethrows the rejection as a normal exception.
• Try/catch error handling: Awaited Promise rejections surface as exceptions, so a single try/catch block can wrap multiple awaits. This replaces the .catch() chain that pure-Promise code needs.
• Multiple syntax forms: async works on function declarations, function expressions, arrow functions, object methods, and class methods. Constructors, getters, and setters cannot be async.
• Top-level await in modules: Inside an ES module, await can sit at the top level without an enclosing async function. This lets a module pause its own evaluation while a fetch or dynamic import resolves.
• Concurrent awaits with Promise.all: await Promise.all([a(), b(), c()]) runs three async calls in parallel and resumes when every Promise settles. Promise.allSettled and Promise.race compose the same way.
• Async iteration with for await...of: for await (const chunk of stream) iterates over an async iterable, which makes streaming reads from the Fetch API or readable streams a single loop instead of recursive Promise chains.

How do you use async functions in older browsers?

Run modern source through Babel and ship the transpiled output to any browser that lacks async support. Babel rewrites async and await into a generator-based state machine, which Internet Explorer 11 and old Safari can execute with a tiny runtime polyfill.

• Install Babel: Add @babel/core, @babel/cli, and @babel/preset-env to your project as dev dependencies through npm install.
• Add the regenerator runtime: Run npm install regenerator-runtime and import it once at the top of your entry file with import "regenerator-runtime/runtime".
• Configure the targets: In babel.config.json, set targets to the browsers you must support, for example { "ie": "11", "safari": "10" }. Babel turns on the right transforms for each target.
• Compile your code: Run npx babel against your src folder and let it write the output to a dist folder. Babel converts every async function in src into a regenerator state machine in dist that runs on ES5.
• Confirm in the target browser: Open the compiled bundle in Internet Explorer 11 or your oldest target, paste the snippet below into the DevTools console, and check that the user object prints without a SyntaxError.

async function getUser(id) {
    const response = await fetch(`/api/users/${id}`);
    if (!response.ok) {
        throw new Error("User fetch failed: " + response.status);
    }
    const user = await response.json();
    return user;
}

(async () => {
    try {
        const user = await getUser(42);
        console.log("User loaded:", user.name);
    } catch (error) {
        console.error("Could not load user:", error);
    }
})();

If the console reports "regeneratorRuntime is not defined", the polyfill import is missing. Add import "regenerator-runtime/runtime" before any module that uses async functions and rebuild.

What are the known issues with async functions?

Async functions are stable, but a handful of edge cases trip up developers and add cross-browser bugs. Most of them come from the gap between language semantics and how each engine schedules micro-tasks.

• Internet Explorer cannot parse the syntax: IE 5.5 through 11 throw a SyntaxError before the page runs. Any bundle that ships raw async syntax breaks IE outright, so transpile to ES5 with Babel before deployment.
• Sequential awaits look concurrent but are not: const [a, b] = [await fetchA(), await fetchB()] runs the calls one after the other. Use await Promise.all([fetchA(), fetchB()]) when the two requests are independent.
• Unhandled rejections in sequential awaits: If an earlier await resolves and a later one rejects, the rejection can fire before the catch handler runs and surface as an unhandled rejection in the console.
• Promise reference inequality: An async function that returns a Promise wraps it in a fresh Promise, so the returned reference is not equal to the original. Code that compares Promise identity with === breaks silently.
• Top-level await blocks module loading: A module that awaits at the top level pauses every importer. Long-running top-level awaits delay app startup and can stall hydration on server-rendered pages.
• await is not allowed in classic scripts: Top-level await works only inside ES modules. Inline scripts without type="module" throw a SyntaxError if you use await outside an async function.
• Safari 11 negation parsing bug: Early Safari 11 misparsed if (!await foo()) as if it were !(await foo()). Patches in later Safari 11 point releases fixed the parser, but legacy iOS 11 devices still carry the bug.
• Promise executor cannot be async: new Promise(async (resolve) => { ... }) is an anti-pattern. ESLint flags it because rejections inside the async executor become unhandled rejections instead of rejecting the new Promise.

In my experience, the trickiest production failure is shipping async function code through a CDN to a fleet that still includes Internet Explorer or old WebView builds. Always compile to ES5 with Babel, import regenerator-runtime once, and feature-detect (async () => {})().constructor.name === "AsyncFunction" before running modern paths.

Citations

All async function version numbers and platform notes in this guide come from these primary sources:

• ECMA-262 ECMAScript Language Specification: tc39.es/ecma262
• MDN Web Docs - async function: developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function
• MDN Web Docs - await operator: developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/await
• MDN Web Docs - AsyncFunction: developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/AsyncFunction
• Wikipedia - Async/await: en.wikipedia.org/wiki/Async/await
• web.dev - Async functions: making promises friendly: web.dev/articles/async-functions
• V8 - Top-level await: v8.dev/features/top-level-await
• TC39 Finished Proposals (async/await): github.com/tc39/proposals/blob/HEAD/finished-proposals.md
• Chrome Platform Status - Async functions: chromestatus.com/feature/5643236363894784
• WebKit Bug 176685 - Safari 10/11 await parsing: bugs.webkit.org/show_bug.cgi?id=176685
• Babel - regenerator-runtime usage: babeljs.io/docs/babel-plugin-transform-regenerator