DEV Community: punavwalke

Why Promises Exist in JavaScript (The Questions I Had as a Beginner)

punavwalke — Tue, 28 Apr 2026 15:44:39 +0000

🔥 The Question That Started It All

When I started learning async JavaScript, I didn’t just want to know how promises work.

I kept asking:

👉 Why do promises even exist?

Before learning syntax, I wanted to understand:

What problem are they solving?
Was the old approach really that bad?
Why was this design needed in the first place?

🤔 The Real Questions I Had

Instead of jumping into syntax, these were my actual doubts:

Was callback hell really such a big problem?
Why didn’t JavaScript just improve callbacks?
Who designed promises and why?
Why does .then() look like this?
How does async execution even work in a single-threaded language?

⚠️ The Problem: Async Code with Callbacks

Before promises, async code often looked like this:

let id="example"
setTimeout(() => {
  console.log("Step 1");

  setTimeout(() => {
    console.log("Step 2");

    setTimeout(() => {
      console.log("Step 3");
    }, 1000);

  }, 1000);

}, 1000);

At First Glance

This works fine.

So my initial thought was:

“Why is this considered a problem?”

💥 The Real Issue (At Scale)

Now imagine real-world applications:

Multiple API calls
Conditional flows
Error handling at each step
Retry mechanisms

This quickly turns into:

Deep nesting
Hard-to-read logic
Difficult debugging
Hard to modify safely

👉 The issue is not indentation—it’s loss of flow clarity

💡 Key Realization

Callback hell is not a problem in small code.

👉 It becomes a problem when the system grows.

🎯 The Deeper Problem: Inversion of Control

This is the real hidden issue behind callbacks.

🧠 What It Means

With callbacks, you pass your logic to another function:

let id="example"
doSomething(() => {
  console.log("I run later");
});

Now you are trusting that function to:

Call your code correctly
Call it only once
Call it at the right time
Not break execution flow

👉 You are no longer in control of execution.

This is called Inversion of Control.

⚠️ Why This Becomes a Problem

In small apps, it’s manageable.

But in large systems:

Many callbacks depend on each other
Execution flow becomes distributed
Debugging becomes unpredictable

👉 You lose confidence in when and how code runs

💡 The Idea Behind Promises

Promises were introduced to solve two core problems:

1. Callback Hell (Structure Problem)

2. Inversion of Control (Trust Problem)

⚙️ 1. Fixing Callback Hell: Making Code Readable

❌ Callback Style

let id="callbackstyle"
api1((res1) => {
  api2(res1, (res2) => {
    api3(res2, (res3) => {
      console.log(res3);
    });
  });
});

✅ Promise Style

let id="promisestyle"
api1()
  .then(res1 => api2(res1))
  .then(res2 => api3(res2))
  .then(res3 => {
    console.log(res3);
  });

💡 What Changed?

Instead of nested logic, we now have:

👉 A flat, readable flow

It becomes:

step 1 → step 2 → step 3

🔒 2. Fixing Inversion of Control: Restoring Predictability

⚠️ With Callbacks

let id="problem"
doSomething(() => {
  console.log("Executed later");
});

You don’t control:

When it runs
How many times it runs
Whether it runs correctly

💡 With Promises

Promises give a structured contract:

Either resolved or rejected
Executes exactly once
Chaining is predictable

let id="solution"
api1()
  .then(res1 => api2(res1))
  .then(res2 => api3(res2))
  .catch(err => console.error(err));

🧠 Key Shift

With promises:

👉 You don’t hand over control of execution
👉 You define a structured sequence of steps

🔗 Why `.then()`?

This confused me initially.

Why:

let id="thenexample"
doSomething().then(nextStep);

Instead of:

let id="directcall"
doSomething(nextStep);

💡 Insight

.then() creates a pipeline of execution steps, not just a function call.

🧩 Compare the Two Approaches

❌ Nested Callbacks

let id="nestedfinal"
step1(step2(step3()));

✅ Promise Chain

let id="chainfinal"
step1()
  .then(step2)
  .then(step3);

🎯 What This Solves

Flat structure
Better readability
Easier debugging
Predictable execution flow

🤯 What Finally Clicked for Me

At this point, everything started connecting:

Callbacks break at scale
Promises bring structure
.then() creates a pipeline
Execution flow becomes predictable

👉 It’s all part of one system design

👀 What About async/await?

Just when promises started making sense, I discovered async/await.

It made things even cleaner—but then I realized:

👉 It is built on top of promises.

That’s a topic for the next part.

🧠 Final Thought

If there’s one lesson from all of this:

Don’t just ask:

“How do I use this?”

Ask:

“Why does this exist?”

👉 That’s where real understanding begins.

🔚 Quick Summary

Callbacks become hard to manage at scale
Promises solve structure and control issues
.then() creates a clean execution pipeline
Promises restore predictability in async code

Understanding JavaScript Event Loop (The Way It Finally Clicked for Me)

punavwalke — Tue, 28 Apr 2026 14:41:12 +0000

🔥 The Question That Confused Me

JavaScript is single-threaded…
So how does it handle things like:

API calls
Timers
User interactions

…without blocking everything?

⚠️ The Problem

JavaScript can only execute one thing at a time on a single thread.

If a long-running task blocks the thread, the entire UI freezes.

👉 But real-world apps don’t work like that.

So something must be managing when async code runs.

⚙️ What is the Event Loop?

The Event Loop is a mechanism that coordinates execution between:

The call stack (where code runs)
The task queues (where async callbacks wait)

👉 It doesn’t execute code itself
👉 It decides when code should be executed

🧩 Core Pieces You Need to Know

1. Call Stack

Where JavaScript executes code
Follows LIFO (Last In, First Out)
Runs synchronous code line by line

2. Web APIs

Things like:

setTimeout
fetch
DOM events

👉 These are handled by the browser, not JavaScript

Once completed, their callbacks are sent to queues.

3. Task Queue (Macrotask Queue)

Includes callbacks from:

setTimeout
setInterval
DOM events

4. Microtask Queue

Higher priority queue that includes:

Promise.then
queueMicrotask

⚡ Important Rule

👉 All microtasks are executed before macrotasks

How It All Works Together

Synchronous code runs on the call stack
Async operations go to Web APIs
When done, callbacks move to queues
The Event Loop checks:

If the call stack is empty
Then pushes tasks from queues to the stack

💥 Let’s Test This

let id="ex1"
console.log("Start");

setTimeout(() => {
  console.log("Timeout");
}, 0);

Promise.resolve().then(() => {
  console.log("Promise");
});

console.log("End");

👉 Pause and predict the output before reading further

✅ Output

Start
End
Promise
Timeout

Step-by-step Breakdown

Start → goes to call stack → executed
setTimeout → goes to Web API → callback sent to task queue
Promise.then → goes to microtask queue
End → executed

Now stack is empty 👇

Event Loop picks microtasks first → Promise
Then picks macrotasks → Timeout

💡 What Finally Clicked for Me

I used to think:

setTimeout(fn, 0) runs immediately

But actually:

It always waits for the stack to be empty
And it runs after microtasks

👉 This explains so many “weird” async bugs

🔚 Simple Summary

JavaScript is single-threaded
The Event Loop coordinates async execution
Microtasks have higher priority than macrotasks

If you're learning JavaScript deeply, understanding this changes how you think about async code completely.