DEV Community: Bishal Singh

async/await Finally Made Sense When I Stopped Treating It as Something New

Bishal Singh — Tue, 26 May 2026 07:36:37 +0000

It is not a replacement for promises. It is just promises wearing a cleaner outfit. Here is how that clicked for me.

If you have already understood promises — what they are, why they exist, and how errors travel through a chain — then async/await is genuinely one step away. Not a big step. One small step.

The problem is most explanations treat it like an entirely new concept. It is not. Once I understood that, everything fell into place.

What promises already solved
Before getting into async/await, it helps to remember what promises fixed. Callbacks nested badly and errors stayed isolated — each function had no idea when something else in the chain failed. Promises fixed both of those things.

But promises still had their own friction. Every step needed a .then. Reading a chain of five operations still required some mental effort to follow. It worked, but it did not feel natural.

async/await did not come to fix a broken system. It came to make an already good system easier to read.

Two keywords. One job each.
async does one thing — it marks a function as one that contains waiting inside it. And it makes that function always return a promise, even if you return a plain value.

await does one thing — it pauses that line, waits for the promise to resolve, and hands you the actual value directly. Then moves to the next line.

That is the entire feature. Two keywords, two jobs.

The moment it clicks
Look at these two blocks of code. They do the exact same thing.

promises
fetchUser()
.then(user => fetchPosts(user))
.then(posts => fetchComments(posts))
.catch(err => handleError(err))
async/await
async function getData() {
try {
const user = await fetchUser()
const posts = await fetchPosts(user)
const comments = await fetchComments(posts)
} catch(err) {
handleError(err)
}
}
Same logic. Same behavior. Same error handling. The second one just reads like normal top to bottom code. No chaining, no callbacks, no mental gymnastics.

JavaScript is converting your async/await into promises behind the scenes anyway. You are not writing something different. You are writing something cleaner.

A question I had about async functions
When I first saw this:

example
async function greet() {
return "hello"
}

greet().then(val => console.log(val)) // "hello"
My first question was — does console.log actually print "hello" here? Yes it does. The async keyword secretly wraps your returned value in a resolved promise. The .then just unwraps it and gives you the value back.

In real code you would never write it that way. You would just use await inside another async function to get the value cleanly. But that example showed me something important — async functions always return a promise, even when it does not look like they do.

Error handling is just try/catch
With promises you used .catch at the end of a chain. With async/await you use the same try/catch you already know from regular JavaScript.

error handling
async function getData() {
try {
const user = await fetchUser()
const posts = await fetchPosts(user)
} catch(err) {
console.log(err) // catches anything that fails
}
}
Same behavior as .catch on a promise chain. If anything inside the try block fails, the error travels straight to catch. Nothing isolated, nothing silent.

The one performance mistake worth knowing early
Because await pauses execution, it is easy to accidentally write slow code without realizing it.

slow — runs one by one
const user = await fetchUser()
const posts = await fetchPosts()
const photos = await fetchPhotos()
If these three do not depend on each other, you are making them wait in a queue for no reason. The fix is Promise.all — it runs all of them at the same time and waits for all of them together.

fast — runs all at once
const [user, posts, photos] = await Promise.all([
fetchUser(),
fetchPosts(),
fetchPhotos()
])
Same result. Much faster. This is the one thing worth keeping in the back of your mind as you start building real projects.

The one line summary
async/await is just promises, written so it reads like normal top to bottom code. Nothing new underneath. No new mental model required. If promises made sense, this is just the cleaner version of the same thing.

The syntax will become muscle memory as you build things. What matters now is knowing you are not learning something entirely new — you are just learning a better way to write something you already understand.

I Finally Understood Callbacks and Promises. Here is What Actually Clicked.

Bishal Singh — Sun, 24 May 2026 10:24:41 +0000

I had read about callbacks and promises multiple times. I understood the words. But I kept feeling like I was missing something underneath — like everyone else had a mental model I did not have yet.

Then two things clicked, and everything made sense. This post is about those two things.

First: both are async. That is not the difference.
When I first compared callbacks and promises, I thought the problem with callbacks was timing — that functions were somehow "not ready" when they needed to be. That was wrong.

Both callbacks and promises handle timing just fine. That is literally what async code is for. The problem with callbacks has nothing to do with when things run. It is about what happens when things go wrong — and how readable your code stays as it grows.

The waiter analogy that actually made sense
Think about ordering food at a restaurant.

With callbacks, you hand the waiter a note with instructions: "when the food is ready, bring it to table 4, then refill the water, then bring the bill." You have handed over control. The waiter runs your instructions. You are just waiting.

With promises, the waiter gives you a buzzer and walks away. When it goes off, you decide what to do next. You are the one in control.

Callbacks hand control away. Promises hand it back to you. That is the real difference.

Problem one: nesting
When you need multiple async operations in sequence, callbacks nest inside each other. Every new step lives inside the previous one.

callback hell
fetchUser(function(user) { fetchPosts(user, function(posts) { fetchComments(posts, function(comments) { // your actual logic is buried here }) }) })
This is not just ugly. It is genuinely hard to debug. You cannot easily see the flow, and changing one step risks breaking the ones around it.

Promises flatten this completely:

promises
fetchUser()
.then(user => fetchPosts(user))
.then(posts => fetchComments(posts))
.catch(err => handleError(err))
Same logic. Flat, readable, easy to follow from top to bottom.

Problem two: functions do not know when others fail
This was the one I almost missed — and it is arguably more important than the nesting issue.

In a callback chain, each function is isolated. It only knows about itself. So if something breaks in the middle, the functions around it have no idea. The error does not travel. It just disappears silently unless you manually handle it at every single level.

silent failure
fetchUser(function(user) {
fetchPosts(user, function(posts) { // fails here
fetchComments(posts, function() { // never runs
// nobody knows what went wrong
})
})
})
With promises, a failure anywhere in the chain automatically travels down to the nearest .catch. You do not have to do anything extra. One handler covers everything.

error travels automatically
fetchUser()
.then(user => fetchPosts(user)) // fails here
.then(posts => fetchComments()) // skipped
.catch(err => handleError(err)) // caught here, automatically
With callbacks, one forgotten error handler means a silent failure. With promises, errors bubble down on their own.

So to summarize what actually changed
Promises were not invented to replace callbacks for style reasons. They were invented because two specific things were genuinely painful:

One — deeply nested callbacks made code hard to read and maintain as projects grew. Two — errors in a callback chain were isolated, invisible, and easy to miss entirely.

Promises fix both. The chain stays flat, and failures propagate automatically.

The syntax will become second nature as you build things. What matters first is understanding why promises exist at all — because once that is clear, the rest starts making sense on its own.

Written by someone who just figured this out, for anyone else who is still figuring it out.