Forem: SATYA SOOTAR

String Polyfills and Common Interview Methods in JavaScript

SATYA SOOTAR — Tue, 05 May 2026 10:48:33 +0000

Hello readers 👋, welcome to the 24th blog in this JavaScript series!

Last time we explored the clever spread and rest operators, learning how the same three dots can either unpack or collect data. Today we are shifting gears to a topic that deeply sharpens your understanding of how JavaScript works under the hood: string polyfills and common interview methods.

Have you ever wondered how "hello".includes("ell") works inside the engine? Or how you could make the same behavior work in an old browser that doesn't support includes? That's exactly what we are going to dive into. We will not just use string methods, we will build several of them from scratch, understand the logic, and then solve some classic interview string problems.

Let's get our hands dirty.

What string methods are

In JavaScript, every string is a primitive value, but when you access a property or method on it, the engine wraps it in a String object behind the scenes. This gives you access to a large set of built-in methods like indexOf, slice, substring, includes, startsWith, endsWith, trim, repeat, and many more.

These methods help you manipulate and inspect strings without manually looping through characters. For example:

const greeting = "Hello, Satya";
console.log(greeting.includes("Satya")); // true
console.log(greeting.startsWith("Hello")); // true
console.log(greeting.endsWith("ya")); // true
console.log(greeting.repeat(2)); // "Hello, SatyaHello, Satya"

They are convenient, but they are also abstractions over simple character-by-character operations. Understanding what happens under the hood is not only fascinating but also extremely valuable for technical interviews.

Why developers write polyfills

A polyfill is a piece of code that provides modern functionality to older browsers that lack it. For example, String.prototype.includes was introduced in ES6 (2015). If you needed to support an environment that didn't have it, you would write your own version of includes and attach it to String.prototype (carefully, of course).

But even in modern development, writing polyfills serves another purpose: it forces you to truly understand how a method works. Interviewers love to ask, "Can you implement your own version of startsWith?" or "How would you write a polyfill for repeat?" Knowing the internal logic makes you a stronger developer and prepares you for these moments.

So, let's start building.

Implementing simple string utilities: polyfills

We will write our own versions of several common string methods. For each one, I'll explain the logic step by step and then show the code. Remember, these are simplified educational versions that aim to mimic the core behavior as per the MDN specification.

Polyfill for `includes`

The includes method determines whether one string can be found within another string, returning true or false. It takes a search string and an optional position from which to start searching. It is case-sensitive.

Logic: Loop through the main string from the given start position. For each index, check if the substring starting there matches the search string. If we find a full match, return true. If we reach the end without a match, return false.

if (!String.prototype.myIncludes) {
  String.prototype.myIncludes = function(search, start) {
    if (search instanceof RegExp) {
      throw new TypeError("First argument must not be a RegExp");
    }
    start = start || 0;
    if (start + search.length > this.length) return false;
    return this.indexOf(search, start) !== -1;
  };
}

Wait, we used indexOf above! That's cheating if we want a from-scratch polyfill without relying on other ES6 methods. So let's do a straight loop:

String.prototype.myIncludes = function(search, start) {
  if (search instanceof RegExp) throw new TypeError("First argument must not be a RegExp");
  start = start || 0;
  var source = this;
  while (start + search.length <= source.length) {
    var match = true;
    for (var i = 0; i < search.length; i++) {
      if (source[start + i] !== search[i]) {
        match = false;
        break;
      }
    }
    if (match) return true;
    start++;
  }
  return false;
};

Now we have a pure implementation. The nested loop checks for character-by-character equality at each possible starting position.

Polyfill for `startsWith`

startsWith checks if a string begins with the characters of a specified string, returning true or false. It also accepts an optional position.

Logic: From the given position, compare the characters of the source string with the search string. If all match, return true. If any mismatch or if the remaining length is shorter than the search string, return false.

String.prototype.myStartsWith = function(searchString, position) {
  position = position || 0;
  if (position + searchString.length > this.length) return false;
  for (var i = 0; i < searchString.length; i++) {
    if (this[position + i] !== searchString[i]) {
      return false;
    }
  }
  return true;
};

This is straightforward: we just compare the two strings side by side from the starting index.

Polyfill for `endsWith`

endsWith checks if a string ends with the characters of a specified string, returning true or false. It accepts an optional length parameter, which sets the length of the string to consider. If not provided, it defaults to the full string length.

Logic: We need to compare the end of the source string (up to the given length) with the search string. The start index for comparison will be (length - searchString.length).

String.prototype.myEndsWith = function(searchString, length) {
  var sourceLen = length !== undefined ? length : this.length;
  if (sourceLen > this.length) sourceLen = this.length;
  var startIndex = sourceLen - searchString.length;
  if (startIndex < 0) return false;
  for (var i = 0; i < searchString.length; i++) {
    if (this[startIndex + i] !== searchString[i]) {
      return false;
    }
  }
  return true;
};

Test it:

console.log("Hello world".myEndsWith("world")); // true
console.log("Hello world".myEndsWith("Hello", 5)); // true

Polyfill for `repeat`

repeat constructs and returns a new string which contains the specified number of copies of the string on which it was called, concatenated together. It throws a RangeError if the count is negative or Infinity, and a count of zero returns an empty string.

Logic: We start with an empty string, then loop count times, appending the original string each time. However, for large counts, this would be inefficient. For a polyfill, a simple loop is fine as it's unlikely to be used with huge numbers in older browsers. But we can implement a more efficient method using doubling.

For simplicity, we'll do a loop and also handle non-integer counts by flooring them.

String.prototype.myRepeat = function(count) {
  if (count < 0 || count === Infinity) {
    throw new RangeError("Invalid count value");
  }
  count = Math.floor(count);
  var result = "";
  for (var i = 0; i < count; i++) {
    result += this;
  }
  return result;
};

Test: "abc".myRepeat(3) gives "abcabcabc".

Polyfill for `trim`

trim removes whitespace from both ends of a string. Whitespace includes spaces, tabs, no-break spaces, and all line terminator characters.

Logic: Use a regular expression to strip leading and trailing whitespace. Alternatively, loop from the start and end to find the first non-whitespace character and slice the string.

A regex approach is simple and works in older environments:

String.prototype.myTrim = function() {
  return this.replace(/^[\s\uFEFF\xA0]+|[\s\uFEFF\xA0]+$/g, "");
};

\s matches spaces, tabs, line breaks; \uFEFF is BOM (Byte Order Mark); \xA0 is non-breaking space. This closely matches the ES5 specification.

Common interview string problems and their logic

Beyond polyfills, interviews often test your ability to manipulate strings using basic algorithms. Here are a few classic problems, along with the thought process and solutions.

1. Reverse a string

Probably the most famous beginner question: "Write a function that reverses a string." The trick is to avoid using the built-in reverse method on arrays, at least in the explanation, but we can show multiple approaches.

Approach 1: Loop from end to start

function reverseString(str) {
  var reversed = "";
  for (var i = str.length - 1; i >= 0; i--) {
    reversed += str[i];
  }
  return reversed;
}

Approach 2: Using array methods (built-in but still asked)

function reverseString(str) {
  return str.split("").reverse().join("");
}

2. Check if a string is a palindrome

A palindrome reads the same forward and backward. You can use the reverse function and compare, but it's more efficient to compare characters from both ends moving inward.

function isPalindrome(str) {
  str = str.toLowerCase().replace(/[^a-z0-9]/g, ""); // sanitize
  var left = 0;
  var right = str.length - 1;
  while (left < right) {
    if (str[left] !== str[right]) return false;
    left++;
    right--;
  }
  return true;
}

3. Count occurrences of a character or substring

A straightforward loop or using split:

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

// Using split trick (but not recommended for interviews if they want algorithm)
function countSubstring(str, sub) {
  return str.split(sub).length - 1;
}

4. Truncate a string

Write a function that truncates a string to a given length and appends "..." if it was truncated.

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

5. Capitalize the first letter of each word

A classic transformation:

function capitalizeWords(str) {
  return str.split(" ").map(function(word) {
    if (word.length === 0) return word;
    return word[0].toUpperCase() + word.slice(1).toLowerCase();
  }).join(" ");
}

6. Remove duplicates from a string

We can use a Set, but interviewers might ask for a manual approach:

function removeDuplicates(str) {
  var seen = {};
  var result = "";
  for (var i = 0; i < str.length; i++) {
    if (!seen[str[i]]) {
      seen[str[i]] = true;
      result += str[i];
    }
  }
  return result;
}

These exercises train you to think in loops and conditionals, which is exactly the skill needed to write polyfills or solve algorithmic challenges.

The importance of understanding built-in behavior

When you write a polyfill, you are essentially stepping into the shoes of the JavaScript engine. You learn to handle edge cases: what happens if the argument is a RegExp? What if the count is Infinity? How does case-sensitivity work? This depth of understanding makes you a safer and more precise developer.

In an interview, if you can not only use includes but also explain how it might be implemented and then code it up on a whiteboard, you demonstrate a fundamental command of the language that many candidates lack. It shows you don't just memorize methods; you understand principles.

Moreover, knowing the internal logic helps you debug mysterious bugs. For instance, understanding that trim removes a specific set of whitespace characters, not just spaces, prevents unexpected failures when dealing with user input.

Visualizing string processing flow

I often picture a string method as a loop with a pointer scanning across the characters. For includes, imagine a sliding window. You have the main string, and you slide the search string along it, checking each position until you find a match or reach the end.

For startsWith, you only look at the very beginning, like checking the first few letters of a book title to see if it matches a given prefix. For endsWith, you look at the last letters, moving your attention to the tail of the string.

For something like repeat, it's like a factory that takes a template and stamps out copies, joining them one after another. For trim, you walk in from both edges, trimming away whitespace until you hit a visible character, then capture the inner part.

This mental imagery makes writing polyfills much easier because you translate the visual into code.

Conclusion

Today we've gone beyond just using string methods and dug into the logic that powers them. We built polyfills for includes, startsWith, endsWith, repeat, and trim, seeing how simple loops and conditionals can replicate browser-native behavior. We also solved common interview string problems to reinforce the thinking pattern.

Let's summarize the key takeaways:

String methods are built-in tools that manipulate strings, but they are all based on fundamental operations like looping, comparison, and slicing.
Polyfills are implementations of modern methods that enable them in older environments, and writing them deepens your understanding of JavaScript.
We created step-by-step polyfills for includes, startsWith, endsWith, repeat, and trim, each with a clear logic.
Interview problems like reversing a string, checking palindromes, counting occurrences, and capitalizing words rely on the same foundational skills.
Truly comprehending built-in behavior prepares you for technical interviews and makes you a more effective developer.

The next time you use a string method, you'll know exactly what's happening behind the scenes, and you'll be ready to tackle any string-related challenge that comes your way.

Hope you found this helpful! If you spot any mistakes or have suggestions, let me know. You can find me on LinkedIn and X, where I post more about web development.

Spread vs Rest Operators in JavaScript

SATYA SOOTAR — Tue, 05 May 2026 10:44:04 +0000

Hello readers 👋, welcome to the 23rd blog in this JavaScript series!

In the last post, we discovered how async/await makes asynchronous code feel as natural as synchronous code. Today, we are going to talk about a pair of operators that look identical but do completely opposite jobs: the spread and rest operators.

Both use three dots (...), but one expands values out while the other collects values in. This tiny syntax is incredibly powerful and appears all over modern JavaScript. Let's unravel the mystery and see where each one shines.

What the spread operator does

Think of the spread operator as an unpacking tool. It takes an array or an object and spreads its elements or properties into individual pieces. It is like opening a box of chocolates and laying them all out on a table. The box (the array) gives you the chocolates (the individual items).

Spreading an array

Before spread, if you wanted to concatenate two arrays, you used concat. With spread, you just unpack the arrays inside a new one:

const fruits = ["apple", "banana"];
const moreFruits = ["orange", "mango"];

// Old way
const combinedOld = fruits.concat(moreFruits);

// Spread way
const combined = [...fruits, ...moreFruits];

console.log(combined); // ["apple", "banana", "orange", "mango"]

You can spread anywhere inside a new array. This makes it effortless to insert elements while copying:

const numbers = [10, 20, 30];
const withZero = [0, ...numbers, 40, 50];
console.log(withZero); // [0, 10, 20, 30, 40, 50]

Spreading an object

With objects, spread lets you copy properties from one object into another. This is incredibly handy for creating modified copies without mutating the original.

const user = {
  name: "Satya",
  age: 25
};

const updatedUser = {
  ...user,
  role: "developer",
  age: 26  // overrides the original age
};

console.log(updatedUser);
// { name: "Satya", age: 26, role: "developer" }

Notice that order matters. If you spread an object and then add a property with the same key later, the later one wins. This makes it easy to override defaults.

Real world example: updating state

In React and other frameworks, you often update state immutably. Before spread, you'd use Object.assign. Spread makes it way cleaner:

// Without spread
const updatedState = Object.assign({}, prevState, { count: prevState.count + 1 });

// With spread
const updatedState = { ...prevState, count: prevState.count + 1 };

What the rest operator does

If spread is unpacking, the rest operator is packing things together. It collects multiple values and condenses them into a single array. The same three dots, but used in a different context, like a vacuum cleaner gathering scattered crumbs into a bag.

Rest parameters in functions

You can use rest in a function's parameter list to capture any number of arguments into an array. This replaces the old arguments object (which was not a real array) and gives you a proper array with all the useful methods.

function sum(...numbers) {
  return numbers.reduce((total, num) => total + num, 0);
}

console.log(sum(1, 2, 3));        // 6
console.log(sum(5, 10, 15, 20));  // 50

The ...numbers collects all passed arguments into the numbers array. You can name it anything you like.

Rest in destructuring

When destructuring an array or object, you can use rest to collect the remaining elements that were not explicitly captured.

const colors = ["red", "green", "blue", "yellow"];
const [first, second, ...restColors] = colors;

console.log(first);       // "red"
console.log(second);      // "green"
console.log(restColors);  // ["blue", "yellow"]

Here, first and second capture the first two elements, and ...restColors collects the rest into a new array.

With objects:

const person = {
  name: "Satya",
  age: 25,
  city: "Bhubaneswar",
  country: "India"
};

const { name, age, ...address } = person;
console.log(name);     // "Satya"
console.log(age);      // 25
console.log(address);  // { city: "Bhubaneswar", country: "India" }

The rest operator grabs the remaining properties and puts them into a fresh object. It's a clean way to separate specific properties from the rest of the object.

Differences between spread and rest

The easiest way to remember the difference is to look at where the three dots appear.

Spread appears on the right side of an assignment or inside a function call. It expands an iterable into individual items or an object's properties into individual properties.
Rest appears on the left side of an assignment (destructuring) or in function parameters. It collects multiple items into a single array or object.

Think of it like a box. Spread is taking things out of the box; rest is putting things back into the box.

Context	Operator	Action
Function call: `func(...arr)`	Spread	Expands array into individual arguments
Array literal: `[...arr]`	Spread	Copies/expands elements into a new array
Object literal: `{...obj}`	Spread	Copies/expands properties into a new object
Function definition: `function f(...args)`	Rest	Collects arguments into an array
Array destructuring: `[a, ...rest]`	Rest	Collects remaining elements into an array
Object destructuring: `{a, ...rest}`	Rest	Collects remaining properties into an object

Practical use cases that show both powers

Combining arrays and adding extras

const opening = ["Love", "Brave"];
const middle = ["Trust", "Peace"];
const closing = ["Hope", "Joy"];

const all = [...opening, "extra", ...middle, ...closing];
console.log(all);

Passing array elements as function arguments

You can spread an array when calling a function like Math.max, which expects comma-separated numbers:

const scores = [45, 89, 32, 98, 12];
const highest = Math.max(...scores);
console.log(highest); // 98

Without spread, you'd need Math.max.apply(null, scores), which is far less readable.

Creating a shallow copy of an object

When you need to duplicate an object without keeping the reference, spread gives a simple one-liner:

const original = { a: 1, b: 2 };
const copy = { ...original };
copy.a = 99;
console.log(original.a); // 1 (unchanged)

Be careful: it's a shallow copy, so nested objects are still referenced.

Collecting function arguments with rest, then spreading them again

Sometimes you capture arguments with rest, do some processing, and then spread them again:

function logWithPrefix(prefix, ...messages) {
  const fullMessages = messages.map(msg => `${prefix}: ${msg}`);
  console.log(...fullMessages);
}

logWithPrefix("INFO", "Server started", "Port 3000");
// INFO: Server started INFO: Port 3000

Splitting an object into a focused part and the rest

Useful when you want to remove specific keys from an object without mutating it:

const data = { id: 1, name: "Satya", password: "secret", role: "admin" };
const { password, ...safeData } = data;
console.log(safeData); // { id: 1, name: "Satya", role: "admin" }

We extracted the sensitive password and left the rest safe for logging or sending to the client.

Visualizing the concepts

Imagine you have a basket of fruits (an array). The spread operator is like emptying the basket onto a table, fruit by fruit. The items are now individual pieces you can move around.

On the other hand, the rest operator is like scooping up the leftover fruits on the table and putting them back into a new basket. You gather them into one container.

This mental image of unpacking vs packing keeps the two straight in your mind.

Conclusion

Spread and rest operators are small syntax additions that make a huge difference in how we write JavaScript. They both use ... but have precisely defined roles: spread expands, rest collects.

To quickly recap:

Spread unpacks elements from an array or properties from an object into individual items. You use it in function calls, array literals, and object literals to copy, merge, or pass values.
Rest collects multiple elements or properties into a single array or object. You use it in function parameters or destructuring patterns.
The context determines the behavior: right-side or call-position means spread, left-side or parameter-position means rest.
Both operators lead to cleaner, more expressive code, replacing verbose methods like concat, apply, or manual cloning.

Mastering these two operators will make your code more readable and help you handle data transformations with elegance. You'll see them everywhere, from React state updates to utility functions.

Hope you found this helpful! If you spot any mistakes or have suggestions, let me know. You can find me on LinkedIn and X, where I post more about web development.

Async/Await in JavaScript: Writing Cleaner Asynchronous Code

SATYA SOOTAR — Tue, 05 May 2026 10:39:57 +0000

Hello readers 👋, welcome to the 22nd blog in this JavaScript series!

In our last post, we learned how try...catch helps us build resilient applications that handle failures gracefully. Today we are going to explore something that makes asynchronous code feel almost as straightforward as synchronous code: async/await.

If you have ever wished that promise chains could read like a simple sequence of steps, or that you could use try...catch directly with async operations, async/await is exactly what you need. It doesn't replace promises; it builds on top of them to make our code cleaner and more intuitive. Let's understand it step by step.

Why async/await was introduced

Promises already solved the callback hell problem. We went from deeply nested callbacks to flat chains of .then(). But even with promises, complex logic can still look a little noisy. Consider a scenario where you need to:

Fetch a user from an API
If the user has a certain role, fetch extra permissions
Use the result to update the UI

With promises alone, you might write something like:

fetchUser(userId)
  .then(user => {
    if (user.role === "admin") {
      return fetchPermissions(user.id)
        .then(permissions => {
          return { user, permissions };
        });
    }
    return { user, permissions: [] };
  })
  .then(result => {
    console.log("Data ready:", result);
  })
  .catch(error => {
    console.log("Failed:", error);
  });

This works, but mixing conditional logic with nested .then() calls makes the flow harder to read. Debugging multiple chained .then() blocks can also be tricky because the stack trace gets cluttered. Async/await was introduced to let us write code that looks and behaves more like regular synchronous code, while still being non-blocking under the hood.

How async functions work

An async function is a function declared with the async keyword. Every async function automatically returns a promise. Whatever value you return from the function is wrapped in a resolved promise. If the function throws an error, the returned promise is rejected.

Here is the simplest form:

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

console.log(greet()); // Promise { <fulfilled>: "Hello!" }

greet().then(value => console.log(value)); // Hello!

Even though we returned a plain string, the caller receives a promise. This means we can use .then(), .catch(), or await on it just like any other promise.

Inside an async function, we can use the await keyword to pause execution until a promise settles. That is where the real magic begins.

The await keyword concept

The await keyword can only be used inside an async function (or at the top level of a module in modern JavaScript). It causes the function execution to pause until the promise on its right-hand side settles, and then it returns the resolved value.

Let's start with a simple delay:

function wait(ms) {
  return new Promise(resolve => setTimeout(resolve, ms));
}

async function run() {
  console.log("Start");
  await wait(2000);
  console.log("Two seconds later");
}

run();
console.log("This logs immediately");

The output order is:

Start
This logs immediately
Two seconds later

When the JavaScript engine hits await wait(2000), the run function suspends. The event loop is free to execute other code, so the outer console.log runs immediately. After two seconds, the promise resolves, and run resumes exactly where it left off.

The key insight: await does not block the main thread. It just makes the async function wait while letting the rest of the program continue. This is exactly what we want.

Rewriting promise chains with async/await

Let's rewrite the earlier user fetching example with async/await. We will use a real API (JSONPlaceholder) and break down the code to see the improvement.

First, the promise version:

function fetchUser(id) {
  return fetch(`https://jsonplaceholder.typicode.com/users/${id}`)
    .then(res => {
      if (!res.ok) throw new Error("Network error");
      return res.json();
    });
}

function fetchPosts(userId) {
  return fetch(`https://jsonplaceholder.typicode.com/posts?userId=${userId}`)
    .then(res => res.json());
}

// Promise chain
fetchUser(1)
  .then(user => {
    console.log("User:", user.name);
    return fetchPosts(user.id);
  })
  .then(posts => {
    console.log("Number of posts:", posts.length);
  })
  .catch(error => {
    console.log("Error:", error.message);
  });

Now the async/await version:

async function displayUserData(userId) {
  try {
    const user = await fetchUser(userId);
    console.log("User:", user.name);

    const posts = await fetchPosts(user.id);
    console.log("Number of posts:", posts.length);
  } catch (error) {
    console.log("Error:", error.message);
  }
}

displayUserData(1);

The difference is striking. The async/await version looks like a normal sequence of steps: wait for user, then log it, then wait for posts, then log them. The variables user and posts are directly available, and we used a simple try...catch block for error handling. No more chaining .then() and passing data through callbacks.

Error handling with async/await

Error handling with async/await is much more natural because we can use the familiar try...catch syntax directly around asynchronous code. If any awaited promise rejects, or if any code inside the try block throws, the catch block catches it.

async function riskyOperation() {
  try {
    const response = await fetch("invalid-url");
    const data = await response.json();
    console.log(data);
  } catch (error) {
    console.log("Something went wrong:", error.message);
  }
}

You can also catch errors at the call site when you call an async function, because the function itself returns a promise:

async function getData() {
  throw new Error("Oops");
}

getData().catch(error => console.log(error.message));

Using both together lets you choose the granularity of error handling. You can handle errors locally with try...catch inside the async function, or let them propagate to the caller.

Comparison with promises

Async/await is syntactic sugar over promises, which means everything you can do with async/await you can do with promises. But the improvement in readability and simplicity is massive.

Let's compare the two approaches side by side:

Aspect	Promises	Async/Await
Readability	Chain of `.then()` calls, can become nested with conditions	Linear code that reads like synchronous steps
Error handling	`.catch()` at the end of chain, or a second argument in `.then()`	Standard `try...catch` blocks
Debugging	Stack traces can be confusing; breakpoints may skip async gaps	More intuitive stack traces; you can step through the code like sync
Intermediate values	Need to thread values through the chain or use external variables	Values are assigned to variables and stay in scope
Conditional logic	Requires nesting `.then()` or using `Promise.resolve()` placeholders	Use regular `if` statements, no nesting

Here is a concrete example that shows the comfort of conditional logic with async/await:

Inline with promises (somewhat messy):

fetchUser(id).then(user => {
  if (user.isAdmin) {
    return fetchAdminData(user.id).then(adminData => {
      console.log(adminData);
    });
  } else {
    console.log("Not an admin");
  }
});

Inline with async/await:

async function handleUser(id) {
  const user = await fetchUser(id);
  if (user.isAdmin) {
    const adminData = await fetchAdminData(user.id);
    console.log(adminData);
  } else {
    console.log("Not an admin");
  }
}

The async/await version is clearly cleaner. The flow is visible at a glance, and we didn't add any extra nesting.

Avoiding common pitfalls

While async/await is wonderful, there are a few traps to watch out for:

1. Using await outside an async function

This will throw a syntax error. If you need to use await at the top level, you can use an async IIFE (Immediately Invoked Function Expression) or, in modern environments, top-level await in a module.

// IIFE workaround
(async () => {
  const result = await someAsyncFunc();
  console.log(result);
})();

2. Forgetting to handle rejections

If an async function is called and its promise is not handled with .catch() or try...catch, then a rejected promise will go unhandled. This can lead to hidden bugs. Always handle errors somewhere in the chain.

3. Unnecessary sequential execution

When you need to run multiple independent async operations, be careful not to await them one by one if they could run in parallel. That can slow down your program.

// Sequential, slower
const user = await fetchUser(1);
const posts = await fetchPosts(1);

// Parallel, faster
const [user, posts] = await Promise.all([fetchUser(1), fetchPosts(1)]);

Use Promise.all (or allSettled) when the operations don't depend on each other.

Visualizing the execution flow

I often picture an async function as a bookmark in a book. When the function hits an await, it puts a bookmark on that line, closes the book, and goes to do other tasks. The event loop keeps turning. When the awaited promise resolves, the function opens the book again, flips to the bookmark, and continues reading from that exact point.

A typical async function flow looks like this:

This "pause and resume" behavior is why debugging async/await feels like debugging synchronous code. You can set breakpoints and step through the lines in the same linear order they appear.

Conclusion

Async/await is one of the most loved features of modern JavaScript, and for good reason. It takes the solid foundation of promises and adds a layer of readability that makes asynchronous code feel natural.

To recap what we learned:

async makes a function return a promise automatically.
await pauses the execution of an async function until a promise settles, without blocking the main thread.
Error handling uses try...catch, mirroring synchronous code patterns.
Async/await greatly improves readability, especially with conditional logic and sequential async steps.
It is not a replacement for promises but a powerful syntax built on top of them.
Be mindful of sequential vs parallel execution; use Promise.all when you can.

With async/await in your toolkit, you can write code that tells a clear story, step by step, no matter how many asynchronous operations it needs to coordinate. It's a joy to read and a pleasure to maintain.

Hope you found this helpful! If you spot any mistakes or have suggestions, let me know. You can find me on LinkedIn and X, where I post more about web development.

Error Handling in JavaScript: Try, Catch, Finally

SATYA SOOTAR — Tue, 05 May 2026 10:30:51 +0000

Hello readers 👋, welcome to the 21st blog in this JavaScript series!

In the last post, we unlocked the elegance of destructuring and how it simplifies working with arrays and objects. Today, we are going to talk about a topic that separates a fragile program from a robust one: error handling. No matter how carefully we write code, things go wrong. A network fails, a file is missing, an API returns an unexpected shape, or a user provides invalid input. Writing code that survives these problems gracefully is what good error handling is all about.

We will explore the tools JavaScript gives us: try, catch, and finally. We will also see how to throw our own custom errors and why this entire practice matters so much.

Let's get into it.

What errors are in JavaScript

Before we handle errors, let's understand what they are. In JavaScript, errors are objects created by the engine when something goes wrong during execution. You might have seen some of them:

SyntaxError: The code cannot be parsed. For example, missing a closing bracket. These errors prevent the whole script from running.
ReferenceError: You try to use a variable that hasn't been declared. Like console.log(x) when x is not defined.
TypeError: You do something with a value that isn't possible, like calling undefined as a function or reading a property on null.
RangeError: You use a number outside an allowed range, like calling new Array(-1) or exceeding the call stack size.
URIError: Occurs when encodeURI or decodeURI gets invalid parameters (rare).

Runtime errors (everything except SyntaxError) happen while the code is running. If we don't catch them, they bubble up, stop the entire script, and leave the user with a broken experience. Our goal is to anticipate and handle these runtime errors so that the application continues to work or fails in a controlled, understandable way.

The try...catch statement

The primary tool for handling runtime errors is the try...catch statement. You wrap the suspicious code inside a try block, and if an error occurs, control jumps straight to the catch block. The program doesn't crash, and you get a chance to react.

A basic example:

try {
  const user = JSON.parse('{ "name": "Satya" }'); // valid JSON
  console.log(user.name); // Satya
} catch (error) {
  console.log("Something went wrong:", error.message);
}

In this case, the JSON is valid, so the try block runs completely, and the catch block is ignored. Now let's see what happens with an error:

try {
  const user = JSON.parse('invalid json string');
  console.log(user.name); // this line never runs
} catch (error) {
  console.log("Failed to parse JSON:", error.message);
}

console.log("Program continues...");

The output will be:

Failed to parse JSON: Unexpected token i in JSON at position 0
Program continues...

Notice that after the error, the remaining code inside the try block is skipped, but the code outside the try...catch continues normally. That is the beauty of error handling. Without try...catch, the script would have stopped dead at the parsing failure.

The catch block receives an error object that typically has two useful properties: message (a human-readable description) and name (the type of error, like "SyntaxError"). In modern environments, you also get stack which shows the call stack at the moment of the error, a lifesaver for debugging.

The finally block

There are times when you need to run some code regardless of whether an error occurred or not. Maybe you opened a database connection, started a loading spinner, or acquired some resource that must be released. The finally block is designed precisely for this: it executes after the try and catch blocks, no matter what.

Here is the flow:

try {
  // attempted code
} catch (error) {
  // runs only if an error occurred
} finally {
  // runs ALWAYS, error or not
}

Let's see an example:

function processData(input) {
  let connection = null;
  try {
    connection = openDatabaseConnection();
    const result = connection.query(input); // dangerous
    console.log(result);
  } catch (error) {
    console.log("Query failed:", error.message);
  } finally {
    if (connection) {
      connection.close();
      console.log("Connection closed.");
    }
  }
}

Even if query() throws an error, the finally block will still close the connection. Without finally, we would need to duplicate the cleanup code in both the try and catch branches, which is messy.

You can also omit the catch block entirely and use try...finally when you don't need to handle the error but still want to clean up. The error will still propagate after finally runs.

Throwing custom errors

So far we've been catching errors that JavaScript throws automatically. But you can also deliberately throw your own errors using the throw statement. This is incredibly useful when your application logic encounters a state that shouldn't be possible.

function divide(a, b) {
  if (b === 0) {
    throw new Error("Division by zero is not allowed.");
  }
  return a / b;
}

try {
  const result = divide(10, 0);
  console.log(result);
} catch (error) {
  console.log("Error:", error.message);
}

Here we guard against division by zero. Throwing an error immediately stops the function and lets the caller handle it. The Error constructor is the standard way to create an error object with a custom message. It captures the stack trace automatically.

You can also create custom error types by extending the Error class. This is helpful when you want to differentiate your application errors from standard ones.

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

function validateAge(age) {
  if (age < 0) {
    throw new ValidationError("Age cannot be negative.");
  }
  return true;
}

try {
  validateAge(-1);
} catch (error) {
  if (error instanceof ValidationError) {
    console.log("Validation failed:", error.message);
  } else {
    console.log("Unknown error:", error);
  }
}

Now you can check the error type with instanceof and react differently. Custom errors give you more expressive power and help to separate expected problems from unexpected bugs.

Why error handling matters

It might be tempting to skip error handling and hope everything just works, but that approach breaks quickly. Here are the key reasons why proper error handling is essential:

Graceful degradation: When a part of the UI fails to load or an API call times out, you can show a friendly message instead of a blank screen or a frozen page. The user experience remains intact.

Debugging superpower: Well-placed try...catch blocks combined with logging or error reporting services let you know exactly where and why failures happen in production. The error object's stack property is a map to the root cause.

Preventing data corruption: If an operation involves multiple steps (like transferring money), an unhandled error mid-process could leave the data in an inconsistent state. Catching errors lets you roll back or recover.

Separation of concerns: Your business logic shouldn't be cluttered with defensive checks everywhere; instead, you can centralize error handling at strategic boundaries. This keeps the code cleaner and easier to test.

Security: Throwing sensitive details to the console or UI can leak information. A catch block can log securely while showing a generic error to the user.

Visualizing the error handling flow

When you write a try...catch...finally, the engine follows this order:

Execute the try block.
If no error occurs, skip catch.
If an error occurs, skip the rest of try and run catch with the error object.
In either case, run finally block afterwards.

It's like a safety net under a trapeze act. The trapeze artist (your code) attempts the routine; if he slips, the net catches him, and someone always cleans up the area (finally). The show goes on.

   try { ... }
        |
    [error?]---- yes ----> catch (error) { ... }
        |                       |
        no                      |
        |                       |
   finally { ... } <-------------
        |
   continue with rest of script

Conclusion

Error handling is not just about avoiding crashes; it's about building resilient, user-friendly applications that behave predictably even when the unexpected happens. The try, catch, and finally trio, combined with custom errors, gives you a powerful and expressive safety harness.

Let's recap what we covered:

JavaScript errors are objects created at runtime, and unhandled errors stop the program.
try...catch allows you to intercept runtime errors and respond without breaking execution.
The finally block always runs, making it perfect for cleanup tasks like closing connections.
throw new Error() lets you create custom exceptions and force callers to handle them.
Custom error classes extending Error help differentiate error types for better handling.
Good error handling improves debugging, user experience, and data integrity.

With these concepts in your mental toolkit, you can write code that not only works under ideal conditions but also holds up gracefully when things go sideways. That's the mark of a thoughtful developer.

Hope you found this helpful! If you spot any mistakes or have suggestions, let me know. You can find me on LinkedIn and X, where I post more about web development.

Destructuring in JavaScript

SATYA SOOTAR — Tue, 05 May 2026 10:29:09 +0000

Hello readers 👋, welcome to the 20th blog in this JavaScript series!

In the last post, we explored Map and Set, two modern data structures that make our code cleaner and more expressive. Today, we are going to talk about a feature that smooths out one of the most common repetitive tasks in JavaScript: pulling values out of arrays and objects. That feature is called destructuring.

If you have ever written lines like const name = user.name; const age = user.age;, you will love how destructuring lets you do the same thing in one clean stroke. Let's break it down from scratch and see why it has become a go-to tool in everyday coding.

What does destructuring mean?

Destructuring is a syntax that allows you to unpack values from arrays or properties from objects into distinct variables. Instead of accessing each value individually and assigning it to a variable, you do it all at once in a single statement.

It looks like this:

// Array destructuring
const numbers = [1, 2, 3];
const [a, b, c] = numbers;
console.log(a, b, c); // 1 2 3

// Object destructuring
const user = { name: "Satya", age: 25 };
const { name, age } = user;
console.log(name, age); // Satya 25

See how concise that is? The left-hand side mirrors the structure of the array or object on the right. The assignment extracts the matching values and puts them straight into variables.

The old way vs destructuring

To understand why destructuring is so useful, let's first remember the code we used to write before it arrived. Without destructuring, you would extract properties or array elements one by one:

// Without destructuring
const user = { firstName: "Satya", lastName: "Sootar", country: "India" };
const firstName = user.firstName;
const lastName = user.lastName;
const country = user.country;

console.log(firstName, lastName, country);

This works, but it's repetitive. Every new variable requires a separate line that repeats the object name and the property name. Now look at the destructured equivalent:

const { firstName, lastName, country } = user;

That one line does the same job. It's shorter, easier to read, and less prone to typos. This before-and-after comparison is the clearest way to see the benefit: destructuring eliminates the noise and lets you focus on what you want to extract.

Destructuring arrays

Array destructuring uses square brackets on the left side of the assignment. The order matters: the first variable gets the first element, the second variable gets the second, and so on.

Basic array destructuring

const colors = ["red", "green", "blue"];
const [firstColor, secondColor, thirdColor] = colors;

console.log(firstColor); // "red"
console.log(secondColor); // "green"

You do not have to use every element. If you only need the first two, simply omit the third variable:

const [primary, secondary] = colors;
console.log(primary); // "red"
console.log(secondary); // "green"

Skipping elements

If you want to skip a particular index, you can leave an empty slot in the pattern:

const fruits = ["apple", "banana", "cherry", "date"];
const [first, , third] = fruits;

console.log(first); // "apple"
console.log(third); // "cherry"

Notice the extra comma in the pattern: it tells JavaScript to skip the second element.

Setting default values

Sometimes an array may have fewer elements than you expect. In that case, destructuring can provide a default value that kicks in when the position is undefined.

const numbers = [10, 20];
const [x, y, z = 30] = numbers;

console.log(x); // 10
console.log(y); // 20
console.log(z); // 30 (default used)

If the third element is present, the default is ignored. This is great for handling optional positions safely.

Swapping variables without a temp

One neat trick with array destructuring is swapping two values without a temporary variable:

let a = 1;
let b = 2;

[a, b] = [b, a];
console.log(a, b); // 2, 1

JavaScript creates a temporary array with the second and first elements, then destructures it back into a and b. It's clean and expressive.

Destructuring objects

Object destructuring uses curly braces on the left side, and the variable names must match the property names of the object. The order does not matter at all, because objects are key-based.

Basic object destructuring

const book = {
  title: "The Alchemist",
  author: "Paulo Coelho",
  year: 1988
};

const { title, author, year } = book;
console.log(title);  // "The Alchemist"
console.log(author); // "Paulo Coelho"

You list the property names you want to extract, and JavaScript pulls the corresponding values from the object. This is probably the most common use of destructuring in day-to-day code.

Renaming variables

Sometimes you want to use a different variable name than the property name. You can do that with a colon:

const user = { name: "Satya", role: "developer" };
const { name: userName, role: userRole } = user;

console.log(userName); // "Satya"
console.log(userRole); // "developer"

Here, name is extracted from the object, but it becomes userName. The property name name still exists on the object, just the local variable is named differently.

Default values for objects

Similar to arrays, you can provide default values for properties that might be missing:

const settings = { theme: "dark" };
const { theme, fontSize = 14 } = settings;

console.log(theme);    // "dark"
console.log(fontSize); // 14 (default used)

If fontSize exists in settings, the default is ignored. Otherwise, the variable takes the fallback value.

Nested destructuring

Objects often contain other objects or arrays. Destructuring can drill down into nested structures in one statement:

const response = {
  data: {
    user: {
      id: 1,
      address: {
        city: "Bhubaneswar"
      }
    }
  }
};

const {
  data: {
    user: {
      address: { city }
    }
  }
} = response;

console.log(city); // "Bhubaneswar"

You define the pattern of nested properties, and only the final innermost variable (city) is created. The temporary paths like data, user, and address are just for navigating the structure and are not bound to variables unless you explicitly rename them. It can take a little practice to read, but once you get used to it, it becomes incredibly powerful for working with APIs and complex data.

Benefits of destructuring in practice

Destructuring is not just a syntax gimmick; it makes code cleaner in several real-world scenarios.

Cleaner function parameters

Instead of passing an object and then accessing its properties inside the function body, you can destructure right in the parameter list. This makes the expected properties explicit and reduces internal clutter.

// Without destructuring
function createUser(userData) {
  const name = userData.name;
  const email = userData.email;
  // use name and email...
}

// With destructuring
function createUser({ name, email, role = "user" }) {
  // use name, email, role directly
}

Now when you call createUser({ name: "Satya", email: "satya@example.com" }), the function signature clearly shows what the function expects. It also supports default values seamlessly.

Handling API responses

When you fetch data from an API, you often get a large JSON object but only need a few fields. Destructuring helps you cherry-pick exactly what you need without carrying the entire response object through your code.

fetch("/api/user")
  .then(res => res.json())
  .then(({ id, name, email }) => {
    console.log(`User ${name} with id ${id} and email ${email}`);
  });

Multiple return values

JavaScript functions can only return one value, but that value can be an array or object that you destructure upon receiving. This effectively gives you multiple return values.

function getMinMax(numbers) {
  return [Math.min(...numbers), Math.max(...numbers)];
}

const [min, max] = getMinMax([3, 5, 1, 9]);
console.log(min, max); // 1, 9

Visualizing destructuring

Sometimes it helps to think of destructuring as unpacking a package. If you receive a box (an object or array) with labeled compartments, instead of opening each compartment one by one and putting the contents into separate containers, you declare upfront which compartments you want and what you want to call the contents. The syntax mirrors the structure of the box.

For object destructuring, imagine the object properties are colored keys:

Object: { name: "Satya", age: 25, role: "admin" }

   Destructure { name, role } 
        │
        ▼
   name = "Satya", role = "admin"

For array destructuring, think of it as matching positions:

Array: [10, 20, 30]

   Destructure [first, , third]
        │         │        │
        ▼         ▼        ▼
  first = 10  (skip)  third = 30

These mental models help you read and write destructuring patterns without guesswork.

Conclusion

Destructuring is one of those features that, once you start using it, you wonder how you ever coded without it. It reduces repetition, clarifies intent, and makes working with arrays and objects a much smoother experience.

Let's quickly recap what we covered:

Destructuring unpacks values from arrays or objects directly into variables.
Array destructuring works by position, lets you skip elements, set defaults, and even swap variables.
Object destructuring works by property name, supports renaming with :, provides default values, and can handle nested structures.
Benefits include cleaner function signatures, easier handling of API responses, and a way to simulate multiple return values.
The syntax dramatically cuts down repetitive code and makes your intentions clear at a glance.

With destructuring in your toolkit, you can write more expressive, readable, and maintainable JavaScript. It pairs wonderfully with the modern features we have already explored, like Promises and Map/Set, and it will appear all over the place in frameworks and libraries you encounter.

Hope you found this helpful! If you spot any mistakes or have suggestions, let me know. You can find me on LinkedIn and X, where I post more about web development.

Map & Set

SATYA SOOTAR — Tue, 05 May 2026 10:26:29 +0000

Hello readers 👋, welcome to the 19th blog in this JavaScript series!

In the last post, we explored the this keyword and how it flexibly points to different callers depending on the context. Today, we are going to talk about two powerful data structures introduced in ES6 that often don't get enough love: Map and Set.

If you have been using plain objects for key-value storage or arrays for everything, you might be missing out on cleaner, more performant ways to handle certain scenarios. Let's break down what Map and Set are, how they differ from traditional Objects and Arrays, and when you should reach for each.

What is a Map?

A Map is a collection of key-value pairs, similar to a regular JavaScript object. But it comes with some significant improvements. A Map object holds key-value pairs and remembers the original insertion order of the keys. Any value, whether it's a primitive or an object reference, can be used as either a key or a value.

Here is a basic example to get us started:

const userRoles = new Map();

// Setting key-value pairs
userRoles.set("satya", "admin");
userRoles.set("priya", "editor");
userRoles.set(42, "meaning of life"); // number as key? Yes, Map allows this

// Getting a value
console.log(userRoles.get("satya")); // "admin"

// Checking if a key exists
console.log(userRoles.has("priya")); // true

// Getting the size
console.log(userRoles.size); // 3

// Deleting a key
userRoles.delete(42);
console.log(userRoles.size); // 2

// Iterating over the Map
for (const [key, value] of userRoles) {
  console.log(`${key}: ${value}`);
}

Notice how we used set(), get(), has(), delete(), and size. These methods make working with key-value data far more straightforward than the manual property manipulation we often do with plain objects.

What problems does Map solve over plain Objects?

At first glance, Map looks like a regular object. Both let you set keys to values, retrieve those values, delete keys, and detect whether something is stored at a key. Historically, objects have been used as maps because JavaScript had no built-in alternative. But Map is preferable in several important cases.

Let's walk through the key differences.

1. Key types are not limited to strings

The keys of a plain object must be strings or symbols. If you try to use a number, it gets converted to a string. With Map, keys can be any value: objects, functions, numbers, booleans, and even NaN.

const obj = {};
const func = function() {};

const myMap = new Map();
myMap.set(obj, "value for an object key");
myMap.set(func, "value for a function key");

// This is simply not possible with plain objects

2. Map has a built-in size property

Getting the number of entries in a plain object is roundabout: you'd typically use Object.keys(obj).length. With a Map, you just refer to the size property.

3. Map is iterable out of the box

A Map is directly iterable. You can use a for...of loop on it and get back [key, value] pairs right away. Plain objects don't implement the iteration protocol by default, so you cannot directly use for...of on them without using Object.keys() or Object.entries() first.

const map = new Map([["a", 1], ["b", 2]]);

// Direct iteration on Map
for (const [key, value] of map) {
  console.log(key, value); // works cleanly
}

// For a plain object, you'd need:
// for (const [key, value] of Object.entries(obj)) { ... }

4. No accidental keys from the prototype

A plain object has a prototype, which means it contains default keys that could collide with your own keys if you are not careful. A Map does not contain any keys by default; it only contains what is explicitly put into it. This makes a Map safer to use with user-provided keys and values, as it avoids potential prototype pollution attacks.

5. Better performance for frequent additions and removals

Map performs better in scenarios involving frequent additions and removals of key-value pairs, while a plain object is not optimized for such usage patterns.

Here is a quick side-by-side comparison for reference:

Feature	Map	Object
Key types	Any value (objects, functions, primitives)	Only strings and symbols
Size	`map.size` property	`Object.keys(obj).length` (manual)
Iteration	Directly iterable with `for...of`	Not directly iterable; needs helper
Default keys	None (safe for user data)	Inherited from prototype (possible collisions)
Performance (add/remove)	Optimized for frequent changes	Not optimized
JSON serialization	No native support (needs custom logic)	Native support via `JSON.stringify`

What is a Set?

A Set is a collection of values where each value may only appear once; it is unique in the collection. Like a Map, a Set also remembers the insertion order of its elements. You can store any type of value in a Set, whether primitive values or object references.

At its core, a Set is like an array that automatically prevents duplicate entries. Let's see it in action:

const uniqueNumbers = new Set();

// Adding values
uniqueNumbers.add(1);
uniqueNumbers.add(2);
uniqueNumbers.add(2); // Duplicate! Will be ignored
uniqueNumbers.add(3);

console.log(uniqueNumbers.size); // 3 (not 4)
console.log(uniqueNumbers.has(1)); // true
console.log(uniqueNumbers.has(99)); // false

uniqueNumbers.delete(2);
console.log(uniqueNumbers); // Set(2) { 1, 3 }

// Iterating over the Set
for (const value of uniqueNumbers) {
  console.log(value);
}

uniqueNumbers.clear();
console.log(uniqueNumbers.size); // 0

The add(), has(), delete(), clear(), and size properties work similarly to what we saw with Map.

The problem Set solves: uniqueness without manual checks

Before Set, if you wanted a collection of unique values in an array, you had to manually check for duplicates before pushing each item. This meant writing repetitive code, and as the array grew larger, checking with indexOf or includes became slower.

// Without Set: manually checking for duplicates
const items = [];
function addItem(item) {
  if (!items.includes(item)) {
    items.push(item);
  }
}

With a Set, uniqueness is guaranteed by design:

const items = new Set();
items.add("apple");
items.add("banana");
items.add("apple"); // ignored, already present

// You can also initialize a Set from an array
const numbers = [1, 2, 2, 3, 3, 4];
const uniqueNums = new Set(numbers);
console.log([...uniqueNums]); // [1, 2, 3, 4]

This makes Set perfect for tasks like removing duplicates from a list, tracking visited items, or maintaining a list of unique tags and identifiers.

Set vs Array: the differences that matter

An array is a list-like object used to store multiple values, ordered by index. A Set, on the other hand, is a collection of unique values stored in insertion order. Here are the main differences:

Uniqueness: Arrays can hold duplicate values; Sets cannot. Every value in a Set must be unique.
Access by index: Arrays let you access elements by their numeric index (arr[0]). Sets don't have indexed access; you check membership via has().
Performance: Checking if an element exists in an array using includes() requires scanning the array from the start until the element is found (linear time, O(n)). The has() method on a Set is designed to be sublinear on the number of elements, meaning it is often significantly faster for membership checks, especially as the collection grows.
Insertion order: Both arrays and sets maintain insertion order, but arrays are indexed, whereas sets are not.

Comparison summary:

Feature	Set	Array
Duplicates	Not allowed (automatically removed)	Allowed
Access	Via `has()` (membership check)	Via index (`arr[0]`)
Lookup speed	Fast (sublinear)	Slower for large collections (linear)
Use case	When uniqueness matters	When order and duplicates matter
Iteration	`for...of` in insertion order	Indexed loops or `for...of`

When should you use Map?

When keys are not known until runtime, or when they are not all strings. Using Map avoids the key type limitations of plain objects.
When you need to store data with keys that are objects, functions, or other non-string values.
When you want a simple, reliable way to get the size of the collection.
When you need to iterate over key-value pairs frequently in insertion order.
When you are dealing with user-provided keys and want to avoid accidental collisions with inherited object properties.

When should you use Set?

When you need to store a collection of unique values, such as tracking visited pages, unique user IDs, or a tag list without duplicates.
When you need fast membership checks: has() is significantly faster than indexOf or includes on large arrays.
When you want to quickly remove duplicates from an array: const unique = [...new Set(arr)] is a clean one-liner.
When you are working with mathematical set operations like union, intersection, or difference. Modern Set methods support these directly.

A practical example: combining Map and Set

Here is a realistic scenario showing both in action. Imagine you are building a simple application to track which users like which posts:

// Map: post ID to a Set of user IDs who liked the post
const postLikes = new Map();

function likePost(postId, userId) {
  if (!postLikes.has(postId)) {
    postLikes.set(postId, new Set()); // create a new Set if first like
  }
  postLikes.get(postId).add(userId); // Set handles uniqueness automatically
}

function getLikeCount(postId) {
  return postLikes.has(postId) ? postLikes.get(postId).size : 0;
}

function hasUserLiked(postId, userId) {
  return postLikes.has(postId) && postLikes.get(postId).has(userId);
}

likePost("post-1", "user-a");
likePost("post-1", "user-b");
likePost("post-1", "user-a"); // duplicate, ignored automatically
likePost("post-2", "user-a");

console.log(getLikeCount("post-1")); // 2
console.log(hasUserLiked("post-1", "user-b")); // true
console.log(hasUserLiked("post-1", "user-c")); // false

A Map stores the relationship between posts and their likers, while Set ensures that each user can only like a post once. This is clean, expressive, and takes advantage of each data structure's strengths.

Conclusion

Map and Set are two additions to JavaScript that bring clarity, safety, and performance to everyday tasks involving keyed collections and unique values. Once you start using them, you will find yourself reaching for them more often and writing simpler code.

To recap the key points:

Map is a key-value collection that allows keys of any type, provides an easy size property, is directly iterable, and has no inherited default keys. It outperforms plain objects in scenarios with frequent additions and deletions.
Set is a collection of unique values stored in insertion order. It excels at removing duplicates, performing fast membership checks, and representing real-world sets.
Use Map when you need flexible keys or frequent iteration of key-value pairs. Use Set when uniqueness and fast lookups are your priority.
Both data structures are directly iterable with for...of and integrate cleanly into modern JavaScript code.

With these tools in your toolkit, you are better equipped to choose the right data structure for the job, rather than forcing plain objects and arrays into situations where they are not ideal.

Hope you found this helpful! If you spot any mistakes or have suggestions, let me know. You can find me on LinkedIn and X, where I post more about web development.

"This" Keyword

SATYA SOOTAR — Thu, 30 Apr 2026 04:37:24 +0000

Hello readers 👋, welcome to the 18th blog in this JavaScript series!

Today we are going to tackle a topic that confuses almost every JavaScript developer at some point: the this keyword. It can feel unpredictable if you don't understand what sets its value, but once you realize that this is simply determined by how a function is called, not where it's defined, everything starts to click.

We will keep things simple, practical, and visual. No deep internal engine details, just a clear mental model you can rely on every time you see this in your code.

Let's begin.

What does `this` represent?

Think of this as a special variable that points to the caller of a function, or more accurately, the execution context in which a function runs. In most cases, you can figure out the value of this by looking at the dot before the function name. If there is an object before the dot, this refers to that object. If there is no dot, this refers to the global object (or is undefined in strict mode).

This one rule covers a huge number of situations. Let's see how it plays out in different contexts.

`this` in the global context

When you are not inside any function or object, this points to the global object. In a browser, that's the window object. In Node.js, it's global. You can test this easily:

console.log(this); // In browser: window object

If you open your browser console and type this, you'll see the window object printed. In a Node REPL, you'll see global. That's the simplest case.

`this` inside a regular function

Here is where people often trip up. In a standalone function call (without an object), the value of this depends on whether strict mode is enabled or not.

In non-strict mode, this inside a function called like myFunc() will be the global object:

function showThis() {
  console.log(this);
}
showThis(); // window (in browser, non-strict)

In strict mode (with "use strict"), this is undefined. This is actually better because it prevents accidentally poking the global object.

"use strict";
function showThis() {
  console.log(this);
}
showThis(); // undefined

The takeaway: a plain function call sets this to the global object or undefined in strict mode. But in both cases, it's not something we typically want.

`this` inside an object method

When a function is called as a method of an object (with object.method()), this points to the object that the method belongs to. This is the most intuitive and common use case.

const person = {
  name: "Satya",
  greet: function() {
    console.log("Hello, I'm " + this.name);
  }
};

person.greet(); // Hello, I'm Satya

Here, person is the caller. The dot before greet() tells us that this inside greet is the person object. So this.name gives "Satya". This works beautifully for sharing data among methods of the same object.

We can also have multiple objects sharing the same method definition. The value of this will change based on which object called the method:

function sayName() {
  console.log(this.name);
}

const user1 = { name: "Amit", speak: sayName };
const user2 = { name: "Priya", speak: sayName };

user1.speak(); // Amit
user2.speak(); // Priya

Notice that sayName is the same function, but because we call it via user1.speak(), this becomes user1. When called via user2.speak(), this becomes user2. The function itself doesn't own a fixed this. The call site decides.

How the calling context changes `this`

The magic of this lies in its dynamic nature. But this also means you can lose the intended binding if you call a method without its object. This happens often with callbacks or when you assign a method to a variable.

Let's see a classic pitfall:

const counter = {
  count: 0,
  increment: function() {
    this.count++;
    console.log(this.count);
  }
};

const inc = counter.increment;
inc(); // NaN or error

What happened? We assigned counter.increment to inc and then called inc() without any object before the dot. That makes this become the global object (or undefined in strict mode). this.count is then undefined, and incrementing it gives NaN. The original counter.count remains untouched.

To fix this, we need to explicitly bind this to a specific object. JavaScript gives us three powerful tools for that: call, apply, and bind.

call and apply

Both call and apply invoke the function immediately with a specified this value. The difference is how you pass arguments.

function introduce(city, country) {
  console.log("I am " + this.name + " from " + city + ", " + country);
}

const user = { name: "Satya" };

introduce.call(user, "Bhubaneswar", "India");
introduce.apply(user, ["Bhubaneswar", "India"]);

Both lines set this to user. call takes arguments one by one, apply takes an array of arguments. This is useful when you need to borrow methods or reuse functions with different contexts.

bind

bind is different. It doesn't call the function immediately. Instead, it returns a new function where this is permanently locked to the given object.

const counter = {
  count: 0,
  increment: function() {
    this.count++;
    console.log(this.count);
  }
};

const boundInc = counter.increment.bind(counter);
boundInc(); // 1
boundInc(); // 2

Even though we call boundInc() without an object, this inside it is always counter. This is incredibly handy for passing methods as callbacks without losing the intended context.

Visualizing the caller relationship

A simple mental picture can help. Imagine every function being a piece of code waiting for an instruction. When you call it through an object, it's like the object hands over its identity key to the function, saying, "I am the one calling you, use me as this."

caller.method()
   ^
   |
 this = caller

If there is no caller object, JavaScript falls back to the global environment (or undefined in strict mode). Explicit binding with call, apply, or bind is like personally handing over a specific identity key, no matter how the function is called later.

This is why losing context happens: you might pass a function without its object, and the default fallback kicks in.

Arrow functions and `this` (a quick note)

You will likely encounter arrow functions, and they handle this differently. Arrow functions don't have their own this. They inherit this from the surrounding scope at the time they are defined. This is called lexical scoping.

For example:

const person = {
  name: "Satya",
  greet: function() {
    const inner = () => {
      console.log(this.name);
    };
    inner();
  }
};

person.greet(); // Satya

Even though inner() is called like a regular function, it uses the this from greet because that's where it was defined. This behavior makes arrow functions very convenient as callbacks inside methods.

But keep in mind: if you define a method itself as an arrow function, it will capture the global this or the this of the enclosing scope, not the object. So it's best to use regular functions for object methods unless you have a specific reason.

Summary of contexts

Let's put everything together in a quick reference:

Context	Value of `this`
Global scope (outside any function)	Global object (window, global)
Regular function call (non-strict)	Global object
Regular function call (strict mode)	`undefined`
Method call (obj.method())	The object before the dot (`obj`)
`call` / `apply`	Explicitly provided value
`bind`	A new function with permanently bound `this`
Arrow function	Lexical `this` from surrounding scope
Constructor call (`new Func()`)	The newly created instance

We haven't covered constructors in this post, but they also set this to the fresh instance. That's a topic for another day.

Conclusion

The this keyword is not magical. It's a dynamic reference that depends on how a function is invoked. Once you train yourself to look at the call site, this becomes predictable and powerful.

To recap the key points:

this represents the calling object when a function is called as a method.
In a plain function call (non-strict), this is the global object; in strict mode, it's undefined.
You can explicitly set this using call, apply, and bind.
Arrow functions don't have their own this; they capture it from the enclosing scope.
The most common pitfall is losing context when passing a method as a callback, which bind easily fixes.

I hope this clears up the mystery around this and gives you confidence to use it intentionally. With this foundation, you are well equipped to handle more complex patterns like constructor functions, classes, and event handling.

Hope you found this helpful! If you spot any mistakes or have suggestions, let me know. You can find me on LinkedIn and X, where I post more about web development.

Promises in JavaScript

SATYA SOOTAR — Wed, 29 Apr 2026 16:20:15 +0000

Hello readers 👋, welcome to the 17th blog in this JavaScript series!

In the last post, we talked about synchronous vs asynchronous code and how JavaScript uses the event loop to stay responsive. Today we are going to dive deeper into one of the most powerful tools for handling async operations cleanly: Promises.

If you have ever written nested callbacks that became hard to read, or if you have struggled to understand how to work with data that arrives later, this post will give you a solid foundation. We will start with the problem Promises solve, understand their lifecycle, and see how they make asynchronous code much more readable and maintainable.

Let’s get into it.

The problem: callback chaos

Before Promises, the standard way to handle something like fetching data from a server was through callbacks. We passed a function that would be called when the data arrived. That works, but it quickly leads to deeply nested code, often called "callback hell" or "the pyramid of doom".

Imagine you need to fetch a user, then fetch their posts, then fetch comments for the first post. With callbacks, it might look like this:

getUser(userId, function(user) {
  getPosts(user.id, function(posts) {
    getComments(posts[0].id, function(comments) {
      console.log(comments);
      // maybe another nested step...
    });
  });
});

Every new step adds another level of indentation. Error handling becomes repetitive and messy, and the whole flow is hard to follow. Promises were introduced to solve exactly this problem by representing a value that will be available in the future, in a flat, chainable way.

What exactly is a Promise?

Think of a promise as a special object that acts as a placeholder for the result of an asynchronous operation. When you start an async task (like a network request), you immediately get back a promise. That promise does not contain the data yet, but it promises to hold the data once the operation completes.

Over time, the promise will either be fulfilled with a value, or rejected with a reason (an error). This is incredibly helpful because you can attach handlers to the promise right away, and they will be called automatically when the result arrives.

A promise is like ordering a coffee at a busy cafe. You place your order and get a buzzer (the promise). You don't have your coffee yet, but you have a guarantee that the buzzer will beep when your coffee is ready, and you can go pick it up. While waiting, you can do other things. That's exactly how promises work in JavaScript.

The three states of a promise

Every promise goes through a lifecycle with three possible states:

Pending: The initial state. The async operation is still in progress, and the outcome is not yet known. This is like the waiting time after you place the order.
Fulfilled: The operation completed successfully, and the promise now holds a value. In our cafe analogy, the coffee is ready, and you get your cup.
Rejected: The operation failed, and the promise holds a reason for the failure (an error). In the cafe, maybe they ran out of ingredients and cannot make your drink.

Once a promise is fulfilled or rejected, it is considered settled. A settled promise never changes state again. It will stay fulfilled with its value, or rejected with its error, forever. This means you can attach handlers even after the promise has settled, and they will still run with the correct result.

Creating a basic promise

You create a promise using the new Promise constructor, passing it a function called the executor. The executor receives two functions as arguments: resolve and reject. You call resolve(value) when the async work succeeds, and reject(error) when it fails.

Here is a simple example that wraps setTimeout to simulate an async task:

const myPromise = new Promise(function(resolve, reject) {
  setTimeout(function() {
    const success = true; // try setting to false to see rejection
    if (success) {
      resolve("Data loaded successfully");
    } else {
      reject("Failed to load data");
    }
  }, 2000);
});

console.log(myPromise); // Promise { <pending> }

Right after creation, myPromise is pending. After two seconds, it becomes fulfilled with the string "Data loaded successfully" (or rejected if success was false). The promise object itself doesn't do anything with the result until we attach handlers.

Handling success and failure

To access the eventual value, we use the .then() method. It takes up to two callback arguments: the first for fulfillment, the second for rejection (though the second is optional, because we have a better way for errors).

myPromise.then(
  function(value) {
    console.log("Success:", value);
  },
  function(error) {
    console.log("Error:", error);
  }
);

A cleaner pattern for handling errors alone is .catch(). We can chain it after .then():

myPromise
  .then(function(value) {
    console.log("Success:", value);
  })
  .catch(function(error) {
    console.log("Error:", error);
  });

Both approaches work, but using .catch() at the end of a chain is more elegant and catches any errors that happen in the preceding .then() handlers as well.

The promise lifecycle visually

If we try to picture the lifecycle, it looks like this:

The arrows show the possible transitions. The promise starts pending, and depending on the outcome, it moves to fulfilled or rejected. The handlers we attach with .then() or .catch() will be queued to execute once the state changes.

Promise chaining: the real magic

The biggest advantage of promises over raw callbacks is chaining. Every call to .then() returns a new promise, which allows us to flatten the code and avoid deep nesting.

Let’s rewrite the earlier nested callback example using promises. Suppose we have promise-based functions:

function getUser(userId) {
  return fetch(`/api/users/${userId}`).then(res => res.json());
}

function getPosts(userId) {
  return fetch(`/api/posts?userId=${userId}`).then(res => res.json());
}

function getComments(postId) {
  return fetch(`/api/comments?postId=${postId}`).then(res => res.json());
}

Now we can chain them cleanly:

getUser(1)
  .then(function(user) {
    return getPosts(user.id);
  })
  .then(function(posts) {
    return getComments(posts[0].id);
  })
  .then(function(comments) {
    console.log("Comments:", comments);
  })
  .catch(function(error) {
    console.log("Something went wrong:", error);
  });

Notice how each step is at the same indentation level. The code reads top to bottom, almost like a story. Each .then() gets the result of the previous handler, and if any step fails, the error skips to the .catch() at the end. That is far easier to reason about than deeply nested callbacks.

A more real-world example with fetch

We already used fetch above, which itself returns a promise. That’s why we can directly call .then() on it. Let’s see a full example of fetching data from a public API and handling both success and failure:

console.log("Start fetching...");

fetch("https://jsonplaceholder.typicode.com/users/1")
  .then(function(response) {
    if (!response.ok) {
      throw new Error("Network response was not OK");
    }
    return response.json();
  })
  .then(function(data) {
    console.log("User name:", data.name);
  })
  .catch(function(error) {
    console.log("Fetch failed:", error.message);
  });

console.log("This runs before the data arrives");

Here we check response.ok and throw an error if the HTTP status is not in the 200 range. That thrown error is caught by the .catch() block. The whole flow is linear and predictable.

Callbacks vs promises: a side-by-side comparison

Let’s put the readability improvement in perspective. Suppose we want to execute three async tasks in sequence.

Using callbacks (deep nesting)

task1(function(result1) {
  task2(result1, function(result2) {
    task3(result2, function(result3) {
      console.log("Done:", result3);
    }, handleError);
  }, handleError);
}, handleError);

Using promises (chaining)

task1()
  .then(result1 => task2(result1))
  .then(result2 => task3(result2))
  .then(result3 => console.log("Done:", result3))
  .catch(handleError);

The promise version is not only shorter, but also separates the success path from the error path clearly. Adding another step is as simple as adding another .then(), without increasing indentation. This flat structure is why promises became the backbone of modern async JavaScript.

Important details to remember

A promise executor runs synchronously when the promise is created. The async part is inside the callbacks passed to resolve/reject, which happen later. So new Promise(fn) runs fn immediately, but the resolution is async.
.then() and .catch() always return a new promise, enabling chaining. Whatever you return from a .then() becomes the resolved value of the next promise in the chain. If you return a promise, the chain waits for that promise to settle.
Error handling with .catch() catches any rejection that hasn’t been handled earlier in the chain. It’s a good practice to place a single .catch() at the end of a chain.
Promises are microtasks. In the event loop, promise callbacks are executed before setTimeout callbacks. This is an advanced nuance but good to know.
You can also create an immediately resolved or rejected promise using Promise.resolve(value) and Promise.reject(error), which are useful shortcuts.

Conclusion

Promises transform the way we think about asynchronous code. Instead of passing callbacks around and ending up with nested chaos, we work with objects that represent future values, and we chain transformations in a clean, readable way.

To quickly recap:

Promises solve the problem of callback hell by providing a flat chain for async operations.
A promise can be in one of three states: pending, fulfilled, or rejected.
Once settled, it never changes state, and handlers always receive the final result.
We use .then() to handle fulfillment and .catch() to handle errors.
Chaining .then() calls returns new promises, allowing sequential async flows without nesting.
Promises make error handling centralized and code far more maintainable.

Once you are comfortable with promises, you are ready for the next step: the async/await syntax, which builds directly on top of promises to make async code look even more like synchronous code. We will cover that in a future blog.

For now, I hope this explanation has made promises feel less like magic and more like a practical tool you can start using confidently.

Hope you found this helpful! If you spot any mistakes or have suggestions, let me know. You can find me on LinkedIn and X, where I post more about web development.

Synchronous vs Asynchronous JavaScript

SATYA SOOTAR — Mon, 27 Apr 2026 05:47:37 +0000

Hello readers 👋, welcome to the 16th blog in this JavaScript series!

Today we are going to talk about a concept that trips up a lot of beginners but, once understood, makes everything about JavaScript feel so much clearer: the difference between synchronous and asynchronous code.

If you have ever wondered why setTimeout doesn't pause your entire program, or why fetching data from an API requires special handling, this is the blog for you. We will start from scratch, use simple examples, and slowly build a mental model that sticks.

What does synchronous mean?

The word "synchronous" simply means things happening one after the other, in sequence. In JavaScript, synchronous code is executed line by line, from top to bottom. Each line waits for the previous line to finish before it runs.

Take this tiny script:

console.log("First");
console.log("Second");
console.log("Third");

You can predict the output perfectly. It will always be:

First
Second
Third

This is synchronous flow at its most basic. The engine cannot move to the next console.log until the current one is completely done. That predictability is great for understanding our code, but it has a hidden downside.

The problem with blocking code

Imagine you are at a coffee shop with a single barista. A customer orders a complicated drink that takes five minutes to prepare. If the barista stands there doing nothing else until that one drink is ready, the line behind that customer will grow, and everyone else will be stuck waiting. That is exactly what happens with synchronous blocking code.

Here is a synchronous example that simulates a heavy task:

console.log("Start");

// Simulate a long-running task
const start = Date.now();
while (Date.now() - start < 3000) {
  // do nothing, just block for 3 seconds
}

console.log("End");

If you run this in a browser, the whole page freezes for three seconds. Buttons won't click, scrolling will lag, and the browser might even show a "page is unresponsive" warning. That is because the single JavaScript thread is stuck inside the while loop and cannot do anything else, not even repaint the screen.

In a real application, this would be disastrous. Imagine fetching data from a server that takes two seconds to respond. If JavaScript blocked the entire page while waiting, the user would see a frozen screen and probably leave. That is precisely why asynchronous behavior exists.

What does asynchronous mean?

Asynchronous code, on the other hand, allows the program to start a task and then move on to the next line without waiting for that task to finish. When the task completes, a callback, a promise, or an event handler takes care of the result. The main thread stays free to keep responding to user interactions, rendering updates, or handling other code.

Let’s look at the most classic asynchronous example: setTimeout.

console.log("Start");

setTimeout(function () {
  console.log("Inside timeout");
}, 2000);

console.log("End");

The output here surprises a lot of newcomers:

Start
End
Inside timeout

Even though setTimeout appears before the last console.log, its callback runs last. The engine does not wait for two seconds before printing "End". It registers the timer, continues executing, and eventually, after two seconds have passed, the callback gets executed. This is non-blocking behavior in action.

Why does JavaScript need async behavior?

JavaScript was born to run inside the browser, and its main job was to react to user interactions: clicks, keypresses, mouse movements. If it blocked the main thread for long periods, the entire UI would become unresponsive. You can't have a button that takes three seconds to react because some data is loading.

Even outside the browser, with Node.js, the same principle applies. A server handling thousands of requests cannot afford to block on a single database query or file read. Asynchronous I/O allows it to start an operation and immediately move on to handle the next request, then come back when the data is ready.

So, asynchronous programming is not a luxury in JavaScript. It is a design necessity driven by its single-threaded nature.

A more practical async example: fetching data

Timers are one thing, but real asynchronous work usually involves things like network requests.

console.log("Fetching user data...");

fetch("https://jsonplaceholder.typicode.com/users/1")
  .then(function (response) {
    return response.json();
  })
  .then(function (data) {
    console.log("Got user:", data.name);
  });

console.log("This runs before the data arrives");

The output will be:

Fetching user data...
This runs before the data arrives
Got user: Leanne Graham

The fetch call initiates a network request. Instead of blocking the whole script until the server replies, JavaScript hands the work to the browser's networking capabilities (a Web API) and continues executing the rest of the code. Once the response comes back, the callback inside .then is placed in a queue and eventually executed.

How does JavaScript handle async tasks behind the scenes?

This is where a little bit of mental imagery helps. Picture four main pieces:

Call Stack – where synchronous code runs, line by line. Like a stack of plates, the topmost function executes first.
Web APIs (in the browser) or background threads (in Node.js) – where actual long-running tasks live (timers, network requests, DOM events). These are provided by the environment, not by JavaScript itself.
Callback Queue (Task Queue/Macrotask Queue) – where callbacks from async operations like setTimeout, DOM events, and I/O wait to be executed.
Microtask Queue – a special queue with higher priority than the callback queue. It holds promise callbacks (.then, .catch, .finally) and queueMicrotask callbacks. The event loop processes all microtasks before moving to the next macrotask.

And there is the most important piece: the Event Loop. Its job is simple. It constantly checks if the call stack is empty. If it is, it first processes all microtasks in the microtask queue. Only after the microtask queue is empty does it take the next task from the callback queue and push it onto the stack for execution.

When you call setTimeout(callback, 2000), the timer is handed over to a Web API. The main thread moves on. After 2 seconds, the callback goes into the callback queue. The event loop, seeing the empty call stack, first checks the microtask queue. If that’s empty, it picks up the callback from the callback queue and runs it.

This is why even a setTimeout(fn, 0) does not execute immediately. It gets placed into the callback queue and has to wait for the stack to clear and for any microtasks to finish first.

Visualising the flow

If you imagine a timeline for synchronous code, it looks like a straight line where each block of code occupies the full attention of the engine until it's done. No other work happens in between.

For asynchronous code, the timeline looks more like a series of requests sent off to the side, while the main line keeps moving forward. The side tasks eventually finish and silently join the back of a waiting line, ready to be picked up when the main line is free.

When the call stack empties, the event loop pushes the first item from the queue onto the stack. This loop runs continuously, allowing JavaScript to handle many tasks without ever blocking.

Common pitfalls with synchronous thinking

When first learning JavaScript, it is natural to write code assuming everything runs in order. That leads to bugs like:

let userData;
fetch("/api/user")
  .then(res => res.json())
  .then(data => { userData = data; });

console.log(userData); // undefined

The console.log runs before the data has arrived. Fixing this requires placing any dependent code inside the async callback or using promises/async-await semantics, which we will explore in another blog.

Another pitfall is deeply nested callbacks, often called callback hell. We won't dive into that now, but it's important to know that modern JavaScript solves this with Promises and the async/await syntax, making async code look almost synchronous while keeping its non-blocking nature.

Synchronous vs asynchronous: a quick comparison

Synchronous	Asynchronous
Code runs one line after another, in order	Code can start a task and move on before it finishes
Each operation blocks the thread until completed	Operations are non-blocking, allowing the thread to stay responsive
Easy to read and predict, but can cause freezes	Needs special handling (callbacks, promises, async/await) but keeps apps smooth
Good for simple calculations, data transformations	Essential for network calls, file reading, timers, user events

Key takeaway

The secret to understanding sync vs async lies in accepting that JavaScript is a single-threaded language that offloads lengthy tasks to the environment and picks up the results later. It is like a chef who takes multiple orders and puts them in the oven at different times, rather than staring at the first dish until it's cooked.

Once you embrace this mental model, setTimeout delays, fetch behaviour, and event handling all become predictable. You stop fighting the language and start working with its natural flow.

Conclusion

To sum it up:

Synchronous code executes sequentially, blocking further execution until the current operation finishes.
Asynchronous code allows the program to start a task and proceed without waiting, keeping the user interface or server responsive.
JavaScript needs async behaviour because it runs on a single thread, and blocking that thread would freeze everything.
setTimeout, API calls with fetch, and event listeners are common examples of asynchronous operations.
Behind the scenes, the event loop, Web APIs, and the callback queue work together to manage async tasks without blocking the call stack.

I hope this gives you a solid foundation. The next time you see a setTimeout execute later than expected or a fetch returning data after a console.log, you will know exactly why.

Hope you found this helpful! If you spot any mistakes or have suggestions, let me know. You can find me on LinkedIn and X, where I post more about web development.

The new Keyword in JavaScript

SATYA SOOTAR — Sun, 26 Apr 2026 16:56:34 +0000

Hello readers 👋, welcome to the 15th blog in this JavaScript series!

Today, let’s talk about something that sits right at the core of object-oriented patterns in JavaScript: the new keyword. You’ve probably used it with constructor functions or classes countless times, but have you ever stopped to wonder what exactly it does behind the scenes?

The new keyword can feel like magic at first, but once you break it down, it’s just a sequence of well-defined steps that create objects and connect them to prototypes. Let’s unpack it in a way that makes complete sense.

What does the new keyword do?

In simple terms, new takes a regular function, turns it into a constructor call, and gives you back a fresh object with its prototype properly linked. When you write something like:

const person = new Person("Satya", 25);

JavaScript does a bunch of things automatically:

Creates a brand new empty object.
Links that object’s internal [[Prototype]] to the constructor’s prototype property.
Calls the constructor function with this pointing to the newly created object.
If the constructor doesn’t explicitly return an object, it returns the newly created object by default.

These four steps form the backbone of how new operates. The rest of this blog will explore each one in detail and show how they come together.

Constructor functions

A constructor function is nothing special. It’s just a regular JavaScript function meant to be called with new. What sets it apart is that we capitalize the first letter (by convention) and use this inside to set properties on the instance that will be created.

Here’s a simple constructor:

function Person(name, age) {
  this.name = name;
  this.age = age;
}

When you call new Person("Satya", 25), you get back an object with name and age properties. But if you forget new and call it like a normal function, this inside it will point to the global object (in non-strict mode) or be undefined (in strict mode). That’s a common source of bugs, and it’s exactly why new exists, to ensure that this refers to the fresh object and that the prototype wiring happens correctly.

The object creation process step by step

To really understand new, let’s recreate its behavior manually. I’ve written a small utility function that mimics what new does under the hood:

function myNew(constructor, ...args) {
  // Step 1: Create a new empty object
  const obj = {};

  // Step 2: Link the new object's prototype to the constructor's prototype
  Object.setPrototypeOf(obj, constructor.prototype);

  // Step 3: Call the constructor with 'this' set to the new object
  const result = constructor.apply(obj, args);

  // Step 4: If the constructor returns an object, use that; otherwise, return the new object
  return result instanceof Object ? result : obj;
}

Now, if you use myNew(Person, "Satya", 25), you get the same result as new Person("Satya", 25). Let’s walk through the steps:

Step 1: A plain, empty object is born. It has no properties yet.
Step 2: That object’s hidden [[Prototype]] property is set to Person.prototype. This is what makes instanceof and prototype methods work.
Step 3: The constructor runs with its this pointing to the newly created object. Any properties added to this inside the constructor become own properties of the instance.
Step 4: By default, the new object is returned. However, if the constructor explicitly returns another object, that returned object overrides the automatically created one. This is a subtle edge case we’ll touch on later.

This step-by-step view strips away the mystery and shows that new is really just a convenience mechanism for object creation and prototype linkage.

How new links prototypes

Prototypes are how JavaScript shares behaviour among instances. When you set something on Person.prototype, all instances created with new Person() get access to it through the prototype chain. The new keyword handles the linkage automatically.

Here’s an example:

function Person(name) {
  this.name = name;
}

Person.prototype.sayHello = function () {
  console.log("Hi, I am " + this.name);
};

const p = new Person("Satya");
p.sayHello(); // Hi, I am Satya

console.log(Object.getPrototypeOf(p) === Person.prototype); // true

The moment new Person("Satya") runs, JavaScript connects p.__proto__ (or more accurately, the internal slot behind Object.getPrototypeOf(p)) to Person.prototype. That’s why p.sayHello works even though sayHello isn’t directly on p. The engine finds it by walking up the prototype chain.

A nice thing about this is that all instances share the same prototype methods. There’s only one copy of sayHello in memory, not one per instance. That’s a big win for performance and maintainability.

Instances created from constructors

Every time you use new, you create a distinct instance with its own set of properties. The constructor sets up the “own” data, while the prototype provides shared behaviour.

function Animal(type) {
  this.type = type;
}

Animal.prototype.describe = function () {
  console.log("This is a " + this.type);
};

const dog = new Animal("dog");
const cat = new Animal("cat");

dog.describe(); // This is a dog
cat.describe(); // This is a cat

console.log(dog.describe === cat.describe); // true

Both dog and cat have their own type property, but they share the exact same describe method through the prototype. Even if you add a new method to Animal.prototype after creating instances, they will immediately see the update, because the chain is live.

Understanding this relationship between constructor, instance, and prototype is the key to really getting JavaScript’s object model.

Visualizing the flow (diagram ideas)

Sometimes a picture is worth a thousand words, but let me describe the flow that a single new call triggers. Imagine a simple visual:

You have the constructor function Person.
new Person("Satya") is called.
An empty object {} is created.
An arrow links that object’s [[Prototype]] to Person.prototype.
The constructor runs with this = {} and adds name: "Satya".
The finished object is returned.

A common pitfall: returning objects from constructors

Most constructors don’t have a return statement, and they simply let new do its default behaviour. But if a constructor explicitly returns an object, the automatic instance is discarded in favour of that returned object.

function Something() {
  this.value = 10;
  return { override: true };
}

const result = new Something();
console.log(result); // { override: true }
console.log(result instanceof Something); // false

This rarely happens in practice, but it’s good to know. A constructor that returns a primitive value (string, number, etc.) doesn’t break the new behaviour—the default object is still returned. Only an object return overrides it.

Why understanding new matters

Even though modern JavaScript has the class syntax, classes are just syntactic sugar over constructor functions and prototypes. Under the hood, new works exactly the same way. If you ever peek at transpiled code or need to debug prototype issues, knowing how new operates will help you reason about what’s happening.

It also helps you understand design patterns like factory functions and why some codebases avoid new altogether. When you know both sides, you can make better decisions.

Conclusion

Let’s quickly recap what we explored:

The new keyword automates object creation, prototype linking, this binding, and returning the instance.
Constructor functions are regular functions meant to be invoked with new.
The process is: create empty object, link prototype, call constructor with this, return the object (unless an object is explicitly returned).
new links the instance’s prototype to the constructor’s prototype, enabling shared methods.
Each instance gets its own data, but methods come from the prototype, saving memory.
Understanding this mechanism demystifies a lot of JavaScript’s object model, including the class syntax.

Once you truly grasp what new does under the hood, a lot of JavaScript’s object-oriented behaviour becomes predictable and even elegant.

Hope you found this helpful! If you spot any mistakes or have suggestions, let me know. You can find me on LinkedIn and X, where I post more about web development.

Callbacks in JavaScript: Why They Exist

SATYA SOOTAR — Sun, 26 Apr 2026 16:32:19 +0000

Hello readers 👋, welcome to the 14th blog in this JavaScript series!

Today, let’s talk about something that’s at the heart of asynchronous JavaScript: callback functions. If you’ve ever worked with async code, you’ve probably used callbacks, maybe without even realizing it.

Callbacks can seem a bit abstract at first, but once you understand why they exist and how they work, they become a powerful tool in your coding toolkit. Let’s break it down step by step.

What is a callback function?

In JavaScript, a callback function is simply a function that is passed as an argument to another function and is executed after some operation has been completed. In other words, it’s a function that “calls back” when something is done.

Here’s a basic example:

function greet(name, callback) {
  console.log(`Hello, ${name}!`);
  callback();
}

function sayGoodbye() {
  console.log("Goodbye!");
}

greet("Satya", sayGoodbye);

In this example, sayGoodbye is a callback function. It’s passed to greet and called after the greeting is printed.

Why do callbacks exist?

Callbacks are especially important in asynchronous programming. JavaScript is single-threaded, meaning it can only do one thing at a time. But many operations like fetching data from a server, reading a file, or waiting for a user to click a button take time. Instead of blocking the entire program, JavaScript uses callbacks to say, “Hey, when this slow operation is done, run this function.”

Example: setTimeout

console.log("Start");

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

console.log("End");

Here, the anonymous function inside setTimeout is a callback. It runs after 2 seconds, but the rest of the code doesn’t wait it keeps executing.

Passing functions as arguments

In JavaScript, functions are first-class objects. This means you can pass them around just like any other value numbers, strings, or objects.

function processUserInput(callback) {
  const name = prompt("Please enter your name:");
  callback(name);
}

processUserInput(function(name) {
  alert(`Hello, ${name}!`);
});

Here, the function processUserInput takes another function as an argument and calls it with the user’s input.

Common use cases for callbacks

1. Event handling

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

The function inside addEventListener is a callback. It runs when the button is clicked.

2. Array methods

Many array methods, like map, filter, and forEach, use callbacks:

const numbers = [1, 2, 3];
const doubled = numbers.map(function(num) {
  return num * 2;
});
console.log(doubled); // [2, 4, 6]

3. Asynchronous operations

Callbacks are everywhere in async code, like reading files or making HTTP requests:

const fs = require('fs');
fs.readFile('example.txt', 'utf8', function(err, data) {
  if (err) throw err;
  console.log(data);
});

The problem with callback nesting

While callbacks are powerful, they can lead to a situation called callback hell or the “pyramid of doom.” This happens when you have multiple async operations that depend on each other, leading to deeply nested callbacks:

getUser(userId, function(user) {
  getPosts(user.id, function(posts) {
    getComments(posts[0].id, function(comments) {
      console.log(comments);
    });
  });
});

This code is hard to read and maintain. Modern JavaScript provides solutions like Promises and async/await to handle this more elegantly.

Conclusion

Callbacks are a fundamental concept in JavaScript, especially for handling asynchronous operations. They allow you to write code that doesn’t block the main thread and can respond to events or data as it becomes available.

To recap:

A callback is a function passed as an argument to another function.
They are essential for async programming in JavaScript.
You can pass functions as arguments because functions are first-class objects.
Callbacks are used in event handling, array methods, and async operations.
Deeply nested callbacks can become hard to manage (callback hell).

If you’re new to JavaScript, understanding callbacks will give you a solid foundation for working with async code and preparing for more advanced topics like Promises and async/await.

Hope you found this helpful! If you spot any mistakes or have suggestions, let me know. You can find me on LinkedIn and X, where I post more about web development.

Template Literals in JavaScript

SATYA SOOTAR — Sun, 26 Apr 2026 16:25:40 +0000

Hello readers 👋, welcome to 13th blog of this JavaScript series!

Today I want to talk about something that completely changed how I write strings in JavaScript - Template Literals. Once you start using them, there's no going back.

If you've ever struggled to build a dynamic message by gluing strings and variables together with + signs, you know the pain. Template literals make that whole process cleaner, more readable, and honestly, a lot more fun.

Let me walk you through everything you need to know.

The pain of traditional string concatenation

Before ES6, if you wanted to create a string that included variables, you had to break out of quotes, add +, then add the variable, then another +, then more quotes. It looked something like this:

const name = "Satya";
const age = 21;
const city = "Delhi";

const message = "Hi, I'm " + name + ". I am " + age + " years old and I live in " + city + ".";
console.log(message);
// Hi, I'm Satya. I am 21 years old and I live in Delhi.

Now imagine doing this for a bunch of lines or with multiple conditions. It gets messy real quick. Some common problems:

Forgetting a space leads to words getting joined incorrectly.
Too many + and quotes make the line hard to read.
Multi-line strings are not supported directly - you'd need \n escape characters.
Adding expressions like ${price * quantity} is impossible; you'd have to calculate separately and then concatenate.

Basically, the old way works but it's like building a sentence by cutting words out of a newspaper. Clunky.

Enter Template Literals

Template literals are defined using backticks ( ` ) instead of single or double quotes. They allow you to embed variables and expressions directly inside the string using ${}.

Syntax:

`string text ${expression} string text`

That's it. Let's rewrite the earlier example:

const name = "Satya";
const age = 22;
const city = "Jaipur";

const message = `Hi, I'm ${name}. I am ${age} years old and I live in ${city}.`;
console.log(message);
// Hi, I'm Satya. I am 22 years old and I live in Jaipur.

Right away, it's so much cleaner. No more + operators breaking the flow. You can read the string just like a normal sentence, with variables inserted where they belong.

Embedding variables (and more)

The ${} placeholder is not limited to just variable names. You can put any valid JavaScript expression inside it - arithmetic, function calls, ternary operators, you name it.

const a = 10;
const b = 5;

console.log(`Sum: ${a + b}`);            // Sum: 15
console.log(`Comparison: ${a > b}`);     // Comparison: true
console.log(`Uppercase: ${"hello".toUpperCase()}`);  // Uppercase: HELLO

const isLoggedIn = true;
console.log(`Welcome ${isLoggedIn ? "back" : "guest"}!`);
// Welcome back!

This means you no longer have to break out of the string, compute something, store it in a temp variable, and then concatenate. Everything stays inside the string, respecting the visual flow.

Multi-line strings become effortless

Another huge pain point with regular quotes was writing multi-line strings. Previously, you'd do:

const poem = "Roses are red,\n" +
             "Violets are blue,\n" +
             "JavaScript is fun,\n" +
             "And so are you.";

With template literals, you just press Enter:

const poem = `Roses are red,
Violets are blue,
JavaScript is fun,
And so are you.`;

The line breaks are preserved exactly as you type them. This is a game-changer when you need to generate HTML templates, email bodies, or any kind of formatted text in your code. No more \n nightmares.

Before vs after - a side-by-side visual

Let's take a real-world scenario: building a dynamic HTML card using JavaScript.

Old way (string concatenation):

const title = "My Blog";
const author = "Satya";
const posts = 12;

const card = '<div class="card">' +
             '<h2>' + title + '</h2>' +
             '<p>by ' + author + '</p>' +
             '<span>' + posts + ' posts</span>' +
             '</div>';

It's a mess of quotes and + signs. You can easily miss a closing quote or a space.

New way (template literal):

const card = `
  <div class="card">
    <h2>${title}</h2>
    <p>by ${author}</p>
    <span>${posts} posts</span>
  </div>
`;

That's night and day. The structure is clear, the values are injected directly, and it actually looks like the HTML you're generating. Readability improves dramatically.

Use cases in modern JavaScript

Template literals aren't just for simple variable injection. You'll see them everywhere in modern code.

1. Generating HTML (as shown above)

Frameworks like React use JSX, but even in vanilla JS, building small UI snippets is a breeze.

2. Dynamic CSS styling strings

For inline styles or CSS-in-JS, you can embed values:

const size = 16;
const style = `font-size: ${size}px; color: ${isActive ? 'green' : 'gray'};`;

3. Constructing URLs and API endpoints

const userId = 42;
const url = `https://api.example.com/users/${userId}/posts`;

4. Logging and debugging messages

Instead of messy concatenation:

console.log(`User ${username} performed ${action} at ${new Date().toLocaleTimeString()}`);

5. Tagged templates (advanced)

A more advanced feature where you can parse template literals with a function. Libraries like styled-components use this. For now, just know it exists.

Quick reference: traditional strings vs template literals

Feature	Old way (' ' or " ")	Template literal ()
Variable embedding	`"Hello " + name`	`Hello ${name}`
Multi-line strings	Requires `\n`	Just press Enter
Expressions inside string	Must calculate outside	`${a + b}` directly
Readability	Gets cluttered with +	Natural and fluid
Quotes inside string	Escape with `\"` or mix quote types	Can use both ' and " freely

Conclusion

Template literals may seem like a small syntactic sugar, but they solve genuine pain points that every JavaScript developer faces daily. Once you get comfortable with backticks and ${}, you'll wonder how you ever managed without them.

To recap:

They eliminate the clutter of + concatenation.
They let you embed any expression directly inside strings.
Multi-line strings become natural, no escape sequences needed.
They drastically improve readability, especially for HTML generation and dynamic messages.

If you're just starting with JavaScript, make template literals your default way of writing strings. It'll make your code clean from day one.

Hope you liked this blog. If there’s any mistake or something I can improve, do tell me. You can find me on LinkedIn and X, I post more stuff there.

Forem: SATYA SOOTAR

String Polyfills and Common Interview Methods in JavaScript

What string methods are

Why developers write polyfills

Implementing simple string utilities: polyfills

Polyfill for includes

Polyfill for startsWith

Polyfill for endsWith

Polyfill for repeat

Polyfill for trim

Common interview string problems and their logic

1. Reverse a string

2. Check if a string is a palindrome

3. Count occurrences of a character or substring

4. Truncate a string

5. Capitalize the first letter of each word

6. Remove duplicates from a string

The importance of understanding built-in behavior

Visualizing string processing flow

Conclusion

Spread vs Rest Operators in JavaScript

What the spread operator does

Spreading an array

Spreading an object

Real world example: updating state

What the rest operator does

Rest parameters in functions

Rest in destructuring

Differences between spread and rest

Practical use cases that show both powers

Combining arrays and adding extras

Passing array elements as function arguments

Creating a shallow copy of an object

Collecting function arguments with rest, then spreading them again

Splitting an object into a focused part and the rest

Visualizing the concepts

Conclusion

Async/Await in JavaScript: Writing Cleaner Asynchronous Code

Why async/await was introduced

How async functions work

The await keyword concept

Rewriting promise chains with async/await

Error handling with async/await

Comparison with promises

Avoiding common pitfalls

1. Using await outside an async function

2. Forgetting to handle rejections

3. Unnecessary sequential execution

Visualizing the execution flow

Conclusion

Error Handling in JavaScript: Try, Catch, Finally

What errors are in JavaScript

The try...catch statement

The finally block

Throwing custom errors

Why error handling matters

Visualizing the error handling flow

Conclusion

Destructuring in JavaScript

What does destructuring mean?

The old way vs destructuring

Destructuring arrays

Basic array destructuring

Skipping elements

Setting default values

Swapping variables without a temp

Destructuring objects

Basic object destructuring

Renaming variables

Default values for objects

Nested destructuring

Benefits of destructuring in practice

Cleaner function parameters

Handling API responses

Multiple return values

Visualizing destructuring

Conclusion

Map & Set

What is a Map?

What problems does Map solve over plain Objects?

Polyfill for `includes`

Polyfill for `startsWith`

Polyfill for `endsWith`

Polyfill for `repeat`

Polyfill for `trim`

What does `this` represent?

`this` in the global context

`this` inside a regular function

`this` inside an object method

How the calling context changes `this`

Arrow functions and `this` (a quick note)