async / await in JavaScript
debt(d4/e3/b3/t6)
Closest to 'default linter catches the common case' (d3), +1 to d4. ESLint (cited in detection_hints.tools) can catch some misuses like await-in-loop (no-await-in-loop rule), but other common mistakes like forgetting await entirely, using async in forEach, or missing try/catch require more careful configuration or code review. Not all issues are caught by default linter rules.
Closest to 'simple parameterised fix' (e3). The quick_fix is replacing sequential await-in-loop with Promise.all(items.map(...)). Most fixes (adding missing await, wrapping in try/catch, replacing forEach with for...of or Promise.all) are localized pattern replacements within a single file or function, not cross-cutting refactors.
Closest to 'localised tax' (b3). async/await is a per-function/per-module concern. While it's pervasive in modern JS codebases, the pattern itself doesn't impose heavy structural weight — it's syntactic sugar over Promises. Misuse creates localized issues rather than system-wide architectural debt. It doesn't define the system's shape the way a framework or data model choice would.
Closest to 'notable trap' (t5), +1 to t6. The misconception that await blocks the thread/event loop is a serious conceptual error that contradicts how blocking works in other languages (e.g., C#'s .Result or Python's synchronous calls). Multiple common_mistakes compound this: forEach not awaiting async callbacks is a genuine trap that contradicts intuition, forgetting await silently returns a Promise object instead of data, and sequential awaiting in loops is a performance trap. These traps go beyond a single documented gotcha but don't quite reach 'the obvious way is always wrong' (t9).
Also Known As
TL;DR
Explanation
async/await is syntactic sugar over Promises, introduced in ES2017. Marking a function async makes it return a Promise implicitly — even a bare return value is wrapped. Inside an async function, await suspends execution until the awaited Promise resolves, then resumes with the resolved value. If the Promise rejects, await throws the rejection reason, making try/catch the natural error-handling pattern. Crucially, await does not block the thread — while waiting, the event loop is free to run other tasks. Multiple independent async operations should be parallelised with Promise.all() rather than awaited sequentially. Top-level await is supported in ES modules. Common pitfalls: forgetting await (getting a Promise instead of its value), sequential awaiting in a loop instead of parallelising, and unhandled rejections when an async function throws inside an event handler with no wrapping try/catch.
Watch Out
Common Misconception
Why It Matters
Common Mistakes
- Forgetting await — const data = fetch(url) gives a Promise object, not the response body.
- Awaiting in a loop sequentially when the iterations are independent — use Promise.all() to run them in parallel.
- Missing try/catch around await — an unhandled rejection inside an async function crashes Node.js workers or produces silent failures in browsers.
- Using async in an Array.forEach callback — forEach does not await the returned Promises, so the loop finishes before the async work completes.
Code Examples
// Sequential awaits — total time = sum of all request times:
async function loadAll(ids) {
const results = [];
for (const id of ids) {
results.push(await fetch(`/api/${id}`)); // waits for each in turn
}
return results;
}// Parallel with Promise.all — total time = slowest single request:
async function loadAll(ids) {
const promises = ids.map(id => fetch(`/api/${id}`));
return Promise.all(promises); // all requests in flight simultaneously
}