Introduction

Most Node.js “asynchronous confusion” comes from one false assumption: developers expect a later result to behave like an immediate return value. Once you separate synchronous return values from future completion, most async code becomes much easier to reason about.

The Core Mental Model

JavaScript in Node.js runs your code on a single main thread, but many operations such as file I/O, timers, and network requests complete later. Node does not pause the whole program waiting for those operations. Instead, it registers callbacks or promise continuations and runs them when the work is ready.

That means this code does not do what beginners expect:

1const fs = require("fs")
2
3function readConfig() {
4  let result = null
5
6  fs.readFile("config.json", "utf8", (err, data) => {
7    if (err) throw err
8    result = data
9  })
10
11  return result
12}
13
14console.log(readConfig())

readConfig() returns before the callback runs, so result is still null.

Returning a Promise Instead

The fix is not to “wait harder” inside the same function. The fix is to return something that represents future completion, usually a promise.

1const fs = require("fs/promises")
2
3async function readConfig() {
4  const data = await fs.readFile("config.json", "utf8")
5  return JSON.parse(data)
6}
7
8async function main() {
9  const config = await readConfig()
10  console.log(config)
11}
12
13main().catch(console.error)

Now the function contract is honest. readConfig() does not claim to have the answer immediately. It returns a promise that resolves later.

Callback Style, Promise Style, and Async/Await

Node supports several async styles because the ecosystem evolved over time.

Callback style passes a function to be called later.

setTimeout(() => {
  console.log("later")
}, 100)

Promise style returns an object representing eventual success or failure.

Promise.resolve(42)
  .then(value => console.log(value))
  .catch(err => console.error(err))

async and await are built on promises. They do not make code synchronous; they only make asynchronous control flow read more like straight-line code.

1async function getNumber() {
2  return 42
3}
4
5getNumber().then(console.log)

Even though return 42 looks immediate, the result is still wrapped in a promise because the function is async.

Ordering and Concurrency

Another source of confusion is assuming await always means “faster because it looks cleaner.” In reality, sequential await can be slower if operations are independent.

1function wait(ms) {
2  return new Promise(resolve => setTimeout(resolve, ms))
3}
4
5async function sequential() {
6  await wait(100)
7  await wait(100)
8  console.log("sequential done")
9}
10
11async function parallel() {
12  await Promise.all([wait(100), wait(100)])
13  console.log("parallel done")
14}

Both versions are correct, but they express different execution plans. Use sequential await when the second step depends on the first. Use Promise.all when the operations are independent.

Error Handling

Async errors also confuse people because try and catch only work if the asynchronous operation is actually awaited inside the try block.

1async function run() {
2  try {
3    await Promise.reject(new Error("boom"))
4  } catch (err) {
5    console.error("handled:", err.message)
6  }
7}
8
9run()

If you forget await, the rejection can escape the local control flow and appear elsewhere as an unhandled promise rejection.

For callback-based APIs, the usual convention is “error-first callbacks,” where the first argument is an error and the second is the result. Mixing callback assumptions with promise assumptions is a common source of bugs.

Common Pitfalls

The most common mistake is trying to return a value from inside a callback and expecting it to become the outer function’s return value. It does not.

Another frequent problem is forgetting that async functions always return promises. Logging the raw return value often prints a promise object, which surprises people who expected the final data.

Developers also accidentally serialize independent work by stacking await calls one after another. That is readable, but it can be unnecessarily slow.

Finally, many async bugs are really error-handling bugs. A rejected promise that is never awaited or caught can make a program fail far from the original source.

Summary

• Asynchronous operations complete later, so they cannot be treated like normal immediate return values.
• Return promises from async functions and use await at the call site.
• 'async and await improve readability, but the code is still asynchronous underneath.'
• Use sequential await for dependent steps and Promise.all for independent work.
• Handle errors explicitly with try and catch or .catch() so failures do not escape unnoticed.