Forem: Ritam Saha

What is NodeJS? JavaScript on the Server Explained

Ritam Saha — Sat, 02 May 2026 20:07:01 +0000

Introduction

Hey there, fellow developers! If you've spent time building web applications, you've likely heard the buzz around NodeJS. If you still haven't, in my previous blog I have discussed about building your first basic NodeJS server from scratch with step-by-step guidance, you can refer here - Setting Up Your First Node.js Application.
It's the technology powering everything big companies to countless startups' APIs. But what exactly is this Node.js, and why did it explode in popularity?

In this blog, we'll explore Node.js from the ground up: its origins, how it shattered the "JavaScript is browser-only" barrier, its core architecture, and why it became a game-changer for backend development. Whether you're a frontend developer looking to go full-stack or a backend engineer exploring new tools, I guarantee you, you'll walk away with some extra information and you will start seeing things in different view.

This post builds on foundational concepts. If you want deeper technical dives into the internals (like the 3-main pillar of NodeJS internal architecture and the internal working based on the event loop phases or thread pool), check out my previous articles:

JavaScript: From Browser Component to Server Powerhouse

JavaScript Was Originally Browser-Only

JavaScript was created in 1995 primarily to add interactivity to web pages (that's why used to be known as LiveScript). It ran inside the browser sandbox, handling DOM manipulation, user events, and form validations including the networkings. Servers, meanwhile, were the domain of languages like Perl, PHP, Java, Ruby, and Python.

This separation made perfect sense at the time:

Browsers needed a lightweight, event-driven scripting language.
Servers required robust I/O, security, and system-level access.

Developers had to context-switch between languages: JavaScript for the frontend and something else for the backend. This led to duplicated logic, slower development, and a fragmented skill set.

The Problem Ryan Dahl Solved

Entry of Ryan Dahl in 2009. While working on high-performance network applications, Dahl grew frustrated with traditional server models. Tools like Apache used a thread-per-request approach: each incoming connection spawned a thread or process. This worked okay for low traffic but scaled poorly under high concurrency due to context-switching overhead and memory usage. Blocking I/O (e.g., waiting for a database query) stalled entire threads.

Ryan wanted a system that would have:

Non-blocking support.
Efficient for I/O-heavy workloads (real-time apps, chat, streaming).
Using one language end-to-end.

He initially experimented with other runtimes but settled on Google's V8 JavaScript engine (freshly open-sourced and blazing fast). In November 2009, he unveiled Node.js — a runtime that was built upon V8 JavaScript engine, libuv and C++ bindings which lets JavaScript run on the server with an event-driven, non-blocking I/O model.

Node.js wasn't just "JavaScript on the server." It was a carefully architectured environment that brought browser-style event handling to backend systems.

What Exactly Is Node.js?

Node.js is an open-source, cross-platform JavaScript runtime environment built on Chrome's V8 engine. It executes JavaScript code outside the browser, enabling server-side scripting. By default, V8 itself only wasn't sufficient for all the WebAPI calls, DOM, timers and other networking calls, for that case, libuv played the key role.

Key clarification: JavaScript is the programming language; Node.js is the runtime.

JavaScript (ECMAScript) defines syntax, data types, promises, async/await, etc based on the ECMA specifications tc39.es
Node.js provides the environment: V8 for execution + additional APIs for file system (fs), networking (http), streams, processes, and more.

This is similar to how browsers provide Web APIs (DOM, Fetch, console) on top of JavaScript. Node.js gives server-specific capabilities.

Analogy: Think of JavaScript as a car engine. The browser is a sleek sports car optimized for road (client-side UI). Node.js is a rugged truck equipped for hauling cargo (server I/O, databases, APIs).

V8 Engine: The Heart of Node.js

Google's V8 is a high-performance JavaScript and WebAssembly engine written in C++. Released with Chrome, it uses Just-In-Time (JIT) compilation to turn JavaScript into optimized machine code at runtime.

Highlights:

Parsing and optimization: Hidden classes, inline caching, and sophisticated garbage collection.
Speed: Near-native performance for many tasks.
Limitations: V8 alone knows nothing about files, networks, or the OS. That's where Node.js layers come in.

Node.js embeds V8 and augments it with C++ bindings and libuv for cross-platform asynchronous I/O.

Event-Driven, Non-Blocking Architecture: The Secret Sauce

Node.js follows an event-driven, non-blocking I/O model powered by libuv's event loop and thread pool. 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.

Core Idea:

Instead of waiting (blocking) for slow operations (database calls, file reads, HTTP requests), Node.js registers a callback and moves on.
When the operation completes, an event is emitted, and the callback runs.
The event loop (a single-threaded loop in the main thread) orchestrates this efficiently.

Most JavaScript code runs on the main thread, while libuv's thread pool (default 4 threads, configurable by process.env.UV_THREADPOOL_SIZE) handles certain blocking operations like DNS lookups or heavy file I/O.

This design shines for I/O-bound applications but requires careful handling of CPU-intensive tasks (use worker threads in modern Node.js).

Browser JS vs Node.js Execution Comparison:

Node.js Runtime Architecture Overview:

Node.js vs. Traditional Backend Runtimes (PHP, Java)

Here's why developers flocked to Node.js:

PHP (Traditional Model): Synchronous by default. Each request often spawns a process (in Apache + mod_php). Great for simple dynamic pages but less efficient for concurrent connections. Blocking calls tie up resources.
Java (Threaded Model): Excellent for enterprise with strong threading and libraries. However, managing threads, callbacks, or reactive frameworks adds complexity and overhead.
On the otherside, Node.js:
- Single-threaded event loop → Simpler mental model, fewer race conditions.
- Non-blocking I/O → Handles thousands of concurrent connections with low memory.
- Unified language (JS/TS) across frontend and backend → Faster development, shared code/types.
- Massive ecosystem via npm — the largest package registry.

Adoption Drivers:

Real-time apps became mainstream with the support of websockets (chat, live updates, streaming).
Full-stack JavaScript reduced context-switching.
Microservices and APIs favored lightweight, scalable runtimes.
Companies like PayPal, Uber, and Netflix reported huge performance and productivity gains after adopting Node.js.

Node.js isn't always the best tool (CPU-heavy tasks like video encoding may suit Go or Java better), but it excels in the right scenarios.

Real-World Use Cases of Node.js

RESTful APIs: Express, Fastify, or NestJS.
Real-time Applications: Websockets (libraries like Socket.io or raw ws), collaborative tools, gaming backends.
Streaming & Microservices: Netflix uses it for edge logic and data handling.
CLI Tools: npm, webpack, and countless dev tools are built with Node.js.
IoT & Servers: Lightweight footprint runs well on edge devices.
Serverless: AWS Lambda, Vercel, etc., love Node.js's fast cold starts.

Why Node.js Still Matters

Node.js didn't just bring JavaScript to the server — it democratized backend development and proved that a simple, event-driven model could power some of the world's largest applications. By solving Ryan Dahl's original pain points with V8's speed and libuv's elegance, it created a runtime that's productive, scalable, and fun to use.

JavaScript, once dismissed as a "toy" language for browsers, is now a full-stack powerhouse thanks to Node.js. The unified ecosystem, vibrant community, and continuous improvements (worker threads, ESM support, better performance) keep it relevant in 2026 and beyond.

If you're new to Node.js, start small: install it from nodejs.org, run node -v, create a simple HTTP server with the built-in http module, then explore Express or NestJS. Experiment with async patterns and the event loop — that's where the real "aha" moments happen.

What's your experience with Node.js? Have you migrated from PHP/Java, or are you building your first full-stack JS app? Drop your thoughts in the comments. And if you enjoyed this, share it or check my deeper architecture posts linked above.

Happy coding! 🚀

References: Official Node.js docs, Ryan Dahl's talks, V8 blog, libuv, and community resources.

Setting Up Your First Node.js Application Step-by-Step

Ritam Saha — Fri, 01 May 2026 18:22:46 +0000

Introduction

Imagine you're a developer staring at a blank screen, buzzing with ideas for your dream web app, but you're stuck at basic square one—no runtime, no environment, no idea where to start how to do. Sound familiar? But not anymore...

Node.js changes everything for us. What seemed impossible one day, but NodeJS says "not anymore broo". Node is the powerhouse JavaScript runtime that lets you run JS on the server side, powering giants like Netflix and LinkedIn. Whether you're a CS student building your portfolio or a hobbyist dipping into full-stack dev, this guide walks you through every step to build your first Node.js app. No frameworks—just pure, hands-on setup. By the end, you'll have a "Hello World" server humming on your machine. Let's dive in.

Installing NodeJS: Setup with Platform Notes

NodeJS installation is straightforward and consistent across operating systems. The golden rule? Use the official NodeSource binaries or your system's package manager for the latest LTS (Long-Term Support) version. This ensures stability for production-like projects.

Step 1: Download from the Official Site (Universal Starting Point)

Head to nodejs.org. Grab the LTS version:

Windows: Download the .msi installer. Run it as administrator mode in powershell, follow the wizard (enable "Add to PATH" checkbox), and restart your terminal.
macOS: Get the .pkg installer. Double-click, enter your password, and let it install. Homebrew users: brew install node.
Linux (Ubuntu/Debian): Use NodeSource repo for freshness:

  curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
  sudo apt-get install -ca nodejs

Linux (Fedora/RHEL): sudo dnf install nodejs (or use NodeSource similarly).
NixOS or Nix Environments: Add to configuration.nix:

  environment.systemPackages = with pkgs; [ nodejs ];

Then sudo nixos-rebuild switch.

Pro tip: Avoid downloading from third-party sites to dodge malware. Installation takes 2-5 minutes max.

Verifying Your Installation

Fire up your terminal (Command Prompt/PowerShell on Windows, Terminal on macOS/Linux/NixOS). Type:

node --version
npm --version

You should see something like v24.14.0 for node, not exactly this, I mean in this structure. And for npm you might see like 11.9.0. npm gets download automatically with node, npm is nothing but node package manager (though if you go to npm's official site, they call it as npm package manager), this is for to install any other packages/dependancies that will help building your site and it comes with node's download by default.

Node is live. This command confirms the runtime is ready to execute JavaScript outside the browser.

Demystifying the Node.js REPL: Your Interactive Playground

Before we code, let's unpack REPL. REPL stands for Read-Eval-Print Loop—Node's built-in interactive shell for testing code snippets on the fly. It's like a JavaScript console in your terminal: type code, hit Enter, see results instantly. Perfect for experimenting without files.

Launch it:

node

Your prompt changes to >. Try:

> console.log('Hello, Node!')
> 2 + 2
> let x = 5; x * 3

Exit with Ctrl+C twice or .exit.

REPL shines for quick prototypes—think debugging math logic or testing string methods before building full scripts.

Creating and Running Your First JavaScript File

Time to level up from REPL. Create a project folder:

mkdir my-first-node-app
cd my-first-node-app

Use your editor (VS Code recommended code . in addressbar, if installed). Make hello.js (touch hello.js in terminal):

console.log('Hello from my first Node.js script!');
console.log('Node version:', process.version);

Save it. Run with:

node hello.js

First execution output (yours should match):

Hello from my first Node.js script!
Node version: v20.12.2

Magic! Node reads the file, compiles it just-in-time, executes in the V8 engine (Chrome's JS heart), and prints to stdout. No browser needed.

Building a Hello World Server: Your First Server

NodeJS excels at servers via its http module (built-in, no npm needed). Create server.js:

const http = require('node:http'); //CommonJS type
//http is built-in module of NodeJS

const server = http.createServer((req, res) => {
  //creating basic HTTP server using createServer()
  res.statusCode = 200;
  res.setHeader('Content-Type', 'text/plain');
  res.end('Hello World from Node.js Server!\n'); //sending basic text
});

const port = 3000; //You can use this within .env, but for that you have to install dotenv from npm
server.listen(port, 'localhost', () => {
  // By this you are enabling server's continuous listening for any request
  console.log(`Server running at http://localhost:${port}/`);
});

Run it:

node server.js

Output: Server running at http://localhost:3000/. Open that URL in your browser, "Hello World from Node.js Server!" greets you.

Stop with Ctrl+C. This introduces Node's event-driven model: the server loops, handling requests non-blockingly.

Wrapping Up: From Zero to Node Hero

You've just conquered Node.js setup—from install to a live server—without frameworks clouding the waters. This foundation unlocks full-stack magic: pair it with Express later, deploy to Vercel (my go-to for portfolio projects), and watch your GitHub shine. As a third-year CS student juggling Java backends and Node experiments, I live this daily—it's empowering.

What's your first project idea? Drop it in the comments!

JavaScript Modules: Import & Export Explained

Ritam Saha — Tue, 28 Apr 2026 19:12:35 +0000

The Chaos of Unorganized Code

Imagine you're building a full-stack app - your main.js file have 1,000+ lines. Functions for user authentication, data fetching, and UI utils all mashed together. Debugging? A nightmare! Reusing a helper function in another project? first find that particular helper function, carefully watch its scopes.. and the copy-paste hell. And sharing code with teammates? Forget it! This "spaghetti code problem" plagued early JavaScript, turning simple scripts into unmaintainable monsters as projects grew.

Entry of JavaScript modules: a game-changer for splitting code into different reusable files, organized pieces. No more codes pollution in one file or script tag. Modules let you export what you create and import what you need, making your code cleaner, scalable, and team-friendly. Let's dive in.

Why Modules Are Needed

Before ES6 modules (introduced in 2015), developers relied on hacks like IIFEs (Immediately Invoked Function Expressions) or global variables. These caused issue in code flows and conflicts.

Modules solve this by:

Encapsulating code: Variables and functions stay private unless explicitly exported or used in closures.
Enabling reuse: Write once, import anywhere.
Improving organization: Break apps into logical files (e.g., auth.js, api.js) for better understanding.

They arrived natively in browsers via <script type="module">, no bundlers required initially.

Exporting Functions or Values

Exporting shares your code with the world. Place export before declarations in your module file.

Named exports (multiple per file):

// mathUtils.js
export const add = (a, b) => a + b;
export const multiply = (a, b) => a * b;
export const PI = 3.14159;

Default export (only one per file, no name needed):

// user.js
const createUser = (name, email) => ({ name, email });

export default createUser;  // Import it as any name later

Export at the end too:

const add = (a, b) => a + b;
const subtract = (a, b) => a - b;
export { add, subtract };  // Re-export named ones

Importing Modules

To use exports, import them in another file by using relative paths like ./mathUtils.js.

Named imports (match export names):

// main.js
import { add, multiply, PI } from './mathUtils.js';

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

Default imports (flexible naming):

// main.js
import createUser from './user.js';  // 'createUser' can be any name

const user = createUser('Ritam', 'ritam@example.com');

Import everything:

import * as math from './mathUtils.js';
math.add(4, 5);

Default vs Named Exports

Named: Specific, great for multiple exports. Must match names on import. Ideal for utilities: import { logError } from './logger.js';.
Default: One per module, import as any name. Perfect for a module's "main" feature: import express from 'express';.

Pro tip: Use named for libraries (predictable API), default for single-purpose modules. Mixing works too!

Benefits of Modular Code

Modules transform maintainability:

Easier debugging: Isolate issues to one file.
Better collaboration: Teams own modules (e.g., you handle auth, I handle API).
Tree-shaking: Unused exports vanish in builds.
Scalability: Your portfolio projects grow without chaos—think Node.js backends or React apps.

Conclusion: Level Up Your JS Projects Today

JavaScript modules aren't just syntax—they're the backbone of modern web dev. Ditch the monolith; embrace exports and imports for code that scales with your ambitions. Next time you start a project, ask: "Can this be a module?" Your future self (and interviewers) will thank you.

Grab your editor, refactor a script, and share your wins!

Mastering Destructuring in JavaScript: Extract Smarter, Code Cleaner

Ritam Saha — Mon, 27 Apr 2026 20:10:09 +0000

Introduction

Imagine checking through a cluttered backpack to grab just your keys, wallet, and phone; tedious, right? That's how grabbing data from arrays or objects feels without destructuring.
Destructuring is JavaScript's elegant shortcut for unpacking values into variables. Since ES6, it revolutionized how we handle data, slashing boilerplate and boosting readability. In this post, we'll break it down step-by-step, with real-world examples showing before-and-after magic.

What Destructuring Means

Destructuring lets you extract values from arrays or objects directly into distinct variables in one line. It's like assigning multiple variables at once, pulling specific pieces without the usual dot-notation, square-braces-notation husstle or index-based access.

Destructuring Arrays: Position-Based Extraction

Arrays destructure by position. Match variables to array indices from left to right.

Before (repetitive):

const scores = [85, 92, 78];
const first = scores[0];
const second = scores[1];
const third = scores[2];

After (clean):

const [first, second, third] = [85, 92, 78];
console.log(first); // 85

Skip elements with commas, or grab the rest with ...:

const [first, , third, ...rest] = [85, 92, 78, 100];
console.log(first, third, rest); // 85, 78, [100]

Use case: Processing function arguments or API response of array-type, maybe like extracting lat/long from coordinates.

Destructuring Objects: Key-Based Extraction

Objects use curly braces {} and match by property names. Order doesn't matter—it's key-driven.

Before (verbose):

const user = { name: 'Ritam', age: 20, city: 'Kolkata' };
const name = user.name;
const age = user.age;
const city = user.city;

After (elegant):

const user = { name: 'Ritam', age: 20, city: 'Kolkata' };
const { name, age, city } = user;

console.log(name) // Ritam
console.log(age) // 20

You can also rename on the fly: { oldName: newName }.

Use case: Handling JSON response from APIs after parsing, like pulling id and title from fetched posts.

Default Values: Handling Optional/Missing Data

What if a property is not defined or passed? Defaults steps in seamlessly.

const config = { theme: 'dark' };
const { theme = 'light', fontSize = 16 } = config;
console.log(theme, fontSize); // 'dark', 16

Use case: API responses with optional fields, preventing errors in your Node.js backend. Some times while we make standardized API-Response or API-Error handler, this feels gold-mine!!

Benefits of Destructuring and Use Cases

Destructuring shines by cutting repetition - swap 5+ lines for 1. It's helpful for functions, nested-friendly, and readable.

Before vs. After in a Function:

// Before
function greet(user) {
  console.log(`Hi, ${user.name}! You're ${user.age} from ${user.city}.`);
}
greet({ name: 'Ritam', age: 20, city: 'Kolkata' });

// After
function greet({ name, age, city }) {
  console.log(`Hi, ${name}! You're ${age} from ${city}.`);
}

Benefits List:

Reduces boilerplate: No more user.name everywhere.
Improves readability: Variables mirror data structure.
Safer with defaults: Graceful fallbacks.
Use cases: React props (const { title, body } = post), Node.js req.body parsing, or nested API data like const { user: { email } } = response.

Wrap Up: Level Up Your Code Standard

Destructuring isn't just syntax sugar—it's a mindset shift toward cleaner, more maintainable code. Next time you're wrestling with objects in your Java/Node projects, reach for it. Practice on a small GitHub repo, and watch your pull requests glow. What's your favorite destructuring trick? Drop it in the comments!

Mastering Array Flattening in JavaScript: From Nested Chaos to Clean Lists

Ritam Saha — Sun, 26 Apr 2026 20:11:03 +0000

Imagine you're building a shopping cart app. Users add items like ["apple", "banana", ["orange", ["grape", "kiwi"]]]. Suddenly, your loops break because of those sneaky nested arrays. Frustrating, right?
Array flattening turns this mess into a simple ["apple", "banana", "orange", "grape", "kiwi"]. In this blog, we'll demystify nested arrays, explore why flattening matters, break down approaches step-by-step, and tackle real interview scenarios—including a custom polyfill you can steal (or improve).

What Are Nested Arrays?

Nested arrays are arrays containing other arrays as elements within it.

Original Nested Array:
[
  1,
  [2, 3],
  [4, [5, 6], 7],
  8
]

Think of it like a filing cabinet: top-level folders hold documents and sub-folders.

Why Flatten Arrays win in Real-world scenarios?

Flattening simplifies data for:

Iteration: Loop once without if (Array.isArray(item)) checks.
Processing: Easier sorting, filtering, or mapping on flat lists.
UI Rendering: Display cart items or file trees linearly.
Performance: Reduces recursion depth in algorithms.

Example: Flattening [1, [2,3], 4] will let array.map(x => x*2) over the flatten array yield [2,4,6,8] cleanly.

The Flattening Concept: Step-by-Step

Flattening extracts all elements into a single-level array. Key decisions:

Copy: Shallow vs. deep
Depth control: Stop at a max depth to avoid infinite nests.
Preserve order: Process left-to-right.

Step 1: Start with [1, [2,3], [4, [5,6], 7], 8]
Step 2: Extract 1 → result: [1]
Step 3: Dive into [2,3] → extract 2,3 → result: [1,2,3]
Step 4: Dive into [4, [5,6], 7] → extract 4, dive deeper to 5,6 → extract 7 → result: [1,2,3,4,5,6,7]
Step 5: Extract 8 → result: [1,2,3,4,5,6,7,8]

Different Approaches to Flatten Arrays

Native `flat(depth)` (ES2019+)

Simplest: Going to flat the given array upto the specified depth. depth means upto which level it's going to be spread. arr.flat(Infinity) handles any depth.

[1, [2, [3]]].flat(Infinity); // [1,2,3]
[1, [2, [3]]].flat(1); // [1,2,[3]]

Pros: Built-in, readable. Cons: Browser support (IE doesn't support).

Iterative with `reduce` + `concat`

No recursion—great for huge arrays.

function flatten(arr) {
  return arr.reduce((acc, val) => Array.isArray(val) ? acc.concat(...val) : acc.concat(val), []);
}

Step-by-step: Accumulator starts empty, concat spreads nested arrays and adds them after spreading, otherwise simple add.

Recursive Custom (Polyfill Style)

Dive deep with a helper function—scales to any depth. We going to discuss about this in the next section.

Common Interview Scenarios

Interviewers love asking: "Implement Array.prototype.flat polyfill!" or "Flatten without natives, handle depth."

Building your own Polyfill: A Strong Solution

Here's your code—clean and correct:

Array.prototype.myFlat = function(depth = 1) {
    const result = [];
    const flatten = function(arr, depth) {
        for(let i = 0; i < arr.length; i++) {
            if (!arr.hasOwnProperty(i)) 
                continue;
            if(Array.isArray(arr[i]) && depth > 0) {
                flatten(arr[i], depth - 1);
            } else {
                result.push(arr[i]);
            }
        }
    }
    flatten(this, depth);
    return result;
}

console.log([1,2,3,4,5,[6,7,8,[9,10]]].myFlat(Infinity)); // [1,2,3,4,5,6,7,8,9,10]
console.log([1,,3].myFlat(1)); // [1,3]

Analysis (Problem-Solving Thinking):

In this polyfill, an empty array been taken called as result.
It uses a helper function, that iterate over every element of the array.
If it's an simple value then directly push to the result array.
If the element is an array and the depth is greater than 0, then it will call the same helper fucntion using the element which is actually an array with depth-1
after the all the nested array been spread (if depth=Infinity) or if the depth becomes 0, then it will stop and return the result array.

Note: I would recommend a dry run by your own. take a pen-paper and try dry-run

Interview Tip: Explain trade-offs: Recursion shines for trees; iteration for 1M+ elements. Here time-complexity: O(n) time (visits each element once) and O(depth) stack space.

Flattening isn't just a trick—it's a mindset for taming messy data. Practice these, tweak your polyfill and you'll crush interviews. Next time you hit nested chaos, myFlat(Infinity) has your back.

Spread vs Rest Operators in JavaScript: Expand or Collect Like a Pro

Ritam Saha — Fri, 24 Apr 2026 18:24:54 +0000

Introduction

Imagine you're juggling arrays and objects in JavaScript, and suddenly you need to copy, merge, or slice them without breaking a sweat.
Entry of the spread operator (...) and rest operator (...)—two syntactic superheroes that look identical buthave different jobs. They're game-changers for clean, readable code in modern JS and provide perfect Developer's experience, especially in React apps, Node.js backend applications.
But what's the difference between these two?

Spread expands values into individual elements;
Rest collects them into a single array or object

Let's dive in with examples and see how they shine (or clash) in real scenarios.

What the Spread Operator Does: Expanding Values

The spread operator (...) is like dropping a glass from a height and it spreads down completely with so many broken parts; this takes an iterable—like an array or object—and spreads (expands) its elements into individual items. It's like unpacking a box: everything spills out for easy use.

const fruits = ['apple', 'banana'];
const moreFruits = ['orange', ...fruits, 'grape'];
// Result: ['orange', 'apple', 'banana', 'grape']

Here, ...fruits expands the array, letting you merge without messy loops.

const user = { name: 'Ritam', city: 'Kolkata' };
const updatedUser = { ...user, age: 20, hobby: 'coding' };
// Result: { name: 'Ritam', city: 'Kolkata', age: 20, hobby: 'coding' }

Spread creates shallow copies and merges—perfect for immutable updates in state management.

What the Rest Operator Does: Collecting Values

The rest operator (...) does the opposite: it gathers (collects) elements into a single array. It only works in function parameters depending on the passed arguments and for destrcturing, acting like a "vacuum" for leftovers.

function sum(...numbers) {
  return numbers.reduce((acc, num) => acc + num, 0);
}
sum(1, 2, 3, 4); // Result: 10 (numbers = [1, 2, 3, 4])

Rest collects all arguments into numbers.

const [first, ...rest] = ['apple', 'banana', 'orange']; //Array destructuring
console.log(first); // 'apple'
console.log(rest);  // ['banana', 'orange']

It grabs the first item, then collects the rest.

Key Differences: Spread Expands, Rest Collects

Aspect	Spread (`...`)	Rest (`...`)
Direction	Expands (unpacks)	Collects (packs)
Context	Anywhere (arrays, objects, calls)	Function params or destructuring
Use Case	Copying, merging, passing args	Variable args, destructuring leftovers
Example	`[...arr]` clones array	`function(...args)`

Spread is for spreading values outward; rest is for gathering them inward. Confuse them? Your code breaks—spread won't work in params!

Practical Use Cases: Real-World Wins

Cloning Arrays/Objects (Spread): Avoid mutations in React state.

   const state = { users: [] };
   const newState = { ...state, users: [...state.users, newUser] };

Function Arguments (Spread): Pass arrays dynamically.

   const coords = [10, 20];
   console.log(Math.max(...coords)); // 20

API Data Merging (Spread): Combine defaults with user input.

   const defaults = { method: 'GET' };
   const config = { ...defaults, url: '/api/users' };
   fetch(config.url, config);

Variable Args in Node.js Utils (Rest): Build flexible helpers.

   function log(...messages) {
     console.log(new Date(), ...messages);
   }
   log('User login:', userId, timestamp);

Destructuring Props (Rest): In React components.

   function Button({ children, ...props }) {
     return <button {...props}>{children}</button>;
   }

These patterns pop up everywhere—from your full-stack deploys on Vercel to interview coding rounds.

Wrapping Up: Master Both for Cleaner JS

Spread and rest operators turn clunky array/object ops into elegant one-liners, saving you headaches in full-stack dev. Remember: spread expands for copying/merging; rest collects for flexible params. Practice with small examples, and they'll become second nature for your portfolio projects. Next time you're refactoring Node.js routes or React components, reach for ...—your future self will thank you. What's your favorite use case? Drop it in the comments!

Mastering Template Literals in JavaScript: Say Goodbye to String Concatenation Nightmares

Ritam Saha — Fri, 24 Apr 2026 11:28:32 +0000

Introduction

Imagine you're building a dynamic dashboard for your full-stack app. You need to greet users like "Welcome back, Ritam! Your last login was on April 24, 2026, at 4:28 PM IST." In the old days, you'd glue strings together with plus signs, escaping quotes, managing calculated spaces and praying for no typos. It quickly turns into a headache—unreadable for devs also, error-prone, and a maintenance nightmare.
Now enters template literals, JavaScript's elegant solution since ES6. They make string building feel natural, boosting your code's readability and productivity. Let's dive in and see why they're a game-changer.

The Pain of Traditional String Concatenation

Before template literals, we relied on concatenation with + or arrays joined by join(''). It works, but it's clunky and wasn't a good experience for the developers.

Example: Old-school greeting


const name = 'Ritam';
const lastLogin = 'April 24, 2026, 4:28 PM IST';
const greeting = 'Welcome back, ' + name + '! Your last login was on ' + lastLogin + '.';
// Output: "Welcome back, Ritam! Your last login was on April 24, 2026, 4:28 PM IST."

Problems abound:

Readability suffers as strings grow;
spotting variables amid quotes is tough.
Easy to miss spaces or add extra ones (e.g., 'back,' + name vs. 'back, ' + name).
No native multi-line support—forces ugly escape-sequence \n or + across lines.
Debugging? Typos in long chains are brutal.

This scales poorly in real apps, like API responses or HTML generation.

Template Literal Syntax: Backticks Unlock the Magic

Template literals use backticks (`) instead of single (') or double (") quotes. Key features:

Interpolation: Embed expressions with ${expression}.
Multi-line: Spans lines without escapes.
Expression support: ${} evaluates anything—variables, functions, math.

const greeting = Hello, world!; // Simple string

Embedding Variables: String Interpolation Made Simple

Interpolate with ${}—JavaScript evaluates and inserts the result/expression. It's dynamic and concise.

const name = 'Ritam';
const city = 'Kolkata';
const greeting = Welcome back to your dashboard, ${name} from ${city}!;

// Output: "Welcome back to your dashboard, Ritam from Kolkata!"

Technical Breakdown:

${name} calls toString() on name implicitly.
Even supports complex expressions: ${name.toUpperCase()} or ${2 + 2} yields "RITAM" or "4".

Compare with concatenation:

const oldGreeting = 'Welcome back to your dashboard, ' + name + ' from ' + city + '!';
// Template literal (clean and readable)
const newGreeting = Welcome back to your dashboard, ${name} from ${city}!;

Template literals win on readability—scan for ${} to spot variables instantly.

Multi-Line Strings: No More Escapes

Need formatted text, like emails or SQL? Backticks handle newlines naturally.

const user = 'Ritam';
const emailBody = `
Dear ${user},

Your portfolio project deployed successfully on Vercel.
Next steps:

Review PR on GitHub
Test Node.js backend

Happy coding!
Team
`;
// Output preserves exact formatting, including indents.

Use Cases in Modern JavaScript

Template literals shine in full-stack dev:

API Responses: const response = User ${userId} logged in at ${new Date().toISOString()};
HTML Templating (pre-React): Hello, ${name}! (sanitize for security).
Tagged Templates (advanced): Libraries like styled-components use them for dynamicity, e.g., styled.divHello ${name}.
Debug Logs: console.log(Error in ${functionName}: ${error.message});
SQL Builders: SELECT * FROM users WHERE id = ${userId} (use params to prevent injection).

Conclusion: Level Up Your JS Strings Today

Template literals transform string handling from a chore to a joy—readable, flexible, and modern. Ditch concatenation; embrace backticks for cleaner code that scales with your projects. Next time you're building that portfolio app or prepping for interviews, reach for ${}. Your future self (and teammates reviewing your PRs) will thank you.

Understanding the this Keyword in JavaScript: The Ultimate Guide

Ritam Saha — Thu, 23 Apr 2026 19:20:17 +0000

Introduction

Imagine you're at a party and someone yells, "Hey you!" – but who are they talking to? It depends entirely on who they’re facing and pointing when they shout. That's exactly how JavaScript's this keyword works. It doesn't have a fixed identity; instead, it dynamically points to whoever called.

Mastering this is crucial for any JavaScript developer because it determines what data your functions can access. Get it wrong, and your code breaks mysteriously. Get it right, and you unlock the full power of object-oriented JavaScript.

Let's demystify this step by step and in every context.

What Does `this` Actually Represent?

In JavaScript, this refers to the object that is currently executing the code. Think of it as "the caller of the function". Its value isn't fixed at write time – it's determined dynamically based on how and where the function gets called.

Key principle: this always depends on:

Where the code is written (browser vs Node.js)
The calling context
Strict mode vs non-strict mode

`this` in Global Context

In the global scope, this points to the global object:

// Browser environment
console.log(this); // window object

// Node.js environment  
console.log(this); // {} (empty object)

// Even typeof works consistently
console.log(typeof this); // "object" (both environments)

Global this = environment's global object.

`this` Inside Objects (Method Calls)

When a function is called as an object method, this refers to that object only:

const person = {
    name: "Ritam",
    greet: function() {
        console.log(`Hello, I'm ${this.name}!`);
    }
};

person.greet(); // "Hello, I'm Ritam!"

For obj.method() : this = obj

`this` Inside Regular Functions

This is where this gets tricky! Regular functions look at their calling context:

// Non-strict mode
function regularFunc() {
    console.log(this);
}

regularFunc(); 
// Browser: window object
// Node.js: global object (or empty object)

// Strict mode
"use strict";
function strictFunc() {
    console.log(this);
}

strictFunc(); // undefined (both environments)

Arrow Functions and `this`

Arrow functions inherit this from their surrounding scope:

// Node.js environment
const arrowTest = () => console.log(this);
arrowTest(); // {} (empty object)

// Browser environment
arrowTest(); // window object

The Classic Pitfall: Nested Functions

Regular nested functions lose the outer this:

const calculator = {
    value: 100,
    calculate: function() {
        // Regular nested function LOSES outer this
        function innerFunc() {
            console.log(this.value); // undefined!
        }
        innerFunc();
    }
};

calculator.calculate(); // undefined

Solution: Use arrow functions inside object methods:

const calculatorFixed = {
    value: 100,
    calculate: function() {
        // Arrow function INHERITS outer this
        const innerFunc = () => {
            console.log(this.value); // 100
        };
        innerFunc();
    }
};

calculatorFixed.calculate(); // Works perfectly!

How Calling Context Changes `this`

Remember our party analogy? Here's the magic:

const user = {
    name: "Ritam",
    sayHello: function() {
        console.log(`Hi from ${this.name}`);
    }
};

// Method call --> this = user object
user.sayHello(); // "Hi from Ritam"

// Function call --> this = global/undefined (Often called as Detached Methods)
const hello = user.sayHello; 
// hello only have the reference of the
// sayHello but don't have any idea whether 
// it come from an object or not. `this` becomes unaccessible.  
hello(); // "Hi from undefined"

Quick Reference Table

Context	Browser (non-strict)	Node.js (non-strict)	Strict Mode
Global	`window`	`{}`	`undefined`
Object Method	Object itself	Object itself	Object itself
Regular Function	`window`	`global`/ `{}`	`undefined`
Arrow Function	Lexical `this`	Lexical `this`	Lexical `this`

Key Takeaways & Best Practices

Think "caller": this = whoever called the function
Object methods are reliable: obj.method() always works
Arrow functions inherit: Perfect for callbacks and nested functions
Avoid this in regular standalone functions unless you know the context
Use const self = this pattern for older codebases

Mastering this transforms you from a JavaScript user to a JavaScript architect. Next time you see that sneaky keyword, you'll know exactly who it's pointing to!

Breaking Down Linux File-System

Ritam Saha — Wed, 22 Apr 2026 18:22:06 +0000

In Linux, everything is a file—not just text documents or executables, but also devices, network sockets, and even running processes. This idea turns the whole operating system into a giant, interconnected file‑system tree that you can “hunt” through like a detective. In this blog I’ll walk you through 10 meaningful discoveries I made while exploring the Linux file system, focusing on what those files and directories actually do, why they exist, and what interesting insights they reveal.

The brain of the system: `/etc`

The /etc directory acts as Linux’s configuration brain. It stores almost all system‑wide configuration files, from user accounts (/etc/passwd, /etc/shadow) to service settings, network parameters, and shell preferences.

Why does it exist?

Linux is designed to be modular and customizable. Instead of baking settings into the kernel, the system keeps them in human‑readable files under /etc, so administrators can tweak behavior without recompiling the OS.

What problem it solves:

Centralized configuration: tools like SSH, NTP, and cron all read their config from here, so you can control the whole machine from one place.
Portability: take /etc from one server and some settings can be reused on another, as long as the distribution is similar.

Interesting insight:

Opening /etc/environment shows where global environment variables are defined; every user and many system services inherit these values. This means a single file can subtly shape how every process behaves across the system.

DNS and name resolution: `/etc/resolv.conf` and `/etc/hosts`

When you type google.com into a browser, Linux must translate that into an IP address. The main files that drive this are /etc/resolv.conf and /etc/hosts.

What they do:

/etc/resolv.conf: tells the resolver which DNS servers to query and sets search domains.
/etc/hosts: maps hostnames to IPs locally, bypassing DNS entirely.

Why they exist:

Without DNS, you’d have to memorise IP addresses for every service. These files let the system know where to ask for DNS answers and allow quick local overrides for testing or debugging.

Example:

$ cat /etc/resolv.conf
nameserver 8.8.8.8
nameserver 1.1.1.1
search mycompany.local

What problem it solves:

Fault isolation: you can point a test server to a different DNS server by changing just /etc/resolv.conf.
Local testing: /etc/hosts lets you temporarily route api.staging.example to 127.0.0.1 without touching DNS infrastructure.

Interesting insight:

On some systems /etc/resolv.conf is just a symlink to /run/systemd/resolve/resolv.conf because systemd-resolved manages DNS and caches queries. This reveals how multiple layers of abstraction (service ↔ config ↔ resolver) all converge into a single file that applications read.

Routing tables on disk: `/proc/net/route` and `/etc/iproute2`

Routing is the process of deciding which network interface and gateway to use for each packet. Linux exposes its routing table through virtual files under /proc and configures higher‑level rules via /etc/iproute2.

What /proc/net/route does:

It’s a text representation of the kernel’s routing table, showing destination networks, gateways, and interfaces in hexadecimal.

Example:

$ cat /proc/net/route
Iface   Destination     Gateway         Flags   RefCnt  Use     Metric  MTU     Window  IRTT
eth0    0000FEA9        00000000        0001    0       0       0       0       0       0
eth0    0200A8C0        00000000        0001    0       0       0       0       0       0

Why /proc/net/route exists:

The kernel maintains routing data in memory, but users‑pace tools need access. /proc exposes this as a file‑like interface so commands like ip route and netstat -r can read and display it.

What problem it solves:

Troubleshooting: if a server can’t reach a remote subnet, inspecting /proc/net/route (or ip route) can show missing or wrong routes.
Scripting: scripts can parse this file to detect routing changes or validate network config.

Interesting insight:

Seeing the table in hexadecimal initially looks cryptic, but once you decode the destination and gateway fields (e.g., 0200A8C0 ↔ 192.168.0.2), you realise it’s literally the kernel’s raw routing logic laid bare as a text file.

Networking interface configuration

Network interfaces are controlled by config files and runtime data exposed under the file system. The exact paths differ by distro and network manager, but the idea is the same: configuration files live under /etc and running‑state info lives under /sys or /proc.

On many modern systems, NetworkManager writes connection‑specific files such as:

$ ls /etc/NetworkManager/system-connections/
wifi-home.nmconnection
server-wired.nmconnection

Why these files exist:

They persist the settings (SSID, IP mode, gateway, DNS) for each interface so the system doesn’t need to re‑ask for configuration every reboot.

What problem they solve:

Automatic re‑connection: after a reboot, the system uses these configs to bring interfaces up correctly.
Multi‑environment: a laptop can have separate configs for home, office, and mobile Hotspot.

Interesting insight:

Exploring /sys/class/net/eth0 shows symbolic links and device‑specific files that expose the interface’s driver, speed, and MAC address. This reveals how even hardware is modelled as a file‑system tree, making low‑level inspection surprisingly scriptable.

Logs and digital breadcrumbs: `/var/log`

System logs are one of the most powerful “forensic” tools in Linux. The /var/log directory houses logs from the kernel, services, and applications, each stored as ordinary text files.

Typical files:

$ ls /var/log/
auth.log    syslog      kern.log    nginx/access.log    apache2/error.log

What they do:

auth.log (or secure on some distros): records SSH logins, sudo attempts, and other auth events.
syslog / messages: general system‑wide messages from daemons and the kernel.
Service‑specific logs (e.g., nginx/*, apache2/*): store web‑server access and errors.

Why they exist:

Logs answer the “what happened and when?” question. They help debug crashes, track performance issues, and detect security incidents.

What problem they solves:

Incident response: after a suspected breach, you can comb through /var/log/auth.log to see if there were brute‑force SSH attempts.
Automation: log‑parsing tools read these files and trigger alerts or dashboards.

Interesting insight:

Reading /var/log/kern.log can show exact timestamps of hardware events, such as when a USB device was plugged in or when a disk driver threw an error. This makes /var/log feel like a chronological diary of the machine’s entire life.

Users and accounts: `/etc/passwd`, `/etc/shadow`, `/etc/group`

User management is surprisingly file‑based. The main files are:

/etc/passwd: user names, UIDs, home directories, and default shells (no passwords).
/etc/shadow: password hashes, expiry dates, and login restrictions.
/etc/group: group definitions and which users belong to them.

Example:

$ head -2 /etc/passwd
root:x:0:0:root:/root:/bin/bash
ritam:x:1000:1000:Ritam,,,:/home/ritam:/bin/zsh

Why they exist:

Linux follows the principle of “everything is a file.” Instead of a hidden database, user and group data live in plain(ish) text files with strict permissions.

What problem they solve:

Fast, portable access: any program that needs UID‑to‑name mapping can open /etc/passwd without a database daemon.
Security separation: sensitive password hashes are stored in /etc/shadow, which is readable only by root, preventing casual inspection.

Interesting insight:

Noticing the x in /etc/passwd’s password field and then finding the actual hash in /etc/shadow reveals a clever separation of concerns: one file for public info, another for secret data, all still under /etc.

Permissions and the role of `/etc/sudoers`

File permissions already give Linux a rich security model, but /etc/sudoers adds another layer on top. It defines which users can run which commands as root or other users.

Example:

$ grep 'ritam' /etc/sudoers
ritam ALL=(ALL:ALL) NOPASSWD:ALL

What it does:

Each line in /etc/sudoers grants a user (or group) permission to run specific commands on specific hosts, sometimes without a password.

Why it exists:

Direct root logins are risky; sudo allows fine‑grained privilege delegation. An admin can give a developer temporary root‑like access to a web server without handing over the root password.

What problem it solves:

Auditability: sudo logs every command to /var/log/auth.log, so you can track who did what.
Least privilege: a backup user can run only backup‑related commands, not arbitrary system changes.

Interesting insight:

Hunting through /etc/sudoers and its included snippets (often under /etc/sudoers.d/) reveals that even privilege‑escalation logic is ultimately driven by human‑editable text files, not a hidden binary policy engine.

Processes as files: `/proc`

The /proc filesystem is one of the most fascinating parts of the Linux file system. Each running process gets a directory under /proc/<PID>, containing status files, memory maps, and environment variables.

Example:

$ ls /proc/1/
cwd  environ  exe  fd/  mem  mounts  status  cmdline

What it does:

status: basic metadata like memory usage, state, and user ID.
cmdline: the command line that started the process.
fd/: symbolic links to open file descriptors.
environ: environment variables as null‑separated strings.

Why /proc exists:

The kernel exposes process‑level information in a file‑like interface so tools like ps, top, and lsof can read it without needing special syscalls for every piece of data.

What problem it solves:

Process inspection: you can literally cat /proc/$PID/environ to see which environment variables a service sees.
Forensics: if a process opens suspicious files or sockets, you can inspect /proc/$PID/fd and /proc/$PID/maps to trace them.

Interesting insight:

Looking at /proc/self (a symlink to the current process’s own directory) makes it feel like each process “lives” in the file system, reading and writing information about itself as if it were any other service talking to a config file.

Device files and `/dev`

In Linux, even hardware devices are represented as files under /dev. These “device files” let you read from or write to physical devices using the same file‑I/O operations a text program would use.

Example:

$ ls -l /dev/sda*
brw-rw---- 1 root disk 8, 0 Apr 22 2026 /dev/sda
brw-rw---- 1 root disk 8, 1 Apr 22 2026 /dev/sda1

What they do:

/dev/sda, /dev/sda1, etc.: block device files for disk and its partitions.
/dev/null: a sink that discards all data written to it.
/dev/random, /dev/urandom: provide entropy for random data.

Why they exist:

The kernel abstracts hardware into a file‑like interface so applications can treat storage, terminals, and other devices uniformly.

What problem it solves:

Abstraction: tools like dd can back up a disk by literally copying /dev/sda to a file, without caring what controller it is.
Security: restrictive permissions on device files prevent random users from directly accessing hardware.

Interesting insight:

Running ls -l /dev and seeing that /dev/sda is a “block special” file (brw-rw----) shows that even raw disk access is just another file, governed by the same permission model used for regular files and directories.

Boot‑time configuration under `/boot` and `/etc/grub`

Booting is orchestrated by files under /boot and configuration under /etc/grub. These files define which kernel to load, which initramfs to use, and what kernel parameters to pass.

Example:

$ ls /boot
vmlinuz-6.8.0-10-generic
initrd.img-6.8.0-10-generic
grub/

What they do:

vmlinuz-*: compressed kernel images.
initrd.img-*: initial RAM disk used early in boot.
/boot/grub/grub.cfg (or /etc/grub.d/*): boot‑menu configuration.

Why they exist:

The bootloader needs to know which kernel and initramfs to load, and the admin needs a way to tweak kernel parameters (e.g., nomodeset, console=ttyS0).

What problem it solves:

Predictable boot: the system can always find the correct kernel and initramfs in /boot.
Flexibility: changing /etc/default/grub and running update-grub generates a new grub.cfg, allowing you to experiment with different boot options.

Interesting insight:

Opening /boot/grub/grub.cfg and seeing kernel‑parameter lines like linux /boot/vmlinuz-6.8.0-10-generic root=UUID=... ro makes it clear that booting is just another script‑like configuration, defined by plain text that you can read and edit.

Environment and system‑wide configuration

Beyond /etc/environment, many environment variables and shell settings are defined in files such as /etc/profile, /etc/profile.d/*.sh, /etc/bash.bashrc, and user‑specific ~/.bashrc, ~/.profile.

Example:

$ cat /etc/profile.d/java.sh
export JAVA_HOME=/usr/lib/jvm/java-17-openjdk
export PATH=$JAVA_HOME/bin:$PATH

What they do:

These scripts set environment variables and shell aliases that are inherited by every interactive shell session.

Why they exist:

To avoid hard‑coding paths and settings into each user’s shell config, distribution maintainers centralize them in /etc.

What problem it solves:

Consistency: every user on the system gets the same JAVA_HOME unless explicitly overridden.
Maintenance: updating one file under /etc can propagate a change to all future logins.

Interesting insight:

Hunting through /etc/profile.d/*.sh and comparing them with your own ~/.bashrc reveals that Linux effectively “assembles” your environment from multiple layers of configuration files, like a stack of configuration cards.

Wrapping up: thinking like a system investigator

Exploring the Linux file system beyond basic commands turns you into a kind of system detective. Instead of seeing /etc, /proc, /dev, and /var/log as abstract directories, you begin to recognise them as the living, file‑based control plane of the entire OS.

Each meaningful discovery—whether it’s decoding a routing table from /proc/net/route, reading environment variables from /etc/environment, or tracing a suspicious process via /proc/$PID—tells you why Linux behaves the way it does and how you can safely change or debug that behaviour. This “hunting” mindset doesn’t just help with assignments; it trains you to think like the OS itself, which is exactly what you want when you step into roles as a developer, DevOps engineer, or security analyst.

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.

Forem: Ritam Saha

What is NodeJS? JavaScript on the Server Explained

Introduction

JavaScript: From Browser Component to Server Powerhouse

JavaScript Was Originally Browser-Only

The Problem Ryan Dahl Solved

What Exactly Is Node.js?

V8 Engine: The Heart of Node.js

Event-Driven, Non-Blocking Architecture: The Secret Sauce

Node.js vs. Traditional Backend Runtimes (PHP, Java)

Real-World Use Cases of Node.js

Why Node.js Still Matters

Setting Up Your First Node.js Application Step-by-Step

Introduction

Installing NodeJS: Setup with Platform Notes

Step 1: Download from the Official Site (Universal Starting Point)

Verifying Your Installation

Demystifying the Node.js REPL: Your Interactive Playground

Creating and Running Your First JavaScript File

Building a Hello World Server: Your First Server

Wrapping Up: From Zero to Node Hero

JavaScript Modules: Import & Export Explained

The Chaos of Unorganized Code

Why Modules Are Needed

Exporting Functions or Values

Importing Modules

Default vs Named Exports

Benefits of Modular Code

Conclusion: Level Up Your JS Projects Today

Mastering Destructuring in JavaScript: Extract Smarter, Code Cleaner

Introduction

What Destructuring Means

Destructuring Arrays: Position-Based Extraction

Destructuring Objects: Key-Based Extraction

Default Values: Handling Optional/Missing Data

Benefits of Destructuring and Use Cases

Wrap Up: Level Up Your Code Standard

Mastering Array Flattening in JavaScript: From Nested Chaos to Clean Lists

What Are Nested Arrays?

Why Flatten Arrays win in Real-world scenarios?

The Flattening Concept: Step-by-Step

Different Approaches to Flatten Arrays

Native flat(depth) (ES2019+)

Iterative with reduce + concat

Recursive Custom (Polyfill Style)

Common Interview Scenarios

Spread vs Rest Operators in JavaScript: Expand or Collect Like a Pro

Introduction

What the Spread Operator Does: Expanding Values

What the Rest Operator Does: Collecting Values

Key Differences: Spread Expands, Rest Collects

Practical Use Cases: Real-World Wins

Cloning Arrays/Objects (Spread): Avoid mutations in React state.

Function Arguments (Spread): Pass arrays dynamically.

API Data Merging (Spread): Combine defaults with user input.

Variable Args in Node.js Utils (Rest): Build flexible helpers.

Destructuring Props (Rest): In React components.

Wrapping Up: Master Both for Cleaner JS

Mastering Template Literals in JavaScript: Say Goodbye to String Concatenation Nightmares

Introduction

The Pain of Traditional String Concatenation

Template Literal Syntax: Backticks Unlock the Magic

Embedding Variables: String Interpolation Made Simple

Multi-Line Strings: No More Escapes

Use Cases in Modern JavaScript

Conclusion: Level Up Your JS Strings Today

Understanding the this Keyword in JavaScript: The Ultimate Guide

Introduction

What Does this Actually Represent?

this in Global Context

this Inside Objects (Method Calls)

this Inside Regular Functions

Arrow Functions and this

The Classic Pitfall: Nested Functions

How Calling Context Changes this

Quick Reference Table

Key Takeaways & Best Practices

Breaking Down Linux File-System

The brain of the system: /etc

DNS and name resolution: /etc/resolv.conf and /etc/hosts

Native `flat(depth)` (ES2019+)

Iterative with `reduce` + `concat`

What Does `this` Actually Represent?

`this` in Global Context

`this` Inside Objects (Method Calls)

`this` Inside Regular Functions

Arrow Functions and `this`

How Calling Context Changes `this`

The brain of the system: `/etc`

DNS and name resolution: `/etc/resolv.conf` and `/etc/hosts`

Routing tables on disk: `/proc/net/route` and `/etc/iproute2`

Logs and digital breadcrumbs: `/var/log`

Users and accounts: `/etc/passwd`, `/etc/shadow`, `/etc/group`

Permissions and the role of `/etc/sudoers`

Processes as files: `/proc`

Device files and `/dev`

Boot‑time configuration under `/boot` and `/etc/grub`

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()`