Forem: Ritam Saha

Synchronous vs Asynchronous JavaScript

Ritam Saha — Thu, 02 Apr 2026 10:38:36 +0000

Introduction

Hey there, fellow coders!
Imagine this: You’re at your favorite café, ordering a latte. The barista takes your order, but instead of starting on your drink right away, they stand there staring at the espresso machine until it’s done… while the entire line behind you grows restless. Annoying, right?!

That’s exactly what happens when JavaScript runs synchronously.

But what if the barista could take your order, hand it off to the machine, and immediately start helping the next customer? That’s asynchronous JavaScript in action — and it’s what makes modern web apps feel lightning-fast instead of painfully frozen.

Today, we’re diving deep into synchronous vs asynchronous JavaScript. No boring textbook jargon — just clear, visual explanations, real-world analogies, and practical examples that will finally make the concepts click (Though in my previous blog I have discussed in detail about how event loop works, how non-blocking I/O operations works internally in NodeJS, here the blog link).

By the end, you’ll understand why async isn’t just a “nice-to-have”… it’s the secret that keeps browsers responsive and your apps delightful. Let’s brew some knowledge!

What Synchronous Code Means (The “One Thing at a Time” Way)

Synchronous JavaScript is just like single handedly doing all the household works one after another maintaining the sequence order. Code executes step by step, line by line. Each line must finish completely before the next one even starts.

Here’s a super simple example:

console.log("Step 1: Start brewing coffee");
const coffee = brewCoffeeSync();  // This takes 5 seconds
console.log("Step 2: Coffee is ready!");
console.log("Step 3: Enjoy your drink");

What happens?

The browser (or Node.js) runs Step 1 instantly.
Then it hits brewCoffeeSync() and… freezes everything for 5 full seconds.
Only after those 5 seconds does it move to Step 2 and Step 3.

This is called blocking code because it blocks the entire execution thread. Nothing else can happen until the current task finishes.

What Asynchronous Code Means (The “Multitasking Ninja” Way)

Asynchronous (async) code is the opposite: it’s non-blocking. JavaScript doesn’t wait around. It says, “Hey, I’ll come back to this later,” and keeps moving.

Same example, but async:

console.log("Step 1: Start brewing coffee");
brewCoffeeAsync()  // Takes 5 seconds, but doesn't block!
    .then(coffee => console.log("Step 2: Coffee is ready! ☕"));
console.log("Step 3: Meanwhile, I'm checking my phone");

What happens?

Step 1 runs instantly.
brewCoffeeAsync() is “outsourced” to thread-pool (more on that in a minute).
Step 3 runs immediately — no waiting!
When the coffee is finally ready, the .then() callback quietly sneaks back in.

This is non-blocking code in action. The main thread stays free to handle clicks, scrolls, animations, or anything else the user wants to do.

Everyday Analogy

Think of ordering food delivery:

Synchronous = You stand at the restaurant waiting until your meal is cooked (everything else in your life is on pause).
Asynchronous = You place the order, go back to work, and the delivery guy knocks when it’s ready. Life continues!

Why JavaScript Needs Asynchronous Behavior

JavaScript was designed to run in browsers. Browsers are single-threaded — they have only one main thread to handle everything: rendering UI, running your code, responding to clicks, etc.

If JavaScript were purely synchronous, every API call, file read, or timer would freeze the entire page. Imagine trying to scroll X while it’s waiting for a server response… nightmare!

That’s why JavaScript invented the Event Loop — a clever system that lets it handle heavy tasks without blocking the main thread. It’s the reason modern web apps feel snappy even when they’re talking to servers halfway across the world.

Outsourcing Examples: API Calls, Timers & More

JavaScript “outsources” time-consuming work to the browser’s Web APIs (or NodeJS APIs). Here are the classics:

setTimeout() / setInterval() — Timers
fetch() or XMLHttpRequest — API calls (getting data from servers)
file reading in Node.js
Database queries, image processing, etc.

Example with a real API call:

console.log("1. Page loaded");

fetch("https://api.example.com/weather")
    .then(response => response.json())
    .then(data => console.log("3. Weather data received:", data));

console.log("2. User can still scroll and click!");

The fetch call gets handed off to the browser’s networking engine which is responsible for the explicit API calls. Your code keeps running. When the data finally arrives, it goes into the queue and the event loop brings it back to the call stack when the stack is empty.

Problems That Occur with Blocking (Synchronous) Code

Let’s be real — blocking code causes real pain:

Frozen UI: Users can’t click buttons, scroll, or even see animations.
Poor User Experience: “Why is this page stuck?!” moments.
Slow Performance: One slow operation ruins the entire app.
Bad scalability: In Node.js servers, blocking code means fewer users can be served at once.

Real-world horror story: Back in the early days of JavaScript, a single long-running loop could make the whole tab unresponsive. Developers had to get creative with setTimeout hacks just to keep things smooth!

Wrapping It Up: Async Is Your Superpower

Synchronous code is simple and predictable — great for quick calculations. But asynchronous code is what makes JavaScript powerful, responsive, and production-ready in the real world.

Understanding the difference (and mastering tools like async/await, Promises, and the event loop) is what separates beginners from confident developers. The next time your app feels sluggish, ask yourself: “Am I blocking the main thread?”

Pro tip: Start using async/await today — it makes asynchronous code read almost like synchronous code, but without the freezing!

async function getWeather() {
    console.log("Fetching...");
    const data = await fetch("https://api.example.com/weather").then(r => r.json());
    console.log("Got it!", data);  // Still non-blocking magic!
}

You’ve got this! Drop your favorite async trick in the comments — I’d love to hear how you’re using non-blocking JavaScript to build smoother apps.

Happy coding, and may your event loops always stay smooth! 🚀

The 'new' Keyword in JavaScript

Ritam Saha — Wed, 01 Apr 2026 11:41:05 +0000

Introduction

Hey there! If you’ve read my previous blog on Understanding Object-Oriented Programming in JavaScript, you already know how powerful classes and objects are in JS. We saw how the new keyword creates instances from classes and got a quick peek at its internal magic.

But today, we’re going deeper. We’re pulling back the curtain on the new keyword itself—especially when used with traditional constructor functions. No bluf, no repetition of OOP pillars or class syntax. Just a crystal-clear, step-by-step look at what new actually does internally, how it creates objects, and why it’s the glue that connects constructors to prototypes and instances.

What Does the `new` Keyword Actually Do?

At its core, new is a special operator that tells JavaScript:

“Hey, I want you to treat this function as a constructor and create a brand-new object instance for me from this function.”

Without new, calling a constructor function just runs it like a regular function (and this usually points to the global object or undefined in strict mode — not what we want). In the other cases like when the function is returning properties by using return keyword and no new keyword been used to create instances, then that will act as the factory methods.

With new, JavaScript performs a whole orchestrated dance behind the scenes. That’s what we’re about to break down.

Constructor Functions — The Blueprints

Before we see new in action, let’s quickly understand constructor functions. They are regular functions that, by convention, start with a capital letter, no need of return keyword and are designed to be called with new.

Here’s a super simple example:

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

That’s it. No class, no constructor keyword — just a plain old function that uses this to attach properties.

The Object Creation Process — Step by Step

This is the heart of the blog. Here’s exactly what happens when you write:

const ritam = new Person("Ritam", 22);

JavaScript executes these five steps (in order):

Creates a brand new empty object

{} — let’s call it newObj.
Links the new object’s prototype

Sets newObj.__proto__ (or more accurately, [[Prototype]]) to Person.prototype.

This is the prototype linking we’ll explore more in a moment.
Binds this to the new object

Inside the constructor function, this now refers to newObj.
Executes the constructor body

The code inside Person() runs, attaching name and age value to newObj.
Returns the new object (automatically)

No need to mention return explicitly, JavaScript returns newObj for you automatically and implicitly.

Result? ritam is now a fully-formed instance with its own properties, but it’s linked to the shared prototype.

Want to see it visually? Here’s the exact flow:

How `new` Links Prototypes (The Real Superpower)

This step #2 is what makes JavaScript’s inheritance work so efficiently.

After new runs, every instance has an internal [[Prototype]] link pointing to the constructor’s .prototype object.

Visualize it like this:

Person.prototype = one shared object that holds methods (e.g., sayHello).
Every instance created with new Person() has instance.__proto__ = Person.prototype.

So if you add a method:

Person.prototype.sayHello = function() {
  console.log(`Hi, I'm ${this.name}`);
};

…then ritam.sayHello() and priya.sayHello() both work, but the method exists in only one place in memory.

Instances Created from Constructors

Every time you use new, you get a unique instance:

const ritam = new Person("Ritam", 22);
const priya = new Person("Priya", 20);

console.log(ritam.name);     // "Ritam"
console.log(priya.age);      // 20
console.log(ritam.sayHello === priya.sayHello); // true → same function reference in memory!

Each instance has its own properties (name, age), but they share the same prototype methods. That’s the perfect balance of individuality and efficiency.

Remember! If it's an factory function then will have different copies, thus would be false in that case.

Wrapping It Up: Why This Matters

Understanding the new keyword isn’t just trivia — it’s the foundation of how JavaScript’s entire object system works under the hood. Once you internalize these five steps and the prototype linking mechanism, debugging prototype chains, fixing this binding issues, and even writing your own advanced patterns becomes second nature.

In my previous OOP blog, we saw the high-level picture with classes. Here, we went microscopic and saw the actual machinery that powers new and how it works under the hood. Together, these two posts give you the complete picture — from surface-level usage to deep internal workings.

So next time you type new, you won’t just be creating an object.

You’ll know exactly what JavaScript is doing for you.

String Polyfills & Common Interview Methods in JavaScript

Ritam Saha — Sun, 29 Mar 2026 19:42:57 +0000

Introduction: Why String Manipulation Still Matters

Imagine this: You’re in a high-stakes JavaScript interview. The interviewer leans in and says, “Implement trim(), replaceAll(), and split() from scratch — no built-ins allowed.” Your pulse quickens… but then you smile. Because you’ve already read my blog, so no worries at all!

String methods are like everyday-needs of JavaScript. They power form validation, data cleaning, URL parsing, and almost every dynamic UI you’ve ever built. Yet most developers treat them as magic.

In this complete guide, we’ll break them down completely: what string methods really are, why polyfills are essential, a full deep-dive into all 15 string polyfills I personally wrote (available in my Polyfills Library on GitHub), the most common interview problems, and — most importantly — the exact logic behind every built-in so you can think like the JavaScript engine itself.

Let’s turn “it just works” into “I know exactly how it works.”

What Are String Methods in JavaScript?

String methods are functions that are attached to String.prototype. When you call "ritam".toUpperCase(), JavaScript is secretly doing:

String.prototype.toUpperCase = function() { /* native optimized code */ };

Key concepts every developer should internalize:

Strings in JavaScript are immutable — every method returns a new string.
Most methods loop through characters (or use fast native shortcuts).
They operate on this (the current string instance).
Common categories: inspection (includes, indexOf), transformation (trim, replace), extraction (slice, substring), and utility (repeat, padStart).

Understanding this flow is your foundation for writing perfect polyfills.

Why Developers Write Polyfills

Polyfills are pure gold for three reasons:

Backward compatibility — older browsers or restricted environments might not have replaceAll, at(), etc.
Deep learning — writing a polyfill forces you to understand the exact algorithm the browser uses. It builds thought process of every developers.
Interview dominance — interviewers specifically ask you to implement these from scratch to test real understanding.

Polyfills turn you from a user of JavaScript into an engineer who knows the language inside-out.

Implementing All String Utilities – My Complete Polyfill Library

Here are all 15 polyfills exactly as I wrote them, with detailed explanations of the logic, how they mimic built-in behavior, and why the implementation matters for interviews.

1. `firstCap()` – Capitalize first letter using ASCII math

String.prototype.firstCap = function() {
    let charCode = this.charCodeAt(0);
    if(charCode >= 97 && charCode <= 122) {
        return String.fromCharCode(charCode - 32) + this.slice(1);
    }
    return this;
};

Logic & Interview Insight: Pure ASCII manipulation. Lowercase letters are 97-122; subtract 32 to get uppercase. No toUpperCase() used — shows you understand character encoding. The String.fromCharCode() static method returns a string created from the specified sequence of UTF-16 code units. Perfect for “capitalize without built-ins” questions.

2. `lastCap()` – Capitalize last letter

String.prototype.lastCap = function() {
    let charCode = this.charCodeAt(this.length - 1);
    if(charCode >= 97 && charCode <= 122) {
        return this.slice(0, this.length - 1) + String.fromCharCode(charCode - 32);
    }
    return this;
};

Logic: Same ASCII trick but targets the final character. Teaches precise index handling.

3. `padBetween()` – Insert separator between every character

String.prototype.padBetween = function(pad) {
    let result = "";
    for(let i=0; i<this.length; i++) {
        result = result + this[i] + (i<this.length-1 ? pad : "");
    }
    return result;
};

Logic: Builds a new string while adding the pad only between characters. Great interview question for “insert separator without split + join”.

4. `reverse()` – Classic reversal

String.prototype.reverse = function() {
    let newString = "";
    for(let i=this.length-1; i>=0; i--) {
        newString = newString + this[i];
    }
    return newString;
};

Logic: Backward iteration + concatenation. Interviewers expect this exact pattern (or two-pointer in-place for arrays).

5. `remove()` – Remove all occurrences of a character

String.prototype.remove = function(removeThis) {
    let newString = "";
    for(let i=0; i<this.length; i++) {
        if(this[i] !== removeThis) {
            newString = newString + this[i];
        }
    }
    return newString;
};

Logic: Skip matching characters while building new string. Direct O(n) solution.

6. `replaceBy()` – Custom replace

String.prototype.replaceBy = function(search, replace) {
    let newString = "";
    let searchLength = search.length;
    for(let i=0; i<this.length; i++) {
        if(this.slice(i, i+searchLength) === search) {
            newString = newString + replace;
            i = i + searchLength - 1;
        } else {
            newString = newString + this[i];
        }
    }
    return newString;
};

Logic: Sliding window comparison using slice. Foundation for understanding replaceAll.

7. `include()` – Custom `includes()`

String.prototype.include = function(search) {
    for(let i=0; i<this.length; i++) {
        if(this.slice(i, i+search.length) === search) {
            return true;
        }
    }
    return false;
};

Logic: Exact substring matching loop. Early return on match.

8. `concatinate()` – Safe concatenation

String.prototype.concatinate = function(separator, newStr) {
    return this + separator + newStr;
};

Logic: Simple but demonstrates chaining with other polyfills (see example in repo).

9. `repeatString()` – Custom `repeat()`

String.prototype.repeatString = function(count) {
    let result = "";
    for(let i=0; i<count; i++) {
        result = result + this;
    }
    return result;
};

Logic: Loop-based repetition. Shows why repeat() is O(n × count).

10. `subString()` – Custom `substring()`

String.prototype.subString = function(start, end){
    let result = "";
    while(start < end && start < this.length) {
        result = result + this[start];
        start++;
    }
    return result;
};

Logic: Boundary-safe extraction with manual loop.

11. `sliceUp()` – Custom `slice()` with optional delete + insert

String.prototype.sliceUp = function(start, deleteCount, insertStr) {
    let result = "";
    for(let i=0; i<start; i++) {
        result += this[i];
    }
    for(let i=0; i<insertStr.length; i++) {
        result += insertStr[i];
    }
    for(let i=start+deleteCount; i<this.length; i++) {
        result += this[i];
    }
    return result;
};

Logic: Three-phase build: prefix + insert + suffix. Extremely useful in interview “edit string at index” problems.

12. `splitUp()` – Full custom `split()`

String.prototype.splitUp = function(separator) {
    let result = [];
    if(separator === "")
        return Array.from(this);
    else{
        if(!this.include(separator)) {
            result.push(this);
        } else {
            let targetIndex = this.indexOf(separator);
            let item = "";
            for(let i=0; i<this.length; i++) {
                if(i === targetIndex) {
                    result.push(item);
                    item = "";
                    targetIndex = this.indexOf(separator, targetIndex+1);
                } else {
                    item += this[i];
                }
            }
            result.push(item);
        }
    }
    return result;
}

Logic: Handles empty separator + multiple occurrences using include() and index tracking.

13. `joinUp()` – Custom `join()` on Array.prototype

Array.prototype.joinUp = function(separator) {
    if(this.length === 0) return this.toString();
    let result = "";
    for(let i=0; i<this.length; i++) {
        result += (this[i] + (i<this.length-1 ? separator : ""));
    }
    return result;
};

Logic: Pairs perfectly with splitUp — the classic interview combo.

14. `trimmer()` – Custom `trim()`

String.prototype.trimmer = function() {
    let start = 0, end = this.length-1;
    while(this[start] === " ") start++;
    while(this[end] === " ") end--;
    return this.slice(start, end+1);
};

Logic: Two-pointer inward scan. Most elegant O(n) trim implementation.

15. `toUpper()` – Custom `toUpperCase()`

String.prototype.toUpper = function() {
    let result = "";
    for(let i=0; i<this.length; i++) {
        let charCode = this.charCodeAt(i);
        if(charCode >= 97 && charCode <= 122) {
            result += String.fromCharCode(charCode - 32);
        } else {
            result += this[i];
        }
    }
    return result;
};

Logic: Full ASCII conversion for every character. Complete understanding of case conversion.

Common Interview String Problems (Solved with These Polyfills)

Reverse a string → reverse()
Trim whitespace → trimmer()
Replace all occurrences → replaceBy() + loop
Split and join custom → splitUp() + joinUp()
Capitalize first/last → firstCap() / lastCap()
Remove characters → remove()
Check substring → include()
Insert between chars → padBetween()

Always mention time complexity (usually O(n)) and immutability in your explanation.

Importance of Understanding Built-in Behavior

When you’ve written these 15 polyfills, you no longer guess — you know. You debug faster, write more efficient code, and impress interviewers by explaining the exact algorithm the browser uses.

Conclusion: Level Up Your JavaScript Game Today

These polyfills aren’t just code — they’re a complete mindset shift. They transform you from someone who uses JavaScript into someone who masters it.

Start today: pick any one from the full GitHub library, understand every line, then try extending it. The next time an interviewer says “implement this without built-ins,” you’ll walk in confident.

You’ve got this.

Happy coding, and may your strings always be perfectly processed! 🚀

Star the repo if these helped you crush an interview. I’d love to hear which polyfill you used first!
~ Written by Ritam – turning complex JS concepts into crystal-clear understanding.

Understanding Object-Oriented Programming in JavaScript

Ritam Saha — Sat, 28 Mar 2026 20:37:29 +0000

Introduction

Hey there, fellow developer!

Imagine building a massive web app where your code feels like a chaotic pile of functions and variables. Then one day you discover Object-Oriented Programming (OOP) — and suddenly everything clicks into place like LEGO bricks. OOP isn’t just another fancy term; it’s the secret weapon that makes your JavaScript code reusable, organized, and scalable.

In this beginner-friendly guide, we’ll break down OOP in JavaScript using simple real-world examples (no overwhelming jargon, promise!). By the end, you’ll be able to create your own classes, instances, and understand why OOP makes developers’ lives so much easier. Let’s dive in!

What Object-Oriented Programming (OOP) Means?

Object-Oriented Programming is a programming paradigm (a style of writing code) that organizes software design around objects (specifically, instances of classes) rather than functions and logic.

Think of it this way:

In procedural code, you write step-by-step instructions.
In OOP, you model real-world things as objects that have properties (key-value pairs data) and behaviours (methods/functions).

The goal? Code reusability. Once you create a blueprint for something, you can reuse it a thousand times without rewriting code. This makes maintenance and collaboration smoother.

What is a Class in JavaScript?

In JavaScript (ES6 and above), a class is a blueprint for creating objects. It’s syntactic sugar over JavaScript’s prototype-based inheritance and constructor function, but it feels much more familiar if you’ve used OOP in other languages like Java.

You define a class using the class keyword:

class Car {
  // properties and methods go here
}

Simple, right? No more messy constructor functions from old-school JavaScript.

Real-World Analogy: Blueprint → Class → Objects

Let’s use the classic Car example (super easy to visualize).

A blueprint (technical drawing) of a car defines everything: engine size, color options, wheels, etc.
The actual cars rolling out of the factory are built from that blueprint. Each car has the same structure but can have different colors, mileage, or features.

You don’t redesign the entire car every time you want a new one — you just use the blueprint and tweak a few details.

That’s exactly how OOP works in JavaScript: the blueprint = Class, and the cars = Objects/Instances.

Creating Instances Using Classes + The `new` Keyword

Once you have a class, you create actual objects (instances) using the new keyword.

const myCar = new Car();

What does new actually do internally? (Quick peek under the hood)

The new keyword is like a mini factory:

It creates a brand-new empty object {}.
It sets the new object's [[Prototype]] (internal prototype link) to the class's prototype property. This enables method sharing without copying methods to every instance.
It binds this inside the constructor to point to this new object.
It runs the constructor function (which usually adds properties via this.property = value).
It implicitly automatically returns the newly created object.

This is what makes each instance unique while sharing the same structure. No new? You’ll get errors or unexpected behaviour — so always use it unless it's a factory-method!

Constructor Method

Every class can have a special method called constructor. It runs automatically when you create an object with new and is perfect for setting initial properties.

class Car {
  constructor(make, model, year) {
    this.make = make;      // 'this' refers to the new object
    this.model = model;
    this.year = year;
  }
}

const tesla = new Car("Tesla", "Model Y", 2025);
console.log(tesla.make); // Tesla

Methods Inside a Class

Methods are functions attached to the class. They define what the object can do.

class Car {
  constructor(make, model, year) {
    this.make = make;
    this.model = model;
    this.year = year;
  }

  startEngine() {
    console.log(`${this.make} ${this.model} engine started!`);
  }

  getAge() {
    return new Date().getFullYear() - this.year;
  }
}

const tesla = new Car("Tesla", "Model Y", 2025);
tesla.startEngine();     // Tesla Model Y engine started!
console.log(tesla.getAge()); // 1 (or whatever the current year is)

Notice how we reuse the same methods across all car objects? Reusability in action!

Note: These methods are nothing but the syntactic-sugar of prototype-based methods. Thus these methods doesn't get copied each time when an instance is created, it's in the shared memory.

Hands-On Example: Building a Student Class (Assignment Time!)

Let’s apply everything we learned. Create a Student class as your mini project:

class Student {
  constructor(name, age) {
    this.name = name;
    this.age = age;
  }

  printDetails() {
    console.log(`Student: ${this.name}, Age: ${this.age}`);
  }
}

// Creating multiple student objects
const student1 = new Student("Ritam", 22);
const student2 = new Student("Priya", 20);
const student3 = new Student("Aarav", 21);

student1.printDetails(); // Student: Ritam, Age: 22
student2.printDetails(); // Student: Priya, Age: 20
student3.printDetails(); // Student: Aarav, Age: 21

Boom! One class → unlimited students. This is the power of OOP.

The Four Pillars of OOP (Basic Ideas)

OOP rests on four foundational concepts which are more oftenly said as Four Pillars of Object-oriented Programming. Here’s the super-simple version:

Abstraction: Hide complex details and show only what’s necessary. (Like pressing the “Start” button on your car — you don’t need to know how the engine works internally.)
Encapsulation: Bundle data and methods together and restrict direct access (in JS we often use _privateVariable convention or #private fields). Keeps your object safe!
Inheritance: Create a new class which is based on an existing one. A Student class can inherit from a Person class and get name/age for free, then add its own features.
Polymorphism: Same method name, different behavior. A Person can speak(), but a Student can override it to say something different.

These pillars are what make OOP truly magical — and why your code stays DRY (Don’t Repeat Yourself).

Conclusion: Why You Should Love OOP in JavaScript

You’ve just gone from “What even is a class?” to “I can build reusable Student class!”

OOP in JavaScript gives you:

Cleaner, more organized code
Massive reusability (write once, use everywhere)
Easier maintenance and collaboration
A mental model that matches the real world

Next time you start a project, try modeling it with classes first — your future self will thank you.

Challenge for you: Extend the Student class with inheritance (make a CollegeStudent that adds major and overrides printDetails). Share your code in the comments!

Happy coding!

Error Handling in JavaScript: Try, Catch, Finally

Ritam Saha — Fri, 27 Mar 2026 12:51:05 +0000

Introduction

Imagine this: You’ve just launched your shiny new web app. Users are loving the smooth UI… until one clicks a button and the entire page freezes with a cryptic red error in the console. Your whatsapp starts blowing up with angry messages.

That’s the nightmare every developer has lived through.

The good news? JavaScript gives you a superhero cape called Error Handling — specifically the try, catch, and finally blocks. With these tools, you can turn crashes into graceful recoveries, make debugging easier, and keep your users happy even when things go wrong.

In this blog, we’ll break it all down step by step, with real-world examples, so you can start writing bulletproof code today.

What Are Errors in JavaScript?

JavaScript errors are unexpected events that break the normal flow of your program. There are two main types:

Syntactical errors (caught before the code even runs like during compilation — think missing brackets or typos)
Runtime errors (the sneaky ones that happen while the code is executing)

Let’s look at some classic ones that crash apps in the wild:

// Example 1: ReferenceError
console.log(nonExistentVariable);  // Oops! Variable doesn't exist

// Example 2: TypeError
const num = 42;
num.toUpperCase();  // Numbers don't have toUpperCase()

// Example 3: RangeError (common in loops or APIs)
new Array(-1);  // Negative array length? Nope.

Without handling, these errors stop execution immediately. Your app crashes, users see a blank screen or broken feature, and you’re left hunting down through console-logs at 3AM.

Using try and catch blocks

This is where the error-handling begins. The try...catch construct lets you attempt risky code and catch any errors that occur.

Basic syntax:

try {
  // Code that might throw an error
  riskyOperation();
} catch (error) {
  // What to do when something goes wrong
  console.error("Something went wrong:", error.message);
  // Show user-friendly message instead of crashing
  showErrorMessageToUser("We couldn't load your data. Please try again later.");
}

Real-world example with graceful failure:

async function fetchUserData(userId) {
  try {
    const response = await fetch(`/api/users/${userId}`);
    if (!response.ok) throw new Error("User not found");
    const data = await response.json();
    renderUserProfile(data);
  } catch (error) {
    console.error("Fetch failed:", error);
    // Graceful failure in action
    displayFallbackUI("Couldn't load profile. Showing demo data instead.");
  }
}

Graceful failure means the app doesn’t die — it recovers intelligently. Users see a polite message or placeholder content instead of a broken page. Your app stays alive, and you keep your users on the page.

Pro tip for debugging:

Inside the catch block, you get the full error object with stack trace, message, and line number which is very help.

The finally Block

Sometimes you need to end up with something no matter what happens — whether the code succeeded or failed. That’s exactly what finally is for.

Syntax:

try {
  // risky code
} catch (error) {
  // handle error
} finally {
  // This ALWAYS runs whether there's any error or not
  console.log("Cleanup complete");
}

Classic use case: Closing database connections, hiding loading spinners, or resetting timers.

Throwing Custom Errors

Sometimes the built-in errors aren’t descriptive enough. You can throw errors using the throw keyword.

function validateAge(age) {
  if (typeof age !== "number" || age < 0) {
    throw new Error("Age must be a positive number");
  }
  if (age > 120) {
    throw new RangeError("A Human body can't live more than 120 years!!");
  }
}

// Usage
try {
  validateAge(-5);
} catch (error) {
  console.error(error.name, error.message); // Error: Age must be a positive number
}

Even better: Create custom error classes for more control by inheriting from Error class.

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

throw new ValidationError("Invalid email format");

Custom errors make debugging faster because you instantly know what went wrong, where and why.

Why Error Handling Matters

Let’s be honest — writing perfect code is impossible keeping in mind about every possible circumstances! But handling errors gracefully separates good developers from great ones.

Here’s why it’s non-negotiable:

Better User Experience: Users never see scary technical errors. They get friendly messages or seamless fallbacks.
Graceful Failure: Your app stays functional even when external services (APIs, databases) go down.
Easier Debugging: Centralized error logging + stack traces = bugs fixed in minutes instead of hours.
Production Safety: Prevent one small error from taking down your entire application.
Professional Code: It shows you care about reliability and user trust.

Conclusion: Make Your Code Bulletproof

Error handling isn’t just a nice-to-have feature — it’s the foundation of reliable, user-friendly JavaScript applications.

By mastering try, catch, and finally (and knowing when to throw custom errors), you transform potential disasters into controlled, graceful experiences. Your users stay happy, your debugging sessions become shorter, and your code becomes something you can truly be proud of.

Next step: Open your current project and wrap at least one risky operation in a try...catch...finally today. You’ll immediately feel the difference.

Happy coding — and may your consoles stay green!

Understanding Event Phases in the DOM

Ritam Saha — Wed, 25 Mar 2026 07:23:57 +0000

Introduction

Hey there, fellow developers!

If you've ever wondered why clicking on a nested element sometimes triggers multiple event handlers in a specific order — or why adding true as the third parameter to addEventListener() changes everything — you're in the right place.

Today, we're diving deep into event phases in the DOM. We'll explore the three phases of events, how addEventListener() controls them with its mysterious third parameter, and exactly what happens under the hood when you click an element.

Grab your favorite chai, and let's make this fun and crystal clear!

The Three Parameters of `addEventListener()`

The addEventListener() method accepts up to three arguments:

element.addEventListener(event, callback, options);

event — The event name (e.g., "click", "mouseover")
callback — The function to run when the event fires
options — This is where the magic happens! It can be a boolean or an object that specifies characteristics about the event listener.

When you pass a boolean as the third argument:

false → Bubbling phase (this is the default)
true → Capturing phase

This third parameter decides when your event handler should run during event propagation.

Event Bubbling vs Event Capturing

Imagine you click on a child element inside a parent. Does the event start at the child and go up? Or start from the top and come down?

Bubbling (default, false): The event starts at the target element and "bubbles up" to its ancestors (bottom → top).
Capturing (true): The event starts from the window and "captures down" to the target element (top → bottom).

Most developers only know bubbling because it's the default. But understanding both gives you superpower for complex UIs.

The Three Event Phases

Every DOM event goes through three distinct phases:

Capturing Phase (top → bottom) — only runs if listeners were added with true
Target Phase — the event has reached the actual element that was clicked
Bubbling Phase (bottom → top) — default behavior

Here's a beautiful diagram that visualizes exactly how these phases flow:

As you can see:

Left side shows bottom-up bubbling (default, false)
Right side shows top-down capturing (true)
The flow always starts from window → html → body → parent → child

Now, let's see this in action with real code!

Live Demo: Understanding All Combinations

Here's our simple HTML structure:

<body>
  <div id="parent">
    <div id="child">Hello I'm Child</div>
  </div>
</body>

We'll add click listeners to both parent and child using different combinations of the third parameter.

Case 1: Both Listeners in Capturing Phase (`true`)

const parent = document.getElementById("parent");
const child = document.getElementById("child");

parent.addEventListener("click", () => {
  console.log("Parent Clicked (Capturing)");
}, true);

child.addEventListener("click", () => {
  console.log("Child Clicked (Capturing)");
}, true);

Output when clicking the child:

Parent Clicked (Capturing)
Child Clicked (Capturing)

Why? Capturing always flow from top to bottom. Parent is higher in the DOM tree, so it fires first.

Case 2: Both in Bubbling Phase (`false` or omitted)

parent.addEventListener("click", () => {
  console.log("Parent Clicked (Bubbling)");
}, false);   // or just omit the third parameter

child.addEventListener("click", () => {
  console.log("Child Clicked (Bubbling)");
});

Output:

Child Clicked (Bubbling)
Parent Clicked (Bubbling)

Classic bubbling behavior — starts at the target (child) and goes up.

Case 3: Parent Capturing (`true`), Child Bubbling (`false`)

parent.addEventListener("click", () => console.log("Parent (Capturing)"), true);
child.addEventListener("click", () => console.log("Child (Bubbling)"));

Output:

Parent (Capturing)
Child (Bubbling)

Why?

Capturing phase runs top-down: the parent’s true listener fires first.

Then the target phase reaches the child, so the child’s listener (registered with false) executes.

Result: Parent first, then Child.

Case 4: Parent Bubbling (`false`), Child Capturing (`true`)

parent.addEventListener("click", () => console.log("Parent (Bubbling)"));
child.addEventListener("click", () => console.log("Child (Capturing)"), true);

Output:

Child (Capturing)
Parent (Bubbling)

Why?

Capturing phase runs top-down: the parent has no capturing listener, so it is skipped. When the phase reaches the child (the target), the child’s true listener fires.

After that, the bubbling phase begins (bottom-up), and the parent’s false listener executes.

How the Flow Actually Works (Step by Step)

Let’s break it down using the diagram:

Capturing Phase begins at the window object and moves top → bottom (window → html → body → parent → child).
- Only listeners added with true (or {capture: true}) will execute during this phase.
Target Phase: Once the event reaches the actual clicked element (the target), all listeners on the target element itself run — regardless of whether they were registered with true (capture) or false (bubble).
Bubbling Phase starts after the target phase and moves bottom → top (child → parent → body → html → window).
- Only listeners added with false (default) will execute here.

Important note: Even if you add listeners in capturing mode and there are also other listeners on bubblinh mode, then the bubbling phase still happens unless you call event.stopPropagation().

Pro Tips for Real Projects

Use capturing (true) when you want to handle events before they reach the target (great for preventing default behaviors early).
Most of the time, bubbling (false) is what you want — it's simpler and sufficient for 90% of use cases.
You can also use the modern object syntax for more control:

element.addEventListener("click", handler, {
  capture: true,      // same as passing true
  once: true,         // auto-remove after first trigger
  passive: true       // performance optimization for scroll/touch
});

Final Thoughts

Event propagation might seem confusing at first, but once you visualize it with the flow (top-down capturing → target → bottom-up bubbling), it becomes incredibly intuitive.

Now you have full control over when your event handlers run. Go ahead and experiment with all four combinations on your own. You'll be amazed at how much power this gives you!

Understanding Objects in JavaScript

Ritam Saha — Tue, 17 Mar 2026 16:58:09 +0000

Introduction

Hello, fellow coders!

Imagine you’re filling your Voter form. You don’t write everything in one long paragraph, right? You neatly fill:

Name: Rahul Sharma
Age: 28
City: Mumbai....

That’s exactly what a JavaScript Object does – it stores related information in clean key-value pairs, just like a bio-data!

Whether you’re building a college student portal, a Zomato-like food app, or even a shaadi.com style matrimonial site, objects are the backbone. They keep your data organised like a joint family living happily under one roof.

In this blog, we’ll cover everything from scratch with super-simple examples and real-life analogies. Let’s turn you into an object expert by the end!

What are Objects?

In JavaScript, an object is a non-primitive data type that is simply a dynamic collection of key-value pairs.

Key = the label (like “name”, “age”, “city”). Can be string or symbol
Value = the actual data (like “Rahul Sharma”, 28, “Mumbai”) which can be of any data-type even an object itself

An object is a self-contained unit that combines data (properties) and behavior (functions/methods).

Think of it as your grandma’s old “khata” (account book) or a neatly filled Aadhaar form — everything is stored with its own clear label so you can find any detail instantly without confusion.

Why Do We Need Objects?

Imagine you are building a big college student management app and you need to store details of 100 students.
Without objects and arrays, most beginners start declaring hundreds of separate variables like this:

let student1Name = "Rahul Sharma";
let student1Age = 20;
let student1Course = "B.Tech";
let student1City = "Kolkata";

let student2Name = "Priya Patel";
let student2Age = 21;
// ... and 96 more students!

Managing 100+ loose variables becomes a nightmare!

The code looks messy and unorganised (like a house where every family member’s clothes are scattered everywhere).
If you forget to use const and use let instead, anyone (or even your own code by mistake) can change the values anytime:

student1Age = 50;     // Oops! Someone accidentally changed the age
student1Course = "MBBS";  // Data got corrupted

In a real project, this kind of accidental manipulation can create serious bugs — wrong marks displayed, wrong fees calculated, or even wrong student records shown to parents.

Even if you try to group everything into arrays to reduce the number of variables, new problems appear:

let student1 = ["Rahul Sharma", 20, "B.Tech", "Kolkata"];

Now you have to remember that index 0 is always name, index 1 is age, index 2 is course… and which variable storing which student's data!! Nightmare!

What if someone adds or removes a field? All indices after that shift and your entire code breaks.
In a team project or after 2–3 months, even you will forget “Was index 3 city or hobby?”
Printing or updating specific details becomes confusing and error-prone.

This is exactly why we need objects. They solve all these headaches in one go — they keep related data together with meaningful labels, prevent accidental mix-ups, and make your code clean, safe, and easy to manage, just like a well-organised Indian joint family where everyone knows exactly which cupboard belongs to whom.
Objects turn chaos into order. That’s why almost every real-world JavaScript app (student portals, Zomato, Paytm, matrimonial sites) uses them heavily.

Creating Objects

The easiest way – use curly braces{}:

const person = {
  name: "Rahul Sharma",
  age: 28,
  city: "Mumbai",
  isMarried: false
};

console.log(person);

You can also create an empty object first (like keeping a blank beforehand):

const person = {}; // empty object
// then fill it later

Accessing Properties – two simple ways!

Dot Notation: Most common way to access the property. When you know the property key directly and it follows standard JavaScript identifier rules.

console.log(person.name); // "Rahul Sharma"
console.log(person.age); // 28

Bracket Notation : This is less commonly used, but when you need to access properties dynamically, this is the only way to access or set a property. You wrap the property name, represented as a string, inside square brackets [].

const key = "city";
console.log(person[key]);     // "Mumbai"

Updating Object Properties

You can use dot notation or bracket notation to assign a new value. By this you can modify any property of the actual object.

person.age = 29;             // age changed from 28 to 29
person.city = "Pune";        // city changed from 'Mumbai' to 'Pune'

Adding & Deleting Properties

We can also add new properties to an object by the same two ways - dot notation and bracket notation.

person.country = "India"

Now the object becomes:

{
  name: "Rahul Sharma",
  age: 29,
  city: "Pune",
  isMarried: false,
  country: "India",
}

To remove a property completely from an object, we use the delete keyword. It removes the whole key-value pair.

delete person.isMarried;

Output:

{
  name: "Rahul Sharma",
  age: 29,
  city: "Pune",
  country: "India",
}

Looping through object keys

Since objects don't have default numerical keys like arrays, we use the for...in loop to iterate through their keys.

Example:

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

Output:

name : Rahul Sharma
age : 29
city : Pune
country : India

Array vs Object – The Crystal Clear Difference

This is the part most beginners get confused about, so let’s make it super clear:

Feature	Array (Queue/List)	Object
Order	Very important (index 0, 1, 2…)	Order doesn’t matter
How you access	By number: `fruits[0]`	By key: `person.name`
Real-life example	Queue at chaiwala or temple prasad line	Your Aadhaar card or PAN details
When to use	List of marks, friends, mangoes	Details of ONE person, student, product
Can you add own keys?	No – default 0-based indexing	Yes – custom keys like “hobby”, “city”

Bottom line: Use array when order matters. Use object when you want meaningful labels.

Conclusion: Objects – Your New Best Friend in JavaScript

You’ve now mastered the basics of JavaScript objects – the most used feature in real-world coding.
From storing a person’s details to building entire apps, objects keep your code clean, readable, and super flexible – just like a well-organised Indian household.

Remember:

Arrays = lists
Objects = meaningful details

If you enjoyed this, share it with your college group or colleagues and tag a friend who still thinks arrays and objects are the same thing or doesn't get bothered!

HTMLCollection vs NodeList in DOM: A JavaScript Guide

Ritam Saha — Mon, 16 Mar 2026 10:47:32 +0000

Introduction

When working with the DOM in JavaScript, you’ll often retrieve groups of elements or nodes. Two of the most common of them you’ll meet are HTMLCollection and NodeList. They look similar at first glance — both are array-like — but they behave differently in important ways.

Neither is a true JavaScript Array, so they don’t have all the usual array methods. Knowing exactly what each one is, how to get it, and where they differ will save you hours of debugging. This short guide covers everything you need.

What is an HTMLCollection?

An HTMLCollection is a live collection that contains only elements nodes (no content nodes, no comments nodes etc.).

It is not an array. You can access items by index or name, but it has no modern array methods like forEach, map, filter, etc.

How to get an HTMLCollection

document.getElementsByTagName('p')
document.getElementsByClassName('highlight')
element.children
document.forms
document.images
// ...and several other legacy properties

Key point: Because it is live, the collection updates automatically whenever the DOM changes (elements added, removed, or moved).

What is a NodeList?

A NodeList is a collection that can contain any type of node (elements, text nodes, comments, etc.). Some NodeLists are static and some are live.

It is also not an array, but modern NodeLists are friendlier: they support forEach(), for...of, entries(), keys(), and values().

How to get a NodeList

document.querySelectorAll('p')           // ← static
element.childNodes                       // ← live
document.getElementsByName('username')   // live in some cases

Key point: Most people use querySelectorAll(), which returns a static snapshot. Other NodeLists (like childNodes) are live.

Key Differences: HTMLCollection vs NodeList

forEach() Support

NodeList has forEach().
HTMLCollection does not.

If you try:

const collection = document.getElementsByTagName('li');
collection.forEach(...) // → TypeError: collection.forEach is not a function

Fix: Convert to a real array first:

Array.from(collection).forEach(...)

Live vs Static Behavior

HTMLCollection is always live.
NodeList from querySelectorAll() is static.

Here’s a complete demo you can use to see the difference:

<div id="container">
      <p>Paragraph 1</p>
</div>

<script>
      // HTMLCollection – LIVE
      const htmlColl = document.getElementsByTagName("p");
      console.log("Initial HTMLCollection length:",htmlColl.length); // 1

      // Add a new paragraph
      const newP = document.createElement("p");
      newP.textContent = "Paragraph 2";
      document.getElementById("container").appendChild(newP);

      console.log("After DOM change – HTMLCollection length:",htmlColl.length); // 2
</script>

<div id="container">
      <p>Paragraph 1</p>
</div>

<script>
      // NodeList from querySelectorAll – STATIC
      const nodeList = document.querySelectorAll("p");
      console.log("Initial NodeList length:", nodeList.length); // 1

      // Add a new paragraph
      const newP = document.createElement("p");
      newP.textContent = "Paragraph 2";
      document.getElementById("container").appendChild(newP);

      console.log("After DOM change – NodeList length:",nodeList.length); // Still 1; no update
</script>

Content:

HTMLCollection = only elements nodes;
NodeList = all nodes

Best practice: When you need array methods or don’t want surprises, convert both with Array.from()

Conclusion

HTMLCollection and NodeList are both useful, but they are not interchangeable.

Use querySelectorAll() + NodeList when you want modern iteration as well as a stable snapshot.

Use getElementsByTagName/getElementsByClassName + HTMLCollection when you need live updates.

And remember the golden rule: when in doubt, turn it into a real array with Array.from().

Master these two and your DOM code becomes cleaner, faster, and far less error-prone. Happy coding!

Deep Dive into Node.js Architecture and Internal Workings

Ritam Saha — Sun, 15 Mar 2026 10:24:55 +0000

Introduction

Hello, fellow coders!

In my previous post, we explored the three core pillars of Node.js: the V8 engine (our JavaScript interpreter), Libuv (the magic behind non-blocking I/O and asynchronous operations), and the C++ bindings that elegantly bridge the two.

Today, we go deeper. We'll uncover exactly what happens under the hood when you type node filename.js and press Enter. By the end, the roles of the Event Loop and Thread Pool will feel crystal clear—and you'll walk away with a solid mental model of Node.js's single-threaded yet highly concurrent architecture.

Let's dive in.

NodeJS Architecture at a Glance

Till now we have known that the V8 engine itself being JS interpreter is not enough to build a production server as many things are not part of V8 and are built by the Broswer devs explicitly like console, fetch, Timers, DOM & the other asynchronous tasks that are outsourced.

So we can say, JavaScript Enviroment in Browser in much more different than the NodeJS enviroment as the for the async tasks are done by the LibUV library and the bindings.

NodeJS = V8 + C++ Bindings + LibUV

In this LibUV there are two main core components that are Event Loop and Thread Pool.

The Event Loop — orchestrates non-blocking I/O operations (networking, file system callbacks once data is ready, etc.).
The Thread Pool — handles CPU-intensive async tasks that can't run efficiently on the main thread (file I/O for large files, cryptography, DNS lookups, compression, etc.). By default, the thread pool has 4 threads (configurable up to 128). Though, the maximum UV_THREADPOOL_SIZE allowed was increased from 128 to 1024 in version 1.30.0 (Source: LINK). This design is what allows Node.js to remain "single-threaded" for JavaScript execution while still performing impressively in I/O-heavy workloads.

Now we are going to discuss about the internal working of NodeJS that how a code file runs and the responsibilty of Event Loop and Thread Pool are going to be more clear to you.

Node.js Internal Workings: From Command to Execution

When you run node filename.js, Node.js spawns a process with a single thread—often called the main thread. This is why JavaScript in Node.js is described as single-threaded: your synchronous code and most JavaScript logic run here.
The startup sequence follows these key steps:

Project Initialization — Node sets up the runtime, loads built-in modules, etc.
Top-level code execution — Any code outside functions (including import/require statements) runs immediately.
Event callbacks registration — Async callbacks (from timers, I/O, etc.) get regstered in the memory.
Event Loop starts — And keeps running until there's nothing left to do.

The Event Loop is essentially a while(true) loop with a base exit condition. It processes tasks in four main user-visible phases (in FIFO order):

Expired Callbacks (timers phase)
I/O Polling (poll phase — retrieves completed I/O events)
setImmediate callbacks (check phase)
Close callbacks (close callbacks phase)

Let's walk through each phase with practical examples.

Expired Callbacks

A timer specifies the threshold after which a provided callback may be executed rather than the exact time a person wants it to be executed. This phase executes callbacks from setTimeout() and setInterval() whose delay has passed.

import fs from 'fs';
setTimeout(() => console.log('Hello from Timer'), 0);
console.log('Hello from Top Level Code');

Output:

Hello from Top Level Code
Hello from Timer

Here, the import statement and the console.log statement at line 3 are top-level code. Though the setTimeout() is also top level code but the callback isn't as it's managed by the event loop. When the top level codes gets executed the timer gets started and as the threshold here is 0ms so the timer gonna expire immediately, thus after the event loop starts, the expired callback will be executed.

I/O Polling (Poll Phase)

This is where completed asynchronous I/O callbacks (e.g., fs.readFile, network responses) are executed. For operations like reading large files, encryption-decryption, compression, cryptography, Node offloads the actual work to the thread pool. The main thread only gets notified when the work is done—keeping it free for other tasks.

import fs from 'fs';

setTimeout(() => console.log('Hello from Timer'), 0);

fs.readFile('sample.txt', 'utf-8', (err, data) => {
  console.log('File Reading Complete...');
});

console.log('Hello from Top Level Code');

Here, the extra line of code that's been introduced is the readFile(). fs.readFile() is also the top level code but not it's callback, it means that the file is being strted to read but if the file size is much bigger then it's gonna take some time and main thread would be engaged for that only that can't be afford.

So, for potentially blocking file operations (especially with large files), Node offloads the work to the thread pool so the main thread isn't blocked. The callback then fires in the poll phase once complete. So the poll phase will be in the IDLE state and wait for the next iteration to check whether the reading file is completed or not. The main thread will be assigned for the setImmediate phase.

Note: Which task will be executed by worker-thread and which one by the Main thread, it can't be decided by us as it's predefined by NodeJS team. Node.js itself decides which one will be performed by the worker thread and which one will be performed by the main thread, depending on the nature of that task, whether it is synchronous or asynchronous.

setImmediate()

This phase allows the event loop to execute callbacks immediately after the I/O Polling **phase has completed. If the **poll phase becomes idle and scripts have been queued with **setImmediate()** .

**setImmediate()** is actually a special timer that runs in a separate phase of the event loop. It uses the libuv API to schedule callbacks to execute after the poll phase completes.

Generally, as the code is executed, the event loop will eventually hit the poll phase where it may wait for the intensive CPU operation, request, etc. However, if a callback has been scheduled with **setImmediate()** and the poll phase becomes idle and handled by a worker-thread from Thread Pool, then continue to the setImmediate **phase rather than waiting for **poll events.

import fs from "fs";

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

fs.readFile("sample.txt", "utf-8", function (err, data) {
  console.log(`File Reading Complete...`);
});

console.log("Hello from Top Level Code");

Output:

Hello from Top Level Code
Hello from Timer
Hello from Immediate
File Reading Complete...

Ideally, in this code, File Reading Complete... output should be before the Hello from Immediate output, but due to the size of the file, it is assigned to a worker thread from thread pool, so it may take time for which the poll phase gets into the idle. The setImmediate function's callback executes.

Note: It is available in both the browser environment (though non-standard and deprecated) and Node.js.

Close Callbacks

This phase handles 'close' events for resources like sockets that were forcibly closed (e.g., socket.destroy()). Most 'close' events are emitted via process.nextTick() instead.

Quick note on process.nextTick()

process.nextTick() is a Node.js function that schedules a callback to run immediately after the current operation completes, but before the event loop continues to the next phase. It executes before I/O operations, timers, and setImmediate() callbacks of event loop cycle. It runs after the synchronous code and before the event loop starts handling timers/IO Polling. Has higher priority than setTimeout(() => {}, 0) and setImmediate().

console.log("Start");
process.nextTick(() => console.log("nextTick"));
setTimeout(() => console.log("setTimeout"), 0);
console.log("End");

Output:

Start
End
nextTick
setTimeout

You can clearly see the priority order in the output of the given code.

Note: process.nextTick() is Node.js-specific and not available in browsers.

setTimeout() vs setImmediate() — The Classic Debate

setImmediate() and setTimeout() are similar, but may behave in different ways depending on when they are called.

setImmediate() is designed to execute once the current I/O polling phase completes.
setTimeout() schedules a script to be run after a minimum threshold in ms has elapsed.

The order in which the timers are executed will vary depending on the context in which they are called. If both are called from within the main module, then timing will be bound by the performance of the process (which can be impacted by other applications running on the machine).

For example, if we run the following script, which is not within an I/O cycle i.e. the main module, the order in which the two timers are executed is non-deterministic, as it is bound by the performance of the process:

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

Output can be any one of the followings:

Hello from Immediate
Hello from Timer

Hello from Timer
Hello from Immediate

And now let's see another script in which both the setImmediate() and setTimeout() functions are within the I/O cycle.

import fs from 'fs';

setTimeout(() => console.log('Hello from Timer'), 0);
setImmediate(() => console.log('Hello from Immediate'));

fs.readFile('sample.txt', 'utf-8', function (err, data) {
  console.log(`File Reading Complete...`);

  setTimeout(() => console.log('Time 2'), 0);
  setTimeout(() => console.log('Time 3'), 0);
  setImmediate(() => console.log('Immediate 2'));
});

console.log('Hello from Top Level Code');

So, inside an I/O callback setImmediate() reliably fires before setTimeout(..., 0) because it runs in the check phase right after poll.

As far as this code is concerned, the import fs statement and the console.log statement at the end should be executed first, as they are the top-level code. Besides that, the setTimeout function, the setImmediate function, and the fs.readFile function should also be executed, as the setTimeout starts the timer and the fs.readFile function starts to read the file. The function will be executed, but not their callbacks.

Next, when the event loop starts, it will check for the expired callback, as a setTimeout function got immediately expired, as that threshold was 0 ms, so "Hello from timer" will be executed next. Ideally, the readFile should be completed, but depending on the file size, it is assigned to a worker thread from the Thread Pool, so it gets the idle state. Then the setImmediate function's callback is executed, as its time is also 0 ms, so "Hello from immediate" will be the output.

Then it will check whether the readFile is completed or not. In some iteration, it will be completed, and when it will be completed, the console.log statement, which is "file reading complete", will be executed next. According to the event loop structure, we can see that after the readFile, I mean the IO polling phase, is completed, then the setImmediate phase should be executed. According to that, immediate 2 will be the output, and then the setTimeout's output will be executed, as the phase order is very much important.

Assignment

After reading the whole blog thoroughly, I don't think there should be any doubts regarding the Node.js internal working. Let's test!
Run the following code in your IDE, but before seeing the output, just brainstorm and guess what the output can be.

console.log("Start");
process.nextTick(() => console.log("nextTick"));
setTimeout(() => console.log("setTimeout"), 0);
setImmediate(() => console.log("setImmediate"));
console.log("End");

Tell me whether you were correct or not. If you were correct, then please explain me the reason behind this output. Deop your thoughts below!

Conclusion

Node.js achieves its legendary performance through a clever division of labor: a single-threaded main thread for JavaScript execution, a powerful Event Loop for orchestrating non-blocking I/O, and a Thread Pool for offloading blocking work.
Understanding the phases—timers, poll, check, and close—plus the subtle differences between setTimeout, setImmediate, and process.nextTick—unlocks the ability to write efficient, predictable code.

Whether you're building APIs, real-time apps, or microservices, this mental model helps you debug weird timing issues, avoid blocking the loop, and squeeze every ounce of throughput from Node.js.
For the canonical reference, check out the official Node.js Event Loop guide:
https://nodejs.org/en/learn/asynchronous-work/event-loop-timers-and-nexttick

Happy coding—and may your event loops never starve! 🚀

Arrow Functions in JavaScript: A Simpler Way to Write Functions

Ritam Saha — Fri, 13 Mar 2026 11:36:49 +0000

Introduction

Hello, fellow coders! Imagine you’re inviting your entire family for a big Diwali get-together in Kolkata. The old-school way? Writing a long, formal letter with “Respected Uncle ji, Aunty ji, please join us on 10th November at 7 PM sharp…” – full boilerplate, lots of time, lots of words.
The modern shortcut? A quick WhatsApp message: “Diwali party at home, 10th Nov 7 PM – everyone come!” Same message, way less typing, everyone still understands.

That’s exactly what arrow functions do in JavaScript. They are the WhatsApp version of functions – shorter, cleaner, and perfect for our fast-paced modern coding life. Introduced in ES6 (2015), arrow functions reduce boilerplate and make your code look sleek, just like using UPI instead of filling bank forms.
Ready to switch from “traditional letter” functions to “quick WhatsApp” functions? Let’s dive in!

What are Arrow Functions?

Arrow functions are a compact way to write functions in JavaScript. They are especially loved by developers because they make code more readable and modern. Think of them as the metro in Kolkata – same destination, but faster and with fewer stops!

Instead of the classic function keyword with curly braces and return, arrow functions use the => (Hash-Rocket) symbol. Super simple, right?

Basic Arrow Function Syntax

Here’s the transformation live:

// Normal function (traditional letter style)
function greet(name) {
  return "Namaste " + name + "!";
}

// Arrow function (WhatsApp style)
const greet = name => "Namaste " + name + "!";

See how much we saved? No function keyword, no curly braces, no return. Pure efficiency!

I know you have some doubts, but I think they are gonna clear in the upcoming sections! So bear with me please!

Arrow Functions with One Parameter

When there’s only one parameter, you can even drop the parentheses – just like skipping the “ji” in casual family chats!

// Normal function
function square(num) {
  return num * num;
}

// Arrow function (one parameter – no brackets needed)
const square = num => num * num;

console.log(square(5)); // 25

Arrow Functions with Multiple Parameters

For two or more parameters, keep the parentheses – just like listing multiple guests in your invitation.

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

// Arrow
const add = (a, b) => a + b;

console.log(add(10, 20)); // 30

Implicit Return vs Explicit Return

This is where arrow functions shine like a shortcut.

Implicit Return (no curly braces): The arrow function automatically returns the result. Perfect for one-line operations.
Explicit Return (with curly braces): You have to write return yourself – same as old functions.

// Implicit return – super short!
const isEven = num => num % 2 === 0;

// Explicit return (if you need multiple lines)
const isEven = num => {
  const result = num % 2 === 0;
  return result;
};

Key Differences Between Arrow Functions and Normal Functions

Arrow functions are not just syntactic sugar. They behave differently in two critical areas that every serious JavaScript developer must understand:

Feature	Normal Function	Arrow Function
Syntax	function keyword + {} + return	=> (very concise)
Boilerplate	More lines	Minimal
Readability	Traditional	Modern & clean
this binding	Dynamic (depends on how it is called)	Lexical (inherits from enclosing scope)
arguments object	Available automatically	Not available (use rest operators ...)
Use case	When you need full control over context	Everyday simple logic & callbacks

`this` – The Most Important Difference

Normal functions create their own this context every time they are invoked.
Arrow functions do not have their own this. They capture this from the surrounding lexical scope at the time of definition.

const person = {
name: "Ritam",
city: "Kolkata",

  // Normal function
  normalGreet: function() {
    console.log(`Namaste from ${this.name}, ${this.city}`);
    // → this refers to the person object
  },

  // Arrow function
  arrowGreet: () => {
    console.log(`Namaste from ${this.name}, ${this.city}`);
    // → this refers to the outer scope
  }
};

person.normalGreet(); // Namaste from Ritam, Kolkata
person.arrowGreet();  // Namaste from undefined, undefined

This is why arrow functions are dangerous inside object methods or constructors if you expect this to point to the object.

`arguments` Object

Normal functions automatically receive an arguments object.
Arrow functions do not have arguments. Trying to access it will throw a ReferenceError.

function normalSum() {
  console.log(arguments);             // Arguments object
  let total = 0;
  for (let i = 0; i < arguments.length; i++) {
    total += arguments[i];
  }
  return total;
}

const arrowSum = (...numbers) => {   // must use rest parameter
  console.log(numbers);             // clean array
  return numbers.reduce((acc, num) => acc + num, 0);
};

normalSum(10, 20, 30); // works
arrowSum(10, 20, 30);  // works with rest
// arrowSum using arguments → ReferenceError

Conclusion

Arrow functions aren’t just shorter syntax — they come with powerful (and sometimes tricky) behavioural changes around this and arguments. Once you internalise these differences, you’ll write cleaner, more predictable modern JavaScript.

So go ahead — rewrite your old functions with arrows, experiment with this and rest parameters, and level up your code.

Drop your code experiments (especially the this and arguments ones) in the comments — I’d love to see your versions.

Difference between global & globalThis

Ritam Saha — Mon, 09 Mar 2026 16:52:25 +0000

Let's get straight to the point.
global and globalThis both refer to JavaScript's global object, but they differ in scope and compatibility across environments.

What is global??

global is NodeJS-specific and serves as the top-level object containing built-in functions like console and setTimeout.
It does not exist in browsers, where attempting to access it throws a ReferenceError.
This environment-specific nature limits its use to server-side code.
global is only specific to NodeJS as will give different result based on different enviroment.

Browsers: window
Node.js: global
Web Workers: self
Strict mode functions: undefined

This made writing universal JavaScript code painful. Before ES2020, you needed this ugly code to get the global object:

function getGlobalObjectOldWay() {
  // Browser
  if (typeof window !== 'undefined') 
      return window;
  // NodeJS
  if (typeof global !== 'undefined') 
      return global;
  // Web Worker
  if (typeof self !== 'undefined') 
      return self;
  // Fallback
  return this;
}

console.log('Old way (Node.js):', getGlobalObjectOldWay());

What is globalThis??

So we already saw the problem with global and to solve this globalThis was introduced in ES2020. globalThis is a standardized, cross-platform way to access the global object that works everywhere - browsers (window), Node.js (global), and Web Workers (self).

globalThis solves this by providing one consistent reference across all environments. In global scope, this equals globalThis, making it memorable.

Aspect	global	globalThis
Environments	Node.js only linkedin	All (browsers, Node, Workers) coreui
Standardization	Non-standard linkedin	ES2020 standard developer.mozilla
Availability	ReferenceError in browsers linkedin	Always works newline
Polyfill Need	None (Node-only)	Rare, for old browsers blog.logrocket

Use globalThis for shared codebases, like your full-stack projects, to avoid environment-specific bugs. However, use global when you're explicitly writing Node.js-specific code.

A Gentle Introduction to the Foundation of Node.js Architecture

Ritam Saha — Mon, 09 Mar 2026 16:52:04 +0000

Introduction

Hey there my fellow developers! If you've ever dealt with server-side JavaScript, you've likely heard the buzz around Node.js. It's the powerhouse behind countless web apps, from Netflix's streaming magic to LinkedIn's dynamic feeds. But what makes Node.js tick under the hood?

In this blog, we'll take a light-hearted stroll through its origins and core architecture—without diving into the weeds of code snippets or advanced configs. We'll focus on the why and how of Node.js, spotlighting three key pillars: the V8 engine, libuv, and Node.js bindings. By the end, you'll see why Node.js is more than just JavaScript on the server—it's a clever symphony of technologies working in harmony.

Let's start at the beginning.

The Birth of Node.js: A Brief History

Imagine this: It's the late 2000s. JavaScript reigns supreme in browsers, but server-side programming? That's the domain of heavyweights like Java, PHP. Developers were frustrated. Why couldn't JavaScript, with its event-driven simplicity, handle the backend too? Entry Ryan Dahl, a young software engineer tinkering in his spare time.

In 2009, Dahl unveiled Node.js at the inaugural JSConf EU in Berlin. Inspired by the rise of event-driven systems, he wanted a lightweight runtime for building scalable network applications. Node.js was born from a simple idea: leverage JavaScript's asynchronous nature to create non-blocking, high-concurrency servers. No more waiting around for database queries or file reads—everything could happen in a single thread, efficiently.

Dahl's creation quickly gained traction. By 2010, Joyent (a cloud computing company) sponsored its development, providing the resources to turn this hobby project into a robust ecosystem. Fast-forward to today, and Node.js powers over 1.5% of all websites, proving that a single-threaded JS runtime could outpace traditional servers in I/O-heavy scenarios.

But how does this magic happen? Node.js isn't just JavaScript—it's layered architecture designed for speed and scalability. Let's break down the core components.

The Building Blocks: V8, libuv, and Node.js Bindings

At its heart, Node.js architecture is a stack of interoperable pieces. Your JavaScript code sits on top, but beneath it lies a trio of engines and libraries that handle execution, I/O, and integration. Here's a handy diagram to visualize it:

This diagram illustrates the flow: JavaScript applications feed into the V8 engine for execution, which interacts with Node.js bindings (the bridge), ultimately delegating to libuv for async operations across the OS and other networking calls. Now, let's zoom in on each.

The V8 Engine: JavaScript's Speed Demon

The V8 engine, the heartbeat of code execution. Developed by Google in 2008 for the Chrome browser, V8 is an open-source JavaScript engine that compiles your JS code directly into machine code—skipping the slow interpretation step that plagued early JS runtimes. This just-in-time (JIT) compilation makes JS blazing fast.

What does V8 do? It parses your code, optimizes it with techniques like hidden classes (for efficient object access) and inline caching, and executes it in near-native speeds. Without V8, Node.js couldn't handle the computational demands of modern apps.
But here's where myths crumble: V8 isn't a full-fledged runtime. It knows nothing about the real world—no networking (like HTTP requests), no file system access, no timers, and certainly no DOM manipulation (that's browser territory). V8 is purely about crunching JS logic in isolation. If you tried running fs.readFile() directly in V8, it'd stare back blankly. V8 provides the horsepower to NodeJS, but it needs a pit crew for everything else.

libuv: The Async I/O Maestro

Entry of libuv, the unsung hero of Node.js's non-blocking powers. This is a cross-platform C library, originally crafted for Node.js but now powering projects like Luvit and Julia. Its official home? Check out the docs at libuv.org, where you'll find the codes for its I/O magic.

libuv's big responsibility? Managing asynchronous operations without breaking a sweat. At its core libuv manages event loop (The event loop continuously checks the call stack, the queue and executes callbacks when their operations complete i.e, when the outsourcing will be done) and the thread pools (Some blocking tasks are offloaded to libuv’s thread pool, so the main event loop remains non-blocking). It also manages the asynchronous operation on TCP/UDP sockets and asynchronous DNS resolutions.

In short, libuv turns Node.js into a concurrency beast. While V8 executes your code, libuv ensures it doesn't wait around for slow disks or distant servers.

Node.js Bindings: The C++ Bridge Builders

Gluing it all together are the Node.js bindings, often called Internal Node C++ bindings. There's also Native addons that allow developers to extend Node with their own C++ modules. These are dynamically linked modules written in C++ that expose native functionality to JavaScript. Think of them as translators: they wrap libuv's C functions and OS calls into familiar JS APIs like console.log, fetch, or process.nextTick.
It acts as the bridge between JS Networking calls and libuv.

Without these bindings, your JS couldn't "talk" to the OS or libuv. They're the reason Node.js feels native—handling everything from error propagation to memory management safely across language boundaries.

How a Node.js Async Operation Actually Executes

Now that we understand the roles of V8 and libuv, let's see what actually happens behind the scenes when Node.js performs an asynchronous task like reading a file.

When a developer calls something like fs.readFile() in JavaScript, the execution flows through several layers of Node.js architecture:
JavaScript initiates the request.
Node.js bindings pass the request to libuv.
libuv delegates the work to its thread pool or the operating system.
Once the operation finishes, libuv places the callback into the event loop queue.
The event loop eventually executes the callback using the V8 engine.

This entire flow allows Node.js to remain non-blocking, meaning the main thread can continue handling other requests while I/O operations are processed in the background.

Debunking the Myth: Node.js Is More Than Just V8

A common misconception! "Node.js is just V8 running JavaScript on our local machines—everything else is built-in."

Not quite!! Pure JavaScript (as speeches by ECMAScript) is sandboxed: no console, no fetch (that's for web API calls), no direct OS calls. Networking? File I/O? Timers? Those are Node.js inventions, courtesy of bindings and libuv.

V8 only converts the codes into machine code and executes that's it, but the real power comes from this layered foundation. Your express server isn't "pure JS"—it's JS invoking C++ bindings, which queue events in libuv's loop, pulling from the OS. This hybrid design is why Node.js scales: efficiently deals with the async I/O operations, with escapes to threads when needed by the use of thread pool. Breaking the illusion shows how Node.js empowers JS to conquer the server, blending browser roots with systems-level smarts.

Wrapping Up: Why Node.js Architecture Still Inspires

From Ryan Dahl's 2009 vision to today's LTS releases, Node.js architecture proves that simplicity scales. The V8 engine delivers raw speed, libuv orchestrates async harmony, and bindings connects all these together.

Together, they transform JavaScript from a frontend sidekick into a full-stack force—non-blocking, cross-platform, and endlessly extensible. Next time you use npm to start a project, remember: you're not just running code; you're unleashing a carefully architected ecosystem. If you're inspired to build something (or tweak this post), drop a comment below. What's your favorite Node.js "aha" moment?

Happy coding!!

Sources: Node.js docs, libuv.org, Google V8 blog, and Wikipedia for historical tidbits.

Forem: Ritam Saha

Synchronous vs Asynchronous JavaScript

Introduction

What Synchronous Code Means (The “One Thing at a Time” Way)

What Asynchronous Code Means (The “Multitasking Ninja” Way)

Everyday Analogy

Why JavaScript Needs Asynchronous Behavior

Outsourcing Examples: API Calls, Timers & More

Problems That Occur with Blocking (Synchronous) Code

Wrapping It Up: Async Is Your Superpower

The 'new' Keyword in JavaScript

Introduction

What Does the new Keyword Actually Do?

Constructor Functions — The Blueprints

The Object Creation Process — Step by Step

How new Links Prototypes (The Real Superpower)

Instances Created from Constructors

Wrapping It Up: Why This Matters

String Polyfills & Common Interview Methods in JavaScript

Introduction: Why String Manipulation Still Matters

What Are String Methods in JavaScript?

Why Developers Write Polyfills

Implementing All String Utilities – My Complete Polyfill Library

1. firstCap() – Capitalize first letter using ASCII math

2. lastCap() – Capitalize last letter

3. padBetween() – Insert separator between every character

4. reverse() – Classic reversal

5. remove() – Remove all occurrences of a character

6. replaceBy() – Custom replace

7. include() – Custom includes()

8. concatinate() – Safe concatenation

9. repeatString() – Custom repeat()

10. subString() – Custom substring()

11. sliceUp() – Custom slice() with optional delete + insert

12. splitUp() – Full custom split()

13. joinUp() – Custom join() on Array.prototype

14. trimmer() – Custom trim()

15. toUpper() – Custom toUpperCase()

Common Interview String Problems (Solved with These Polyfills)

Importance of Understanding Built-in Behavior

Conclusion: Level Up Your JavaScript Game Today

Understanding Object-Oriented Programming in JavaScript

Introduction

What Object-Oriented Programming (OOP) Means?

What is a Class in JavaScript?

Real-World Analogy: Blueprint → Class → Objects

Creating Instances Using Classes + The new Keyword

Constructor Method

Methods Inside a Class

Hands-On Example: Building a Student Class (Assignment Time!)

The Four Pillars of OOP (Basic Ideas)

Conclusion: Why You Should Love OOP in JavaScript

Error Handling in JavaScript: Try, Catch, Finally

Introduction

What Are Errors in JavaScript?

Using try and catch blocks

The finally Block

Throwing Custom Errors

Why Error Handling Matters

Conclusion: Make Your Code Bulletproof

Understanding Event Phases in the DOM

Introduction

The Three Parameters of addEventListener()

Event Bubbling vs Event Capturing

The Three Event Phases

Live Demo: Understanding All Combinations

Case 1: Both Listeners in Capturing Phase (true)

Case 2: Both in Bubbling Phase (false or omitted)

Case 3: Parent Capturing (true), Child Bubbling (false)

Case 4: Parent Bubbling (false), Child Capturing (true)

How the Flow Actually Works (Step by Step)

Pro Tips for Real Projects

Final Thoughts

Understanding Objects in JavaScript

Introduction

What are Objects?

Why Do We Need Objects?

Creating Objects

Accessing Properties – two simple ways!

Updating Object Properties

What Does the `new` Keyword Actually Do?

How `new` Links Prototypes (The Real Superpower)

1. `firstCap()` – Capitalize first letter using ASCII math

2. `lastCap()` – Capitalize last letter

3. `padBetween()` – Insert separator between every character

4. `reverse()` – Classic reversal

5. `remove()` – Remove all occurrences of a character

6. `replaceBy()` – Custom replace

7. `include()` – Custom `includes()`

8. `concatinate()` – Safe concatenation

9. `repeatString()` – Custom `repeat()`

10. `subString()` – Custom `substring()`

11. `sliceUp()` – Custom `slice()` with optional delete + insert

12. `splitUp()` – Full custom `split()`

13. `joinUp()` – Custom `join()` on Array.prototype

14. `trimmer()` – Custom `trim()`

15. `toUpper()` – Custom `toUpperCase()`

Creating Instances Using Classes + The `new` Keyword

The Three Parameters of `addEventListener()`

Case 1: Both Listeners in Capturing Phase (`true`)

Case 2: Both in Bubbling Phase (`false` or omitted)

Case 3: Parent Capturing (`true`), Child Bubbling (`false`)

Case 4: Parent Bubbling (`false`), Child Capturing (`true`)

`this` – The Most Important Difference

`arguments` Object