Sameer's Dev Log

React Virtual DOM Explained: How It Works Under the Hood

Sameer Bhagtani — Fri, 08 May 2026 20:33:03 GMT

Introduction

If you've ever built something with vanilla JavaScript and had to update the UI frequently, you already know the pain. You call document.getElementById, change some text, update a class, maybe re-render a list. It works. But at some point, as the app grows, it slows to a crawl. Pages feel sluggish. Simple interactions feel heavier than they should.

That sluggishness has a cause. And the Virtual DOM is React's answer to it.

The Problem with Direct DOM Manipulation

The real DOM (Document Object Model) is a tree of nodes that the browser builds from your HTML. Every time you touch it, the browser has to do work.

Change a single element's text? The browser may reflow the layout. Add a class? It might repaint parts of the screen. Remove a child node and add a new one? It recalculates styles, repaints, and composites everything again.

These operations are not free. The DOM was built to represent documents, not dynamic user interfaces that update dozens of times per second. When you write a loop that calls innerHTML repeatedly, or update many nodes in quick succession, you're forcing the browser to redo expensive work on every single change.

React solves it by introducing a layer between your code and the real DOM.

What the Virtual DOM Actually Is

The Virtual DOM is not magic. It's a plain JavaScript object that describes what the UI should look like.

When you write JSX like this:

const element = Hello;

React converts it into something like this under the hood:

const element = {
    type: 'h1',
    props: {
        className: 'title',
        children: 'Hello'
    }
};

That's it. A JavaScript object. No browser APIs involved. No layout recalculations. Just a description of a node.

A full component tree becomes a tree of these objects. React holds this in memory and uses it to figure out what, if anything, needs to change in the real DOM. Since reading and writing plain JavaScript objects is orders of magnitude faster than touching the DOM, React can do a lot of computation cheaply before it ever commits a single change to the browser.

Step 1: The Initial Render

When your app loads for the first time, React builds a Virtual DOM tree from your component tree, then walks it once to generate the corresponding real DOM nodes and insert them into the page.

App
 └── Header
 │     └── h1: "My App"
 └── Main
       └── p: "Welcome"

React creates the equivalent real DOM elements, attaches event listeners, and paints the initial UI. This first render has no diffing to do. It just builds.

Step 2: Something Changes

Now a user clicks a button. You call setState. A prop changes. React knows something has changed, so it needs to figure out what the new UI should look like.

The key thing here: React does not immediately touch the real DOM.

Instead, it re-runs your component functions (or render methods) to produce a brand new Virtual DOM tree that reflects the new state.

// Old Virtual DOM tree
App
 └── Counter
       └── p: "Count: 0"
       └── button: "Increment"

// New Virtual DOM tree (after state change)
App
 └── Counter
       └── p: "Count: 1"   <--- changed
       └── button: "Increment"

Both trees exist in memory. Now React has to compare them.

Step 3: Diffing (Reconciliation)

Reconciliation is the process of comparing the old Virtual DOM tree with the new one, node by node, to find what changed.

React calls this diffing. Walking through the two trees looks roughly like this:

Old Tree              New Tree
-----------           -----------
App                   App
 └── Counter           └── Counter
       └── p: "0"            └── p: "1"   <- different
       └── button             └── button  <- same

React starts at the root and walks both trees in parallel. For each node, it asks: is this the same type of element? Do the props match? What about the children?

In this case, it finds one difference: the text content of the p tag changed from "0" to "1". Everything else is identical.

React does not re-render the button. It does not re-render the Counter wrapper. It marks only that one p node as needing an update.

A few rules React uses to make this fast:

Elements of different types (like swapping a div for a span) are treated as a full replacement. The old subtree is discarded and a new one is built.
For elements of the same type, React updates only the changed attributes or children.
For lists, React uses key props to match old items to new ones. Without keys, React has to guess, which can produce wrong results.

Step 4: The Commit Phase

Once diffing is done, React has a list of the minimal changes it needs to make. It then applies those changes to the real DOM in a single batch.

In the example above, it does one thing: updates the text content of that paragraph. Not the button. Not the wrapper. Just the text.

// Only this real DOM operation runs:
paragraphNode.textContent = "Count: 1";

This batching is where the performance benefit becomes real. Instead of updating the DOM after every setState call individually, React collects all the changes from a render cycle and applies them at once. The browser does one reflow and one repaint, not many.

The Full Flow

Here's the flow from start to finish:

[State/Props Change]
        |
        v
[React re-runs components]
[New Virtual DOM tree is created]
        |
        v
[Diffing: old tree vs new tree]
[Minimal list of changes is computed]
        |
        v
[Commit phase: changes applied to real DOM]
        |
        v
[Browser repaints]

React separates the "figuring out what changed" step (render and diff) from the "actually changing the DOM" step (commit). The first part is cheap. The second part is expensive. By minimizing how often and how much of the second part runs, React keeps UIs fast.

Is the Virtual DOM Always Worth It?

You might write a component that re-renders on every keystroke. Without Virtual DOM, that would mean dozens of DOM writes per second. With React's approach, most of those re-renders produce a Virtual DOM that's nearly identical to the previous one. After diffing, maybe only one input's value attribute gets updated in the real DOM.

The Virtual DOM doesn't eliminate DOM work. It reduces it to only what's necessary.

There's a tradeoff worth knowing: for extremely simple UIs, the overhead of maintaining a Virtual DOM and diffing it isn't worth it. Vanilla JavaScript can be faster for small, static pages. But once your UI has real complexity and frequent updates, the Virtual DOM approach pays off quickly.

Conclusion

The mental model here, render to a virtual tree, diff it against the previous tree, commit only the changes, is accurate enough to write better React code, debug re-render issues, and understand why key props matter in lists.

That's the Virtual DOM. A JavaScript object tree, a comparison algorithm, and a batched write to the real DOM. Nothing more, nothing less.

Behind the Root: Linux Filesystem Demystified

Sameer Bhagtani — Wed, 22 Apr 2026 17:08:19 GMT

Introduction

If you've ever installed and tried out Linux after seeing a cool hacking sequence in a sci-fi movie, you know that opening it feels like stepping into a strange city with many roads named /bin, /home and /tmp. As beginners, we tend to ignore them and go on with our Linux usage by simply remembering the most commonly used commands.

While that approach works initially, it is good to take a step back and understand the Linux Filesystem properly. As "good" developers, who actually get their code out of localhost, we need to understand Linux to its core, because that is what drives the majority of web servers.

In this blog post, I have broken down the philosophy behind the Linux Filesystem, what all those randomly named directories actually do, and some cool insights along the way.

The Core Philosophy: Everything is a File

A fascinating thing about Linux is that everything, literally everything in Linux, is represented as a file in the Filesystem. This includes not just documents, but devices, processes, sockets, and even hardware!

To digest this idea properly, we need to change our perspective on what a "file" actually means. We usually think of a "file" as a document on our system. In Linux though, a "file" is just a stream of bytes with a path. That's it. Anything that can be read from or written to fits that definition.

Let's look at some examples of files as per this new definition:

Path	Description
`/home/user/gta-cheat-codes.txt`	Just a simple file that the user has created
`/dev/input/...`	Your input devices like keyboard, mouse
`/dev/sda`	Literally your hard drive
`/proc/1234`	A running process

Since everything is a file, you can do powerful things like pipe data between programs, redirect output, and chain tools together. This is the exact reason why the Linux terminal is so powerful.

This core philosophy is what gives the Linux Filesystem its structure.

Filesystem Hierarchy Standard (FHS)

Before we dive deep into the directory structure, I want to mention that the Linux Filesystem isn't a random arrangement of resources in a tree-like structure. There is a specification called the "Filesystem Hierarchy Standard" that defines the directory structure and contents in Linux and other Unix-like operating systems. It is maintained by the Linux Foundation.

The Problem it Solves

Before FHS, different Unix distributions placed files wherever they wanted. A config file might live in /etc on one system and /usr/config on another. This made it a nightmare to:

Write portable software
Move between distributions
Predict where anything lives

FHS serves as a guideline, which most major distros like Debian, Fedora and Arch follow closely to maintain uniformity and predictability.

The Root Directory

The root directory is the top of the entire filesystem tree in Linux. It is represented by /. The reason it is called the "root" is because there is nothing above it. You can go back as much as you want but never beyond the "root".

If you're from the Windows ecosystem, you can think of this as your C:\. Everything, including files, devices, processes, and external drives, all mount within this same tree.

We can run the ls command at the root of our linux system, and would get the following directories:

/
├── bin     -> Essential command binaries
├── boot    -> Kernel and bootloader files
├── dev     -> Device files to interface with hardware
├── etc     -> Text-based configuration files
├── home    -> Personal directories for each user
├── lib     -> Shared library files used by binaries
├── media   -> Mount point for removable media (USBs, CDs)
├── mnt     -> Temporary mount point for filesystems
├── opt     -> Optional, add-on software packages
├── proc    -> Virtual filesystem tracking running processes
├── root    -> Home directory for the root user
├── run     -> Runtime data for processes since last boot
├── sbin    -> System binaries for administrative use
├── srv     -> Data served by the system (FTP, HTTP, etc.)
├── sys     -> Virtual filesystem exposing kernel internals
├── tmp     -> Temporary files, cleared on reboot
├── usr     -> Secondary hierarchy for user installed software
└── var     -> Variable data like logs, caches and spools

`/etc`: System Configuration Hub

I personally like to refer to it as the "Configuration Hub" of the entire system. The reason is that every major program, service, and system behavior has its config file here.

Moreover, it's all just plain text. This simple design choice makes configurations readable and easily editable. This is what makes Linux so customizable.

/etc
├── hostname       -> The machine's host name
├── hosts          -> Local DNS overrides
├── nsswitch.conf  -> Controls the order of lookups
├── resolv.conf    -> DNS server configuration
├── network/       -> Network interface configuration (Debian)
├── netplan/       -> Network interface configuration (Ubuntu)
├── passwd         -> User account information
├── shadow         -> Hashed user passwords
├── group          -> Group memberships
├── sudoers        -> Controls who can run commands as root
├── environment    -> System-wide environment variables
├── profile        -> Shell environment on login
└── systemd/
    └── system/    -> Service unit files

Password Storage

Most people assume passwords are stored somewhere as plain text or in one file. Linux is much smarter than that. It splits user information across multiple files with specific jobs.

`/etc/passwd`

Despite the name, this file does not store passwords anymore. It stores user account information. Every line is one user, and it looks like this:

root:x:0:0:root:/root:/bin/bash
sameer:x:1000:1000:Sameer Bhagtani:/home/sameer:/bin/bash

Each colon-separated field means:

Username
Password field: just an x, meaning "go look in /etc/shadow"
UID: User ID, a unique number for the user
GID: Group ID, the user's primary group
GECOS: Full name or description
Home directory
Default shell

`/etc/shadow`

This is where the actual passwords live. Linux doesn't store them in plain text format. Instead, it hashes the password for security.

This file is only readable by root. A line looks like:

root:\(y\)j9T\(randomsalt\)hashedpasswordstring:20384::::::

Each colon-separated field means:

Username
Hashed password
Last password change: days since Jan 1, 1970
Minimum password age: days before password can be changed
Maximum password age: days before password must be changed
Warning period: days before expiry to warn the user
Remaining fields: inactivity period, expiry date, reserved

Groups

A group in Linux is simply a collection of users. Linux uses groups to manage permissions at scale. Instead of setting permissions for each user individually, you assign permissions to a group and add users to it.

For example, you have 5 developers who all need access to /var/www/. Instead of giving each of them individual access, you create a www-data group, give the group access to that folder, and add all 5 users to it.

All this information is stored in /etc/group, where a line looks like:

network:x:27:user1,user2

Each colon-separated field means:

Group name
Password: almost always x or empty, group passwords are rarely used
GID: Group ID
Members: comma-separated list of users in the group

Default Groups

Following are the meanings of some of the default groups in Linux:

Group	What it gives you access to
`wheel`	`sudo` privileges
`audio`	Sound devices
`video`	GPU and display devices
`storage`	Mounting drives and storage devices
`network`	Managing network connections

DNS Configuration

When you type google.com in your browser, your system needs to figure out the IP address behind it. This process is called DNS resolution. I have written a blog post about DNS resolution in depth, in case you're interested:

https://blog.sameerbhagtani.dev/dns-resolution-explained

Linux handles this in a specific order, and /etc controls that entire pipeline.

`/etc/hosts`

This is checked before any DNS server is even contacted. It's a simple static lookup table that maps hostnames to IP addresses manually. It looks like:

127.0.0.1       localhost
192.168.1.10    myserver.local

So if you add google.com here pointing to some other IP, your system will use that and never bother asking a DNS server. This is why it's called a local DNS override. Developers use this all the time to point a domain to their local machine for testing.

`/etc/resolv.conf`

This is where your DNS servers are defined. When /etc/hosts has no answer, your system goes here to find out which DNS server to ask. It looks like:

nameserver 8.8.8.8
nameserver 8.8.4.4

The above example shows Google's DNS severs. You can also use 1.1.1.1 which is Cloudflare's.

`/etc/nsswitch.conf`

This is the traffic controller of the whole resolution process. It defines the order in which your system looks things up. The relevant line looks like:

hosts: files dns

This tells the system: first check files (which means /etc/hosts), then go to dns (which means /etc/resolv.conf). This is why /etc/hosts always wins over DNS servers.

The full DNS resolution flow

Check /etc/nsswitch.conf for the lookup order
Check /etc/hosts for a static entry
No match? Go to /etc/resolv.conf for the DNS server
Ask that DNS server for google.com
Get the IP back, connect

Network Interface Configuration

A network interface is your system's way of connecting to a network. It can be physical, like your ethernet port or WiFi card, or virtual, like a loopback interface. Each interface gets a name:

eth0 or enp3s0: your ethernet card
wlan0 or wlp2s0: your WiFi card
lo: the loopback interface, always 127.0.0.1, used by your system to talk to itself

You can see all your interfaces with:

ip link show

The location of these network config files varies by distro, which is one of the few places where the FHS does not give you full uniformity.

For Debian and older Ubuntu systems, the file is located at /etc/network/interfaces:

auto eth0
iface eth0 inet dhcp

This says: bring up eth0 automatically on boot, and get its IP via DHCP.

Service Configurations

When you run systemctl start nginx or systemctl enable ssh, systemd needs to know:

What those services actually are?
How should they start?
What user should run them?
What happens if they crash?

All of this is defined in a unit file.

/etc/systemd/system/ is where your local unit files live. These are either custom services you created yourself, or overrides to the default unit files that came with installed packages.

What does a unit file look like?

Let's look at a simple example. Say you want to create a service that runs a Node.js app on boot:

[Unit]
Description=My Node.js App
After=network.target

[Service]
ExecStart=/usr/bin/node /home/sameer/app/index.js
Restart=always
User=sameer

Breaking down the two sections:

[Unit]: Metadata about the service.
- After=network.target: Don't start this service until the network is up.
[Service]: The actual behavior
- ExecStart: the command to run
- Restart=always: if the process crashes, restart it automatically
- User: run the process as this user, not as root

Enabling vs Starting

There is an important distinction here that trips up a lot of beginners:

systemctl start nginx    # starts the service right now
systemctl enable nginx   # makes it start automatically on every boot

start is temporary. enable is permanent. You almost always want both:

systemctl enable --now nginx

The --now flag starts it immediately and enables it for future boots in one command.

Where do default unit files live then?

If /etc/systemd/system/ is for local configs, where do the unit files for packages like nginx or ssh live? Those ship to /usr/lib/systemd/system/.

The rule is simple: /etc/systemd/system/ always takes priority over /usr/lib/systemd/system/. So if you want to override how a package's service behaves without touching the original file, you drop your version in /etc/systemd/system/ and systemd will use that instead.

`/proc`: The Process Filesystem

/proc is one of those things that genuinely makes you stop and think. It looks like a directory full of files, but none of these files actually exist on your disk. There is nothing written to your SSD or HDD here.

/proc is a virtual filesystem that the kernel generates in memory, live, every time you look at it.

Think of it as a window into your running kernel. Whatever is happening on your system right now, the kernel is exposing it as readable files inside /proc. The moment a process starts, an entry appears. The moment it dies, it disappears.

You can verify this yourself:

ls /proc

You will see a bunch of numbered directories like 1, 423, 1089 and so on. Each number is a PID (Process ID), and each directory contains information about that running process. Open one up:

ls /proc/1

You will find files like status, cmdline, maps, fd and more, all describing exactly what that process is doing right now.

For example:

cat /proc/1/status

This will show you the name of the process, its state, memory usage, which user is running it, and more. All of that, served as a plain text file.

This is the "everything is a file" philosophy at its most elegant. The kernel is not a black box. It is constantly talking to you through /proc, and all you need to read it is cat.

Routing Tables

When your system wants to send a packet to some IP address, it does not just blindly throw it onto the network. It first consults a routing table, which is essentially a set of rules that answer one question: for this destination, which interface should I use and where should I forward the packet?

A simple way to see your routing table is:

ip route show

You will see something like:

default via 192.168.1.1 dev wlan0
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.105

The first line says: for everything else, forward to 192.168.1.1 (your router) via wlan0.
The second line says: for anything in the 192.168.1.0/24 range, you can reach it directly through wlan0 without going through a gateway.

Now, this same information is also exposed as a file inside /proc:

cat /proc/net/route

Iface    Destination  Gateway   Flags  RefCnt  Use  Metric  Mask
wlan0    00000000     0101A8C0  0003   0       0    100     00000000
wlan0    0001A8C0     00000000  0001   0       0    100     00FFFFFF

This is the raw version of the same routing table, but in hex. The values for Destination, Gateway and Mask are in little endian hex format, which is why 0101A8C0 translates to 192.168.1.1. Not the most human readable format, which is exactly why tools like ip route exist on top of it.

The key insight here is that /proc/net/route is not a config file. You cannot edit it to change your routes. It is purely a read only window into what the kernel currently knows about routing, consistent with the whole philosophy of /proc.

System Logs

When something goes wrong on your system, the first place you go is /var/log. This is where Linux keeps logs for pretty much everything: the kernel, system services, applications, authentication events, and more.

ls /var/log

You will see a bunch of files and directories. Here are the important ones:

/var/log
├── syslog     -> General system activity logs (Debian/Ubuntu)
├── auth.log   -> Authentication events (logins, sudo usage)
├── kern.log   -> Kernel messages
├── dmesg      -> Boot time hardware detection logs
└── journal/   -> systemd's binary log store

Reading logs

For most log files, a simple cat or tail works:

tail -f /var/log/auth.log

The -f flag follows the file in real time, so you can watch events as they come in. Useful for monitoring login attempts or debugging a service.

For systemd based systems, the preferred way to read logs is through journalctl:

journalctl -u nginx        # logs for a specific service
journalctl -f              # follow logs in real time
journalctl --since today   # logs from today only

What insights do logs actually give you?

A few practical examples of what you can catch from logs:

Someone repeatedly trying to SSH into your server with wrong passwords: visible in auth.log
A service that keeps crashing on boot: visible in journalctl -u servicename
A kernel panic or hardware error: visible in kern.log or dmesg
General system misbehavior: visible in syslog

File Descriptors

When a program opens a file, the kernel does not give it direct access to the file. Instead, it gives back a small integer called a file descriptor. This integer is just a reference that the program uses to interact with the file going forward.

Every process gets three file descriptors by default when it starts:

0 -> stdin  (standard input)
1 -> stdout (standard output)
2 -> stderr (standard error)

When the program opens additional files, they get assigned the next available numbers: 3, 4, 5 and so on.

You can see the file descriptors of any running process through /proc:

ls /proc//fd

This will show you every file, socket, pipe or device that process currently has open, each represented as a numbered symlink.

Everything is a File Descriptor

This is where the "everything is a file" philosophy gets very practical. In Linux, file descriptors are not just for files on disk. They represent:

Regular files
Directories
Network sockets
Pipes between processes
Device files in /dev

When your Node.js server accepts an incoming HTTP connection, the kernel hands it a file descriptor for that socket. The server reads from it and writes to it just like a regular file. Same interface, whether it is a text file or a network connection.

The Default Limit and Why it Matters

The kernel puts a limit on how many file descriptors a single process can have open at once. You can check yours with:

ulimit -n

On most systems this defaults to 1024. This means a single process can have at most 1024 files, sockets, or connections open at the same time.

For a simple script or a CLI tool, 1024 is more than enough. But for a web server or a WebSocket server, this becomes a real problem fast.

The WebSocket Problem

A WebSocket server maintains a persistent open connection with every connected client. Each connection is a file descriptor. So if you have 1024 concurrent users connected to your WebSocket server, you have hit the limit. The 1025th user cannot connect. The kernel will throw a Too many open files error and your server will start rejecting connections.

This is not a bug in your code. It is a system level limit you need to raise.

Raising the Limit

There are two limits to be aware of:

ulimit -n   # soft limit, applies to your current session

To raise it permanently, you edit /etc/security/limits.conf:

*    soft    nofile    65536
*    hard    nofile    65536

The * applies to all users. nofile stands for number of open files. 65536 is a common production value for web servers.

For systemd managed services, you set it directly in the unit file instead:

[Service]
LimitNOFILE=65536

After making these changes, restart the service and verify:

cat /proc//limits

This is one of the first things you tune when deploying a WebSocket server or any high concurrency application in production. A server with default limits will quietly start failing under load, and the logs will tell you exactly why.

Conclusion

In the end, the Linux filesystem is far more than a collection of folders. It reflects a philosophy of simplicity, consistency, and treating system resources through one unified interface.

Once you understand what lives where, Linux stops feeling mysterious and starts feeling logical. And as developers, that understanding gives us a real edge when working with servers, debugging production systems, or simply feeling more at home inside the machines that run the modern web.

Understanding this in JavaScript

Sameer Bhagtani — Wed, 15 Apr 2026 05:00:00 GMT

Introduction

Most JavaScript confusion around this comes from one wrong assumption: that this depends on where a function is defined. It doesn't. It depends on who called the function.

That one shift in thinking makes most of the confusion go away.

What `this` Actually is

this is a reference to the calling context of a function. When a function runs, JavaScript looks at what triggered the call and sets this to that thing.

Not where the function lives in your file. Not which object it belongs to in your source code. Who called it at runtime.

`this` in the Global Context

When you call a plain function with nothing owning it, this falls back to the global object.

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

greet();

In a browser, that logs window. In Node.js, it's global. In strict mode, it's undefined.

Nobody specific called it, so JavaScript picks the default.

`this` Inside an Object

This is where this starts being useful.

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

person.greet(); // Hi, I'm Alice

person is calling greet, so this is person. That's it.

How Calling Context Changes `this`

Here's the part that trips people up. Take the exact same function from above and pull it out of the object:

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

Same function. Different caller. Now nobody owns the call, this falls back to the global object, and name isn't defined there.

This is the source of most this bugs. The function didn't change. The calling context did.

`this` Inside Nested Functions

The problem compounds when you have a function inside a method.

const person = {
    name: 'Alice',
    greet: function () {
        function inner() {
            console.log(this.name); // undefined
        }
        inner();
    }
};

person.greet();

greet is called by person, so this inside greet is person. But inner is called as a plain function with no owner, so this resets to the global object.

A common fix is to capture this before going in:

const person = {
    name: 'Alice',
    greet: function () {
        const self = this;
        function inner() {
            console.log(self.name); // Alice
        }
        inner();
    }
};

Or just use an arrow function, which doesn't have its own this and inherits from the surrounding scope:

const person = {
    name: 'Alice',
    greet: function () {
        const inner = () => {
            console.log(this.name); // Alice
        };
        inner();
    }
};

Arrow Functions Don't Have Their Own `this`

Arrow functions inherit this from wherever they were defined, and nothing can change that.

const person = {
    name: 'Alice',
    greet: () => {
        console.log(this.name); // undefined, always
    }
};

person.greet();

Even though greet is on person, it's an arrow function. this here is whatever this was in the outer scope when the object was created, not person. Arrow functions are great in a lot of situations, but if you need this to refer to the object, use a regular function.

Summary

Where `this` appears	What it refers to
Global function call	Global object (or `undefined` in strict mode)
Object method call	The object before the dot
Nested plain function	Global object (loses the outer `this`)
Arrow function	Inherited from surrounding scope

Once you internalize "who called this function," most this surprises stop being surprises. The function is the same. The caller is what changes.

Map and Set in JavaScript: A Practical Guide

Sameer Bhagtani — Thu, 09 Apr 2026 15:23:00 GMT

Introduction

JavaScript gives you objects and arrays out of the box, and for a long time those two were the default answer to almost every data storage problem. Objects for key-value pairs, arrays for lists. Simple enough.

But both come with quirks that can bite you in real code. Map and Set were added in ES6 specifically to address those quirks. They're not replacements, but they solve certain problems cleaner than their older counterparts.

What Is a Map?

A Map is a collection of key-value pairs, similar to a plain object. The big difference is that a Map accepts any value as a key, not just strings and symbols.

const map = new Map();

map.set('name', 'Alice');
map.set(42, 'the answer');
map.set({ id: 1 }, 'an object key');

console.log(map.get('name')); // 'Alice'
console.log(map.get(42));     // 'the answer'
console.log(map.size);        // 3

Maps also maintain insertion order, iterate predictably, and give you a .size property without any tricks.

What Is a Set?

A Set is a collection of unique values. If you try to add a duplicate, it gets silently ignored. That's pretty much the core feature.

const set = new Set([1, 2, 3, 2, 1]);

console.log(set.size);          // 3
console.log([...set]);          // [1, 2, 3]

set.add(4);
set.delete(1);
console.log(set.has(1));        // false
console.log(set.has(4));        // true

Sets also maintain insertion order when you iterate over them.

Map vs Object: Where Objects Fall Short

Plain objects look like key-value stores, and they mostly work as one. But there are a few real-world gotchas.

Keys are coerced to strings

If you use a number or an object as a key on a plain object, JavaScript quietly converts it to a string. That can cause silent bugs.

const obj = {};
obj[1] = 'one';
obj['1'] = 'overwritten';

console.log(obj[1]); // 'overwritten'

With a Map, the key 1 (number) and '1' (string) are different keys.

Prototype pollution

A plain object comes with inherited properties from Object.prototype. That's usually harmless, but if you're checking for a key with 'toString' in obj, you'll get true even though you never set it.

No built-in size

Getting the number of keys in an object means calling Object.keys(obj).length, which creates a temporary array. A Map just has .size.

Here's a side-by-side:

Feature	Object	Map
Key types	Strings and Symbols only	Any value
Key ordering	Not guaranteed (mostly)	Insertion order
Size	`Object.keys(obj).length`	`map.size`
Prototype pollution	Yes	No
Iteration	`for...in`, `Object.entries()`	`for...of`, `.forEach()`

Use a plain object for structured data with known string keys, like a config or a DTO.
Use a Map when keys are dynamic, non-string, or when you need reliable iteration and size.

Set vs Array: The Duplicate Problem

Arrays are ordered and they allow duplicates. That's fine for most things. But if you have a list that should only contain unique values, an array leaves the enforcement to you.

Say you're tracking which user IDs have been processed:

const processed = [];

function process(id) {
    if (!processed.includes(id)) {
        processed.push(id);
        // do the work
    }
}

That includes check is O(n). Every call scans the whole array. For small lists it doesn't matter. For large ones it starts to hurt.

With a Set:

const processed = new Set();

function process(id) {
    if (!processed.has(id)) {
        processed.add(id);
        // do the work
    }
}

.has() on a Set is O(1). The Set also handles the uniqueness guarantee automatically.

Removing duplicates from an array is another place Sets show up in practice:

const nums = [1, 2, 2, 3, 4, 3, 5];
const unique = [...new Set(nums)];

console.log(unique); // [1, 2, 3, 4, 5]

One line. No filter, no reduce, no external library.

The tradeoff: Sets don't have index access. You can't do set[0]. If you need to access items by position, you still need an array.

Feature	Array	Set
Duplicates	Allowed	Not allowed
Index access	Yes (`arr[0]`)	No
`.has()` / `.includes()`	O(n)	O(1)
Maintaining order	Insertion order	Insertion order
Iteration	Yes	Yes

When to Use Map

Your keys aren't strings. Numbers, objects, functions as keys all work fine.
You're building a lookup table and need reliable size or iteration.
You're concerned about prototype pollution on a plain object.
You need to delete entries frequently. map.delete(key) is cleaner than delete obj.key.

A practical example: caching computed results by object reference.

const cache = new Map();

function getLabel(user) {
    if (cache.has(user)) {
        return cache.get(user);
    }
    const label = `\({user.firstName} \){user.lastName}`;
    cache.set(user, label);
    return label;
}

You can't do that with a plain object. The user object would get coerced to "[object Object]" as a key, and every user would collide.

When to Use Set

You need a unique list of anything.
You're doing frequent membership checks on a large collection.
You want to deduplicate an array quickly.
You're tracking "seen" or "visited" states.

Say you're building a tag input where users can add tags to a post, and you want to make sure the same tag can't be added twice:

const tags = new Set();

tags.add('javascript');
tags.add('webdev');
tags.add('javascript'); // already in there, silently ignored

console.log([...tags]); // ['javascript', 'webdev']
console.log(tags.size); // 2

No manual duplicate check needed. The Set just handles it.

WeakMap and WeakSet

JavaScript also has WeakMap and WeakSet. These are similar to Map and Set, but they hold weak references to their keys (WeakMap) or values (WeakSet). That means if the only reference to an object is inside a WeakMap, the garbage collector can still clean it up.

They're useful for attaching private metadata to objects without preventing garbage collection. But they're not iterable and don't have a .size.

Conclusion

Map and Set aren't exotic features. They're practical tools with real performance and correctness benefits over objects and arrays in specific situations. The key is knowing which situation you're in.

If your keys are dynamic or non-string, reach for Map. If your list needs to stay unique or you're checking membership often, reach for Set. Otherwise, objects and arrays are still perfectly fine.

Destructuring in JavaScript: Write Less, Read More

Sameer Bhagtani — Thu, 09 Apr 2026 13:12:00 GMT

Introduction

Most JavaScript codebases are full of code like this:

const user = { name: "Sara", age: 28, city: "Mumbai" };
const name = user.name;
const age = user.age;
const city = user.city;

Three separate lines to pull three values out of one object. It works, but it's tedious. Destructuring is the cleaner way to do the same thing.

What Destructuring Actually Means

Destructuring is a syntax that lets you unpack values from arrays or properties from objects into individual variables, all in one line. The word sounds more complicated than the concept. You're just telling JavaScript: "grab these specific things and give them their own names."

It showed up in ES6 (2015) and has become one of those features you use constantly once you know it.

Destructuring Arrays

With arrays, destructuring works by position. The first variable gets the first element, the second gets the second, and so on.

Before:

const colors = ["red", "green", "blue"];
const first = colors[0];
const second = colors[1];
const third = colors[2];

After:

const colors = ["red", "green", "blue"];
const [first, second, third] = colors;

Same result, less noise.

Skipping Elements

You can skip positions you don't care about using commas:

const [, second, , fourth] = [10, 20, 30, 40];
console.log(second); // 20
console.log(fourth); // 40

Rest in Arrays

You can grab the first few items and collect the rest into a new array:

const [head, ...tail] = [1, 2, 3, 4, 5];
console.log(head); // 1
console.log(tail); // [2, 3, 4, 5]

The above example makes use of the rest operator. If you do not know about it, checkout this other blog post I wrote on Spread & Rest Operators in JavaScript.

Destructuring Objects

With objects, you match by property name, not position. The variable name has to match the key you want to extract.

Before:

const product = { title: "Notebook", price: 120, stock: 50 };
const title = product.title;
const price = product.price;
const stock = product.stock;

After:

const { title, price, stock } = product;

Same three variables, one line.

Renaming While Destructuring

If you want a different variable name than the property key:

const { title: productName, price: cost } = product;
console.log(productName); // "Notebook"
console.log(cost);        // 120

The syntax reads as "extract title, but call it productName."

Nested Objects

Objects inside objects work too, you just nest the destructuring syntax:

const order = {
    id: 101,
    customer: {
        name: "Raj",
        email: "raj@example.com"
    }
};

const { customer: { name, email } } = order;
console.log(name);  // "Raj"
console.log(email); // "raj@example.com"

Default Values

What happens if the property you're trying to extract doesn't exist? Without a default, you get undefined. With a default, you get a fallback.

const settings = { theme: "dark" };
const { theme, language = "en" } = settings;

console.log(theme);    // "dark"
console.log(language); // "en"

language wasn't in settings, so the default kicked in. This works for arrays too:

const [a = 0, b = 0] = [5];
console.log(a); // 5
console.log(b); // 0

Defaults only apply when the value is undefined, not when it's null or 0 or an empty string.

Where This Shows Up in Real Code

Function Parameters

This is probably the most common use. Instead of pulling properties out at the start of every function:

// Before
function greet(user) {
    const name = user.name;
    const age = user.age;
    console.log(`\({name} is \){age} years old`);
}

// After
function greet({ name, age }) {
    console.log(`\({name} is \){age} years old`);
}

The function signature now tells you exactly what it needs. That's a real improvement when you're reading unfamiliar code.

Swapping Variables

Without destructuring, swapping two variables needs a temp:

let x = 1, y = 2;
let temp = x;
x = y;
y = temp;

With destructuring:

let x = 1, y = 2;
[x, y] = [y, x];

Returning Multiple Values from a Function

Functions can only return one thing, but that thing can be an array or object. Destructuring makes unpacking the result clean:

function getMinMax(arr) {
    return { min: Math.min(...arr), max: Math.max(...arr) };
}

const { min, max } = getMinMax([3, 1, 7, 2, 9]);
console.log(min); // 1
console.log(max); // 9

Why It Matters

The real benefit isn't that destructuring saves a few lines. It's that code becomes easier to scan. When you see const { name, age } = user at the top of a function, you immediately know what data that function works with. You don't have to trace through user.this and user.that scattered across 20 lines.

It also reduces the chance of typos. Writing user.nmae is easy to miss. Destructuring once at the top and using name everywhere after that gives you one place where a typo can happen instead of many.

That said, don't destructure everything just because you can. For a one-off property access, user.name is perfectly readable. Destructuring earns its place when you're using multiple properties, passing them into functions, or cleaning up function parameters.

Error Handling in JavaScript: Try, Catch, Finally

Sameer Bhagtani — Thu, 09 Apr 2026 08:42:00 GMT

Introduction

You write some code. It looks right. You run it, and instead of the output you expected, the browser throws a red wall of text and the whole script stops dead. That's a runtime error, and if you haven't planned for it, your user just saw a broken page.

JavaScript has a structured way to handle this: the try...catch...finally block. It's not glamorous, but understanding it properly will save you a lot of late-night debugging.

What Errors Actually Are

JavaScript has several built-in error types. You'll run into these most often:

ReferenceError: accessing a variable that doesn't exist
TypeError: calling something that isn't a function, or reading a property off null
SyntaxError: malformed code (usually caught before runtime)
RangeError: a value that falls outside an allowed range

Here's a classic example:

const user = null;
console.log(user.name); // TypeError: Cannot read properties of null

JavaScript tries to access .name on null, fails, and throws an error. Without any handling, execution stops right there. Everything below that line never runs.

The try and catch Blocks

The try block wraps code that might fail. If it does, execution jumps to catch, which receives the error as an argument.

try {
    const user = null;
    console.log(user.name);
} catch (error) {
    console.log("Something went wrong:", error.message);
}

The script no longer crashes. Instead of a red wall of text, you get a controlled message. That's what "graceful failure" means in practice. Not pretending errors don't happen, just deciding what to do when they do.

The error object has a few useful properties:

error.message: a human-readable description
error.name: the type of error ("TypeError", "ReferenceError", etc.)
error.stack: the full call stack, useful for debugging

Getting into the habit of logging error.stack (not just error.message) during development will show you exactly where things went wrong, including the file and line number.

The finally Block

finally runs no matter what, whether the try block succeeded, threw an error, or even hit a return statement.

function fetchData() {
    try {
        // simulate a risky operation
        const data = JSON.parse("invalid json {{{");
        return data;
    } catch (error) {
        console.log("Failed to parse:", error.message);
    } finally {
        console.log("Cleanup done.");
    }
}

The finally block is where you put cleanup code: closing a database connection, hiding a loading spinner, releasing a lock. Stuff that needs to happen regardless of whether the operation worked.

A common real-world pattern looks like this:

async function loadUser(id) {
    showSpinner(true);
    try {
        const response = await fetch(`/api/users/${id}`);
        const user = await response.json();
        renderUser(user);
    } catch (error) {
        showErrorMessage("Could not load user.");
    } finally {
        showSpinner(false);
    }
}

The spinner always gets hidden. It doesn't matter if the fetch succeeded or failed. Without finally, you'd need to call showSpinner(false) in both the try and the catch, and you'd inevitably miss a case.

Throwing Custom Errors

JavaScript lets you throw your own errors with the throw keyword. You can throw a string, a number, or an object, but the cleanest approach is to throw an actual Error instance so you get a stack trace.

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

try {
    const result = divide(10, 0);
} catch (error) {
    console.log(error.message); // "Division by zero is not allowed."
}

You can also extend the built-in Error class to create named custom errors. This is useful when you want to handle different error types differently:

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

function validateAge(age) {
    if (typeof age !== "number") {
        throw new ValidationError("Age must be a number.");
    }
    if (age < 0 || age > 120) {
        throw new ValidationError("Age must be between 0 and 120.");
    }
}

try {
    validateAge("twenty");
} catch (error) {
    if (error instanceof ValidationError) {
        console.log("Validation failed:", error.message);
    } else {
        throw error; // re-throw unexpected errors
    }
}

Notice the re-throw at the end. If the error isn't a ValidationError, you probably don't know how to handle it, so let it bubble up. Swallowing all errors silently is one of the more frustrating bugs to track down, because nothing tells you something went wrong.

Why Error Handling Matters

There are three practical reasons to get this right.

Your users get a better experience

A caught error can show a friendly message or a fallback UI. An uncaught one shows nothing, or breaks the page mid-render.

Debugging gets easier

When you log errors consistently, you build a trail. Adding something like console.error(error.stack) in your catch blocks gives you a line number and a call path, not just a vague failure.

Your app keeps running

An unhandled error in one place can cascade and break unrelated parts of the page. Containing it means the rest of your code still works.

Handling Async Err

One thing worth knowing: try...catch only catches synchronous errors by default. For async code, you need to use it inside an async function with await, or chain .catch() on a promise. Forgetting this is a common source of "my error handler isn't catching anything" confusion.

// This does NOT catch the rejection:
try {
    fetch("/api/data"); // not awaited
} catch (error) {
    console.log("This never runs");
}

// This DOES:
try {
    const response = await fetch("/api/data");
} catch (error) {
    console.log("Network error:", error.message);
}

Conclusion

Error handling isn't about anticipating every possible failure. It's about deciding, ahead of time, what your code should do when something goes wrong. The try block says "try this." The catch block says "if it breaks, do this instead." The finally block says "either way, do this."

That structure alone handles most of the cases you'll encounter. Custom errors and re-throwing handle the rest.

JavaScript Modules: Import and Export Explained

Sameer Bhagtani — Sun, 05 Apr 2026 06:23:00 GMT

Introduction

Picture a codebase from five years ago. One file. Maybe two. A couple of

Sameer's Dev Log

React Virtual DOM Explained: How It Works Under the Hood

Introduction

The Problem with Direct DOM Manipulation

What the Virtual DOM Actually Is

Hello

Step 1: The Initial Render

Step 2: Something Changes

Step 3: Diffing (Reconciliation)

Step 4: The Commit Phase

The Full Flow

Is the Virtual DOM Always Worth It?

Conclusion

Behind the Root: Linux Filesystem Demystified

Introduction

The Core Philosophy: Everything is a File

Filesystem Hierarchy Standard (FHS)

The Problem it Solves

The Root Directory

/etc: System Configuration Hub

Password Storage

/etc/passwd

/etc/shadow

Groups

Default Groups

DNS Configuration

/etc/hosts

/etc/resolv.conf

/etc/nsswitch.conf

The full DNS resolution flow

Network Interface Configuration

Service Configurations

What does a unit file look like?

Enabling vs Starting

Where do default unit files live then?

/proc: The Process Filesystem

Routing Tables

System Logs

Reading logs

What insights do logs actually give you?

File Descriptors

Everything is a File Descriptor

The Default Limit and Why it Matters

The WebSocket Problem

Raising the Limit

Conclusion

Understanding this in JavaScript

Introduction

What this Actually is

this in the Global Context

this Inside an Object

How Calling Context Changes this

this Inside Nested Functions

Arrow Functions Don't Have Their Own this

Summary

Map and Set in JavaScript: A Practical Guide

Introduction

What Is a Map?

What Is a Set?

Map vs Object: Where Objects Fall Short

Keys are coerced to strings

Prototype pollution

No built-in size

Set vs Array: The Duplicate Problem

When to Use Map

When to Use Set

WeakMap and WeakSet

Conclusion

Destructuring in JavaScript: Write Less, Read More

Introduction

What Destructuring Actually Means

Destructuring Arrays

Skipping Elements

Rest in Arrays

Destructuring Objects

Renaming While Destructuring

Nested Objects

Default Values

Where This Shows Up in Real Code

Function Parameters

`/etc`: System Configuration Hub

`/etc/passwd`

`/etc/shadow`

`/etc/hosts`

`/etc/resolv.conf`

`/etc/nsswitch.conf`

`/proc`: The Process Filesystem

What `this` Actually is

`this` in the Global Context

`this` Inside an Object

How Calling Context Changes `this`

`this` Inside Nested Functions

Arrow Functions Don't Have Their Own `this`