TL;DR: JavaScript errors don't have to crash your program. The try/catch/finally block gives you a structured way to intercept failures, respond to them, and always clean up — regardless of what went wrong.

Problem

Unhandled errors in JavaScript throw uncaught exceptions — they halt execution and give the user nothing useful. Consider fetching user data from an API: the network can fail, the response can be malformed, or the server can be down. Without error handling, any of these causes a silent crash or an unformatted stack trace in the console.

// Without error handling — crash if fetch fails
const response = await fetch("https://video.thitainfo.com/api/health");
const data = await response.json();
console.log(data.status); // Explodes if fetch throws or json() fails

The fix is a deliberate error-handling strategy using try, catch, and finally.

Solution

Step 1 — Wrap risky code in a try block

The try block contains any code that might throw. If an error occurs anywhere inside it, execution immediately jumps to catch.

// Wrapping a network call
async function fetchUser(userId) {
  try {
    const response = await fetch(`https://api.example.com/users/${userId}`);

    if (!response.ok) {
      throw new Error(
        `HTTP \({response.status}: Failed to fetch user \){userId}`,
      );
    }

    const user = await response.json();
    return user;
  } catch (error) {
    console.error("fetchUser failed:", error.message);
    return null;
  }
}

// Usage
const user = await fetchUser(42);
// Output on network failure: fetchUser failed: Failed to fetch

The catch block receives the error object. error.message is the human-readable description; error.name tells you the type (e.g. TypeError, SyntaxError).

Step 2 — Use finally for guaranteed cleanup

finally always executes — whether the try succeeded, catch ran, or even if return was called mid-block. It's the right place for cleanup: closing connections, hiding loading spinners, releasing locks.

async function fetchUserWithSpinner(userId) {
  showSpinner(); // Start loading UI

  try {
    const response = await fetch(`https://api.example.com/users/${userId}`);

    if (!response.ok) {
      throw new Error(`HTTP ${response.status}`);
    }

    return await response.json();
  } catch (error) {
    console.error("Request failed:", error.message);
    return null;
  } finally {
    hideSpinner(); // Runs no matter what — success or failure
  }
}

Without finally, a thrown error inside catch could leave the spinner visible forever.

Step 3 — Throw custom errors for precise control

JavaScript's built-in Error class is generic. For application logic, extend it to create specific error types that carry more context — and that let catch blocks distinguish between failure modes.

class ValidationError extends Error {
  constructor(field, message) {
    super(message);
    this.name = "ValidationError";
    this.field = field; // Extra context beyond just the message
  }
}

class NetworkError extends Error {
  constructor(statusCode, message) {
    super(message);
    this.name = "NetworkError";
    this.statusCode = statusCode;
  }
}

function validateAge(age) {
  if (typeof age !== "number") {
    throw new ValidationError("age", "Age must be a number");
  }
  if (age < 0 || age > 150) {
    throw new ValidationError("age", `Age ${age} is out of valid range`);
  }
  return true;
}

// Catch block can now branch by error type
try {
  validateAge("thirty");
} catch (error) {
  if (error instanceof ValidationError) {
    console.error(
      `Validation failed on field '\({error.field}': \){error.message}`,
    );
    // Output: Validation failed on field 'age': Age must be a number
  } else {
    throw error; // Re-throw anything unexpected
  }
}

Re-throwing is important: only handle what you understand. Silently swallowing all errors (catch (e) {}) hides real bugs.

Now here's the full execution order, so there's no ambiguity about when each block runs:finally runs in every path. That's the guarantee worth internalizing.

Results

A codebase with structured error handling produces measurably better outcomes:

• Errors surface with specific messages (ValidationError on field 'email') instead of generic uncaught exceptions, cutting average debugging time significantly on production incidents.

• finally blocks eliminate resource leaks — open file handles, visible loading states, database connections — that compound over time in long-running Node.js processes.

• Custom error classes let monitoring tools (Sentry, Datadog) group errors by type rather than by stack trace, making alerting far less noisy.

Trade-offs

try/catch is not free. In hot loops (tens of thousands of iterations), wrapping every iteration in try/catch can impose a measurable overhead in V8. Move the try/catch outside the loop and handle errors at the batch level if performance matters there.

It doesn't catch everything. try/catch only catches synchronous errors and errors in await-ed promises. An unhandled promise rejection (fetch(...).then(...) without .catch()) won't be caught by a surrounding try/catch. Use async/await consistently so await surfaces rejections into the nearest catch.

Overly broad catch blocks hide bugs. catch (e) { /* do nothing */ } is almost always wrong. At minimum, log the error. Better: only catch errors you can meaningfully handle, and re-throw the rest.

Conclusion

Error handling isn't defensive programming — it's the contract your code makes with everyone calling it. try marks what can fail, catch defines the recovery, finally enforces cleanup. Custom error classes give you the precision to distinguish user mistakes from infrastructure failures. Start with try/catch around any I/O, validate inputs with custom errors, and use finally wherever resources need releasing.

Further reading

• MDN — try...catch — complete syntax reference

• MDN — Error — all built-in error types and how to extend them

• Jake Archibald — Tasks, microtasks, queues and schedules — essential context for understanding where async errors surface

• Node.js — Error handling best practices — production-grade patterns for server-side JS

• Sentry — JavaScript error monitoring — turning caught errors into actionable alerts

You've written constructor functions. You've used new. But if someone asked you to explain what JavaScript does internally when new runs — step by step — could you?

Most developers can't, and that gap causes real bugs: unexpected undefined properties, broken prototype chains, and confusion when constructor functions behave differently with and without new.

This post fixes that.

What new Does

When you write:

const dog = new Animal("Rex");

JavaScript executes four steps internally, in this order:

Step 1 — Create a fresh object: An empty object {} is created.

Step 2 — Link the prototype: The new object's [[Prototype]] is set to Animal.prototype. This is what makes instanceof work and enables method lookup via the prototype chain.

Step 3 — Run the constructor: The constructor function (Animal) is called with this bound to the new object. Any property assignments inside the constructor land on this object.

Step 4 — Return the object: Unless the constructor explicitly returns a different object, the new object is returned automatically.

Here's that flow visually:---

Constructor Functions

A constructor function is just a regular function — the convention is to capitalize it. The magic isn't in the function itself, it's in calling it with new.

function Animal(name, sound) {
  this.name = name;
  this.sound = sound;
}

// Method lives on the prototype — shared across all instances
Animal.prototype.speak = function () {
  return `\({this.name} says \){this.sound}`;
};

const dog = new Animal("Rex", "woof");
const cat = new Animal("Miso", "meow");

console.log(dog.speak());  // Rex says woof
console.log(cat.speak());  // Miso says meow

Why put speak on the prototype, not inside the constructor?

If you defined speak as this.speak = function() {...} inside the constructor, every instance would get its own copy of that function — wasted memory. By putting it on Animal.prototype, all instances share one copy and look it up via the prototype chain.

The Object Creation Process, Step by Step

Here's a manual recreation of what new does — without using new:

function manualNew(Constructor, ...args) {
  // Step 1: create empty object
  const obj = {};

  // Step 2: link prototype
  Object.setPrototypeOf(obj, Constructor.prototype);

  // Step 3: run constructor with `this` = new object
  const result = Constructor.apply(obj, args);

  // Step 4: return the new object (or constructor's return if it's an object)
  return result instanceof Object ? result : obj;
}

function Vehicle(make, model) {
  this.make = make;
  this.model = model;
}
Vehicle.prototype.describe = function () {
  return `\({this.make} \){this.model}`;
};

const car = manualNew(Vehicle, "Toyota", "Camry");
console.log(car.describe()); // Toyota Camry
console.log(car instanceof Vehicle); // true

Property lookup order:

1. Check the instance itself (d.name → found)

2. Check Dog.prototype (d.breed → found)

3. Check Object.prototype (.hasOwnProperty, .toString, etc.)

4. null → undefined

Here's what the prototype chain looks like:---

Instances from Constructors

Multiple instances from the same constructor share the prototype but own their own data:

function Counter(start = 0) {
  this.count = start;
}

Counter.prototype.increment = function () {
  this.count += 1;
  return this;
};

Counter.prototype.value = function () {
  return this.count;
};

const a = new Counter(0);
const b = new Counter(10);

a.increment().increment();
b.increment();

console.log(a.value()); // 2
console.log(b.value()); // 11

// They share the prototype methods but not the data
console.log(a.increment === b.increment); // true  (same function reference)
console.log(a.count === b.count);         // false (own properties, separate values)

What Happens Without new

Call a constructor without new and this points to the global object (or is undefined in strict mode):

"use strict";

function Point(x, y) {
  this.x = x;
  this.y = y;
}

const p = Point(3, 4); // TypeError: Cannot set properties of undefined

Without strict mode, the x and y properties silently pollute the global object — a notoriously confusing bug.

Guard against misuse:

function Point(x, y) {
  if (!(this instanceof Point)) {
    return new Point(x, y);
  }
  this.x = x;
  this.y = y;
}

Or just use class syntax (see trade-offs below).

Results

After reading this, you should be able to:

• Predict the exact output of any new call

• Explain why methods go on .prototype rather than inside the constructor

• Debug undefined property bugs caused by missing new

• Implement new manually — useful for meta-programming and polyfills

Trade-offs

new + constructor functions vs ES6 class: Both compile to the same prototype mechanism. class syntax adds constructor enforcement (calling a class without new throws automatically), cleaner inheritance via extends, and better readability. Prefer class in new code — but understand that it's not a different system, just a cleaner syntax for the same one.

Shared prototype mutation: All instances share the same prototype object. If you add a property to Dog.prototype at runtime, every existing instance immediately sees it. Useful sometimes, surprising when it happens by accident.

Performance: Prototype-based method lookup is fast but not free. For extremely hot paths (millions of calls), inlining methods directly on instances can be faster, at the cost of memory.

new returning an explicit object: If the constructor returns a plain object, new gives you that object instead of the auto-created one. This breaks instanceof and is almost always a mistake.

function Weird() {
  return { surprise: true }; // new Weird() instanceof Weird → false
}

Conclusion

The new keyword is four steps in sequence: create, link, run, return. Every behavior you observe — instanceof, inherited methods, shared state, constructor-less calls breaking — follows directly from those four steps. Internalize them and constructor functions become completely predictable.

The natural next step is ES6 class syntax, which wraps this mechanism in a safer, more expressive API without changing the underlying model.

Further Reading

• MDN: new operator

• MDN: Object prototypes

• You Don't Know JS: this & Object Prototypes

• MDN: class syntax

• MDN: Object.create() — for the prototype-only pattern without constructors

Audience: This post assumes basic JavaScript knowledge. No framework experience required.

Problem

String concatenation in JavaScript has always worked — but it's never been readable.

Consider building a user greeting with a name, role, and login time:

// Traditional concatenation
const name = "Hitesh";
const role = "admin";
const loginTime = "08:42 AM";

const message = "Welcome back, " + name + "! You are logged in as " + role + ". Last login: " + loginTime + ".";

This works. But:

• Every " and + is a chance to make a typo

• Reading the output string requires mentally reassembling fragments

• Adding multi-line output requires \n escapes or ugly concatenation chains

• Nesting conditional expressions turns into a visual nightmare

The more complex your strings, the worse this gets.

Solution

Template literals (introduced in ES2015) replace quote characters with backticks (`) and support inline expressions using ${}.

// Template literal version
const name = "Hitesh";
const role = "admin";
const loginTime = "09:42 AM";

const message = `Welcome back, \({name}! You are logged in as \){role}. Last login: ${loginTime}.`;

Same output. Half the noise.

Core Syntax

1. Embedding Variables

Any valid JavaScript expression goes inside ${}. Variables, function calls, ternaries — all fair game.

const user = { name: "Arjun", age: 28 };

// Variable
console.log(`User: ${user.name}`);
// → User: Arjun

// Arithmetic
console.log(`Born around: ${new Date().getFullYear() - user.age}`);
// → Born around: 1997

// Function call
const greet = (name) => `Hello, ${name}!`;
console.log(`${greet(user.name)} Welcome back.`);
// → Hello, Arjun! Welcome back.

// Ternary
const status = true;
console.log(`Account is ${status ? "active" : "suspended"}.`);
// → Account is active.

Why this matters: The expression is evaluated at runtime. You're not just inserting strings — you're embedding logic.

2. Multi-line Strings

With concatenation, multi-line strings are painful:

// Old way
const html = "<div>\n" +
  "  <h1>Hello</h1>\n" +
  "  <p>World</p>\n" +
  "</div>";

Template literals preserve actual newlines in the source:

// New way
const html = `
<div>
  <h1>Hello</h1>
  <p>World</p>
</div>
`;

console.log(html);
// →
// <div>
//   <h1>Hello</h1>
//   <p>World</p>
// </div>

No \n. No +. The string looks exactly like what gets output.

3. Expressions Inside Interpolation

You can embed any expression — including conditionals and array operations:

const items = ["TypeScript", "React", "Node.js"];
const isPremium = true;

const summary = `
Skills: ${items.join(", ")}
Plan: ${isPremium ? "Premium" : "Free"}
Total skills: ${items.length}
`.trim();

console.log(summary);
// → Skills: TypeScript, React, Node.js
// → Plan: Premium
// → Total skills: 3

Before vs. After: Visual Comparison

──────────────────────────────────────
BEFORE: String Concatenation
──────────────────────────────────────

  "Hello, " + firstName + " " + lastName + "! You have " + count + " messages."

  Problems:
  ┌─ Hard to scan at a glance
  ├─ Error-prone (missing spaces, mismatched quotes)
  └─ Gets worse with more variables


──────────────────────────────────────
AFTER: Template Literals
──────────────────────────────────────

  `Hello, \({firstName} \){lastName}! You have ${count} messages.`

  Wins:
  ┌─ Structure of the output is immediately visible
  ├─ Variables are clearly marked with ${}
  └─ Scales gracefully with complexity
──────────────────────────────────────

Use Cases in Modern JavaScript

Use Case 1: Building HTML Strings

const product = {
  name: "Mechanical Keyboard",
  price: 4999,
  inStock: true,
};

const card = `
  <div class="product-card">
    <h2>${product.name}</h2>
    <p>Price: ₹${product.price.toLocaleString("en-IN")}</p>
    <span class="${product.inStock ? "badge--green" : "badge--red"}">
      ${product.inStock ? "In Stock" : "Out of Stock"}
    </span>
  </div>
`.trim();

console.log(card);

Expected output:

<div class="product-card">
  <h2>Mechanical Keyboard</h2>
  <p>Price: ₹4,999</p>
  <span class="badge--green">
    In Stock
  </span>
</div>

Use Case 2: Logging with Context

const requestId = "req_7f3a91";
const endpoint = "/api/users";
const statusCode = 404;
const duration = 38;

console.error(`[\({requestId}] \){endpoint} returned \({statusCode} in \){duration}ms`);
// → [req_7f3a91] /api/users returned 404 in 38ms

Structured log lines like this are far easier to parse — both for humans and log aggregators.

Use Case 3: SQL / Query Building

const userId = 42;
const limit = 10;
const offset = 20;

// Note: For production use, always use parameterised queries.
// This example shows readability — not injection-safe raw query building.
const queryDescription = `
  SELECT * FROM orders
  WHERE user_id = ${userId}
  ORDER BY created_at DESC
  LIMIT \({limit} OFFSET \){offset}
`;

console.log(queryDescription.trim());

Use Case 4: Error Messages

function divide(a, b) {
  if (b === 0) {
    throw new Error(`Division by zero: cannot divide \({a} by \){b}`);
  }
  return a / b;
}

try {
  divide(10, 0);
} catch (err) {
  console.error(err.message);
  // → Division by zero: cannot divide 10 by 0
}

Error messages with context tell you exactly what broke — without needing to add a debugger.

Use Case 5: Tagged Templates (Advanced)

Tagged templates let you process a template literal with a function. This is how libraries like styled-components and graphql-tag work.

// A simple "safe HTML" tag that escapes user input
function safeHtml(strings, ...values) {
  const escaped = values.map((val) =>
    String(val)
      .replace(/&/g, "&")
      .replace(/</g, "&lt;")
      .replace(/>/g, "&gt;"),
  );

  return strings.reduce(
    (result, str, i) => result + str + (escaped[i] ?? ""),
    "",
  );
}

const userInput = "<script>alert('xss')</script>";
const output = safeHtml`<p>User said: ${userInput}</p>`;

console.log(output);
//<p>User said: &lt;script&gt;alert('xss')&lt;/script&gt;</p>

The tag function receives strings (the static parts) and values (the interpolated expressions) separately — letting you sanitize, transform, or reformat before the final string is assembled.

String Interpolation: How It Works

Template literal at parse time:
─────────────────────────────────────
`Hello, \({firstName}! You have \){count} new messages.`
│ │ │
│ └── Expression 1 └── Expression 2
└── Static text fragments: ["Hello, ", "! You have ", " new messages."]

At runtime:
──────────────────────────────────────
Static[0] + eval(Expr1) + Static[1] + eval(Expr2) + Static[2]
"Hello, " + "Hitesh" + "! You have " + "3" + " new messages."

Result:
──────────────────────────────────────
"Hello, Hitesh! You have 3 new messages."

The JavaScript engine splits the template into alternating static strings and dynamic expressions, evaluates each expression, then joins them in order. This is also how tagged templates intercept the process.

Results

Switching from string concatenation to template literals:

Trade-offs

Template literals are not a universal upgrade. Know when to hold back:

1. They don't sanitize input by default. ${userInput} embeds the value as-is. Never use raw template literals to build SQL queries or HTML from untrusted input without sanitization. Use tagged templates or a library for that.

2. Nesting gets ugly fast.

// This is valid but borderline unreadable
const msg = `\({isLoggedIn ? `Welcome, \){user.name}` : `Please ${`log in`}`}`;

When you reach two levels of nesting, extract to a variable or function.

3. No lazy evaluation. Expressions inside ${} are evaluated immediately when the template literal is encountered. You can't defer execution without wrapping in a function.

const expensiveValue = `Result: ${computeHeavyThing()}`; // Runs immediately
const deferred = () => `Result: ${computeHeavyThing()}`; // Runs on call

Conclusion

Template literals are a small change with a large payoff. They make string construction readable, reduce typo-prone punctuation, and unlock multi-line and expression embedding with zero overhead.

Start with the basics — replace + with backticks where you build complex strings. Once comfortable, explore tagged templates for sanitization, internationalization, or DSL use cases.

The goal is code that communicates clearly. Template literals move in that direction.

Further Reading

1. MDN: Template literals — Complete specification with edge cases

2. MDN: Tagged templates — How styled-components and graphql-tag work under the hood

3. ES2015 spec: Template Literal Revision — If you want to go deep on the grammar

4. styled-components docs — Real-world tagged template usage in CSS-in-JS

5. OWASP: XSS Prevention — Context for why sanitizing interpolated values matters

"I thought I knew strings. Then an interview asked me to implement .includes() from scratch — and I froze."

🌍 Why This Problem Matters

Here's the thing: JavaScript is everywhere. But JavaScript engines? Not all equal.

A feature like String.prototype.replaceAll wasn't added until ES2021. Before that, if you needed to replace all occurrences of a character in a string — on an older browser, an old Node.js runtime, or a legacy environment — you'd get:

TypeError: str.replaceAll is not a function

That's a real production bug. And it happens more than you think in banking apps, government portals, and IoT dashboards where the runtime is frozen years behind.

This is where polyfills come in. A polyfill is just a piece of code that says:

"Hey, if this method doesn't exist natively — here, I'll build it for you."

At scale — millions of users, hundreds of browser versions, dozens of environments — polyfills aren't optional. They're survival tools.

🧠 Basic Concept — What Even Is a String Method?

Before we implement anything, let's build intuition.

Think of a JavaScript string like a train. Each character is a passenger sitting in a numbered seat: seat 0, seat 1, seat 2... and so on till the end of the line.

A string method is like a train attendant who walks through and does something — counts passengers, checks tickets, rearranges seating. When you call "hello".toUpperCase(), the attendant walks through and shouts every passenger's name louder.

Now: where do these methods live?

They live on String.prototype — a shared blueprint that every string in JavaScript inherits from. It's like a rulebook that every train in the network follows.

console.log(typeof String.prototype.trim);   // "function"
console.log(typeof String.prototype.includes); // "function"

This is important. Because when you write a polyfill, you're adding a new rule to that shared rulebook — but only if the rule doesn't already exist.

⚠️ Where Things Break — The Polyfill Trap

Okay, here's where it gets interesting.

I assumed polyfills are just "backup code." Simple. Safe. Harmless.

I was wrong.

Here's a classic mistake beginners make. They write a polyfill like this:

String.prototype.includes = function(search) {
  return this.indexOf(search) !== -1;
};

Do you see the problem?

They didn't check if includes already exists. So they're overwriting the native, optimized, spec-compliant version with a custom one. In some environments, the native version handles edge cases (like regex-like inputs, or Unicode normalization) that your version doesn't.

At scale — imagine this running on a Node.js server handling 10,000 requests per second — you've just silently degraded performance across your entire application. And the bug is nearly invisible.

The right pattern:

if (!String.prototype.includes) {
  String.prototype.includes = function(search, start) {
    if (typeof start !== 'number') start = 0;
    return this.indexOf(search, start) !== -1;
  };
}

The if (!String.prototype.includes) guard is the entire difference between safe and dangerous.

💥 Aha Moment — What Interviewers Are Actually Testing

This is where it clicked for me.

When an interviewer asks you to implement trim() or includes() from scratch, they don't care if you know the answer. They care about how you think.

They want to know:

1. Do you understand what the method is supposed to do? (spec knowledge)

2. Can you handle edge cases? (defensive thinking)

3. Do you reach for loops instinctively? (engineering intuition)

This is actually crazy 🤯 — because the "simple" question "implement trim()" is hiding a systems design question: "Do you understand how primitive types and prototype chains work?"

Let me show you what I mean.

🛠️ Advanced Solutions — Implementing the Core Methods

Let's go method by method. For each, I'll explain the intuition first, then the implementation.

1. String.prototype.trim()

Intuition: Imagine you have a sentence written on paper with a bunch of blank spaces on the left and right margins. Trim just removes those margins — it doesn't touch anything in the middle.

What it does: Removes leading (left) and trailing (right) whitespace — spaces, tabs (\t), newlines (\n).

if (!String.prototype.myTrim) {
  String.prototype.myTrim = function() {
    let start = 0;
    let end = this.length - 1;

    // Walk forward until we hit a non-whitespace character
    while (start <= end && this[start] === ' ') start++;

    // Walk backward until we hit a non-whitespace character
    while (end >= start && this[end] === ' ') end--;

    return this.slice(start, end + 1);
  };
}

console.log("   hello world   ".myTrim()); 

Edge case most people miss: What about tabs and newlines? The native trim() handles all whitespace (\t, \n, \r). A robust polyfill uses a regex test:

String.prototype.myTrimFull = function() {
  return this.replace(/^\s+|\s+$/g, '');
};

This is what trim() does under the hood — it's essentially a regex operation on both ends.

2. String.prototype.includes()

Intuition: Think of includes() like using Ctrl+F in a browser. You type a word, and the browser scans the entire page to see if it finds that word anywhere.

What it does: Returns true if the search string exists anywhere inside the main string, false otherwise.

if (!String.prototype.myIncludes) {
  String.prototype.myIncludes = function(search, startIndex) {
    if (search === undefined) return false;
    if (typeof startIndex !== 'number') startIndex = 0;

    const str = String(this);
    const searchStr = String(search);

    // Can't find something longer than what we're searching in
    if (searchStr.length > str.length) return false;

    for (let i = startIndex; i <= str.length - searchStr.length; i++) {
      if (str.slice(i, i + searchStr.length) === searchStr) {
        return true;
      }
    }

    return false;
  };
}

console.log("hello world".myIncludes("world")); // true
console.log("hello world".myIncludes("xyz"));   // false
console.log("hello world".myIncludes("world", 7)); // false (starts searching from index 7)

The startIndex parameter is what most candidates forget. The native includes() accepts a second argument — where to begin the search. Miss that in an interview, and you've missed a spec detail.

3. String.prototype.startsWith()

Intuition: Like checking if someone's name on an attendance list starts with "Saurabh." You don't read the whole entry — just the first few characters.

if (!String.prototype.myStartsWith) {
  String.prototype.myStartsWith = function(search, position) {
    const str = String(this);
    if (typeof position !== 'number') position = 0;

    return str.slice(position, position + search.length) === search;
  };
}

console.log("javascript".myStartsWith("java")); // true
console.log("javascript".myStartsWith("script", 4)); // true

Notice the clean logic: slice exactly search.length characters from the position, then compare. One slice, one comparison. That's it.

4. String.prototype.repeat()

Intuition: Like a copy machine. You feed in one page and tell it: "give me 5 copies."

if (!String.prototype.myRepeat) {
  String.prototype.myRepeat = function(count) {
    count = Math.floor(count);

    if (count < 0) throw new RangeError('Invalid count value');
    if (count === 0) return '';

    let result = '';
    for (let i = 0; i < count; i++) {
      result += this;
    }

    return result;
  };
}

console.log("ha".myRepeat(3)); // "hahaha"
console.log("*".myRepeat(5)); // "*****"

Interview insight: This is O(n × k) — linear in both the string length and the count. At scale, repeating large strings thousands of times can be a memory problem. A smarter approach doubles the string repeatedly (like exponentiation by squaring), but interviewers rarely expect that unless they hint toward optimization.

5. String.prototype.replaceAll() — The Tricky One

Intuition: The classic replace() is like a search-and-replace that stops after the first match. replaceAll() keeps going until there's nothing left to replace — like a global search-replace in a code editor.

if (!String.prototype.myReplaceAll) {
  String.prototype.myReplaceAll = function(search, replacement) {
    // Escape special regex characters in the search string
    const escaped = String(search).replace(/[.*+?^\({}()|[\]\\]/g, '\\\)&');
    return this.replace(new RegExp(escaped, 'g'), replacement);
  };
}

console.log("cat and cat and cat".myReplaceAll("cat", "dog"));
// "dog and dog and dog"

Where I went wrong initially: I tried to do this with a while loop and indexOf. It works but it's error-prone — if your replacement string contains the search string, you get an infinite loop. The regex approach with 'g' flag is cleaner and is actually how browsers implement it internally.

6. Common Interview Problem — Reverse a String

Not a built-in method, but this comes up constantly.

function reverseString(str) {
  // Naive: split → reverse → join
  return str.split('').reverse().join('');
}

// Without built-ins:
function reverseStringManual(str) {
  let result = '';
  for (let i = str.length - 1; i >= 0; i--) {
    result += str[i];
  }
  return result;
}

console.log(reverseString("javascript")); // "tpircsavaj"

Depth question: What about Unicode? Emoji and multi-byte characters can break naive reversal because they span multiple character codes.

"😊abc".split('').reverse().join(''); // "cba😊" — ✅ works here, but...
"👨‍👩‍👧".split('').reverse().join(''); // ❌ garbled family emoji

This is a 🤯 moment — the naive solution fails on emoji families because they use multiple Unicode code points joined with invisible "zero-width joiner" characters. The spec-correct solution uses the spread operator with Unicode-aware iteration:

[..."👨‍👩‍👧".split(/(?:)/u)].reverse().join('');

A senior interviewer might push you here. I wish I knew this earlier.

7. Count Occurrences of a Character

Another classic interview question that tests your understanding of iteration and string indexing.

function countOccurrences(str, char) {
  let count = 0;
  for (let i = 0; i < str.length; i++) {
    if (str[i] === char) count++;
  }
  return count;
}

// Or one-liner using split:
function countOccurrences2(str, char) {
  return str.split(char).length - 1;
}

console.log(countOccurrences("banana", "a")); // 3

Insight: The split trick is clever but has a conceptual overhead — you're creating an entire array just to count. For very long strings, the loop version is more memory-efficient.

⚖️ Tradeoffs — When to Write Polyfills, When to Skip

Let me be honest: polyfills aren't always the right call.

Performance vs consistency: A handwritten polyfill is almost never as fast as the native implementation, which is usually written in C++ inside the V8 engine. So you're trading speed for compatibility.

Simplicity vs correctness: The simple version of trim() (just removing spaces) might miss edge cases like non-breaking spaces (\u00A0). The correct version uses a regex — which is less readable but more compliant with the spec.

🚀 Real-World Usage

Babel + core-js is how modern teams handle this at scale. When you write "hello".includes("ell") and Babel transpiles it, core-js automatically injects the polyfill for environments that need it — and skips it where it's not needed.

At IBM, we work on Maximo — an enterprise asset management platform that runs on some environments where you can't always guarantee the latest JS runtime. Understanding what polyfills do (even if Babel handles them for us) helps us debug weird runtime issues and write code that doesn't surprise us in production.

Browser support tools like Browserslist let you define which browsers your app supports. Combined with a bundler, polyfills are injected selectively — so modern Chrome users don't download KB of unnecessary compatibility code, while users on older browsers get exactly what they need.

🧾 Final Summary

• String methods live on String.prototype — a shared blueprint for all strings.

• Polyfills inject custom implementations only when native ones don't exist.

• Always guard with if (!String.prototype.method) before injecting.

• Common interview methods: trim, includes, startsWith, repeat, replaceAll.

• Edge cases are the real test: Unicode, empty strings, negative indices, non-string inputs.

• At scale: use Babel + core-js — don't hand-roll polyfills in production apps unless you have very specific needs.

🙌 Personal Reflection

What surprised me most isn't the code — it's what these questions are really asking.

When an interviewer says "implement includes()", they're not running a trivia quiz. They're checking: do you think about the thing before you build it? Do you consider edge cases? Do you understand the contract your code makes?

I used to use string methods like appliances — plug in, press button, get result. Now I think about them differently. They're tiny algorithms. Each one is a small engineering decision made by someone who thought hard about performance, correctness, and API design.

That's what I wish I knew before that interview. And honestly? Getting stumped was the best thing that happened to me — because it sent me down this rabbit hole.

Understanding the internals makes you better at using the externals. Every time.

Written by Saurabh Prajapati — Software Engineer @ IBM India Software Lab - WebDev Cohort 2026

Written by Saurabh Prajapati Software Engineer @ IBM India Software Lab

🔥 Hook — The Moment That Confused Me

I remember the first time I saw this in someone's code:

fs.readFile('data.txt', function(err, data) {
  console.log(data);
});

I stared at it and thought — "Why are we passing a function… inside another function?"

It felt weird. Like, why not just return the data and use it?

That confusion is exactly what this blog is about. By the end, you'll not only understand what callbacks are — you'll understand why JavaScript needed them in the first place.

🌍 Why This Problem Matters

JavaScript runs in the browser. And the browser does a lot of waiting.

• Waiting for a network request to finish

• Waiting for a file to be read

• Waiting for a user to click a button

If JavaScript stopped and waited for each of these — your entire page would freeze. No scrolling. No interaction. Nothing.

That's a terrible user experience.

Callbacks were JavaScript's first answer to this problem. They're the foundation of async programming in JS — and even though we have Promises and async/await today, they're all built on the same idea.

Understanding callbacks = understanding JavaScript's soul.

🧠 Basic Concept — Start Here

Functions are Values in JavaScript

This is the key insight that makes callbacks possible.

In most languages, a function is just a function. You define it, you call it. That's it.

But in JavaScript, a function is a value — just like a number or a string.

Which means you can:

// Store a function in a variable
const greet = function() {
  console.log("Hello!");
};

// Pass a function as an argument
function runIt(fn) {
  fn(); // call whatever was passed in
}

runIt(greet); // prints: Hello!

Read that again. We passed greet into runIt — and runIt called it.

That function we passed? That's a callback.

A callback is just a function you pass to another function, so that other function can call it later.

Simple. That's it.

A Real-World Analogy

Imagine you order food at a restaurant.

You don't stand at the counter, frozen, waiting for your food. That would be ridiculous.

Instead, you give the waiter your number (the callback). You go sit down. When the food is ready, they call you back.

JavaScript works the same way.

⚠️ Where Things Break — The Async Reality

Here's where it gets interesting.

Why Can't We Just Return the Value?

Let's say you want to read a file:

// You wish this worked...
const data = readFile('data.txt');
console.log(data); // undefined 

This returns undefined. Not because readFile is broken — but because the file isn't ready yet.

JavaScript didn't wait. It moved on. By the time readFile finished, your console.log had already run and left.

This is the core problem of asynchronous programming.

So We Use a Callback:

readFile('data.txt', function(err, data) {
  // This runs AFTER the file is ready
  console.log(data); // ✅ works!
});

Now we're not asking for the value immediately. We're saying:

"Hey, when you're done — call this function with the result."

That's the entire philosophy of callbacks.

💥 The Aha Moment

Here's what clicked for me:

Callbacks don't solve async problems by waiting. They solve it by saying what to do next.

Instead of blocking the thread (like most languages do), JavaScript hands off the task and continues running. When the task is done, it calls your function.

This is what makes JavaScript non-blocking. This is why it can handle thousands of users in a web server without breaking a sweat.

It's not magic. It's just callbacks.

🛠️ Callbacks in Common Scenarios

1. Event Listeners

The most common callback you'll ever write:

document.getElementById('btn').addEventListener('click', function() {
  console.log('Button clicked!');
});

You're saying: "When this button is clicked, run this function."

That function? Callback.

2. setTimeout / setInterval

console.log("Start");

setTimeout(function() {
  console.log("This runs after 2 seconds");
}, 2000);

console.log("End");

Output:

Start
End
This runs after 2 seconds

Wait — End printed before the timeout? Yes!

JavaScript didn't stop at setTimeout. It registered the callback and moved on. After 2 seconds, the callback was called.

This confused me a lot at first. Now it makes total sense.

3. Array Methods

const numbers = [1, 2, 3, 4];

const doubled = numbers.map(function(num) {
  return num * 2;
});

console.log(doubled); // [2, 4, 6, 8]

map takes a callback and calls it for every element. This is a synchronous callback — but it's still a callback.

Callbacks aren't only for async code. They're for "tell me what to do" situations.

4. Node.js File Reading

const fs = require('fs');

fs.readFile('notes.txt', 'utf8', function(err, data) {
  if (err) {
    console.error("Something went wrong:", err);
    return;
  }
  console.log("File contents:", data);
});

Classic Node.js pattern. The callback gets two arguments: err and data. Always check err first.

⚠️ The Basic Problem — Callback Nesting

Now here's where things get ugly.

What if you need to do multiple async operations in sequence?

getUser(userId, function(err, user) {
  getPosts(user.id, function(err, posts) {
    getComments(posts[0].id, function(err, comments) {
      getAuthor(comments[0].authorId, function(err, author) {
        console.log(author.name);
        // ... and it keeps going
      });
    });
  });
});

This is called Callback Hell (or the Pyramid of Doom).

Look at the shape of that code. It keeps going right. It's hard to read, hard to debug, and easy to mess up.

Problems with this:

• Error handling becomes a nightmare — you have to handle err at every single level

• Logic is hard to follow — the flow is buried inside nesting

• Debugging is painful — stack traces are confusing

• Reuse is nearly impossible — the code is tightly coupled

Why Does This Happen?

Because each operation depends on the result of the previous one. You need the user before you can fetch posts. You need posts before you can fetch comments.

With callbacks, the only way to chain dependent async tasks is to nest them. And nesting = the pyramid.

This is the conceptual problem that Promises and async/await were designed to solve.

But that's a story for another blog.

⚖️ Tradeoffs

When to use callbacks:

• Event listeners (always)

• Simple one-off async tasks

• Array methods like map, filter, forEach

• When you're working in older codebases

When NOT to use raw callbacks:

• When you have 3+ dependent async operations

• When you need clean error handling across steps

• When readability matters (use Promises or async/await instead)

🚀 Real-World Usage

Callbacks are everywhere, even if you don't notice them:

• React's onClick, onChange — all callbacks

• Express.js route handlers — callbacks

• Array.prototype.sort() — takes a comparator callback

• setTimeout / setInterval — callbacks

• Node.js fs, http modules — callback-based APIs

Even inside Promises and async/await, the engine is using callbacks under the hood. You're just writing cleaner syntax on top.

🧾 Final Summary

Core insight: A callback is just JavaScript's way of saying — "Don't wait. When you're ready, call me."

📚 What's Next?

Now that you understand callbacks, the natural next step is:

• Promises — how JavaScript cleaned up the callback mess

• async/await — how we write async code that looks synchronous

• Event Loop — the engine that makes all of this work

Each one builds on callbacks. Understanding this foundation makes everything else easier.

Written by Saurabh Prajapati (SP) Software Engineer @ IBM India Software Lab Builds scalable web & AI systems · Loves system design & real-world problems · Shares learnings openly

The Real Problem: Code Without Boundaries

Before we even talk about modules, let me paint a picture of what life looks like without them.

Imagine you're building a small web app. You have functions for doing math calculations, functions for formatting dates, functions for fetching user data, and functions for rendering things on screen. If all of this lives in one file, a few bad things start happening.

First, naming collisions become a nightmare. If you accidentally name two functions the same thing, one silently overwrites the other. JavaScript won't warn you. It'll just break in mysterious ways.

Second, dependencies become invisible. When everything is global, any function can call any other function. There's no clear map of what depends on what. You change one thing, and something completely unrelated breaks.

Third, reusing code becomes painful. Say you want to use your date-formatting function in another project. You'd have to copy the entire file, including all the unrelated stuff — or carefully extract just that one function.

Modules solve all three of these problems elegantly. Think of a module as a self-contained unit of code — like a toolbox that holds only the tools relevant to one specific job. It hides what's internal and only exposes what other parts of your app actually need.

What Even Is a Module?

In JavaScript, a module is just a file. Seriously — that's it. Any .js file can be a module. What makes it a module rather than a plain script is that it has its own scope.

This is the key mental model to internalize: variables and functions defined in a module are private by default. They don't leak into the global scope. Nothing outside that file can see them unless you explicitly choose to share them.

That explicit sharing is what export is for. And pulling shared things into your file is what import is for.

Let's see this in action.

Exporting: Sharing What You Want Others to Use

Say you have a file called mathUtils.js that handles some common calculations.

// mathUtils.js

// This function is private — only usable inside this file
function square(n) {
  return n * n;
}

// These are exported — other files can use them
export function add(a, b) {
  return a + b;
}

export function multiply(a, b) {
  return a * b;
}

export const PI = 3.14159;

Notice the square function? It has no export keyword. That means it stays completely private inside mathUtils.js. The outside world doesn't even know it exists. This is intentional — you only expose what others actually need.

You can also export things at the bottom of the file, which a lot of people (including me) find more readable:

// mathUtils.js — alternative export style

function add(a, b) {
  return a + b;
}

function multiply(a, b) {
  return a * b;
}

const PI = 3.14159;

// Export everything at once at the bottom
export { add, multiply, PI };

Both approaches do exactly the same thing. It's a style preference — but the bottom export style has a nice advantage: you can see at a glance what the module's public API is just by looking at the last line.

Importing: Pulling In What You Need

Now let's say you have a main.js file that wants to use those math utilities.

// main.js

// Destructure exactly what you need from the module
import { add, multiply, PI } from './mathUtils.js';

console.log(add(3, 4));       // 7
console.log(multiply(5, 6));  // 30
console.log(PI);              // 3.14159

The { add, multiply, PI } syntax is called named imports. You're cherry-picking exactly what you need. This is great because:

• You don't import unnecessary stuff (keeps things lean)

• It's self-documenting — anyone reading this file knows exactly what it depends on

• Your editor can autocomplete and catch typos instantly

What if you want to import everything a module exports, all at once? You can do that too, using a namespace import:

// Import everything under a single namespace object
import * as MathUtils from './mathUtils.js';

console.log(MathUtils.add(2, 3));   // 5
console.log(MathUtils.PI);          // 3.14159

I personally use this when I'm importing from a file with lots of exports and I don't want to list them all individually. The tradeoff is that you lose some of that self-documenting clarity — MathUtils.add is a little more verbose than just add.

Default vs Named Exports — What's the Difference?

This is the part that confused me the most at first. Let me break it down clearly.

Named exports are what we've been using so far. A file can have as many named exports as it wants, and each one has a specific name that importers must match.

Default exports are different. Each file can have exactly one default export, and when you import it, you can call it whatever you want.

Here's a classic use case — a React-style component:

// UserCard.js

// The main thing this file does — a default export
export default function UserCard({ name, role }) {
  return `<div>\({name} — \){role}</div>`;
}

// A helper used only in this file — not exported at all
function formatName(name) {
  return name.trim().toUpperCase();
}

Now when you import it:

// You can name it anything — no curly braces needed
import UserCard from './UserCard.js';

// Or even rename it entirely (useful when names clash)
import ProfileWidget from './UserCard.js';

No curly braces. No need to match the original name. Total flexibility on the importer's side.

You can also mix both in the same file, which is very common in libraries:

// theme.js

export const colors = { primary: '#d4762a', text: '#1e1c18' };
export const spacing = { sm: '8px', md: '16px', lg: '32px' };

// The "main" export — what this file is fundamentally about
export default {
  colors,
  spacing,
  fontFamily: 'DM Sans, sans-serif'
};

// Importing both at once
import theme, { colors, spacing } from './theme.js';

The rule of thumb I follow: use a default export when the file represents one primary "thing" (a component, a class, a main function). Use named exports for utility files that provide multiple related tools.

Seeing the Full Picture: A File Dependency Diagram

Let me show you how modules connect in a real app. Imagine you're building a small user management feature.

src/
├── utils/
│   ├── mathUtils.js        (exports: add, multiply, PI)
│   ├── formatUtils.js      (exports: formatDate, formatName)
│   └── validators.js       (exports: isEmail, isRequired)
│
├── components/
│   └── UserCard.js         (default export: UserCard component)
│                           (imports from: formatUtils.js)
│
├── services/
│   └── userService.js      (exports: fetchUser, saveUser)
│                           (imports from: validators.js)
│
└── main.js                 ← entry point
                            (imports from: UserCard.js, userService.js)

See how the dependency flow is clear and one-directional? main.js imports from UserCard.js and userService.js. Those in turn import from utility files. Nothing is tangled. If you need to change how names are formatted, you go to formatUtils.js — and only there.

This is what "separation of concerns" actually looks like in practice.

The Import/Export Flow at a Glance

Here's a simple mental model of how data flows between modules:

┌─────────────────────────────────┐
│          mathUtils.js           │
│                                 │
│  function add(a, b) { ... }     │
│  function multiply(a, b) { .. } │
│  const PI = 3.14159             │
│                                 │
│  export { add, multiply, PI }   │
│         ↓ named exports         │
└──────────┬──────────────────────┘
           │  (flows into)
           ▼
┌─────────────────────────────────┐
│            main.js              │
│                                 │
│  import { add, PI }             │
│    from './mathUtils.js'        │
│                                 │
│  console.log(add(2, 3))  → 5   │
│  console.log(PI)  → 3.14159    │
└─────────────────────────────────┘

The exporting file says: "Here's what I'm willing to share." The importing file says: "Here's exactly what I need." Everything else stays private.

Key Discoveries Along the Way

The ./ at the start of the path matters. When I first tried writing import { add } from 'mathUtils.js', nothing worked. The ./ tells JavaScript you're importing from a relative file path, not an installed package. Without it, JavaScript looks for an npm package named mathUtils.js and obviously can't find it. I wish someone had told me this on day one.

Modules are singletons. If three different files all import from mathUtils.js, JavaScript only loads and runs mathUtils.js once. They all share the same instance. This is actually very useful — it means you can store state in a module and it acts like a shared, controlled global.

Circular imports exist and they're a code smell. If fileA.js imports from fileB.js, and fileB.js imports from fileA.js, you have a circular dependency. JavaScript technically handles this, but it often leads to confusing bugs where something is undefined when you expect it to have a value. If you notice a circle forming, it's usually a sign to extract the shared thing into a third file.

You can rename on import. This one was a pleasant surprise:

// Rename to avoid naming conflicts
import { add as addNumbers, multiply as multiplyNumbers } from './mathUtils.js';

Super useful when two different modules export something with the same name.

Benefits of Modular Code

Once I restructured my old Thitainfo-code project into modules, the improvement was immediate and dramatic.

Maintainability shoots up. Each file has a clear, focused responsibility. When a bug shows up in date formatting, you know exactly which file to open.

Reusability becomes natural. Your validators.js can be dropped into any project. Zero rework required.

Collaboration gets easier. Two developers can work on different modules simultaneously without stepping on each other's code. The boundaries are enforced by the language itself.

Testability improves dramatically. A module with a clear input-output contract is trivially easy to unit test. You import it, call it, check the result. No global state, no hidden dependencies.

What Can You Build With This?

Now that you understand modules, a whole pattern opens up. Here's a quick practical example — a mini utility library for a project:

// lib/string.js
export function capitalize(str) {
  return str.charAt(0).toUpperCase() + str.slice(1).toLowerCase();
}

export function truncate(str, maxLength) {
  if (str.length <= maxLength) return str;
  return str.slice(0, maxLength) + '...';
}

export function slugify(str) {
  return str.toLowerCase().replace(/\s+/g, '-').replace(/[^\w-]/g, '');
}

// lib/index.js — a "barrel" file that re-exports everything
export * from './string.js';
export * from './math.js';
export * from './validators.js';

// Now in your app, one clean import gives you everything
import { capitalize, slugify, isEmail } from './lib/index.js';

This pattern — where an index.js re-exports from multiple files — is called a barrel export. It's extremely common in professional codebases. It gives your app a single, clean entry point into a whole collection of utilities.

Wrapping Up

Here's what clicked for me after going through all of this: modules aren't a fancy advanced feature. They're just a formalization of something every developer intuitively wants — organized code with clear boundaries.

The export keyword is your way of saying, "This is the contract I'm offering to the outside world." The import keyword is your way of saying, "These are the exact things I'm depending on." Everything else stays hidden, protected, and clean.

If your codebase currently lives in one big file, I'd genuinely encourage you to try splitting just one logical piece out into its own module. Format it, export it, import it back. You'll feel the difference immediately.

And then — like me — you probably won't want to go back.

About the Author

Saurabh Prajapati is a Full-Stack Software Engineer at IBM India Software Lab, where he builds cloud-native, enterprise-level solutions for the Maximo platform. He specializes in GenAI, React, and modern web technologies, and has worked on everything from AI-powered tools and RAG pipelines to scalable web platforms.

When he's not shipping features at IBM, he's writing about the things he's actively learning — because the best way to understand something is to explain it.

• 📧 saurabhprajapati120@gmail.com

• 🐙 github.com/prajapatisaurabh

• 💼 linkedin.com/in/saurabh-prajapati

Author: Saurabh Prajapati · Software Engineer @ IBM India · May 2025

The Mystery That Started This

I was writing some async Node.js code and stumbled across something that genuinely confused me. Look at this snippet:

setTimeout(() => console.log("setTimeout"), 0);
setImmediate(() => console.log("setImmediate"));

I ran it and got:

setImmediate
setTimeout

Wait… what? I set the timeout to 0 milliseconds. That means "run immediately," right? So why did setImmediate run first?

Then I added one line — just a console.log at the top — and everything flipped:

console.log("Hello from console");
setTimeout(() => console.log("setTimeout"), 0);
setImmediate(() => console.log("setImmediate"));

Output:

Hello from console
setTimeout
setImmediate

Now setTimeout runs before setImmediate. How?! Both snippets look almost identical. This drove me crazy until I finally understood what Node.js is actually doing under the hood.

Let me walk you through exactly what I learned.

First, Let's Understand the Node.js Event Loop

Before we can solve this mystery, we need a mental model of how Node.js handles async code. Node.js is single-threaded, which means it can only do one thing at a time. But it can schedule things to happen later using the event loop.

Think of the event loop like a to-do list manager. It has different trays for different kinds of tasks, and it processes each tray in a specific order — every single tick.

The simplified order of phases looks like this:

┌─────────────────────────────────┐
│         timers phase            │  ← runs setTimeout / setInterval callbacks
├─────────────────────────────────┤
│      pending callbacks          │
├─────────────────────────────────┤
│        idle / prepare           │
├─────────────────────────────────┤
│          poll phase             │  ← waits for I/O, fetches new events
├─────────────────────────────────┤
│         check phase             │  ← runs setImmediate callbacks  ✅
├─────────────────────────────────┤
│      close callbacks            │
└─────────────────────────────────┘
         ↑ loops back up ↑

Two phases matter most for our mystery:

Timers phase is where setTimeout and setInterval callbacks live. Node checks: "Has enough time passed for this timer to be due?" If yes, it runs the callback.

Check phase is where setImmediate callbacks live. This phase always runs after the poll phase, every single loop iteration.

So the order in the loop is always: timers → ... → poll → check. That means setTimeout callbacks are checked before setImmediate callbacks in the phase order. You'd expect setTimeout to always win, right?

This is where it gets interesting.

The Real Culprit: Timer Precision

Here's the thing about setTimeout(fn, 0) — it doesn't actually mean "zero milliseconds." It means "run this after at least 0 milliseconds." The minimum delay in Node.js is technically 1ms, and even that isn't guaranteed because reading the system clock takes a tiny amount of time.

So when Node.js starts the event loop and reaches the timers phase, it asks the system clock: "Is the timer ready?" If that clock read happens to be just a hair too early — say the timer was registered 0.3ms ago and the minimum is 1ms — Node says "not yet" and skips the setTimeout callback for this tick.

Then the event loop continues to the check phase, runs setImmediate, and only on the next tick does it come back to timers and find that setTimeout is now ready.

This is why the output of the first snippet is non-deterministic — you might even see it flip if you run it multiple times. It entirely depends on the timing of when Node reads the clock.

So Why Does Code 2 Always Produce a Consistent Order?

This is the key insight. When you add console.log("Hello from console") at the top, you're running that code synchronously — it executes before the event loop even starts. The setTimeout and setImmediate are registered after that synchronous work completes.

By the time Node.js finishes the synchronous code and enters the event loop, a small but real amount of time has already passed. That extra time is almost always enough for the 1ms minimum timer threshold to be comfortably satisfied.

So when the event loop reaches the timers phase, it checks: "Is the setTimeout(0) ready?" And now the answer is yes — because enough real time has passed. It runs the setTimeout callback first, then moves on to the check phase and runs setImmediate.

Think of it this way:

No sync work before them → timer might not be ready → setImmediate can sneak in first → order is unpredictable.

Sync work before them → timer is definitely ready by the time event loop starts → setTimeout runs first → order is predictable.

Let's Cement This With the Timeline

Here's exactly what happens in Code 1 (no prior sync work):

1. Node.js starts the event loop almost immediately
2. Enters TIMERS phase → checks setTimeout(0)
   → "Is 1ms elapsed?" → Maybe not yet! → SKIPPED
3. Enters CHECK phase → runs setImmediate  ← prints "setImmediate"
4. Next iteration → TIMERS phase again
   → "Is 1ms elapsed?" → YES now → runs setTimeout  ← prints "setTimeout"

And here's what happens in Code 2 (with a sync console.log first):

1. Synchronous code runs: console.log("Hello from console")  ← prints immediately
   (This takes a few microseconds of real time)
2. Node.js enters the event loop
3. Enters TIMERS phase → checks setTimeout(0)
   → "Is 1ms elapsed?" → YES, sync work already used that time → runs it  ← prints "setTimeout"
4. Enters CHECK phase → runs setImmediate  ← prints "setImmediate"

One More Thing

If you call setTimeout and setImmediate inside an I/O callback, the order becomes always predictable — setImmediate will always run before setTimeout, no matter what. That's because I/O callbacks fire during the poll phase, and the check phase comes right after poll in every single loop iteration.

const fs = require("fs");

fs.readFile(__filename, () => {
  setTimeout(() => console.log("setTimeout"), 0);
  setImmediate(() => console.log("setImmediate"));
});

Output is always:

setImmediate
setTimeout

Inside an I/O callback, you're already past the timers phase. So setTimeout cannot possibly run until the next loop iteration. But setImmediate runs in the very next phase (check), so it always wins here.

This is why setImmediate is the recommended way to schedule something "right after the current I/O cycle" — it's predictable and reliable inside async callbacks.

The Final Answer

Let's bring it all together. The two snippets behave differently because:

Code 1 gives Node.js almost no time before the event loop starts. The setTimeout(0) timer might not have crossed the 1ms minimum threshold by the time the timers phase runs, so setImmediate (which lives in the check phase, guaranteed to run every loop) gets a chance to run first. This makes the output non-deterministic.

Code 2 runs a synchronous console.log first. That tiny bit of real-world execution time is enough for the timer to be considered ready by the time the event loop's timers phase runs. So setTimeout reliably fires first, followed by setImmediate. The output is predictable.

The deeper lesson is this: setTimeout(fn, 0) does not mean "run right now." It means "run as soon as possible after at least 1ms." The event loop's timer phase simply checks whether the delay has been satisfied — and sometimes the answer is "not quite yet."

Quick Reference

Try It Yourself

Run both snippets a few times and watch the output of Code 1 vary between runs — you might see it flip. Then wrap them inside a fs.readFile callback and notice that setImmediate always wins. Playing with it hands-on is what made this truly click for me.

About the Author

Saurabh Prajapati is a Full-Stack Software Engineer at IBM India Software Lab, working on Maximo — cloud-native enterprise solutions. He specializes in GenAI, React, and modern web technologies, and loves documenting his learning journey so others don't have to stumble on the same confusing bugs.

Connect with him: GitHub — prajapatisaurabh · LinkedIn — saurabh-prajapati · saurabhprajapati120@gmail.com

Why I Decided to Explore This

I'll be honest — for the longest time, this in JavaScript confused the heck out of me.

I'd write some code, it would work. I'd move the same function somewhere else, and suddenly this was undefined. I'd scratch my head, Google it, patch it with an arrow function, and move on without really understanding why.

Sound familiar?

After seeing call(), apply(), and bind() pop up again and again — in interview questions, open-source code, and MDN docs — I decided: okay, let's actually figure this out.

This blog is me documenting everything that finally made it click. Let's go.

1. What Is this in JavaScript?

Here's the simplest way to think about it:

this = "who is calling the function right now?"

this is not about where the function is written. It's about who is calling it at the moment it runs.

Think of it like a name tag that changes depending on who's wearing it.

function greet() {
  console.log("Hello, I am " + this.name);
}

If this is the window object, it looks for window.name.
If this is a user object, it looks for user.name.

Same function. Different this. Different result. That's the core idea.

2. this Inside Normal Functions

Let's start simple.

function sayHello() {
  console.log(this);
}

sayHello();

In a browser, this logs the window object (in non-strict mode).
In strict mode ("use strict"), this is undefined.

This tripped me up early on. I expected this to mean "the function itself." Nope. When no one specifically "calls" the function as a method, this defaults to the global object — or undefined in strict mode.

I wish I knew this earlier: this inside a plain function call doesn't refer to the function. It refers to whatever called it — often window by default.

3. this Inside Objects

Now it gets more interesting.

const developer = {
  name: "Saurabh",
  greet: function () {
    console.log("Hi, I'm " + this.name);
  },
};

developer.greet(); // Hi, I'm Saurabh

Here, developer is calling greet(). So this = developer. Makes sense, right?

But here's where it gets weird:

const greetFn = developer.greet;
greetFn(); // Hi, I'm undefined

Wait, what?

When you detach the function from the object and call it on its own, this no longer points to developer. It goes back to the global object (or undefined in strict mode).

This is the exact moment I thought — "Okay JavaScript, you're doing this on purpose to mess with me."

But it actually makes sense once you remember the rule: this depends on WHO is calling the function, not where the function lives.

4. What Does call() Do?

call() lets you manually set this when calling a function.

function greet(role) {
  console.log(`Hi, I'm \({this.name} and I work as a \){role}`);
}

const person = { name: "Saurabh" };

greet.call(person, "Software Engineer");
// Hi, I'm Saurabh and I work as a Software Engineer

Think of call() like saying:
"Hey function, run right now — and treat THIS object as your this."

Syntax

functionName.call(thisArg, arg1, arg2, ...);

• thisArg → the object you want this to be

• arg1, arg2, ... → normal function arguments, passed one by one

Real Use Case — Method Borrowing

const ibmDev = {
  name: "Saurabh",
  company: "IBM",
};

const visileanDev = {
  name: "Rahul",
  company: "Visilean",
};

function introduce() {
  console.log(`I'm \({this.name} from \){this.company}`);
}

introduce.call(ibmDev);     // I'm Saurabh from IBM
introduce.call(visileanDev); // I'm Rahul from Visilean

One function. Two different objects. call() makes it work for both.
This is called function borrowing — and it's actually super useful.

5. What Does apply() Do?

apply() is almost identical to call().

The only difference: instead of passing arguments one by one, you pass them as an array.

function greet(role, city) {
  console.log(`Hi, I'm \({this.name}, a \){role} from ${city}`);
}

const person = { name: "Saurabh" };

// call() — arguments one by one
greet.call(person, "Software Engineer", "India");

// apply() — arguments as an array
greet.apply(person, ["Software Engineer", "India"]);

Both produce the exact same output:

Hi, I'm Saurabh, a Software Engineer from India

When is apply() Useful?

It shines when your arguments are already in an array — like when using Math.max:

const scores = [85, 92, 78, 96, 88];

console.log(Math.max.apply(null, scores)); // 96

We pass null as thisArg because Math.max doesn't use this. We just need the array-spread behavior.

Honest take: With modern JavaScript, you can use the spread operator (...) instead of apply() in many cases. But knowing apply() helps you read older codebases — and it comes up in interviews all the time.

6. What Does bind() Do?

Here's where things get really interesting.

bind() doesn't call the function immediately. Instead, it returns a new function with this permanently bound to an object.

function greet() {
  console.log(`Hi, I'm ${this.name}`);
}

const person = { name: "Saurabh" };

const boundGreet = greet.bind(person);

// Call it whenever you want
boundGreet(); // Hi, I'm Saurabh
boundGreet(); // Hi, I'm Saurabh (still Saurabh, always Saurabh)

You get a function that remembers its this. Forever.

Real Use Case — Event Listeners

This is where bind() saves the day in React and vanilla JS:

const button = {
  label: "Click Me",
  handleClick: function () {
    console.log("Button clicked: " + this.label);
  },
};

// Without bind — 'this' would be the DOM element, not the button object
document.querySelector("button").addEventListener(
  "click",
  button.handleClick.bind(button)
);

I used this pattern a lot while building components at IBM. When you pass a method as a callback, it loses its this. bind() fixes that cleanly.

Pre-set Arguments with bind()

Here's a bonus feature I discovered — you can also pre-fill arguments:

function multiply(a, b) {
  return a * b;
}

const double = multiply.bind(null, 2);

console.log(double(5));  // 10
console.log(double(9));  // 18

2 is always the first argument. You just supply the second. This pattern is called partial application — and it feels like magic once you get it.

7. The Difference — call vs apply vs bind

Here's the table I wish someone had shown me from the beginning:

Simple memory trick I use:

• call → Call it now, Comma-separated args

• apply → Apply it now, Array of args

• bind → Bind it for later, returns a Bound function

8. Visualizing the Relationship

Here's how I think about it mentally:

Regular Function Call
─────────────────────
sayHello()
    └── this = window (or undefined in strict mode)


Object Method Call
──────────────────
developer.greet()
    └── this = developer ✅


call() / apply()
─────────────────
greet.call(customObj, args)
    └── this = customObj ✅ (runs immediately)


bind()
──────
const fn = greet.bind(customObj)
fn()
    └── this = customObj ✅ (runs later, always bound)

9. Hands-On Assignment — Try This Yourself!

Here's a small exercise I'd encourage you to do right now. Open your browser console or a CodeSandbox and follow along.

Step 1 — Create an Object with a Method

const developer = {
  name: "Saurabh",
  skills: ["React", "Node.js", "GenAI"],
  introduce: function (role, company) {
    console.log(
      `Hi! I'm \({this.name}. I work as a \){role} at ${company}.`
    );
    console.log(`My skills: ${this.skills.join(", ")}`);
  },
};

developer.introduce("Software Engineer", "IBM");

Step 2 — Borrow the Method with call()

const anotherDev = {
  name: "Priya",
  skills: ["Vue.js", "Python", "Docker"],
};

developer.introduce.call(anotherDev, "Backend Engineer", "Infosys");

Step 3 — Use apply() with Array Arguments

const args = ["Full-Stack Engineer", "Google"];

developer.introduce.apply(anotherDev, args);

Step 4 — Use bind() and Store the Function

const boundIntroduce = developer.introduce.bind(anotherDev);

// Use it anywhere, anytime
boundIntroduce("Frontend Engineer", "Flipkart");

// Still works!
setTimeout(boundIntroduce, 1000, "DevOps Engineer", "Microsoft");

Try changing the objects. Try passing different arguments. Break it and fix it — that's how it really sticks.

Key Discoveries from My Journey

A few things that genuinely surprised me:

• Arrow functions don't have their own this. They inherit this from the surrounding scope. So call(), apply(), and bind() have no effect on them. Took me way too long to figure this out.

• bind() is a lifesaver in React class components. That whole this.handleClick = this.handleClick.bind(this) in the constructor? Now I actually understand why it's there.

• apply() was more useful before the spread operator. Now Math.max(...scores) does the same thing as Math.max.apply(null, scores). But apply() is still worth knowing.

• this is runtime, not write-time. It's determined when the function is called, not when it's defined. That single realization fixed 80% of my this confusion.

How would you approach this? Do you have a better mental model for this?
Drop a comment or connect with me — I'd love to hear how you think about it!

About the Author

Saurabh Prajapati is a Full-Stack Software Engineer at IBM India Software Lab, where he builds cloud-native enterprise solutions for Maximo. He specializes in GenAI, React, and modern web technologies — and loves turning confusing concepts into approachable learning experiences.

• 🐙 GitHub: prajapatisaurabh

• 💼 LinkedIn: saurabh-prajapati

• 📧 Email: saurabhprajapati120@gmail.com

Why I Wanted to Explore This

When I first started writing JavaScript, I would just write functions like this and move on:

function greet() {
  console.log("Hello!");
}

Simple enough, right? But then I started seeing code like this all over the place:

const greet = function() {
  console.log("Hello!");
}

Wait... aren't these doing the same thing? Why would anyone write it differently?

Let me walk you through everything I discovered.

First, What Even Is a Function?

Before we compare, let's get on the same page.

A function is just a reusable block of code. Instead of writing the same logic again and again, you wrap it in a function and call it whenever you need it.

Think of it like a recipe. You write the steps once, and then you can "use" that recipe anytime you want to cook that dish.

Here's the simplest example:

function addNumbers(a, b) {
  return a + b;
}

console.log(addNumbers(3, 5)); // Output: 8
console.log(addNumbers(10, 20)); // Output: 30

You write the logic once. You reuse it everywhere. That's the power of functions.

Function Declaration

This is the classic way. You've probably seen it a hundred times.

function multiply(a, b) {
  return a * b;
}

console.log(multiply(4, 5)); // Output: 20

The syntax is straightforward:

• Start with the function keyword

• Give it a name (multiply)

• Define the parameters inside ()

• Write the logic inside {}

That's it. Clean, simple, readable.

Function Expression

Now here's where it gets interesting.

In a function expression, you create a function and assign it to a variable.

const multiply = function(a, b) {
  return a * b;
};

console.log(multiply(4, 5)); // Output: 20

Notice what changed:

• No function name after the function keyword (this is called an anonymous function)

• The function is stored inside a const variable called multiply

• There's a ; at the end (because it's a variable assignment)

The result is the same. But how JavaScript treats these two approaches behind the scenes? Very different.

Side-by-Side Comparison

Here's a quick visual to make it stick:

┌─────────────────────────────────┬─────────────────────────────────────┐
│      Function Declaration       │        Function Expression          │
├─────────────────────────────────┼─────────────────────────────────────┤
│ function greet() { ... }        │ const greet = function() { ... };   │
├─────────────────────────────────┼─────────────────────────────────────┤
│ Has a name always               │ Usually anonymous                   │
├─────────────────────────────────┼─────────────────────────────────────┤
│ Hoisted (can call before it's   │ NOT hoisted (must define first,     │
│ defined)                        │ then call)                          │
├─────────────────────────────────┼─────────────────────────────────────┤
│ Great for utility functions     │ Great for callbacks, passing        │
│ used everywhere                 │ functions around                    │
├─────────────────────────────────┼─────────────────────────────────────┤
│ Defined at parse time           │ Defined at runtime                  │
└─────────────────────────────────┴─────────────────────────────────────┘

The Big Difference: Hoisting

Okay, this is the part that tripped me up the most. Let me explain it simply.

Hoisting means JavaScript reads through your code before running it and "moves" certain things to the top. Not literally — but it behaves that way.

Function Declarations Are Hoisted ✅

// Calling BEFORE the function is defined
console.log(greet()); // Output: "Hello!"

function greet() {
  return "Hello!";
}

Wait — how did this work? We called greet() before we even wrote the function!

That's hoisting. JavaScript saw the function declaration, mentally "lifted" it to the top, and made it available everywhere in the file.

Function Expressions Are NOT Hoisted ❌

// Calling BEFORE the function expression is defined
console.log(greet()); // ❌ Error: Cannot access 'greet' before initialization

const greet = function() {
  return "Hello!";
};

This throws an error. Because greet is just a variable here. And variables declared with const or let are not available before their line in the code.

I made this mistake early on. I was confused why one worked and the other didn't. Now I know exactly why.

Key rule to remember:

• Function declaration → Call it anywhere in the file ✅

• Function expression → Must define it first, then call ✅

When Should You Use Each One?

Honestly, this is a judgment call. But here's how I think about it:

Use Function Declaration when:

• The function is a general utility used across many places

• You want the flexibility to call it anywhere in your file

• You're defining named, standalone functions

// Good use of declaration - utility function used everywhere
function formatDate(date) {
  return new Date(date).toLocaleDateString();
}

Use Function Expression when:

• You're passing a function as an argument (callback)

• You want to conditionally define a function

• You're using arrow functions (a modern form of expression)

// Good use of expression - passing as a callback
const numbers = [1, 2, 3, 4];
const doubled = numbers.map(function(num) {
  return num * 2;
});

console.log(doubled); // [2, 4, 6, 8]

A Quick Look at Arrow Functions (Bonus)

You've probably seen this syntax too:

const multiply = (a, b) => a * b;

console.log(multiply(3, 4)); // Output: 12

Arrow functions are a shorter form of function expressions. They're very popular in modern JavaScript.

Same rules apply — they are NOT hoisted.

Assignment: Try It Yourself

Here's a small challenge to solidify your understanding:

Step 1 — Write a Function Declaration

function multiplyDeclaration(a, b) {
  return a * b;
}

console.log(multiplyDeclaration(6, 7)); // Expected: 42

Step 2 — Write the Same as a Function Expression

const multiplyExpression = function(a, b) {
  return a * b;
};

console.log(multiplyExpression(6, 7)); // Expected: 42

Step 3 — Try Calling Before Defining

// Test hoisting behavior

console.log(multiplyDeclaration(3, 3)); // ✅ Works — 9
console.log(multiplyExpression(3, 3)); // ❌ Error — try it!

function multiplyDeclaration(a, b) {
  return a * b;
}

const multiplyExpression = function(a, b) {
  return a * b;
};

Run this in your browser console or Node.js. See the error with your own eyes. That experience will make hoisting click better than any explanation.

What I Wish I Knew Earlier

A few quick "I wish I knew this" moments:

• The name on a function expression is optional — but you can name it for better stack traces in errors

• Arrow functions are expressions too — same hoisting rules apply

• var behaves differently from const/let with hoisting — but that's a rabbit hole for another day

• Most modern codebases use both — don't feel like you have to pick just one

Key Takeaways

Let's wrap up what we covered:

• A function is a reusable block of code

• Function declaration uses the function keyword with a name — hoisted ✅

• Function expression assigns a function to a variable — not hoisted ❌

• Use declarations for general-purpose utilities

• Use expressions for callbacks and dynamic logic

• Arrow functions are a modern shorthand for expressions

About the Author

Saurabh Prajapati is a Full-Stack Software Engineer at IBM India Software Lab, working on enterprise-level cloud-native solutions using Maximo. He specializes in GenAI, React, and modern web technologies, and loves sharing his learning journey with other developers.

• 🐙 GitHub: prajapatisaurabh

• 💼 LinkedIn: saurabh-prajapati

• 📧 saurabhprajapati120@gmail.com

Why I Decided to Explore This

When I first started learning JavaScript, I thought operators were just... math symbols. Like, how complicated can + and - really be?

Turns out — more interesting than I expected. 😄

The moment that really got me was when I wrote this:

console.log(0 == "0");  // true
console.log(0 === "0"); // false

Wait, what? How are those different?

That confusion sent me down a rabbit hole. And honestly? I'm glad it did. Because once operators clicked for me, writing conditions, doing calculations, and controlling logic in JavaScript became so much easier.

Let me walk you through what I learned — step by step.

So... What Even Is an Operator?

Think of an operator as a symbol that tells JavaScript to do something with values.

That's it.

let result = 5 + 3; // '+' is the operator. It adds 5 and 3.

The values around the operator (like 5 and 3) are called operands. The operator sits between them and does the work.

JavaScript has several types of operators — each with its own job. Let's go through them one by one.

1. Arithmetic Operators — The Math Ones

These are the ones you probably already know. They handle basic math.

Most of these feel natural. But % (modulus) confused me at first.

Here's how I think about it now: it gives you the leftover after division.

console.log(7 % 3); // 1
// Because 7 ÷ 3 = 2, with 1 left over

A super common real-world use? Checking if a number is even or odd:

let num = 8;
console.log(num % 2); // 0 → even!

let num2 = 7;
console.log(num2 % 2); // 1 → odd!

I use this trick all the time. Once I learned it, I started seeing it everywhere in code.

2. Comparison Operators — Is This True or False?

These operators compare two values and return either true or false.

The Big One: == vs ===

This is where I made my first mistake. And honestly, so does almost everyone.

== (loose equality) compares values, but ignores the data type. JavaScript does some behind-the-scenes type conversion to make the comparison work.

=== (strict equality) compares both the value AND the type. No shortcuts. No conversions.

console.log(5 == "5");   // true  → value is same, type is ignored
console.log(5 === "5");  // false → number vs string, not the same!

console.log(0 == false);  // true  → 0 and false are treated as equal
console.log(0 === false); // false → different types!

My rule now? Always use === unless you have a very specific reason not to.

It avoids bugs that are really hard to track down. Trust me on this one — I've been there.

3. Logical Operators — Combining Conditions

Once you can compare values, you'll want to combine those comparisons. That's where logical operators come in.

There are three of them:

&& — AND

let age = 20;
let hasID = true;

if (age >= 18 && hasID) {
  console.log("You can enter!"); // Both are true → runs this
}

Both conditions have to be true for && to return true.

|| — OR

let isWeekend = false;
let isHoliday = true;

if (isWeekend || isHoliday) {
  console.log("No work today! 🎉"); // At least one is true → runs this
}

At least one condition being true is enough for ||.

! — NOT

This one just flips the value.

let isLoggedIn = false;

if (!isLoggedIn) {
  console.log("Please log in first."); // !false = true → runs this
}

Truth Table (For Reference)

| A | B | A && B | A || B | !A | | --- | --- | --- | --- | --- | | true | true | true | true | false | | true | false | false | true | false | | false | true | false | true | true | | false | false | false | false | true |

When I first saw a truth table, it felt very CS-textbook. But once I started writing real conditions in my code, I referred back to this mental model constantly.

4. Assignment Operators — Setting (and Updating) Values

You already know =. It assigns a value to a variable.

let score = 10; // assigns 10 to score

But there are shorter ways to update a variable using assignment operators:

let score = 10;

score += 5;  // score is now 15
score -= 3;  // score is now 12
score *= 2;  // score is now 24

console.log(score); // 24

I started using += and -= a lot once I realized it made score-tracking, counters, and loops so much cleaner to write.

5. Key Discoveries Along the Way

A few things that surprised me or saved me later:

• === over == — always. Loose equality has caused so many sneaky bugs in real projects. Strict equality is your friend.

• % is more useful than it looks. Checking even/odd, cycling through items in a list, pagination logic — the modulus operator shows up everywhere.

• ! can be stacked. !!value is a common trick to convert any value into a proper boolean. Weird at first, useful once you know it.

• Logical operators don't always return true or false. They return one of the actual values. This one's a bit more advanced, but keep it in mind for later.

6. Let's Put It All Together — Quick Assignment

Here's a small exercise I'd suggest trying yourself. It covers everything we talked about:

// --- Arithmetic ---
let a = 15;
let b = 4;

console.log("Sum:", a + b);        // 19
console.log("Difference:", a - b); // 11
console.log("Product:", a * b);    // 60
console.log("Quotient:", a / b);   // 3.75
console.log("Remainder:", a % b);  // 3

// --- Comparison ---
console.log(a == "15");  // true  (loose)
console.log(a === "15"); // false (strict)
console.log(a > b);      // true
console.log(a < b);      // false

// --- Logical ---
let isAdult = a > 18;     // false
let hasPermission = true;

if (!isAdult && hasPermission) {
  console.log("Minor with permission — allowed conditionally.");
}

if (isAdult || hasPermission) {
  console.log("At least one condition passed — allowed!");
}

Try running this in your browser console or a quick Node.js script. Then change the values of a and b and see how the outputs shift. That's the best way to really internalize it.

About the Author

Saurabh Prajapati is a Full-Stack Software Engineer at IBM India Software Lab, currently building cloud-native enterprise solutions on Maximo. He specializes in GenAI, React, and modern web technologies — and loves documenting his learning journey for other developers.

• 🐙 GitHub: prajapatisaurabh

• 💼 LinkedIn: saurabh-prajapati

• 📧 Email: saurabhprajapati120@gmail.com

By Saurabh Prajapati | Full-Stack Software Engineer at IBM India

Why I Decided to Explore This

When I first started learning JavaScript, arrays felt natural to me. A list of things? Easy. But then I kept running into this pattern everywhere in codebases at work:

const user = { name: "Saurabh", age: 25, city: "India" };

And I thought — wait, this looks different. What even is this?

That curiosity led me down a rabbit hole of JavaScript objects. And honestly? It was one of those topics where once it clicked, I started seeing it everywhere. APIs return objects. React state is an object. Config files are objects.

Let me walk you through everything I learned — step by step, the way I wish someone had explained it to me.

So... What Even Is an Object?

Think about a real person. They have a name, an age, a city they live in. Now, how would you store all of that in code?

You could use separate variables:

let name = "Saurabh";
let age = 25;
let city = "Ahmedabad";

But this gets messy fast. What if you had 100 users? You'd have 300 variables flying around.

That's where objects come in. An object lets you group related data together under one name.

const person = {
  name: "Saurabh",
  age: 25,
  city: "Ahmedabad"
};

Clean, right? Everything about that person lives in one place.

The Key-Value Pair Structure

Here's the mental model that made it click for me:

An object is like a dictionary — or even a real-life ID card.

Every piece of information has a label (key) and a value.

┌─────────────────────────────┐
│         person              │
├──────────────┬──────────────┤
│     KEY      │    VALUE     │
├──────────────┼──────────────┤
│    name      │  "Saurabh"  │
│    age       │     25      │
│    city      │ "Ahmedabad" │
└──────────────┴──────────────┘

• The key is always a string (or symbol, but let's not go there yet)

• The value can be anything — a string, number, boolean, array, even another object

Wait, How Is This Different from an Array?

Great question — I confused these two at first.

Here's the honest difference:

// Array — ordered list, accessed by index (position)
const fruits = ["apple", "mango", "banana"];
console.log(fruits[0]); // "apple"

// Object — labeled data, accessed by key (name)
const person = { name: "Saurabh", age: 25 };
console.log(person.name); // "Saurabh"

Use an array when you have a collection of things. Use an object when you want to describe one thing with multiple properties.

Creating Objects

There are a few ways to create objects. The most common (and cleanest) is the object literal syntax:

const person = {
  name: "Saurabh",
  age: 25,
  city: "Ahmedabad"
};

That's it. Curly braces {}, key-value pairs separated by colons :, and commas , between pairs.

You can also create an empty object and add properties later (we'll get to that):

const person = {};

Accessing Properties

Okay, so we have an object. Now how do we read the values?

There are two ways to do this.

1. Dot Notation (Most Common)

const person = {
  name: "Saurabh",
  age: 25,
  city: "Ahmedabad"
};

console.log(person.name);  // "Saurabh"
console.log(person.age);   // 25
console.log(person.city);  // "Ahmedabad"

Simple and readable. This is what you'll use 90% of the time.

2. Bracket Notation

console.log(person["name"]);  // "Saurabh"
console.log(person["age"]);   // 25

Looks a bit unusual at first. But here's when it's actually really useful — when the key is stored in a variable:

const key = "name";
console.log(person[key]);  // "Saurabh" 🎉

I didn't get why bracket notation existed until I hit this exact situation. Now I use it whenever the property name is dynamic (like from user input or an API response).

Updating Object Properties

Objects are mutable — you can change their values after creation.

const person = {
  name: "Saurabh",
  age: 25,
  city: "Ahmedabad"
};

// Update an existing property
person.age = 26;
console.log(person.age);  // 26

Wait, isn't person a const? Can we still change it?

Yes! const means you can't reassign the variable itself, but you can modify what's inside the object. This tripped me up early on.

// ❌ This will throw an error
person = { name: "Someone else" };

// ✅ This is perfectly fine
person.name = "SP";

Adding and Deleting Properties

Adding a New Property

Just assign to a new key — even if it didn't exist before:

const person = {
  name: "Saurabh",
  age: 25
};

// Add a new property
person.country = "India";
person.isAvailable = true;

console.log(person);
// { name: "Saurabh", age: 25, country: "India", isAvailable: true }

This felt almost too easy at first. No need to declare it — just assign and it's there.

Deleting a Property

Use the delete keyword:

delete person.age;

console.log(person);
// { name: "Saurabh", country: "India", isAvailable: true }

Honestly, I rarely use delete in real projects. It's cleaner to either set a property to null or undefined, or just not include it at all. But it's good to know.

Looping Through Object Keys

Here's something I spent too long Googling before it stuck.

You can't loop over an object with a regular for loop like you do with arrays. Objects aren't indexed.

But you have a few solid options:

Option 1: for...in Loop

const person = {
  name: "Saurabh",
  age: 25,
  city: "Ahmedabad"
};

for (let key in person) {
  console.log(key + ": " + person[key]);
}

// name: Saurabh
// age: 25
// city: Ahmedabad

This loops over every key in the object. Notice how we use bracket notation person[key] here — because key is a variable. Dot notation wouldn't work!

Option 2: Object.keys(), Object.values(), Object.entries()

These are super useful helpers:

// Get all keys as an array
console.log(Object.keys(person));
// ["name", "age", "city"]

// Get all values as an array
console.log(Object.values(person));
// ["Saurabh", 25, "Ahmedabad"]

// Get key-value pairs as an array of arrays
console.log(Object.entries(person));
// [["name", "Saurabh"], ["age", 25], ["city", "Ahmedabad"]]

I use Object.entries() a lot when I need to loop with both the key and the value at the same time:

for (let [key, value] of Object.entries(person)) {
  console.log(`\({key}: \){value}`);
}

This blew my mind when I first saw it. So clean!

Key Discoveries Along the Way

Here's what surprised me most:

• Objects can hold anything as values — including functions (which become "methods") and other objects. This is how things like console.log() actually work.

• Properties don't have to be valid variable names — if your key has spaces or special characters, you must use quotes and bracket notation:

  const obj = { "my-key": "value" };
  console.log(obj["my-key"]); // "value"
  

• Order isn't guaranteed — well, mostly. Numeric keys are sorted first, then string keys in insertion order. Don't rely on order if you need a sorted list — use an array instead.

Practical Application: Where You'll Actually Use This

Once I understood objects, I started noticing them everywhere:

• API responses — almost every API returns JSON, which is just... objects

• React state — useState({ loading: false, data: null, error: null })

• Config files — package.json is literally a JavaScript object

• Function parameters — passing objects as arguments keeps code clean

A quick real-world example from my work at IBM with enterprise apps:

// A config object for a Maximo API call
const apiConfig = {
  endpoint: "/api/mbo/workorder",
  method: "GET",
  headers: {
    "Content-Type": "application/json",
    "Authorization": "Bearer token123"
  },
  timeout: 5000
};

Once you understand objects, patterns like this start making complete sense.

Wrapping Up

Alright, let's recap what we covered:

• What objects are — key-value pairs that group related data

• How to create them — using object literal syntax {}

• Accessing properties — dot notation and bracket notation (and when to use each)

• Updating properties — direct assignment

• Adding and deleting — just assign new keys or use delete

• Looping — for...in, Object.keys(), Object.values(), Object.entries()

Objects are one of those foundational topics in JavaScript that everything else builds on. Spend time here, experiment in your browser console, and build a few small things with them.

Have a go at the student assignment above, and if you feel confident, try creating an object that represents yourself — name, skills (as an array!), and current role.

I'm still exploring deeper object patterns myself — things like object destructuring, the spread operator, and object methods. If you want me to cover those next, let me know!

About the Author

Saurabh Prajapati is a Full-Stack Software Engineer at IBM India Software Lab, where he works on Maximo — building cloud-native, enterprise-level solutions.

He specializes in GenAI, React, and modern web technologies, and loves sharing his learning journey with the developer community. He's worked across multiple companies building AI-powered tools, enterprise applications, and scalable web platforms.

• 📧 saurabhprajapati120@gmail.com

• 💻 GitHub: prajapatisaurabh

• 🔗 LinkedIn: saurabh-prajapati

By Saurabh Prajapati — Full-Stack Engineer @ IBM India | GenAI & React Enthusiast

Wait — What Even Is "Control Flow"?

Let me be honest. When I first saw the term "control flow" in a programming book, I thought it sounded way more complicated than it actually is.

Here's the simple truth: control flow just means the order in which your code runs.

By default, JavaScript reads your code from top to bottom, line by line. But what if you only want certain code to run in certain situations? That's exactly where control flow comes in.

Think about real life for a second:

🚦 If the traffic light is green → you drive. Otherwise → you stop.

That's control flow. You're making a decision based on a condition.

In JavaScript, we do the same thing. We check a condition, and based on whether it's true or false, we run different pieces of code.

Let's explore exactly how that works.

1. The if Statement

The if statement is the most basic building block of decision-making in JavaScript.

Syntax

if (condition) {
  // code runs only if condition is true
}

Real Example

let age = 20;

if (age >= 18) {
  console.log("You are eligible to vote!");
}

Output: You are eligible to vote!

The code inside the curly braces {} only runs if the condition age >= 18 is true.

If age was 15, nothing would happen at all. The block would be completely skipped.

💡 I wish I knew this earlier: The condition inside if() doesn't have to be a comparison. Anything "truthy" works — like a non-empty string, a number that isn't zero, or even an object. JavaScript is flexible like that.

2. The if-else Statement

Okay, but what if you want something to happen even when the condition is false? That's where else comes in.

Syntax

if (condition) {
  // runs if condition is true
} else {
  // runs if condition is false
}

Real Example

let marks = 35;

if (marks >= 40) {
  console.log("You passed!");
} else {
  console.log("You failed. Better luck next time.");
}

Output: You failed. Better luck next time.

Think of if-else like a fork in the road. You always take one path or the other — never both, never neither.

[Condition?]
    |
   YES → run if block
    |
   NO  → run else block

This is the most common pattern you'll use as a developer. I use it literally every day at work.

3. The else if Ladder

Sometimes two options aren't enough. What if you have three or more conditions to check?

That's where else if steps in.

Syntax

if (condition1) {
  // runs if condition1 is true
} else if (condition2) {
  // runs if condition2 is true
} else {
  // runs if none of the above are true
}

Real Example — Grading System

let marks = 72;

if (marks >= 90) {
  console.log("Grade: A");
} else if (marks >= 75) {
  console.log("Grade: B");
} else if (marks >= 60) {
  console.log("Grade: C");
} else if (marks >= 40) {
  console.log("Grade: D");
} else {
  console.log("Grade: F — Please retry");
}

Output: Grade: C

JavaScript checks each condition from top to bottom. The moment it finds one that's true, it runs that block and stops checking the rest.

This is important! Here's what I mean:

let marks = 95;

if (marks >= 60) {
  console.log("Grade: C"); // ← This runs first... and stops!
} else if (marks >= 90) {
  console.log("Grade: A"); // ← This never runs!
}

See the bug? Order matters. Always put your most specific or highest condition first.

😅 I made this exact mistake when I was learning. Spent 20 minutes debugging a grading script before realizing the conditions were in the wrong order. Lesson learned.

🗺️ Flowchart: How if-else Works

        ┌─────────────────┐
        │  Start          │
        └────────┬────────┘
                 │
        ┌────────▼────────┐
        │  Check          │
        │  Condition 1?   │
        └────────┬────────┘
           YES   │    NO
     ┌───────────┘    └───────────┐
     ▼                            ▼
┌─────────┐              ┌────────────────┐
│ Run     │              │ Check          │
│ Block 1 │              │ Condition 2?   │
└─────────┘              └────────┬───────┘
                            YES   │    NO
                      ┌───────────┘    └──────────┐
                      ▼                            ▼
                 ┌─────────┐               ┌─────────────┐
                 │ Run     │               │ Run else    │
                 │ Block 2 │               │ block       │
                 └─────────┘               └─────────────┘

4. The switch Statement

Now here's something I found really interesting when I first discovered it.

Imagine you're building a day-of-the-week app. With if-else, it would look like this:

if (day === 1) {
  console.log("Monday");
} else if (day === 2) {
  console.log("Tuesday");
} else if (day === 3) {
  console.log("Wednesday");
// ...and so on

That's a lot of repetition. switch is designed exactly for situations like this — when you're comparing one variable against many fixed values.

Syntax

switch (expression) {
  case value1:
    // code
    break;
  case value2:
    // code
    break;
  default:
    // code if no case matches
}

Real Example — Day of the Week

let day = 3;

switch (day) {
  case 1:
    console.log("Monday");
    break;
  case 2:
    console.log("Tuesday");
    break;
  case 3:
    console.log("Wednesday");
    break;
  case 4:
    console.log("Thursday");
    break;
  case 5:
    console.log("Friday");
    break;
  case 6:
    console.log("Saturday");
    break;
  case 7:
    console.log("Sunday");
    break;
  default:
    console.log("Invalid day number");
}

Output: Wednesday

Wait, What's break Doing Here?

Great question. I was confused about this too at first.

Without break, JavaScript doesn't stop after finding a matching case. It keeps running every case below it — which is almost never what you want.

This behavior is called "fall-through".

let day = 3;

switch (day) {
  case 3:
    console.log("Wednesday"); // ← This runs
  case 4:
    console.log("Thursday");  // ← This ALSO runs (no break!)
  case 5:
    console.log("Friday");    // ← And this too!
}

Output:

Wednesday
Thursday
Friday

See the problem? We matched case 3, but without break, it kept going.

Always add break at the end of each case. (Unless you intentionally want fall-through — which is rare, but possible for grouping cases.)

Grouping Cases (Intentional Fall-Through)

let day = 6;

switch (day) {
  case 6:
  case 7:
    console.log("It's the weekend! 🎉");
    break;
  default:
    console.log("It's a weekday.");
}

Output: It's the weekend! 🎉

Here both case 6 and case 7 fall through to the same code block. This is a clean pattern for grouping similar cases.

What About default?

default is like the else in a switch. It runs when no case matches.

let color = "purple";

switch (color) {
  case "red":
    console.log("Red");
    break;
  case "blue":
    console.log("Blue");
    break;
  default:
    console.log("Unknown color"); // ← This runs
}

🗺️ Switch Branching Diagram

         ┌──────────────────┐
         │  switch(value)   │
         └────────┬─────────┘
                  │
       ┌──────────┼──────────┐
       ▼          ▼          ▼
  [case 1]    [case 2]   [default]
       │          │          │
    (code)     (code)     (code)
       │          │          │
    [break]    [break]    (end)

5. When to Use switch vs if-else?

This is the question I kept asking myself. Here's what I've figured out after using both in real projects:

A Quick Rule of Thumb

Use if-else when you need flexible conditions. Use switch when you're matching one thing to many exact values.

Key Discoveries Along the Way

Here's what genuinely surprised me while diving into this topic:

1. switch uses strict equality (===) It doesn't do type conversion. So case "1" won't match if your value is the number 1.

let input = 1; // number

switch (input) {
  case "1":  // ← string "1" — won't match!
    console.log("One");
    break;
  case 1:    // ← number 1 — matches!
    console.log("One (number)");
    break;
}

2. You can use switch with strings too

let language = "JavaScript";

switch (language) {
  case "JavaScript":
    console.log("Runs in the browser!");
    break;
  case "Python":
    console.log("Great for data science!");
    break;
  default:
    console.log("Cool choice!");
}

3. if conditions can be anything truthy

let name = "Saurabh";

if (name) {
  console.log("Name exists: " + name);
}
// Works! Because a non-empty string is truthy.

Wrapping Up

Control flow is one of those foundational concepts that everything else in programming is built on. Once you understand how if, else, and switch work, you start seeing them everywhere.

Here's a quick recap of what we covered:

• if — runs code when a condition is true

• if-else — runs one block if true, another if false

• else if — chains multiple conditions together

• switch — cleanly matches one value against many fixed options

• break — essential in switch to prevent fall-through

• default — the fallback when no case matches

About the Author

Saurabh Prajapati (SP) Full-Stack Software Engineer at IBM India Software Lab, working on cloud-native enterprise solutions with Maximo. Passionate about GenAI, React, and modern web technologies.

Skills: JavaScript · TypeScript · React · Next.js · Node.js · LangChain · OpenAI API · AWS · Docker

📧 saurabhprajapati120@gmail.com 🐙 GitHub: prajapatisaurabh 💼 LinkedIn: saurabh-prajapati

Why I Wanted to Learn This (Again)

Okay, I know what you're thinking — "Variables? Really? Isn't that the most basic thing in JavaScript?"

Yes. And that's exactly why it matters.

I've been building full-stack apps with React, Node.js, and even LangChain pipelines. But every time I onboard someone new to JavaScript, I realize how often the fundamentals trip people up. So I decided to write this one down properly — the way I wish someone had explained it to me when I started.

If you're just starting out, stick with me. This one will click.

What Even Is a Variable?

Think of a variable like a labeled box.

You have a box. You write a name on it. You put something inside it. Later, you can open that box and see what's in it — or swap it out for something new.

📦 Box labeled "userName"
   Inside: "Saurabh"

In JavaScript, that looks like this:

let userName = "Saurabh";

That's it. You just created a box called userName and stored the value "Saurabh" in it.

Why do we need this? Because programs work with data — names, numbers, true/false answers. Variables let us store and reuse that data instead of writing it out every single time.

How to Declare a Variable

JavaScript gives you three ways to create a variable:

var oldWay = "I'm from the past";
let modernWay = "I can change";
const fixedWay = "I never change";

Let's understand each one.

var — The Old Way

var was the original way to declare variables in JavaScript. It works, but it has some quirky behavior that caused a lot of bugs.

var city = "Ahmedabad";
city = "Mumbai"; // ✅ This works fine

Honestly? Just avoid var in modern code. Use let or const instead. I'll explain why in a bit.

let — The Modern, Flexible Variable

Use let when you know the value will change over time.

let score = 0;
score = 10;   // ✅ Updated!
score = 25;   // ✅ Updated again!

Real-world example: a counter, a user's score, or a form input value.

const — The Locked Box

Use const when the value should never change.

const appName = "DevExplorer";
appName = "Something Else"; // ❌ Error! You can't do this.

The moment you try to reassign a const, JavaScript throws an error.

I wish I knew this earlier: Use const by default. Only switch to let if you know the value needs to change. This habit prevents a lot of accidental bugs.

var vs let vs const — Quick Comparison

Primitive Data Types

Every value you store in a variable has a type. JavaScript has 5 primitive types you need to know right now.

1. String — Text

let name = "Saurabh";
let greeting = 'Hello, World!';
let template = `Hi, my name is ${name}`; // Template literal!

Anything wrapped in quotes is a string.

2. Number — Any Number

let age = 25;
let price = 99.99;
let temperature = -5;

JavaScript doesn't separate integers and decimals. It's all just number.

3. Boolean — True or False

let isLoggedIn = true;
let isStudent = false;

Think of it like a light switch. On or off. Yes or no. This is incredibly useful in conditions and logic.

4. Null — Intentionally Empty

let selectedUser = null;

null means "this box exists, but I've intentionally left it empty." You're saying: "I know there's nothing here right now."

5. Undefined — Accidentally Empty

let result;
console.log(result); // undefined

undefined means you created the box but never put anything in it. JavaScript fills it with undefined automatically.

Wait, what? Yes, null and undefined both mean "empty" — but they mean it differently. null is intentional. undefined is accidental. I confused these for weeks before it finally clicked.

What Is Scope? (Keep It Simple)

Scope answers one question: "Where can I use this variable?"

Think of it like rooms in a house.

• Variables declared inside a room (block) can only be used in that room.

• Variables declared in the hallway (outside) can be used everywhere.

// Outside — accessible everywhere
let globalMessage = "I'm available everywhere";

{
  // Inside a block
  let roomMessage = "I only exist in here";
  console.log(globalMessage); // ✅ Works
  console.log(roomMessage);   // ✅ Works
}

console.log(globalMessage); // ✅ Works
console.log(roomMessage);   // ❌ Error! roomMessage doesn't exist out here

Scope Visualization

┌─────────────────────────────────┐
│  GLOBAL SCOPE                   │
│  let globalMessage = "..."      │
│                                 │
│  ┌───────────────────────────┐  │
│  │  BLOCK SCOPE { }          │  │
│  │  let roomMessage = "..."  │  │
│  │                           │  │
│  │  ✅ Can use globalMessage │  │
│  │  ✅ Can use roomMessage   │  │
│  └───────────────────────────┘  │
│                                 │
│  ✅ Can use globalMessage       │
│  ❌ Cannot use roomMessage      │
└─────────────────────────────────┘

This is why let and const are safer than var — they respect block scope. var doesn't, which is what causes the buggy behavior I mentioned earlier.

Key Discoveries

Here's what surprised me (or what trips up beginners the most):

• const doesn't mean the value is frozen forever for objects/arrays — just the variable reference. But for primitives like strings and numbers, it's completely locked. (We'll explore this in a future post!)

• undefined vs null — I used to use them interchangeably. Don't. Use null when you want to express emptiness. undefined is what JavaScript gives you when you forget something.

• Scope is everywhere — every if, for, while, or {} block creates its own scope. Once I understood this, so many bugs made sense.

Wrapping Up

Variables are the foundation of everything in JavaScript. Every app I've built — from enterprise tools at IBM to personal projects like Chat With Your PDF — uses these fundamentals at their core.

Here's the quick recap:

• Variables are named containers for storing data

• Use const by default, let when values change, avoid var

• Primitive types: string, number, boolean, null, undefined

• Scope controls where a variable can be accessed

The moment this clicked for me was when I stopped thinking of variables as "code things" and started seeing them as labeled boxes holding information. Everything else follows from there.

Have you just started learning JavaScript? Or maybe you're revisiting the basics like I did? Drop a comment or reach out — I'd love to hear where you are in your journey.

About the Author

Saurabh Prajapati is a Full-stack Software Engineer at IBM India Software Lab, working on enterprise cloud-native solutions with Maximo. He specializes in GenAI, React, and modern web technologies — and loves breaking down complex topics into simple, learnable pieces.

• 🐙 GitHub: prajapatisaurabh

• 💼 LinkedIn: saurabh-prajapati

• 📧 saurabhprajapati120@gmail.com

• 🌐 Available for work

WebDev Cohort 2026 · By Saurabh Prajapati · JavaScript Series

Why I Finally Explored Arrow Functions

Okay, real talk. When I first started learning JavaScript, I kept seeing code like const add = (a, b) => a + b everywhere — in tutorials, GitHub repos, Stack Overflow answers. And I kept wondering: "What is this weird arrow thing?"

I ignored it for a while and kept writing the old-school way. Then one day, I was reading through a modern React codebase and realized... basically every function used this syntax. I knew I had to dive in.

Spoiler: it took me about 20 minutes to "get it" and about 5 minutes to realize I'd been writing unnecessarily verbose code for weeks. Let me save you those weeks.

💡 What You'll Learn By the end of this post, you'll understand arrow function syntax, when to use implicit vs explicit return, how they compare to normal functions, and how to use them in real scenarios like array methods.

1. So, What IS an Arrow Function?

An arrow function is just a shorter, more modern way to write a function in JavaScript. That's honestly all it is. It was introduced in ES6 (2015) and has become the go-to style for writing functions in modern JS.

Let me show you the same function written both ways:

The Old Way (Regular Function)

function greet(name) {
  return "Hello, " + name + "!";
}

console.log(greet("Saurabh"));  // Hello, Saurabh!

The New Way (Arrow Function)

const greet = (name) => {
  return "Hello, " + name + "!";
};

console.log(greet("Saurabh"));  // Hello, Saurabh!

Same result. Less boilerplate. Notice how we replaced the function keyword with a => symbol. That arrow is what gives the syntax its name.

2. The Syntax, Step by Step

Let me break this down visually. The basic pattern of an arrow function looks like this:

const functionName = (parameters) => {
  // function body
  return value;
};

Now let's walk through each variation. Arrow functions have a few shorthand tricks that make them even cleaner.

No Parameters

Use an empty pair of parentheses when there's nothing going in:

const sayHello = () => {
  return "Hello, World!";
};

console.log(sayHello());  // Hello, World!

One Parameter

This is where it gets a little neat — with exactly one parameter, you can skip the parentheses entirely:

// With parentheses (always valid)
const double = (n) => {
  return n * 2;
};

// Without parentheses (valid with ONE parameter)
const double = n => {
  return n * 2;
};

console.log(double(5));  // 10

When I first saw this, I thought it was a typo. Nope — it's completely valid JS!

Multiple Parameters

Back to parentheses when you have two or more:

const add = (a, b) => {
  return a + b;
};

console.log(add(3, 7));  // 10

3. The Magic: Implicit Return

Okay, this is the part that blew my mind. Arrow functions let you skip the return keyword and even the curly braces, as long as your function body is a single expression.

Explicit Return (the long form)

const square = (n) => {
  return n * n;
};

Implicit Return (the short form)

const square = (n) => n * n;

console.log(square(4));  // 16

That one-liner does the exact same thing! No curly braces, no return keyword — just the expression itself.

⚠️ Important Rule You can only use implicit return when the function body is a single expression. If you need multiple lines or statements, use curly braces and an explicit return.

A few more examples to make this really click:

// Multiply two numbers
const multiply = (a, b) => a * b;

// Check if a number is even
const isEven = n => n % 2 === 0;

// Greeting message
const greet = name => `Hello, ${name}!`;

console.log(multiply(4, 5));    // 20
console.log(isEven(6));         // true
console.log(greet("Saurabh")); // Hello, Saurabh!

4. Arrow Function vs Regular Function: The Key Difference

Here's where I want to keep things simple, because there's actually a deep topic here (called "this" binding) that can get complicated fast. I'll save that for a dedicated post. But for now, here's the practical difference that matters most day-to-day:

Don't worry about the this row for now. It'll make a lot more sense once you've done more object-oriented work in JS. For now, just know arrow functions are perfect for callbacks and short utility functions.

5. Arrow Functions in Action: map(), filter(), reduce()

This is where arrow functions really shine in everyday JavaScript. If you've ever worked with arrays, you'll love how clean this feels.

Using map() to transform an array

const numbers = [1, 2, 3, 4, 5];

// Old way
const doubled = numbers.map(function(n) {
  return n * 2;
});

// Arrow function way
const doubled = numbers.map(n => n * 2);

console.log(doubled);  // [2, 4, 6, 8, 10]

Using filter() to find specific items

const scores = [45, 72, 88, 55, 91, 63];

// Get only passing scores (>= 60)
const passing = scores.filter(score => score >= 60);

console.log(passing);  // [72, 88, 91, 63]

Chaining them together

const numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];

// Get even numbers and double them
const result = numbers
  .filter(n => n % 2 === 0)
  .map(n => n * 2);

console.log(result);  // [4, 8, 12, 16, 20]

Honestly, once I saw how clean this looked compared to nested function expressions, I never looked back. It just reads so much more naturally.

Key Discoveries and "I Wish I Knew This Earlier" Moments

A few things I wish someone had told me when I was first learning this:

• Implicit return is your friend — but only for single expressions. The moment you need two lines, use curly braces and return explicitly. Don't try to squeeze complex logic into one line just to avoid writing return.

• Arrow functions don't replace all functions. In some places (like object methods or class methods), regular functions still make more sense. You'll learn when, with time.

• Returning an object with implicit return needs wrapping. This one tripped me up badly.

// This DOESN'T work (JS thinks {} is function body)
const getUser = () => { name: "Saurabh", age: 25 };  // ❌

// This DOES work (wrap in parentheses)
const getUser = () => ({ name: "Saurabh", age: 25 });  // ✅

• Arrow functions are everywhere in modern JS. React components, promise chains, event handlers, API calls — you'll see them constantly. Getting comfortable with this syntax is genuinely a skill unlock.

Wrapping Up: Should You Use Arrow Functions?

Short answer: yes, most of the time, for modern JavaScript.

They're cleaner, more concise, and they fit naturally with array methods and callback patterns. Once the syntax clicks, you'll find yourself defaulting to them automatically.

The longer answer is: use the right tool for the job. Regular functions still have their place, especially when you need named, hoisted functions or when working with this in object contexts. But for 80% of the everyday functions you write? Arrow functions will serve you beautifully.

🚀 What to Explore Next Now that you've got arrow functions down, explore: this keyword behavior in depth, array methods like reduce() and find(), and how arrow functions work inside React components and hooks.

Found this helpful? Share it with a fellow developer who's just getting into modern JavaScript! And if you have questions or a different approach, drop a comment — I'd genuinely love to hear how you're using arrow functions.

About the Author

Saurabh Prajapati (SP)

Full-stack Software Engineer at IBM India Software Lab, specializing in GenAI, React, and Modern Web Technologies. Working on Maximo — building cloud-native, enterprise-level solutions. Saurabh loves learning, building, and sharing knowledge with the developer community.

• 🐙 GitHub: prajapatisaurabh

• 💼 LinkedIn: saurabh-prajapati

• 📧 Email: saurabhprajapati120@gmail.com

Before We Start — Picture This...

It's 8:15 AM. Hitesh Bhaiya's chai stall is absolutely packed.

Ten students from the cohort are standing around, all shouting their orders at once. Someone wants regular chai, someone wants masala chai, someone wants ginger chai with extra adrak, and Piyush bhai just walked in asking for samosa too.

Hitesh Bhaiya is one person. He can only do so much.

So what does he do? He gives everyone a token. A little receipt that says: "Your order is being made. I promise."

That token? That's a JavaScript Promise.

And today, we're going to understand exactly how JavaScript handles multiple async operations — using the most relatable metaphor possible. Chai. Orders. Hitesh bhaiya. Let's go. ☕

What Even Is a Promise?

Okay, before we jump into the fancy methods, let's make sure the basics are solid.

A Promise in JavaScript is an object that represents the eventual result of an asynchronous operation. It's JavaScript's way of saying: "I don't have the answer right now, but I promise I'll get back to you."

Think of it like Hitesh bhaiya handing you an order token. At that moment, your chai isn't ready. But you have a promise that it will be. And that promise can have three outcomes:

• Pending — your order is still being made ⏳

• Fulfilled — your chai is ready, come collect it! ✅

• Rejected — sorry yaar, we ran out of milk 😢

Here's what that looks like in code:

const chaiOrder = new Promise((resolve, reject) => {
  const chaiReady = true;

  if (chaiReady) {
    resolve("Here's your masala chai! ☕");
  } else {
    reject("Sorry, we ran out of milk 😢");
  }
});

chaiOrder
  .then((message) => console.log(message))   
  .catch((error) => console.log(error));     

Simple enough, right? Now here's where it gets interesting — what happens when you have multiple orders at once?

That's where Promise.all(), Promise.race(), Promise.any(), and Promise.allSettled() come in.

Promise.all() — The Group Order 🫂

Imagine a group of five students placing a group order. They all want chai together. They're going to sit together, study together, and they want their chai at the same time.

Hitesh bhaiya says: "Theek hai, wait karo. Jab sab ready ho jaayega, tab deta hoon."

That's Promise.all().

It waits for ALL promises to resolve. If even ONE fails, the whole thing fails.

function makeChai() {
  return new Promise((resolve) => {
    setTimeout(() => resolve("Regular Chai ☕"), 2000);
  });
}

function makeSamosa() {
  return new Promise((resolve) => {
    setTimeout(() => resolve("Samosa 🥟"), 3000);
  });
}

function makeParatha() {
  return new Promise((resolve) => {
    setTimeout(() => resolve("Paratha 🫓"), 1500);
  });
}


Promise.all([makeChai(), makeSamosa(), makeParatha()])
  .then((items) => {
    console.log("Group order complete:", items);
    // Output: ["Regular Chai ☕", "Samosa 🥟", "Paratha 🫓"]
  })
  .catch((error) => {
    console.log("Sorry, we're out of gas! Order failed. ☹️", error);
  });

The key thing here — all three start simultaneously. Promise.all() doesn't wait for chai to finish before starting samosa. Everything runs in parallel!

But if makeSamosa() rejects? The whole .catch() fires. Game over for the group order.

When to use it:

• You need ALL results before proceeding

• Example: Fetching user profile + their orders + their settings before showing a dashboard

• If any one API fails, you don't want to show broken data anyway

Promise.race() — First Chai Ready Wins 🏃

Now imagine Hitesh bhaiya has three helpers today. All three start making chai at the same time. Whoever finishes first — that's the order that gets served.

The student doesn't care which helper made it. They just want chai. Fast.

That's Promise.race().

The first promise to settle (resolve OR reject) wins. Rest are ignored.

function regularChai() {
  return new Promise((resolve) => {
    setTimeout(() => resolve("Regular Chai (3 min) ☕"), 3000);
  });
}

function masalaChai() {
  return new Promise((resolve) => {
    setTimeout(() => resolve("Masala Chai (1 min) 🌶️☕"), 1000);
  });
}

function gingerChai() {
  return new Promise((resolve) => {
    setTimeout(() => resolve("Ginger Chai (2 min) 🫚☕"), 2000);
  });
}

Promise.race([regularChai(), masalaChai(), gingerChai()])
  .then((firstReady) => {
    console.log("Here's your chai! Others still coming...", firstReady);
    // Output: "Masala Chai (1 min) 🌶️☕" (wins at 1 second)
  })
  .catch((error) => {
    console.log("All failed somehow:", error);
  });

Masala chai finishes first (at 1 second), so that's what you get. The other two are still being made, but you're already sipping away.

When to use it:

• Timeout logic — if an API doesn't respond in 5 seconds, show an error

• Fetching from multiple servers — take whoever responds first

Promise.any() — Survival Mode 🆘

Okay this one is my favorite. Let me paint you a picture.

It's 8:55 AM. Your morning class starts in 5 minutes. You NEED chai. You literally cannot function without it.

Three stalls are near your college. You place orders at all three simultaneously. You just need ANY ONE of them to deliver in time.

That's Promise.any().

The first promise to RESOLVE wins. Rejections are ignored unless ALL fail.

function chaiFromStall1() {
  return new Promise((resolve, reject) => {
    setTimeout(() => reject("Stall 1: Sorry, no milk today 😭"), 1000);
  });
}

function chaiFromStall2() {
  return new Promise((resolve, reject) => {
    setTimeout(() => resolve("Stall 2: Chai ready! ☕"), 2000);
  });
}

function chaiFromStall3() {
  return new Promise((resolve, reject) => {
    setTimeout(() => resolve("Stall 3: Chai here! ☕"), 3000);
  });
}

Promise.any([chaiFromStall1(), chaiFromStall2(), chaiFromStall3()])
  .then((firstSuccess) => {
    console.log("Finally! Zindagi bach gayi ☕", firstSuccess);
    // Output: "Stall 2: Chai ready! ☕" (first SUCCESS at 2s)
  })
  .catch((error) => {
    // Only fires if ALL three reject
    console.log("ALL stalls failed. No chai for you. 💀", error);
  });

Stall 1 rejected at 1 second — but Promise.any() doesn't care! It just moves on. Stall 2 resolves at 2 seconds — winner! You get your chai, you make it to class, life is good.

The .catch() only fires when literally every single promise rejects. That's when it throws an AggregateError with all the rejection reasons.

When to use it:

• Redundancy — trying multiple servers and you just need one to work

• Fallback APIs — primary fails, try backup

• Resource loading — try CDN 1, CDN 2, local fallback

Difference from Promise.race(): race() responds to the first settle (reject OR resolve). any() only cares about the first resolve. Small but massive difference. I confused these for way too long. 😭

Promise.allSettled() — End of Day Report 📊

The stall is closing. Hitesh bhaiya wants to know: out of all 20 orders today, how many were fulfilled and how many failed?

He doesn't want to stop early if one order failed. He wants the complete picture — successful orders, failed orders, everything.

That's Promise.allSettled().

Waits for ALL promises to settle (resolve OR reject). Never rejects. Gives you the full report.

function order1() {
  return new Promise((resolve) =>
    setTimeout(() => resolve("Chai delivered to Ravi ✅"), 1000)
  );
}

function order2() {
  return new Promise((_, reject) =>
    setTimeout(() => reject("Chai spilled for Priya ❌"), 1500)
  );
}

function order3() {
  return new Promise((resolve) =>
    setTimeout(() => resolve("Chai delivered to Amit ✅"), 2000)
  );
}

Promise.allSettled([order1(), order2(), order3()])
  .then((results) => {
    results.forEach((result, index) => {
      if (result.status === "fulfilled") {
        console.log(`Order \({index + 1}: ✅ \){result.value}`);
      } else {
        console.log(`Order \({index + 1}: ❌ Failed — \){result.reason}`);
      }
    });
  });

// Output:
// Order 1: ✅ Chai delivered to Ravi ✅
// Order 2: ❌ Failed — Chai spilled for Priya ❌
// Order 3: ✅ Chai delivered to Amit ✅

See that? Even though Order 2 failed, we still got the results for Orders 1 and 3. No early stopping. Full accountability. Hitesh bhaiya knows exactly what happened.

When to use it:

• Analytics and logging — you need to know what succeeded AND what failed

• Batch operations — sending 100 emails and you want a full success/fail report

• Dashboard updates — update as many widgets as possible, report failures separately

This is the one you reach for when you care about every single outcome, not just the happy path.

The Comparison Table 📋

Okay let's put it all together. Here's the chai stall cheat sheet:

Print this. Screenshot it. Tattoo it. Whatever works. 😄

Resources & Links

• 📘 MDN Docs: Promise

• 📘 MDN: Promise.all()

• 📘 MDN: Promise.race()

• 📘 MDN: Promise.any()

• 📘 MDN: Promise.allSettled()

• 💻 Chai aur Code — Hitesh Choudhary's Channel

• 🐙 GitHub: prajapatisaurabh

• 💼 LinkedIn: saurabh-prajapati

About the Author

Saurabh Prajapati is a Full-Stack Software Engineer at IBM India Software Lab, working on Maximo — a cloud-native enterprise solution. I specializes in GenAI, React, and modern web technologies, and loves building things with LangChain, GPT-4, and RAG pipelines.

When he's not writing code, he's probably writing about it.

📧 saurabhprajapati120@gmail.com | 🐙 prajapatisaurabh | 💼 saurabh-prajapati

Wait — Do You Really Know JavaScript Arrays?

Before we dive in, let me throw a quick challenge at you. What does this code output?

let fruits = ['apple', 'banana', 'mango'];
fruits.favorite = 'orange';
fruits[5] = "mango";

console.log(fruits.length);
console.log(fruits);

Drop your answer in the comments. I'll explain the twist at the end. 😄

So What Even Is an Array?

Simple answer: an array is a way to store multiple values in one variable.

let fruits = ["apple", "banana", "orange"];
let mixed = ["apple", 123, false, { name: "xyz" }];

You can throw anything in there — strings, numbers, booleans, even objects. JavaScript doesn't complain.

Here's something that blew my mind when I first learned it: arrays are objects in JavaScript. That's why they have built-in properties and methods. And that's also why the code challenge above behaves the way it does — you can add custom properties to arrays just like objects!

Now let's get to the fun part.

The 10 Array Methods Worth Knowing

#1 — copyWithin()

I'd never heard of this one until recently. It copies part of the array to another position within the same array — without changing its length.

A fun way to think about it: imagine a terminal command history that auto-shifts when you add a new command.

let history = [
  "npm start",
  "git status",
  "git add .",
  "git commit"
];

history.copyWithin(0, 1);
history[history.length - 1] = "git push";

console.log(history);
// ["git status", "git add .", "git commit", "git push"]

It "shifts everything left" and makes room for the new entry at the end. Honestly, weird at first — but kind of clever once you see it in action.

#2 — every()

This one checks if all elements pass a condition. Think of it like a quality gate in CI/CD.

const files = [
  { fileName: "login.js", coverage: 92 },
  { fileName: "signup.js", coverage: 88 },
  { fileName: "dashboard.js", coverage: 95 },
  { fileName: "profile.js", coverage: 90 }
];

const isCoverageGood = files.every(file => file.coverage >= 80);
console.log(isCoverageGood); // true

If even one file dips below 80%, it returns false. Super clean for validation logic.

#3 — reduce()

Okay, this one most developers have seen — but not everyone really gets it. The idea: take a whole array and boil it down to one value.

const numbers = [1, 2, 3, 4, 5];
const sum = numbers.reduce((acc, curr) => acc + curr, 0);
console.log(sum); // 15

Think of acc as your running total, and curr as the current item being processed. Once it clicked for me, I started using reduce() everywhere — for summing, grouping, building objects, you name it.

#4 — reduceRight()

Same idea as reduce(), but it starts from the right side of the array. Here's a fun example:

const words = ["ChaiCode", "the", "to", "Welcome"];

const sentence = words.reduceRight((acc, curr) => acc + " " + curr);
console.log(sentence); // "Welcome to the ChaiCode"

The array is in reverse order, and reduceRight() assembles it correctly. I wish I'd known this earlier — I used to reverse arrays manually first. 🤦

#5 — some()

While every() checks if all elements pass, some() checks if at least one does. Great for role-based access checks.

const user = {
  isLoggedIn: true,
  roles: ["member", "editor"]
};

const requiredRoles = ["admin", "editor"];

const hasAccess = user.isLoggedIn && user.roles.some(role => requiredRoles.includes(role));
console.log(hasAccess); // true

The user has "editor" in their roles, and that matches one of the required roles — so access granted. Clean, readable, and practical.

#6 — with()

This is a newer one and it's really handy. It returns a new array with one item replaced at a specific index — without mutating the original.

const students = ["Saurabh", "Hitesh", "Piyush"];
const updatedStudents = students.with(0, "Anirudh");

console.log(updatedStudents); // ["Anirudh", "Hitesh", "Piyush"]
console.log(students);        // ["Saurabh", "Hitesh", "Piyush"] — unchanged!

When working with React state or any immutable data pattern, this is a lifesaver. No more spreading and remapping just to change one element.

#7 — shift()

This removes the first element from an array and returns it.

const numbers = [1, 2, 3, 4, 5];
const first = numbers.shift();

console.log(first);   // 1
console.log(numbers); // [2, 3, 4, 5]

It does mutate the original array though, so use with care. Think of it like a queue — first in, first out.

#8 — unshift()

The opposite of shift() — it adds elements to the beginning of an array.

let presenters = ["Saurabh", "Pradip", "Yash"];
presenters.unshift("Rahul", "Amit");

console.log(presenters);
// ["Rahul", "Amit", "Saurabh", "Pradip", "Yash"]

Also mutates the original. I use this when I need to prepend items dynamically — like adding a "pinned" item to a list.

#9 — flatMap()

This one is a combo of map() and flat(). It maps over each element and then flattens the result by one level.

const numbers = [1, 2, [3, 4], 5];
const result = numbers.flatMap(n => Array.isArray(n) ? n : n);

console.log(result); // [1, 2, 3, 4, 5]

Where it really shines is when your map produces arrays and you don't want nested arrays in the output. I used this while building a chat message parser — each message could expand into multiple UI elements, and flatMap() kept things clean.

#10 — includes()

Simple but essential. Checks if an array contains a specific value.

const numbers = [1, 2, 3, 4, 5];

console.log(numbers.includes(3)); // true
console.log(numbers.includes(6)); // false

Cleaner than using indexOf() !== -1 — which is what I used to do before I discovered this. 😅

The Challenge Answer

Remember the puzzle from the beginning?

let fruits = ['apple', 'banana', 'mango'];
fruits.favorite = 'orange';
fruits[5] = "mango";

console.log(fruits.length); // 6
console.log(fruits);
// ['apple', 'banana', 'mango', empty × 2, 'mango', favorite: 'orange']

The length is 6 because we set fruits[5] — JavaScript creates "empty" slots for the gaps. And fruits.favorite is a property on the array object, so it doesn't affect length at all. Arrays in JavaScript are more flexible (and weird) than they look!

Key Takeaways

• copyWithin() — shift data within the same array

• every() / some() — check conditions across elements

• reduce() / reduceRight() — collapse arrays into a single value

• with() — immutable single-element replacement (underrated!)

• shift() / unshift() — add/remove from the front

• flatMap() — map + flatten in one step

• includes() — clean existence check

About the Author

Saurabh Prajapati is a Full-Stack Software Engineer at IBM India Software Lab, where he builds cloud-native enterprise solutions on Maximo. He's passionate about GenAI, React, and modern web tech — and loves documenting his learning journey for fellow developers.

🔗 GitHub · LinkedIn · 📧 saurabhprajapati120@gmail.com · Available for work

So, I recently sat down to design WhatsApp from scratch. Not the real thing — obviously — but the kind of "design this system" challenge you'd face in a senior-level system design interview.

And honestly? It was one of the most fun and mind-bending exercises I've done in a while.

I wanted to document the whole journey here — not just the final architecture, but the thinking process, the mistakes, and those "wait, that's actually brilliant" moments along the way.

Let's get into it.

Why WhatsApp? Why Now?

I kept seeing WhatsApp pop up as a classic system design interview question. And every time, I'd think — "Yeah, it's just a messaging app, how hard can it be?"

Spoiler alert: incredibly hard.

Once I actually started breaking it down — 500 million daily active users, real-time messaging, group chats, end-to-end encryption — I realized this single app touches almost every concept in modern system design.

So I thought: why not try it myself and see where I get stuck?

That's exactly what happened. And this blog is me sharing everything — the good, the confusing, and the "I wish someone had told me this earlier" parts.

Step 1: Start With the Requirements (Seriously, Don't Skip This)

Before touching any architecture diagram, the first thing we did was define what WhatsApp actually needs to do.

This is split into two buckets:

Functional Requirements (What the app does)

• Real-time one-on-one messaging

• Group chats

• Media sharing (images, videos, documents)

• End-to-end encryption (E2EE)

Non-Functional Requirements (How well it does it)

• Low latency — messages should feel instant (< 200ms)

• High availability — the app should almost never go down (99.99% uptime)

• Massive scale — we're talking 500 million+ daily active users

I'll be honest — when I first wrote down "500 million DAU," my brain just kind of short-circuited for a second. That's not a small number. That number changes everything about how you design the system.

💡 I wish I knew this earlier: Always nail down the scale first. It's the single biggest factor that shapes every decision you make — from database choices to caching strategies.

Step 2: The High-Level Architecture

Okay, here's where it gets exciting. We mapped out the big picture — all the major components and how they talk to each other.

Here's the flow:

Client Apps → Load Balancer → Chat Servers → Message Queue (Kafka) → Database Layer → Cache (Redis) → Push Notification Service

Let me break down what each piece does:

• Client Apps — The WhatsApp app on your phone or desktop. This is where the user interacts.

• Load Balancer — Spreads incoming traffic across multiple chat servers so no single server gets overwhelmed.

• Chat Servers — The brain of the operation. They handle incoming messages, route them, and manage WebSocket connections.

• Message Queue (Kafka) — A buffer that holds messages before they get written to the database. This is huge for reliability (more on that later).

• Database Layer — Where all the data actually lives. (We used two different databases here — and the reason why is interesting.)

• Cache (Redis) — Stores frequently accessed data in memory so we don't hit the database every single time.

• Push Notification Service (FCM/APNs) — Sends notifications to your phone when you get a new message and you're not actively using the app.

The moment this all clicked together for me was when I realized — every single piece here exists for a reason. Nothing is extra. Nothing is "just there." Each component solves a specific problem at scale.

Step 3: How Do Devices Actually Talk? (Protocols)

This was one of the parts I found really interesting to think about.

Not all communication in WhatsApp uses the same protocol. Different situations call for different tools:

• WebSockets — For real-time messaging. WebSockets keep a persistent, two-way connection open between your device and the server. So when you type a message, it goes through instantly — no need to make a new request every time.

• HTTP/REST — For things like signing up, updating your profile, or fetching your contact list. These are one-time requests, so a simple HTTP call works perfectly.

• FCM / APNs — For push notifications when you're offline. FCM is Google's service (Android), APNs is Apple's (iOS).

🤔 A question I asked myself: "Why not just use WebSockets for everything?" The answer? WebSockets are great for real-time stuff, but they're overkill for simple request-response tasks like fetching your profile. Using the right tool for the right job = less complexity, less resource usage.

Step 4: Choosing the Right Databases (This One Blew My Mind)

Okay, this was a big learning moment for me. WhatsApp doesn't use just one database. It uses multiple databases, each built for a different kind of data.

Here's the breakdown:

Cassandra — For Messages

• Messages are written constantly and in massive volumes

• Cassandra is built for exactly this — insane write throughput

• It's also great for time-series data (messages are naturally ordered by time)

• Think of it as: "I need to store a river of messages, fast and reliably"

PostgreSQL — For User & Group Data

• User profiles, group info, contact lists — this data is relational

• You need to join tables, run complex queries

• PostgreSQL is a classic, reliable relational database — perfect for this

Redis — For Caching & Online Status

• "Is this user online right now?" — that's a question that gets asked millions of times per second

• Hitting PostgreSQL every single time would be way too slow

• Redis stores this in memory — lightning fast reads

💡 The "aha" moment: I always thought of apps using "a database." But at this scale, you pick the bestdatabase for each type of data. It's like choosing the right tool from a toolbox — not just grabbing the first one you see.

Key Data Models We Defined

Step 5: The Message Flow — Where the Magic Happens

This was my favorite part. Let's trace what actually happens when you send a message to a friend.

Case 1: Both Users Are Online

You type "Hey!" → Your app sends it via WebSocket
→ Chat Server receives it
→ Message is written to Kafka (queued)
→ Message is saved to Cassandra (database)
→ Chat Server forwards it to your friend's WebSocket connection
→ Your friend sees "Hey!" on their screen

Total time for this? Around 150–200ms. That's basically instant to a human.

Case 2: Your Friend Is Offline

You type "Hey!" → Same flow as above...
→ But your friend has no active WebSocket connection
→ Message is stored in the database (kept for up to 30 days)
→ A push notification (FCM/APNs) is sent to their phone
→ When they open the app, the message is fetched and delivered

Makes sense, right? The message doesn't disappear just because your friend isn't online.

Case 3: Group Messages

This one is trickier. When you send a message to a group of, say, 50 people:

Your message → Chat Server → Fan-out to all 50 members

"Fan-out" just means the server sends the message out to everyone individually. At scale, this can be expensive — but that's where optimizations like Kafka partitioning come in handy.

Case 4: What If the Network Fails?

This is where things get really interesting. What if your message gets lost mid-send?

• Your app uses exponential backoff — it retries sending, but waits a little longer each time (so it doesn't spam the server)

• Deduplication makes sure that even if a message is sent multiple times during retries, it only gets stored once

🤯 Wait, this is actually really cool because... The system is designed to expect failures. It doesn't hope everything works perfectly — it plans for things to break and handles it gracefully. That's a whole mindset shift.

Step 6: Scaling to 500 Million Users (The Hard Part)

Okay, here's where the rubber meets the road. How do you actually make this thing work for half a billion people?

We talked about a bunch of strategies:

Database Sharding

• You can't fit all 500M users' messages on one database server

• Sharding splits the data across multiple servers

• We used hash-based sharding — each user's messages go to a specific shard based on a hash of their user ID

• One cool detail: we planned for growing from 16 shards to 32 shards — and discussed how to migrate data smoothly during that transition

Read Replicas

• Most of the time, people are reading messages (scrolling through chats) more than writing new ones

• Read replicas are copies of the database that only handle read requests — spreading the load

Multi-Level Caching

• L1 Cache — Super fast, for the most recent messages

• L2 Cache — A bit larger, for slightly older data

• L3 Cache — Even larger, catches anything L1 and L2 miss

• Think of it like layers of a safety net — each one catches what the previous one missed

Other Scaling Tricks

• GeoDNS — Routes users to the nearest server based on their location (lower latency!)

• Kafka Partitioning — Splits message processing across multiple workers

• Auto-Scaling — Automatically adds more servers when traffic spikes

• Rate Limiting (Token Bucket) — Prevents any single user or bot from overwhelming the system

💰 The Cost Optimization That Surprised Me

Here's a stat that genuinely surprised me: deleting messages after they're delivered saves 99.2% of storage costs.

Think about it — once a message is delivered and the recipient has it, do you really need to keep it on the server forever? For most messages, no. That single optimization saves an insane amount of money at scale.

Step 7: End-to-End Encryption — The Security Layer

This one is a big deal. WhatsApp uses the Signal Protocol for E2EE, and it's honestly fascinating.

Here's the simplified version of how it works:

• Double Ratchet Algorithm — Every single message is encrypted with a different key. So even if someone somehow cracks one key, they can't read any other messages.

• Forward Secrecy — If a key is compromised today, it can't be used to decrypt past messages. Only future messages could potentially be affected.

🤔 My honest reaction: I spent a good chunk of time just trying to understand the double ratchet. It's one of those things that sounds complex but once you get the "why" behind it — protecting each message independently — it actually makes a lot of sense.

Step 8: Cool Advanced Features We Explored

Beyond basic messaging, WhatsApp has a bunch of features that each have their own interesting design challenges:

• Disappearing Messages — Uses a TTL (Time-To-Live) value. After X seconds/days, the message is automatically deleted. Simple concept, but enforcing it reliably across all devices? That's the tricky part.

• View-Once Media — Images/videos that can only be opened once. Requires careful client-side enforcement + server-side tracking.

• Status / Stories — These use a pull-based model (your app fetches statuses when you open it) and expire after 24 hours.

• Voice Messages — Encoded using the Opus codec, which is great for compressing audio without losing quality.

• Live Location Sharing — Your phone sends a GPS update every 30 seconds to the server, which forwards it to whoever you're sharing with. Simple idea, but at scale, that's a lot of location updates flying around.

Step 9: What Happens When Things Break? (Failure Handling)

No system is perfect. The real test of a well-designed system is: what happens when something goes wrong?

We covered a bunch of failure scenarios:

Disaster Recovery Numbers

• RTO (Recovery Time Objective): 15 minutes — the system should be back up within 15 minutes of a major failure

• RPO (Recovery Point Objective): 5 minutes — we can tolerate losing at most 5 minutes of data

💡 Key Insight: The phrase "write to Kafka before ACK" is one of the most important reliability patterns here. It means: don't tell the user their message was sent until it's safely in the queue. Even if the next step fails, the message isn't lost.

Step 10: The Gaps — What We Didn't Fully Cover

Here's the part I actually appreciated the most from our session. The interviewer flagged areas where a real interview would expect deeper answers. Being honest about gaps is part of growth, so here they are:

• Message Search — Searching through millions of messages. Tools like Elasticsearch can help, but it gets complicated when messages are encrypted (you can't search encrypted text easily).

• Spam & Abuse Prevention — A 5-layer approach is needed to catch spam, scams, and abusive content at scale.

• Media Processing Pipeline — Generating thumbnails, transcoding videos, serving via CDN — this is its own mini-system.

• User Authentication — OTP-based login flow, JWT tokens for session management, and how to authenticate WebSocket connections.

• API Design & Versioning — How to structure and version the APIs cleanly.

• Cost Estimation — Rough estimate for running this whole thing: ~$650K/month for 500 million users. Yeah, WhatsApp is not cheap to run.

These are areas I want to dive deeper into next. Especially message search and the media pipeline — they sound like they'd make great blog posts on their own!

What I'd Do Differently Next Time

Looking back, here are a few things I'd change or improve:

1. Start with the message flow earlier. The message flow diagram is the heart of the system. Everything else is built around it. I'd draw that first, then layer in the components.

2. Think about failure scenarios from the start. I added failure handling at the end, but in reality, you should be asking "what if this breaks?" at every step.

3. Estimate costs earlier. Numbers like $650K/month give you a sense of scale — and that helps you make better design decisions earlier on.

🎯 Interview Tip: Structure your system design answer like this: Requirements → High-Level Design → Deep Dive → Scaling → Wrap-Up

Don't jump straight to solutions. Don't hand-wave on scale. And don't ignore edge cases. These are the three most common mistakes candidates make.

About the Author

Saurabh Prajapati is a Full-Stack Software Engineer at IBM India Software Lab, specializing in GenAI, React, and modern web technologies. He loves exploring new tools, building things, and sharing what he learns along the way.

📧 saurabhprajapati120@gmail.com 🐙 GitHub: prajapatisaurabh 💼 LinkedIn: saurabh-prajapati

Currently available for work. Let's build something cool together.

"Just learn HTML," they said. "It's easy," they said.

But honestly? I had no idea what a "tag" was or why some elements needed closing tags while others didn't. If you're in the same boat, don't worry—I'm going to walk you through everything I learned, step by step.

Let's dive in.

What is HTML, Really?

Think of a webpage like a house.

HTML (HyperText Markup Language) is the skeleton of that house—the walls, floors, and rooms that give it structure.

CSS makes it look pretty (paint, furniture, decorations).

JavaScript makes it interactive (lights that turn on, doors that open).

But without HTML? There's no house at all.

HTML tells the browser:

• "This is a heading."

• "This is a paragraph."

• "This is an image."

• "This is a button."

It's the foundation of everything you see on the web.

What is an HTML Tag?

Here's where it clicked for me.

An HTML tag is like a label you put on content to tell the browser what it is.

Let's say you have some text:

Welcome to my blog

The browser sees this and thinks, "Okay, it's just text. But what kind of text? A heading? A paragraph? A button?"

That's where tags come in.

You wrap the text in tags:

<p>Welcome to my blog</p>

Now the browser knows: "Oh, this is a paragraph!"

Breaking Down a Tag: Opening, Closing, and Content

Let's zoom in on that example:

<p>Welcome to my blog</p>

Here's what's happening:

• <p> → This is the opening tag. It says, "Hey, a paragraph starts here."

• Welcome to my blog → This is the content. The actual text you want to show.

• </p> → This is the closing tag. It says, "Okay, the paragraph ends here."

Notice the forward slash (/) in the closing tag? That's how the browser knows the tag is closed.

Another example:

<h1>My First Blog Post</h1>

• <h1> → Opening tag (heading level 1)

• My First Blog Post → Content

• </h1> → Closing tag

Pretty straightforward, right?

So What's an HTML Element?

Okay, here's something that confused me at first:

What's the difference between a tag and an element?

Simple answer:

• A tag is just the <p> or <h1> part.

• An element is the whole thing—opening tag, content, and closing tag.

Example:

<p>This is a paragraph.</p>

• Tag: <p> and </p>

• Element: The entire <p>This is a paragraph.</p>

Think of it this way:

• A tag is like a box.

• An element is the box with something inside it.

Wait, Some Tags Don't Close?

Yep. This threw me off too.

Some HTML tags are self-closing (also called void elements). They don't need a closing tag because they don't wrap around content.

Examples:

<img src="photo.jpg" alt="A photo">
<br>
<hr>
<input type="text">

Why don't these close?

Because they don't contain content.

An <img> tag just points to an image file—it doesn't wrap around text or other elements.

A <br> tag just creates a line break. There's nothing to "close."

Pro tip: In older HTML, you might see self-closing tags written like this:

<img src="photo.jpg" />

The / at the end was a thing in XHTML. Modern HTML5 doesn't require it, but some developers still use it out of habit. Both work fine.

Block-Level vs Inline Elements: The Layout Game

This is where things get interesting.

HTML elements behave in two main ways:

1. Block-Level Elements

These take up the full width of their container. They start on a new line.

Think of them like full-width boxes stacked on top of each other.

Examples:

<div>I'm a block element</div>
<p>Me too!</p>
<h1>Same here!</h1>

If you use these in your HTML, each one will appear on its own line, taking up the full width.

When I saw this in action, it clicked: Block elements are like paragraphs in a document—they naturally stack vertically.

2. Inline Elements

These only take up as much space as they need. They sit next to each other on the same line.

Think of them like words in a sentence.

Examples:

<span>I'm inline</span> <a href="#">So am I</a> <strong>Me three!</strong>

These will all appear on the same line, side by side.

Real-world example:

<p>This is a <strong>bold word</strong> inside a paragraph.</p>

The <strong> tag is inline, so it doesn't break the sentence onto a new line. It just makes that word bold and keeps flowing with the rest of the text.

Quick visual:

• Block: Think of stacking LEGO bricks vertically.

• Inline: Think of placing beads on a string horizontally.

Commonly Used HTML Tags (The Ones I Use All the Time)

Let me show you the tags I reach for constantly:

Headings

<h1>Main Title</h1>
<h2>Subheading</h2>
<h3>Smaller Subheading</h3>

Headings go from <h1> (biggest) to <h6> (smallest).

I use <h1> for the main page title, <h2> for section headings, and <h3> for sub-sections.

Paragraphs

<p>This is a paragraph. Most of your text will live here.</p>

Links

<a href="https://example.com">Click here</a>

The href attribute tells the browser where to go when someone clicks.

Images

<img src="photo.jpg" alt="Description of photo">

The alt attribute describes the image (super important for accessibility and SEO).

Divisions and Spans

<div>I'm a container for grouping stuff</div>
<span>I'm for styling small bits of text</span>

<div> is block-level (great for layout).

<span> is inline (great for styling parts of a sentence).

Lists

Unordered (bullet points):

<ul>
  <li>First item</li>
  <li>Second item</li>
</ul>

Ordered (numbered):

<ol>
  <li>Step one</li>
  <li>Step two</li>
</ol>

Buttons and Inputs

<button>Click me!</button>
<input type="text" placeholder="Enter your name">

These are interactive elements users can click or type into.

A Real Example: Putting It All Together

Here's a simple HTML snippet I might write:

<div>
  <h1>Welcome to My Blog</h1>
  <p>Hi! I'm <strong>Saurabh</strong>, a developer from India.</p>
  <p>I love exploring <a href="#">new technologies</a> and sharing what I learn.</p>
  <img src="profile.jpg" alt="Saurabh's profile picture">
</div>

What's happening here?

• <div> groups everything together (block-level container)

• <h1> creates a heading

• <p> contains paragraphs

• <strong> makes "Saurabh" bold (inline)

• <a> creates a clickable link (inline)

• <img> shows an image (self-closing)

Pro Tips I Wish I Knew Earlier

1. Use Browser DevTools

Right-click on any webpage and select Inspect (or press F12).

You'll see the HTML of that page.

This is how I learned. I'd inspect websites I liked and see how they built things.

Try it right now! Inspect this blog post and see the HTML behind it.

2. Start Simple

Don't worry about memorizing every tag.

Start with:

• Headings (<h1> to <h6>)

• Paragraphs (<p>)

• Links (<a>)

• Images (<img>)

• Divisions (<div>)

You'll naturally learn more as you build projects.

3. Semantic HTML Matters

Later, you'll learn about semantic tags like <header>, <nav>, <main>, <footer>, and <article>.

These make your HTML more meaningful (and better for accessibility and SEO).

But for now, just focus on understanding tags and elements.

4. Experiment!

Create a simple .html file, open it in your browser, and play around.

Change tags. Add content. Break things. See what happens.

That's how real learning happens.

Try This Challenge

Open a text editor (like VS Code or even Notepad).

Create a file called index.html.

Write this:

<!DOCTYPE html>
<html>
<head>
  <title>My First Page</title>
</head>
<body>
  <h1>Hello, World!</h1>
  <p>I'm learning HTML!</p>
</body>
</html>

Save it and open it in your browser.

Boom. You just created your first webpage.

Now change the text. Add more paragraphs. Add a link. Add an image.

The best way to learn is by doing.

Final Thoughts

HTML tags and elements are the foundation of everything you'll build on the web.

At first, they might feel like just a bunch of angle brackets and text. But once you understand how they work, you'll start seeing the web differently.

You'll inspect websites and think, "Oh, that's just a <div> with some <p> tags inside."

You'll build your own projects and feel that awesome moment when your code actually works.

That's the journey. And honestly? It never stops being fun.

Keep exploring. Keep building. And remember—every expert started exactly where you are right now.

Written by Saurabh Prajapati
Full-stack Software Engineer | GenAI & React Specialist
Currently building enterprise solutions at IBM India
GitHub • LinkedIn

Yeah, I've been there too.

I remember spending way too much time just typing <div class="container">, then scrolling to close it with </div>, making sure I didn't miss anything. And if I needed to create 10 list items? Copy-paste became my best friend.

Then I discovered Emmet.

And honestly? It felt like unlocking a cheat code for HTML.

Let me show you what I mean.

What is Emmet? (The Simple Version)

Emmet is basically a shortcut language for writing HTML (and CSS, but we'll focus on HTML here).

Instead of typing out full HTML tags, you write short abbreviations, hit a key (usually Tab or Enter), and Emmet instantly expands it into proper HTML code.

Think of it like autocomplete, but way smarter.

For example:

• Type div → Press Tab → Get <div></div>

• Type ul>li*3 → Press Tab → Get a full unordered list with 3 items

Wait, what? Yeah, it gets even cooler. Stick with me.

Why Should You Care About Emmet?

Here's why I think every beginner should learn Emmet early:

1. You write HTML way faster
No more typing opening and closing tags manually. Emmet does it for you.

2. You make fewer mistakes
Ever forget to close a </div>? With Emmet, tags are always properly paired.

3. It's already built into most editors
VS Code, Sublime Text, Atom—they all support Emmet out of the box. No installation needed.

4. It makes complex structures easier
Need a navigation menu with 5 links? Or a card layout with multiple nested divs? Emmet handles it in seconds.

5. Once you learn it, you'll never go back
Seriously. After using Emmet, writing HTML the old way feels... painful.

How Emmet Works Inside Your Code Editor

Before we dive into syntax, let's quickly understand how to use Emmet.

Step 1: Open your HTML file in VS Code (or any editor that supports Emmet).

Step 2: Start typing an Emmet abbreviation.

Step 3: Press Tab (or Enter in some editors).

Step 4: Watch the magic happen.

That's it.

No plugins. No setup. It just works.

Here's a quick example:

Type: h1
Press: Tab
Result: <h1></h1>

Your cursor will automatically be placed inside the tag, ready for you to type content.

Creating HTML Elements Using Emmet

Let's start with the basics: generating single HTML elements.

Single Elements

div     → <div></div>
p       → <p></p>
h1      → <h1></h1>
span    → <span></span>
button  → <button></button>

Super simple, right?

But here's where it gets interesting.

Self-Closing Elements

Emmet is smart enough to know which elements don't need closing tags:

img     → <img src="" alt="">
input   → <input type="text">
br      → <br>
hr      → <hr>

Notice how img automatically includes src and alt attributes? Emmet knows what attributes are commonly used and adds them for you.

Adding Classes and IDs

Now let's make things more practical.

In real projects, you'll almost always need classes and IDs. Here's how Emmet handles them:

Classes

Use a dot (.) to add a class:

div.container

Press Tab →

<div class="container"></div>

You can add multiple classes:

div.card.shadow.rounded

Result:

<div class="card shadow rounded"></div>

IDs

Use a hash (#) for IDs:

div#header

Result:

<div id="header"></div>

Combining Classes and IDs

div#main.container.flex

Result:

<div id="main" class="container flex"></div>

Adding Custom Attributes

What if you need to add custom attributes like data-* or href?

Use square brackets:

a[href="https://example.com"]

Result:

<a href="https://example.com"></a>

You can combine this with classes:

button.btn[type="submit"]

Result:

<button class="btn" type="submit"></button>

Or add multiple attributes:

img[src="logo.png"][alt="Company Logo"]

Result:

<img src="logo.png" alt="Company Logo">

Creating Nested Elements

This is where Emmet really starts to shine.

Use the > symbol to create child elements:

div>p

Result:

<div>
  <p></p>
</div>

You can nest as deep as you want:

div>ul>li

Result:

<div>
  <ul>
    <li></li>
  </ul>
</div>

Sibling Elements

Use + to create elements at the same level:

div>h1+p

Result:

<div>
  <h1></h1>
  <p></p>
</div>

Climbing Up

Use ^ to go back up one level:

div>ul>li^p

Result:

<div>
  <ul>
    <li></li>
  </ul>
  <p></p>
</div>

Notice how <p> is a sibling of <ul>, not a child of <li>.

Repeating Elements with Multiplication

Here's one of my favorite Emmet features: multiplication.

Use * to repeat elements:

ul>li*5

Result:

<ul>
  <li></li>
  <li></li>
  <li></li>
  <li></li>
  <li></li>
</ul>

This is so useful for creating lists, navigation menus, or any repeating structure.

Adding Classes to Repeated Elements

ul>li.item*3

Result:

<ul>
  <li class="item"></li>
  <li class="item"></li>
  <li class="item"></li>
</ul>

Numbering with $

Want numbered classes or IDs? Use $:

ul>li.item$*3

Result:

<ul>
  <li class="item1"></li>
  <li class="item2"></li>
  <li class="item3"></li>
</ul>

You can even pad numbers with zeros:

ul>li.item$$$*3

Result:

<ul>
  <li class="item001"></li>
  <li class="item002"></li>
  <li class="item003"></li>
</ul>

Grouping with Parentheses

Sometimes you need to group elements together. Use () for that:

div>(header>h1)+(main>p)+(footer>p)

Result:

<div>
  <header>
    <h1></h1>
  </header>
  <main>
    <p></p>
  </main>
  <footer>
    <p></p>
  </footer>
</div>

This keeps your Emmet abbreviations organized and readable.

Real-World Example: Building a Card Component

Let's put everything together and build a common UI component—a card.

Here's the Emmet abbreviation:

.card>(.card-header>h2.title)+(.card-body>p.description)+(.card-footer>button.btn)

Press Tab →

<div class="card">
  <div class="card-header">
    <h2 class="title"></h2>
  </div>
  <div class="card-body">
    <p class="description"></p>
  </div>
  <div class="card-footer">
    <button class="btn"></button>
  </div>
</div>

That would've taken forever to type manually. With Emmet? Done in seconds.

Generating Full HTML Boilerplate

Here's a game-changer I wish I knew earlier:

Just type ! and press Tab.

Result:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Document</title>
</head>
<body>

</body>
</html>

Boom. Full HTML5 boilerplate in one keystroke.

No more searching for templates or copy-pasting from old projects.

Common Emmet Patterns You'll Use Daily

Here are some shortcuts I use all the time:

Navigation Menu:

nav>ul>li*5>a

Form with Inputs:

form>input[type="text"]+input[type="email"]+button[type="submit"]

Grid Layout:

.container>.row>.col*3

Article Structure:

article>header>h1+p^^section>p*3

Try these in your editor. Play around. Break things. That's how you learn.

Tips for Learning Emmet

1. Start small
Don't try to learn everything at once. Master basic elements first, then add classes, then nesting.

2. Practice with real projects
Use Emmet every time you write HTML. It'll become muscle memory.

3. Use the cheat sheet
Keep the Emmet cheat sheet bookmarked. I still refer to it sometimes.

4. Experiment in the editor
Type random abbreviations and see what happens. That's how I learned most tricks.

5. Remember: Emmet is optional
You don't have to use it. But once you do, you'll wonder how you ever coded without it.

Final Thoughts

Emmet isn't magic. It's just a tool.

But it's a really good tool.

It won't make you a better developer overnight. But it will make you a faster one.

And in this field, speed matters—not because you should rush, but because the less time you spend on repetitive tasks, the more time you have for creative problem-solving.

So give Emmet a try. Open your editor. Type ! and press Tab.

See what happens.

I think you'll like it.

Happy coding!

— Saurabh

About the Author

Hey! I'm Saurabh Prajapati, a full-stack software engineer at IBM India Software Lab, where I work on Maximo building cloud-native enterprise solutions.

I love exploring new tools and technologies and sharing what I learn along the way. If you're into web development, AI-powered tools, or modern JavaScript, let's connect!

• GitHub: prajapatisaurabh

• LinkedIn: saurabh-prajapati

• Email: saurabhprajapati120@gmail.com

Currently available for interesting projects and collaborations. Let's build something cool together!

That's when I realized I needed to actually understand CSS selectors properly. Not just copy-paste from Stack Overflow, but really get how they work.

Let me share what I learned.

Why Do We Even Need CSS Selectors?

Here's the thing: HTML gives you the structure, but CSS makes it look good. But how does CSS know which elements to style?

That's where selectors come in.

Think of it like addressing a letter. You can't just write "Hey you!" on an envelope and expect it to reach the right person. You need an address, a name, something specific.

CSS selectors are exactly that—they're the addressing system for your HTML elements.

When I first started, I thought all I needed was:

p {
  color: blue;
}

And sure, this works. But what if I only want some paragraphs to be blue? What if I have 50 paragraphs and only want to style 3 of them?

That's when things get interesting.

The Element Selector: Keep It Simple

The most basic selector is the element selector. It targets all elements of a specific type.

h1 {
  color: navy;
}

p {
  font-size: 16px;
}

button {
  background-color: green;
}

This is super straightforward. Every <h1> on your page gets navy color. Every <p> gets 16px font size. Every <button>gets a green background.

When I use this:

When I want consistent styling across all elements of the same type. Like making all headings the same color or all paragraphs the same font size.

The catch:

It's too broad. If you have 10 buttons and only want to style 1 of them differently, this won't help.

The Class Selector: Your Best Friend

This is where things clicked for me. Classes let you group elements together, even if they're different types.

<h2 class="highlight">Important Heading</h2>
<p class="highlight">Important paragraph</p>
<button class="highlight">Important Button</button>

.highlight {
  background-color: yellow;
  font-weight: bold;
}

See that dot (.) before highlight? That's how you target a class in CSS.

Now, all three elements—heading, paragraph, and button—get the same styling because they share the class highlight.

Why I love this:

You can reuse classes anywhere. Need 5 different elements to have the same style? Give them all the same class. Done.

Real example from my project:

I was building a card layout and needed all cards to look the same. Instead of styling each card individually, I just gave them all a .card class:

.card {
  border: 1px solid #ddd;
  padding: 20px;
  border-radius: 8px;
  box-shadow: 0 2px 4px rgba(0,0,0,0.1);
}

Saved me so much time.

The ID Selector: Use Sparingly

IDs are like classes, but with one major difference: an ID should be unique on the page.

<div id="header">Site Header</div>
<div id="main-content">Main content here</div>
<div id="footer">Footer</div>

#header {
  background-color: darkblue;
  color: white;
}

#main-content {
  padding: 40px;
}

#footer {
  text-align: center;
  font-size: 14px;
}

Notice the hash symbol (#) before the ID name? That's the syntax.

When I use IDs:

Honestly? Not that often for styling. IDs are great for JavaScript or linking to specific sections (like <a href="#main-content">), but for CSS, classes are usually better.

Here's why:

IDs have higher specificity (we'll get to that), and they're harder to reuse. If you give something an ID, you're saying "this is the only one on the page." That's rarely what you want for styling.

My rule of thumb:

Classes for styling, IDs for unique page sections or JavaScript hooks.

Group Selectors: DRY (Don't Repeat Yourself)

This was a game-changer when I discovered it.

Let's say you want multiple elements to share the same styles:

h1 {
  color: navy;
  font-family: Arial, sans-serif;
}

h2 {
  color: navy;
  font-family: Arial, sans-serif;
}

h3 {
  color: navy;
  font-family: Arial, sans-serif;
}

That's... repetitive. And boring. And hard to maintain.

Here's the better way:

h1, h2, h3 {
  color: navy;
  font-family: Arial, sans-serif;
}

Just separate the selectors with commas. Now all three headings get the same styles.

You can mix and match too:

h1, .special-text, #intro {
  text-transform: uppercase;
}

This applies uppercase styling to all <h1> elements, anything with the class special-text, and the element with ID intro.

When I use this:

Whenever I notice I'm writing the same CSS rules multiple times. It keeps my code clean and makes updates easier.

Descendant Selectors: Getting Specific

Okay, this is where it gets really powerful.

Sometimes you want to style an element, but only when it's inside another element.

<div class="card">
  <p>This paragraph is inside the card.</p>
</div>

<p>This paragraph is outside the card.</p>

.card p {
  color: blue;
}

This targets only the <p> that's inside .card. The paragraph outside? Unaffected.

The syntax:

Just put a space between the selectors. .card p means "a <p> that's a descendant of .card."

Real-world example:

I had a navigation menu where I wanted links to look different:

<nav class="main-nav">
  <a href="#">Home</a>
  <a href="#">About</a>
  <a href="#">Contact</a>
</nav>

<a href="#">Regular link outside nav</a>

.main-nav a {
  color: white;
  text-decoration: none;
  padding: 10px;
}

Now only the links inside .main-nav get styled. The link outside? It stays as a default browser link.

Important note:

Descendant selectors work for any level of nesting. If you have:

<div class="card">
  <div class="content">
    <p>Text here</p>
  </div>
</div>

The selector .card p will still work, even though the <p> is nested two levels deep.

Selector Priority: Who Wins?

Here's something that confused me for ages: What happens when multiple selectors target the same element?

<p class="intro" id="first-paragraph">Hello!</p>

p {
  color: black;
}

.intro {
  color: blue;
}

#first-paragraph {
  color: red;
}

Which color wins?

The answer: red.

CSS has a specificity system. Think of it as a scoring system:

• Element selectors: 1 point

• Class selectors: 10 points

• ID selectors: 100 points

So in our example:

• p has 1 point

• .intro has 10 points

• #first-paragraph has 100 points

The highest score wins. That's why the ID selector wins here.

What I learned the hard way:

Don't fight specificity with !important. I used to do this:

.intro {
  color: blue !important;
}

This forces the rule to apply no matter what. But it creates chaos later when you need to override that rule.

Better approach:

Use more specific selectors instead:

div.intro {
  color: blue;
}

This has more specificity than just .intro, and it's cleaner than using !important.

Before & After: Seeing the Difference

Let me show you a real example of selectors in action.

Before (no selectors, default styling):

<h1>My Website</h1>
<p>Welcome to my site.</p>
<p>Here's some content.</p>
<button>Click Me</button>
<button>Another Button</button>

Everything looks bland. Default black text, Times New Roman font, unstyled buttons.

After (with selectors):

<h1 class="page-title">My Website</h1>
<p class="intro">Welcome to my site.</p>
<p>Here's some content.</p>
<button class="primary-btn">Click Me</button>
<button>Another Button</button>

.page-title {
  color: darkblue;
  font-family: Arial, sans-serif;
  font-size: 36px;
}

.intro {
  font-size: 18px;
  font-weight: bold;
  color: #333;
}

.primary-btn {
  background-color: blue;
  color: white;
  padding: 10px 20px;
  border: none;
  border-radius: 5px;
  cursor: pointer;
}

Now:

• The heading stands out with color and size

• The intro paragraph is emphasized

• The primary button looks professional

• The regular paragraph and second button keep default styles

This is the power of selectors. You target exactly what you want, nothing more, nothing less.

Key Takeaways (What I Wish I Knew Earlier)

1. Start with element selectors for global styles
   Use them for things that should be consistent everywhere (like body font, heading sizes).

2. Classes are your workhorses
   Use them for most styling. They're reusable and flexible.

3. IDs are for unique elements
   Great for page sections or JavaScript, but don't rely on them for styling.

4. Group selectors save time
   Stop repeating yourself. Group common styles together.

5. Descendant selectors give you control
   Want to style something only in a specific context? This is how.

6. Specificity matters
   More specific selectors win. Plan your selector strategy accordingly.

Final Thoughts

CSS selectors seemed complicated at first, but now I see them as one of the most elegant parts of web development.

They're precise. They're powerful. They're the bridge between your HTML structure and your visual design.

And once you understand them, styling becomes less about fighting with CSS and more about crafting exactly the look you want.

If you're just starting out, take your time with this. Practice with small projects. Build a simple webpage and experiment with different selectors.

Trust me, it's worth it.

Have you struggled with CSS selectors before? What clicked for you? I'd love to hear your "aha!" moment.

Written by Saurabh Prajapati
Full-stack Software Engineer specializing in GenAI, React, and Modern Web Technologies.
Currently building enterprise solutions at IBM India Software Lab.

Want to connect? Find me on GitHub or LinkedIn.