DEV Community: Janmejai Singh

How WhatsApp Works Without Internet: Offline Messaging and Sync Explained

Janmejai Singh — Sun, 31 May 2026 15:43:09 +0000

You're on a train, signal drops to zero. You type a message and hit send. A single grey tick appears.

Then — the moment you exit the tunnel — two ticks appear.

How did that work? You were offline.

This isn't magic. It's offline-first architecture, and it's one of the most practical ideas in mobile engineering. Let's break it down.

The Scenario: Sending a Message in Airplane Mode

Imagine you toggle airplane mode and type:

"Just took off. Landing in 3 hours!"

WhatsApp doesn't show an error. It doesn't freeze. You see a message bubble with one grey tick.

Here's what actually happened:

The app saved your message to a local database on your phone
It added the message to an outgoing queue
It rendered the message immediately in the UI — no waiting
It set the internal status to PENDING

Your message never touched a server. The app made a promise to deliver it when connectivity returns. That promise — that optimistic local-first action — is the heart of offline-first design.

Local Storage and Message Persistence

Every message is first written to a local SQLite database on the device, before anything goes to the cloud.

WhatsApp uses SQLite. Android apps use Room. iOS apps use Core Data. In React Native, you'd reach for expo-sqlite or @op-engineering/op-sqlite.

A simplified message record looks like this:

CREATE TABLE messages (
  id              TEXT PRIMARY KEY,  -- Generated on device, not server
  conversation_id TEXT NOT NULL,
  content         TEXT NOT NULL,
  created_at      INTEGER NOT NULL,  -- Device timestamp
  status          TEXT DEFAULT 'PENDING',
  media_uri       TEXT,              -- Local file path for media
  server_ack_id   TEXT               -- Set after server confirms receipt
);

Two things worth noting:

The ID is generated on the device, so WhatsApp can display the message before the server even knows it exists.
Status starts as PENDING — honest, explicit, and essential for the queue system.

The UI reads from local storage. It never waits for the network.

The Message Queue

When a message is saved locally, it also enters an outgoing queue — a persistent list of things the app needs to send when it can.

┌──────────────────────────────────────┐
│         OUTGOING MESSAGE QUEUE       │
│  [msg_001] "Just took off..." PENDING│
│  [msg_002] "See you soon!" PENDING   │
│  [msg_003] photo.jpg       PENDING   │
└──────────────────────────────────────┘
         ↕  No internet — held on device

This queue is written to disk, not held in RAM. If the app crashes, the queue survives. When internet returns, the app processes messages in order, retrying failures with exponential backoff (1s → 2s → 4s → ...) to handle flaky connections gracefully.

Syncing When Connectivity Returns

The moment internet returns, the app fires off four steps almost simultaneously:

Internet returns
      │
      ▼
1. Flush outgoing queue  →  Send all pending messages to server
      │
      ▼
2. Pull missed messages  →  Fetch messages sent to YOU while offline
      │
      ▼
3. Reconcile local DB    →  Merge server state with local state
      │
      ▼
4. Update the UI         →  Ticks change, new messages appear

Step 1 — Each queued message is sent to WhatsApp's servers. The server acknowledges receipt and the status upgrades from PENDING to SENT.

Step 2 — People may have messaged you while you were offline. The app requests everything from the server since the last sync timestamp.

Step 3 — Local DB is updated with what came from the server.

Step 4 — Because the UI observes the local DB reactively, everything updates automatically. No manual refresh needed.

Delivery States: Sent, Delivered, Read

The tick system maps directly to a message state machine:

[PENDING] → [SENT] → [DELIVERED] → [READ]
  clock      1 grey    2 grey        2 blue
              tick      ticks         ticks
     └──────→ [FAILED] (retries exhausted)

State	What it means
Pending	Saved locally, not yet on server
Sent	Server received it
Delivered	Recipient's device has it
Read	Recipient opened the conversation
Failed	Couldn't deliver after all retries

State transitions are triggered by acknowledgements (acks) from the server or recipient's device via a persistent connection.

Why separate "Sent" from "Delivered"? Because the server having your message ≠ the recipient's phone having it. They could be offline too.

Handling Media While Offline

Text messages are tiny. Photos and videos are not. WhatsApp handles this with a decoupled upload strategy:

Capture & save locally — photo is stored on device
Queue the message with a local file reference (local://img_001.jpg)
Upload media in background when internet returns
Server returns a CDN URL — message record updates from local:// to https://mmg.whatsapp.net/...
Recipient downloads on demand — they get the URL and fetch media lazily

This is why you sometimes see a blurred thumbnail or "Waiting for media" — the text message arrived, but media hasn't been downloaded yet.

Conflict Resolution and Message Ordering

What happens when messages arrive out of order after going offline?

The problem: Device clocks are unreliable. Your phone might be 30 seconds off, or in the wrong timezone. If WhatsApp trusted device timestamps alone, messages could appear out of order.

The solution:

Server-assigned timestamps — when a message reaches the server, it gets a canonical timestamp used for ordering
Sequence numbers — monotonically increasing numbers break ties between messages with identical timestamps
Last-write-wins for status — message status can only move forward (SENT → DELIVERED, never backwards)

This is a simplified form of eventual consistency:

The system doesn't guarantee every device sees the same state at the same instant. But given time and connectivity, all devices converge on the same state.

For messaging, this is an acceptable tradeoff. A message appearing 200ms out of order is fine. A message that never appears is not.

Why Offline-First Matters

Traditional approach:

User action → Network request → Update UI (only if network works)

Offline-first approach:

User action → Update local DB → Update UI → Background sync to server

The difference in feel is enormous.

Traditional (online-first)	Offline-first
Broken without internet	Works fully offline
User waits on every action	Instant UI feedback
Lost actions on failure	Queue retries automatically
Spinner on every tap	Smooth always
Terrible on slow networks	Great on any network

The tradeoffs are real though:

Conflict resolution becomes your responsibility
Local data needs encryption (WhatsApp uses SQLCipher)
Testing network edge cases is harder
Storage management (when do you purge old queued messages?)

The Full Lifecycle in One Diagram

User types and hits send
        ↓
App generates local ID
        ↓
Saved to SQLite (PENDING)
        ↓
Added to outgoing queue
        ↓
UI renders immediately (optimistic update)
        ↓
─── [Internet returns] ───────────────────
        ↓
Queue flushed → sent to server
        ↓
Server acks → status: SENT (1 grey tick ✓)
        ↓
Recipient's device comes online → delivered
        ↓
Delivery ack → status: DELIVERED (2 grey ✓✓)
        ↓
Recipient opens chat → read receipt sent
        ↓
Read ack → status: READ (2 blue ✓✓) ✅

Building This in React Native

Here's the toolkit you'd reach for:

Need	Library
Local DB	`expo-sqlite` or `@op-engineering/op-sqlite`
Fast key-value (queue)	`react-native-mmkv`
Network state	`@react-native-community/netinfo`
Background sync	`expo-task-manager` + background fetch
Real-time acks	`socket.io-client` or Firebase RTDB

The pattern is always: local first → background sync → UI driven by local state.

Key Takeaways

WhatsApp never waits for the network — it writes locally and syncs later
The outgoing queue persists to disk and survives crashes
Delivery states (PENDING → SENT → DELIVERED → READ) are driven by server and device acks
Media uploads are decoupled from text — text queues fast, media uploads in background
Server-side timestamps and sequence numbers resolve ordering conflicts
Offline-first trades implementation complexity for much better UX

What to Explore Next

WatermelonDB — a React Native DB built specifically for offline-first at scale
CRDTs — the math behind conflict-free sync
Firebase Firestore offline persistence — a managed offline-first solution
XMPP / MQTT — the protocols behind real-time messaging

Next time you see those grey ticks turn blue on a plane with spotty Wi-Fi, you'll know exactly what just happened. 🛫

Found this useful? Drop a ❤️ and share it with your dev cohort!

How Instagram, WhatsApp, Uber & Netflix Would Be Built Today Using Expo Router

Janmejai Singh — Sun, 31 May 2026 14:21:55 +0000

You tap Record. You nail the take. You save as Draft. You close Instagram, reopen it — and your Reel is right there. What just happened under the hood?

This post traces that full journey: from your device's camera buffer to your follower's screen halfway across the world. We'll cover local storage, drafts, cloud uploads, media processing, caching, and CDNs — with diagrams at each stage.

Why Social Media Apps Need Efficient Media Storage

Photos and videos are the heaviest assets any mobile app handles. A single 60-second Reel captured at 1080p can be 200–400MB before any compression. Multiply that by a billion daily uploads and you begin to understand why media storage is not a solved problem — it's an ongoing engineering discipline.

Efficiency matters at three levels:

Device level — local storage is limited; apps can't balloon in size
Network level — large uploads over mobile connections are fragile and slow
Cloud level — storing, processing, and serving billions of files requires distributed systems

Instagram's architecture solves each of these with different tools, layered together.

How Photos and Videos Are Stored Before Upload

When you record a Reel, the app doesn't immediately try to upload it. Your device is the first storage layer.

The recording pipeline looks like this:

Camera Sensor
     ↓
In-Memory Frame Buffer  ← (active recording, fast but volatile)
     ↓
Local Temp Cache        ← (flushed from buffer, survives brief interruptions)
     ↓
User Decision Point
  ├── Discard → Delete temp files
  ├── Save Draft → Move to persistent storage
  └── Post → Enqueue for upload

Why local-first?

Three reasons:

Networks are unreliable — especially on cellular. Streaming raw video directly to a cloud server mid-recording is a recipe for data loss.
User intent is unknown — the app doesn't know you'll keep the clip until you decide.
Upload costs — uploading every test take wastes bandwidth, battery, and server resources.

Local storage on mobile comes in different tiers:

Tier	Speed	Persistence	Cleared by
RAM buffer	Fastest	Lost on kill	OS memory pressure
Cache directory	Fast	Semi-persistent	OS under storage pressure
Documents directory	Fast	Persistent	Only explicit delete

Active recordings live in the cache. Once you decide to keep them — as a draft or a post — they move to the documents directory.

What Happens When a User Saves a Draft

A draft isn't just a video file. It's a bundle of state that must survive app restarts:

The raw video clip(s)
Applied audio track (and timestamp offset)
Stickers, text overlays, and their screen positions
Trim start/end points
Filter and effect choices
Selected thumbnail frame

When you tap "Save Draft," Instagram performs a transactional write:

1. Write video file to documents directory
2. Write metadata record to local SQLite database
   (file path, audio, effects, trim points, etc.)
3. Confirm both writes succeeded
4. Show "Draft Saved" confirmation

Either both writes succeed or neither is surfaced to the user. This is critical — a draft pointing to a missing file, or a video file with no matching metadata record, is worse than no draft at all.

How drafts survive app restarts:

On launch, Instagram queries the SQLite database for all draft records. For each record, it reads the stored file path and reconstructs the preview. No network call needed. The entire drafts tray is built from local data.

App Launch
    ↓
Query SQLite: SELECT * FROM drafts ORDER BY updated_at DESC
    ↓
For each row: read video file at stored path → generate thumbnail
    ↓
Render Drafts tray

Local Storage vs. Cloud Storage

These two worlds have opposite strengths:

┌──────────────────────────┬──────────────────────────┐
│     LOCAL STORAGE        │     CLOUD STORAGE        │
├──────────────────────────┼──────────────────────────┤
│ ✅ Near-zero latency     │ ✅ Unlimited scale        │
│ ✅ Works offline         │ ✅ Durable (replicated)   │
│ ✅ No network dependency │ ✅ Accessible everywhere  │
│ ❌ Limited capacity      │ ❌ Network dependent      │
│ ❌ Lost if device lost   │ ❌ Slower (network I/O)   │
│ ❌ Single device only    │ ❌ Costs money at scale   │
└──────────────────────────┴──────────────────────────┘

Instagram's architecture uses both — local for speed and offline capability, cloud for durability and sharing. The transition point is the upload pipeline.

Uploading Large Media Files Efficiently

Uploading a 200MB video over cellular as one HTTP POST is a terrible idea. One dropped packet and you start over. Instagram avoids this with two techniques:

1. Chunked / Resumable Uploads

The file is split into small chunks (e.g., 5MB each). Each chunk is uploaded independently. If a chunk fails, only that chunk retries.

Full Video: 200MB
 ├── Chunk 01 (5MB) → ✅
 ├── Chunk 02 (5MB) → ✅
 ├── Chunk 03 (5MB) → ❌ (network drop)
 │       └── Retry Chunk 03 → ✅
 ├── Chunk 04 (5MB) → ✅
 └── ... 36 more chunks

Server-side, the chunks are tracked by upload session ID. Once all are received, the server reassembles them in order.

2. Background Uploads

After you tap Post, you don't have to wait in the app. The upload continues in the background using OS-level transfer APIs:

iOS: URLSession with .background configuration
Android: WorkManager or JobScheduler

These transfers are managed by the operating system, not the app. They survive the app being backgrounded or even force-quit, and resume automatically when connectivity returns.

The Upload Queue

A local queue tracks upload status for each piece of media:

PENDING → IN_PROGRESS → COMPLETED
              ↓
           PAUSED (network lost)
              ↓
           RETRYING
              ↓
           FAILED (max retries hit)

This queue state is persisted to SQLite, so if the app is killed mid-upload, it knows exactly where to resume.

Media Processing and Compression

Once your raw video lands in Instagram's cloud, it enters a processing pipeline before being stored for delivery.

Raw Upload Received
        ↓
Validation
(corrupt file check, content policy scan, format verification)
        ↓
Transcoding
(re-encode to H.264/H.265, normalize codec/container)
        ↓
Multi-Resolution Encoding
(1080p, 720p, 480p, 360p — for adaptive bitrate streaming)
        ↓
Audio Processing
(normalize levels, validate sync)
        ↓
Thumbnail Extraction
(keyframe analysis + ML quality scoring)
        ↓
Distribute to Storage + CDN

Compression Concepts

Raw uploads are transcoded to significantly smaller files without noticeable quality loss:

Codec efficiency: H.265 (HEVC) compresses ~40% better than H.264 at equal visual quality
Variable Bitrate (VBR): Static scenes get fewer bits; fast-moving scenes get more — no bits wasted
Perceptual encoding: Human vision is less sensitive to chroma (color) detail than luma (brightness), so color channels are compressed more aggressively

A 200MB raw Reel might become a 12–20MB streamable video after processing.

Thumbnail Generation and Previews

Thumbnails are more than decoration — they're a performance optimization.

A thumbnail is a single JPEG, typically under 50KB, that can be fetched and displayed in milliseconds. Without thumbnails, every feed scroll would require pre-buffering video before anything appeared on screen.

How Thumbnails Are Created

During the processing pipeline:

Multiple keyframes are extracted from the video at regular intervals
Each keyframe is scored by an ML model for visual quality (avoiding blurry, over-exposed, or mid-blink frames)
The highest-scoring frame is selected (or the creator's manually chosen frame is used if available)
The selected frame is saved as a separate JPEG in object storage

Low-Quality Image Placeholders (LQIP)

Instagram also generates a tiny blur placeholder — sometimes just 20x20 pixels encoded as a base64 string in the API response. This renders instantly (before any network request for the actual thumbnail) and gives the feed a fluid scrolling feel even on slow connections.

Feed item appears
     ↓
Base64 blur hash renders (immediate — no network)
     ↓
Full thumbnail fetched from CDN (50–200ms)
     ↓
Swap: blur → thumbnail
     ↓
User taps play → ABR video stream begins

Caching Frequently Viewed Content

Every content request has a cost: network latency, server load, battery usage. Caching short-circuits that cost by keeping a local copy of recently used content.

Multi-Level Cache Architecture

Request for content
        ↓
Memory cache (L1) → HIT → Render (~0ms)
        ↓ MISS
Disk cache (L2)   → HIT → Render + promote to L1 (~5–20ms)
        ↓ MISS
CDN Edge          → HIT → Render + store in L2 (~30–100ms)
        ↓ MISS
Origin Storage    → Fetch → Render + propagate to CDN + store in L2

What Gets Cached

Content Type	Cache Location	TTL
Profile pictures	Disk (long TTL)	Days
Feed thumbnails	Disk (medium TTL)	Hours
Active video buffers	Memory	Session only
Stories (viewed)	Disk (short TTL)	Until expiry
Prefetched posts	Disk	Minutes

Prefetching: Getting Ahead of the User

While you're watching post #3, Instagram is already fetching thumbnails and initial video buffers for posts #6–10 in your feed. This makes scrolling feel instantaneous — by the time your thumb reaches those posts, the content is already on your device.

Prefetching is throttled by connection quality: aggressive on Wi-Fi, conservative on 4G, minimal on 3G.

Cache Invalidation

Knowing when to throw away cached content is hard. Instagram's approach:

TTL (Time-to-Live): Cached items expire after a configured duration
Cache-Control headers: Server communicates max-age per content type
Versioned URLs: When content changes (e.g., profile photo update), the URL hash changes, forcing a fresh fetch

Content Delivery Using CDNs

Your followers in Tokyo, Lagos, and Berlin all load your Reel at similar speeds because Instagram doesn't serve media directly from a central data center — it uses a Content Delivery Network.

How CDN Delivery Works

User in Tokyo requests Reel video
           ↓
DNS resolves to nearest CDN edge node (Tokyo)
           ↓
Edge node checks local cache
  ├── HIT → Serve immediately (low latency)
  └── MISS → Fetch from origin → Cache locally → Serve
           ↓
Response travels <50ms vs ~200ms from US origin

Meta operates its own CDN infrastructure alongside partnerships with commercial CDN providers. Edge nodes are placed in internet exchange points worldwide to minimize the physical distance content must travel.

Adaptive Bitrate Streaming (ABR)

Instagram doesn't just serve one video file — it serves a manifest file (HLS or DASH format) that lists multiple quality variants. Your device's player selects the appropriate variant based on real-time network conditions:

Excellent connection → 1080p @ 8Mbps
Good connection      → 720p  @ 4Mbps
Fair connection      → 480p  @ 2Mbps
Poor connection      → 360p  @ 800Kbps

If your connection degrades mid-playback, the player seamlessly switches to a lower quality tier without rebuffering — you see slightly less detail, but playback continues uninterrupted.

Managing Storage, Performance, and User Experience

All of these systems involve tradeoffs. More aggressive caching = faster loads but higher device storage use. More compression = smaller files but potential quality loss. More CDN edge nodes = lower latency but higher infrastructure cost.

Device Storage Management

Instagram's client periodically runs cache eviction to prevent disk bloat:

LRU eviction: Least-recently-used content is removed first
Size caps: Cache directories are bounded to a maximum size
OS pressure response: When device storage is low, the OS may clear cache directories without asking

Drafts are immune to OS-level eviction because they live in the documents directory — only explicit deletion removes them.

Adaptive Behavior Based on Context

Condition	System Response
On Wi-Fi	Aggressive prefetch, high quality, run pending uploads
On cellular	Conservative prefetch, adaptive quality, throttle background work
Low battery	Pause non-critical background tasks
Storage low	Evict cache aggressively, warn user if drafts at risk
App in background	Continue uploads, pause prefetching

Full Architecture: End-to-End

Let's map the complete journey from recording to playback:

┌─────────────────────────────────────────────────────────────────┐
│  DEVICE                                                          │
│  Record → Frame Buffer → Temp Cache                             │
│  Edit/Draft → Documents Dir + SQLite                            │
│  Post → Upload Queue → Chunked Upload (background)             │
└────────────────────────────┬────────────────────────────────────┘
                              │ HTTPS chunks
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│  INSTAGRAM CLOUD                                                 │
│  Ingest API → Reassemble → Validation → Processing Pipeline     │
│  Transcode + Compress + Multi-res → Thumbnails → Object Storage │
└────────────────────────────┬────────────────────────────────────┘
                              │ Push to edge
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│  CDN EDGE NETWORK                                               │
│  Edge Node (Tokyo) │ Edge Node (London) │ Edge Node (São Paulo) │
└───────────┬─────────────────┬───────────────────┬──────────────┘
            │                 │                   │
            ▼                 ▼                   ▼
       Viewer (JP)       Viewer (UK)        Viewer (BR)
   ABR stream → cache   ABR stream → cache  ABR stream → cache

Key Takeaways for Mobile Developers

Building a React Native app with media features? Steal these patterns:

Local-first: Always write to local storage before assuming network success
Atomic draft saves: Video file + metadata must succeed together or both fail
Chunked uploads: Never send large files as single requests; build retry logic per chunk
Background transfers: Use OS-level APIs, not in-app timers
Queue your uploads: Persist queue state to SQLite; recover from kills gracefully
Multi-level caching: Memory + disk + prefetch = fast perceived performance
CDN for media, API for metadata: Your app servers shouldn't serve video files
Adaptive quality: Detect connection quality and degrade gracefully

Wrapping Up

What looks like a simple "save" or "post" action is actually a cascade of decisions made across every layer of the stack: memory buffers, SQLite databases, upload queues, processing pipelines, object storage, CDN edge networks, and device-side caches.

Understanding this architecture helps you build mobile apps that feel fast, handle failures gracefully, and respect your users' devices and data connections. Architecture and product thinking are inseparable — every engineering decision is ultimately a UX decision.

What would you like to explore next — building a resumable upload queue in React Native, implementing multi-level caching, or designing a local draft system? Let me know in the comments!

How React's Virtual DOM Works Under the Hood

Janmejai Singh — Thu, 21 May 2026 16:32:54 +0000

How React's Virtual DOM Works Under the Hood

You've heard it a hundred times: "React uses a Virtual DOM for performance."

But what does that actually mean?

In this article, we'll trace exactly what happens from the moment you call setState() to the moment you see pixels update on screen — no hand-waving, no magic, just the mental model that unlocks everything else in React.

Let's dig in. 🛠️

The Problem: Why Direct DOM Manipulation Is Slow

Before we understand the solution, we need to understand the problem.

The browser's DOM (Document Object Model) is a live, tree-shaped object that represents your HTML page. Whenever JavaScript changes a DOM node, the browser has to do expensive work:

Style recalculation — which CSS rules now apply?
Layout / Reflow — what is every element's new size and position?
Repaint — what pixels need to be redrawn?

Direct DOM Update:
─────────────────
JS writes to DOM
     │
     ▼
Style Recalc → Layout (Reflow) → Paint → Composite
                    ↑
               ALL of this, potentially,
               for a single text change 😬

This is fine for occasional updates. But modern web apps update the UI constantly — typed characters, live data feeds, animations. At high frequency, direct DOM manipulation becomes a bottleneck that shows up as janky, sluggish UIs.

The Solution: Virtual DOM as a Lightweight Proxy

React introduces the Virtual DOM: a plain JavaScript representation of the UI tree that exists purely in memory, completely decoupled from the browser's rendering engine.

// This is a Virtual DOM node. It's just a JS object.
{
  type: 'button',
  props: {
    className: 'btn-primary',
    onClick: handleClick,
    children: 'Click me'
  }
}

Creating this object costs almost nothing. No browser APIs. No layout. No paint. It's just memory allocation.

React's insight: compute changes cheaply in JS-land first, then apply the minimal real-DOM mutations in one go.

Step 1 — Initial Render

When your app first loads:

JSX / Components
      │
      │  (Babel compiles JSX to React.createElement calls)
      ▼
Virtual DOM Tree
(plain JS objects, built entirely in memory)
      │
      │  (React walks the tree and creates real nodes)
      ▼
Real DOM  ←  User sees the UI ✅

React calls your component functions, collects the returned JSX (which becomes React.createElement() calls), and assembles a full Virtual DOM tree. It then makes a single full pass to create and insert real DOM nodes.

This is the only time React builds the entire DOM from scratch.

Step 2 — State or Props Change

Something triggers an update:

const [count, setCount] = useState(0);

// Button clicked:
setCount(count + 1);  // 🔔 React queues a re-render

setCount doesn't immediately update the DOM. React schedules an update and may batch it with other pending updates for efficiency. Then it moves into the render phase.

Step 3 — New Virtual DOM Tree is Created

React re-runs your component function with the new state. The result is a brand new Virtual DOM tree in memory:

 OLD Virtual DOM          NEW Virtual DOM
 ───────────────          ───────────────
 <div>                    <div>
   <h1>Score</h1>   vs      <h1>Score</h1>
   <span>0</span>           <span>1</span>  ← CHANGED
   <button>+</button>       <button>+</button>
 </div>                   </div>

Both trees exist in memory simultaneously. React needs to figure out what's different.

Step 4 — Diffing (Reconciliation)

React's diffing algorithm compares the two trees node-by-node to produce a minimal change set.

Comparing node by node:

  <div>        ✅ Same type → keep, recurse into children
  <h1>Score</h1>  ✅ Same type, same props → NO CHANGE
  <span>       ✅ Same type → check props
    "0" → "1"  ❌ Text content changed → MARK FOR UPDATE
  <button>+</button>  ✅ Same type, same props → NO CHANGE

Change set: [ updateTextContent(spanNode, "1") ]

React uses two key heuristics to keep this efficient:

Different element types → rebuild the subtree

If a <div> becomes a <section> at the same position, React doesn't try to reuse it. It destroys the old subtree and builds a new one.

Keys → stable identity for list items

// ❌ Bad — React can't tell which item is which after reorder
{items.map(item => <li>{item.name}</li>)}

// ✅ Good — React can match, reuse, and correctly update items
{items.map(item => <li key={item.id}>{item.name}</li>)}

Keys let React correlate old list nodes with new ones. Without them, React might destroy and re-create nodes it could have reused — wasting work and losing local state (like focus or scroll position).

Step 5 — Commit Phase: Minimal Real DOM Updates

Once the diff is done, React enters the commit phase — the only point where it writes to the real DOM:

Change set from diff:
┌──────────────────────────────────────┐
│  • Update text of <span>: 0 → 1     │
│  (1 operation total)                 │
└──────────────────────────────────────┘
         │
         ▼
  Real DOM ← only the <span>'s text node is touched
  Everything else: untouched, no reflow triggered 🎯

Compare this to a naive approach that re-renders the entire list after every keystroke. With React, only the nodes that actually changed are touched.

Why This Improves Performance

Approach	What Happens on Update
Direct DOM manipulation	Write immediately → browser reflows everything potentially affected
React Virtual DOM	Diff in memory → write only changed nodes → minimal browser work

The Virtual DOM isn't magic. Creating JS objects has a cost too. The real win is batching and minimization: React figures out the cheapest path from the current UI to the desired UI, then executes it in one optimized burst.

The Full Lifecycle — Visual Summary

┌────────────────────────────────────────────────────────┐
│            REACT: RENDER → DIFF → COMMIT               │
│                                                        │
│  setState() / new props                                │
│       │                                                │
│       ▼                                                │
│  ┌─────────────────────────────────────┐               │
│  │         RENDER PHASE                │               │
│  │  Component functions run            │               │
│  │  New Virtual DOM tree built         │               │
│  └──────────────┬──────────────────────┘               │
│                 │                                      │
│                 ▼                                      │
│  ┌─────────────────────────────────────┐               │
│  │      RECONCILIATION (DIFF) PHASE    │               │
│  │                                     │               │
│  │  Old VDOM ◄──── compared ────► New VDOM             │
│  │  Minimal change set computed        │               │
│  └──────────────┬──────────────────────┘               │
│                 │                                      │
│                 ▼                                      │
│  ┌─────────────────────────────────────┐               │
│  │         COMMIT PHASE                │               │
│  │  Only changed nodes written to DOM  │               │
│  │  useLayoutEffect runs               │               │
│  └──────────────┬──────────────────────┘               │
│                 │                                      │
│                 ▼                                      │
│  Browser paints minimal changes ✅                     │
│  useEffect runs                                        │
└────────────────────────────────────────────────────────┘

Quick Reference: Key Concepts

Concept	What It Means
Virtual DOM	Plain JS object tree mirroring the UI — cheap to create
Re-render	React calling your component function again to get new VDOM
Diffing	Comparing old VDOM vs new VDOM to find changes
Reconciliation	The full process: diff + decide what to update
Commit	The moment React writes to the real DOM
Key	Stable identity hint for list items during diffing

Things to Know (But Out of Scope Here)

React Fiber — React's internal concurrent scheduler that adds priority lanes and time-slicing on top of this model
React 18 Concurrent Mode — useTransition and useDeferredValue let you mark updates as non-urgent
React.memo — skips re-render (and therefore skips VDOM creation) when props haven't changed

Wrapping Up

React's Virtual DOM is elegant in its simplicity: represent the UI as cheap JS objects, compare states, compute minimal mutations, apply them. The render → diff → commit pipeline is the foundation of React's performance story — and once you have this mental model, concepts like key, memo, and concurrent features all start making intuitive sense.

If this clicked for you, follow along — next up we're diving into React Keys deep dive and why index-as-key breaks your app in surprising ways.

Happy coding! ⚛️

Tagged: #react #javascript #webdev #beginners

How DNS Resolution Works: From `dig . NS` to Your Browser Loading Google

Janmejai Singh — Sat, 09 May 2026 09:24:28 +0000

Every time you type google.com into a browser, something remarkable happens in milliseconds — a global, distributed lookup system translates that human-readable name into a machine-readable IP address. No single server handles this. No central database stores it all.

This is DNS, and understanding how it works will make you a sharper developer, a better debugger, and a more informed system designer.

In this article, we'll use the dig command to inspect each layer of DNS resolution, building a mental model from the ground up.

Why Name Resolution Exists

Computers communicate using IP addresses — numerical labels like 142.250.195.78. Every server on the internet has one. But humans don't think in IP addresses. We think in names.

DNS (Domain Name System) solves this mismatch. It's the protocol and infrastructure that translates google.com → 142.250.195.78 so your browser knows where to send its request.

What makes DNS interesting (and worth understanding deeply) is its architecture:

Distributed — No single server holds all records. The system delegates responsibility across a global hierarchy.
Cached — Responses are stored at multiple levels to reduce latency.
Fault-tolerant — Each layer has multiple servers so no single failure breaks name resolution.

Meet `dig` — Your DNS Diagnostic Tool

dig (Domain Information Groper) is a command-line utility for querying DNS name servers. It ships with most Unix-like systems and is the go-to tool for DNS inspection.

Install it:

# macOS — usually pre-installed
dig --version

# Ubuntu / Debian
sudo apt install dnsutils

# CentOS / RHEL / Fedora
sudo yum install bind-utils

Basic syntax:

dig [domain] [record_type] [options]

Useful flags:

+short          # Concise output (just the answer)
+trace          # Full recursive trace from root down
@8.8.8.8        # Use a specific resolver
+norecurse      # Query the server directly without recursion

Now let's use dig to walk the DNS hierarchy from top to bottom.

The DNS Hierarchy at a Glance

Before commands, here's the architecture we're navigating:

                         ┌─────────────┐
                         │   Root NS   │  ← dig . NS
                         │  (. zone)   │
                         └──────┬──────┘
                                │ "Ask .com servers"
                         ┌──────▼──────┐
                         │   TLD NS    │  ← dig com NS
                         │ (.com zone) │
                         └──────┬──────┘
                                │ "Ask Google's servers"
                         ┌──────▼──────┐
                         │ Auth NS     │  ← dig google.com NS
                         │(google.com) │
                         └──────┬──────┘
                                │ "Here's the IP"
                         ┌──────▼──────┐
                         │  A Record   │  ← dig google.com
                         │142.250.x.x  │
                         └─────────────┘

DNS resolution is a top-down delegation chain. Each layer only knows how to refer you to the next. Let's explore each layer.

Layer 1: Root Name Servers — `dig . NS`

dig . NS

The . (dot) is the DNS root zone — the very top of the entire DNS hierarchy.

Output:

;; ANSWER SECTION:
.    518400  IN  NS  a.root-servers.net.
.    518400  IN  NS  b.root-servers.net.
.    518400  IN  NS  c.root-servers.net.
...
.    518400  IN  NS  m.root-servers.net.

There are 13 root name server names (a through m), but behind each name sit hundreds of physical servers globally — distributed via anycast routing. They're operated by a mix of organizations: ICANN, NASA, Verisign, Internet Systems Consortium, and others.

What they do: Root servers don't know the IP of google.com. They only know which servers are responsible for each Top-Level Domain (.com, .org, .net, .io, etc.).

The TTL of 518400 (6 days) tells you how stable these records are. Root server information almost never changes.

What NS records mean: An NS record points to the name server responsible for a DNS zone. Here, the root zone's NS records point to... the root servers themselves.

Layer 2: TLD Name Servers — `dig com NS`

dig com NS

Now we query the name servers for the .com TLD.

Output:

;; ANSWER SECTION:
com.    172800  IN  NS  a.gtld-servers.net.
com.    172800  IN  NS  b.gtld-servers.net.
...
com.    172800  IN  NS  m.gtld-servers.net.

These are Verisign's gTLD (Generic Top-Level Domain) servers — responsible for the entire .com namespace. Over 160 million domain names fall under their jurisdiction.

What they do: When a recursive resolver asks "Who is authoritative for google.com?", the gTLD servers respond with Google's name server hostnames. They do not know Google's IP address directly — they only know who to ask next.

System Design Insight: This delegation model is what allows DNS to scale to billions of domains. No single database. No central authority below the root. Responsibility is partitioned and delegated hierarchically.

Layer 3: Authoritative Name Servers — `dig google.com NS`

dig google.com NS

Now we find the servers that actually own Google's DNS records.

Output:

;; ANSWER SECTION:
google.com.    21600  IN  NS  ns1.google.com.
google.com.    21600  IN  NS  ns2.google.com.
google.com.    21600  IN  NS  ns3.google.com.
google.com.    21600  IN  NS  ns4.google.com.

These are Google's own authoritative name servers. Unlike the layers above them, these servers hold the actual DNS records:

Record Type	Purpose
`A`	IPv4 address
`AAAA`	IPv6 address
`MX`	Mail server
`CNAME`	Canonical alias
`TXT`	Verification, SPF, DKIM

Google runs its own infrastructure here. Many companies delegate this to DNS providers like Cloudflare, AWS Route 53, or Namecheap instead.

The TTL of 21600 (6 hours) is shorter than root/TLD records because these records can change — for example, when rotating infrastructure or updating configs.

The Full Resolution — `dig google.com`

dig google.com

This is the query your browser ultimately needs: "What's the IP address for google.com?"

Output:

;; QUESTION SECTION:
;google.com.                    IN  A

;; ANSWER SECTION:
google.com.    300    IN  A    142.250.195.78

;; Query time: 12 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)

Breaking It Down

Field	Explanation
`IN A`	Internet class, A (IPv4) record type
`142.250.195.78`	The actual IP address your browser connects to
`300`	TTL of 5 minutes — Google rotates IPs frequently for load balancing
`Query time: 12 msec`	Fast because this was cached by `8.8.8.8`
`SERVER: 8.8.8.8`	Google's public DNS answered this query

The Step-by-Step Flow (Uncached)

1. You type google.com
   ↓
2. Browser checks its DNS cache → miss
   ↓
3. OS checks /etc/hosts + system cache → miss
   ↓
4. Query sent to recursive resolver (8.8.8.8)
   ↓
5. Resolver asks Root NS: "Who handles .com?"
   ← "Ask a.gtld-servers.net"
   ↓
6. Resolver asks gTLD NS: "Who handles google.com?"
   ← "Ask ns1.google.com"
   ↓
7. Resolver asks ns1.google.com: "What's the A record for google.com?"
   ← "142.250.195.78, TTL 300"
   ↓
8. Resolver returns IP to your OS, caches it for 300 seconds
   ↓
9. Browser opens TCP connection to 142.250.195.78:443
   ↓
10. TLS handshake → HTTP request → Page loads ✓

The whole chain (steps 5–7) typically completes in under 100ms.

Recursive Resolvers: The Unsung Heroes

A recursive resolver is the server that does the work of traversing the hierarchy on your behalf. When you configure DNS on your router or device, you're pointing to a recursive resolver.

Your Device
    │
    ▼
Recursive Resolver (8.8.8.8)
    │  Checks its cache first...
    │  If miss, walks the chain:
    ├──► Root NS      → referral
    ├──► TLD NS       → referral
    └──► Auth NS      → answer ✓
         Caches the result
         Returns to you

Why Caching Matters

Every DNS response includes a TTL (Time to Live). Recursive resolvers cache answers for that duration before querying again.

Root NS TTLs      → ~2 days   (very stable)
TLD NS TTLs       → ~2 days   (very stable)
Auth NS TTLs      → hours     (occasionally updated)
A record TTLs     → seconds to hours (varies by domain)

This is why DNS changes take time to "propagate" — resolvers worldwide are still serving cached responses until TTLs expire. When you update a DNS record, it's fully live for everyone only after the old TTL has expired everywhere.

Popular Public Recursive Resolvers

8.8.8.8      → Google Public DNS
1.1.1.1      → Cloudflare DNS (fastest globally, strong privacy)
9.9.9.9      → Quad9 (security-focused, blocks malware domains)
208.67.222.222 → OpenDNS (Cisco)

Mapping `dig` Commands to DNS Stages

Here's a quick reference connecting each command to its role in the resolution flow:

dig . NS            # Stage 1: Who are the root name servers?
dig com NS          # Stage 2: Who manages the .com TLD?
dig google.com NS   # Stage 3: Who is authoritative for google.com?
dig google.com      # Stage 4: What's the actual IP address?

Or run them all at once with the trace flag:

dig +trace google.com

+trace makes dig itself walk the full hierarchy — from root to authoritative — and print every step. It's the most educational single command for understanding DNS resolution.

DNS in the Context of Real Browser Requests

When you visit https://google.com, DNS is step zero of the entire connection:

DNS Resolution       → ~1ms (cached) to ~100ms (fresh)
TCP Handshake        → ~10–50ms
TLS Handshake        → ~20–100ms
HTTP Request         → ~10–50ms
Page Render          → varies

DNS is often the fastest part once cached — but a cold DNS lookup on first visit adds real latency. This is why modern browsers implement:

DNS prefetching — Pre-resolving domains found in <link rel="dns-prefetch"> or in page links
Connection pre-warming — Opening TCP/TLS connections before the user clicks
HTTP/3 with QUIC — Reduces connection overhead after DNS

And infrastructure teams use:

Low TTLs (60–300s) on CDN records to route users to the nearest edge node
DNS-based load balancing — Returning different IPs based on geography or health
DNS-over-HTTPS (DoH) — Encrypting DNS queries so ISPs can't snoop on which sites you visit

Quick Reference Card

# The resolution hierarchy
dig . NS                    # Root name servers
dig com NS                  # .com TLD name servers
dig google.com NS           # Authoritative name servers
dig google.com              # Final A record (IPv4)

# Other record types
dig google.com AAAA         # IPv6 address
dig google.com MX           # Mail servers
dig google.com TXT          # TXT records (SPF, DKIM, verification)
dig google.com CNAME        # Canonical name alias

# Diagnostic flags
dig +short google.com       # Just the IP
dig +trace google.com       # Full resolution trace from root
dig @1.1.1.1 google.com    # Force a specific resolver
dig +norecurse @a.root-servers.net google.com  # Direct root query

Key Takeaways

DNS is hierarchical and distributed. No single server knows everything — each layer delegates to the next.
Root servers (. NS) point to TLD servers. There are 13 names, backed by hundreds of anycast servers.
TLD servers (e.g., com NS) point to authoritative servers for each domain.
Authoritative servers hold the actual records — A, MX, TXT, CNAME, etc.
Recursive resolvers traverse the full chain on your behalf and cache results using TTLs.
dig +trace is the fastest way to see the entire resolution chain in one command.

Resources

If this helped you build a clearer mental model of DNS, share it with your cohort. Understanding the infrastructure beneath the web makes you a better engineer at every layer of the stack.

Template Literals in JavaScript — From Messy Concatenation to Clean, Modern Strings

Janmejai Singh — Sat, 09 May 2026 09:16:32 +0000

Template Literals in JavaScript — From Messy Concatenation to Clean, Modern Strings

JavaScript strings used to be a chore. Between escaped quotes, awkward \n newlines, and chains of + operators, writing dynamic strings felt like assembling furniture with the wrong tools.

ES6 template literals changed all of that in 2015. A decade later, they're still one of the most impactful readability improvements in modern JavaScript — and they're still underused by developers who haven't fully made the switch.

This guide covers everything: the problem, the solution, the syntax, real use cases, and the advanced tricks most tutorials skip.

The Problem with String Concatenation

Let's start honest. Here's what string-building looked like before template literals:

const firstName = "Ananya";
const lastName = "Sharma";
const score = 98;
const subject = "JavaScript";

// 😩 Traditional approach
const report = "Student: " + firstName + " " + lastName + 
               "\nSubject: " + subject + 
               "\nScore: " + score + "/100" +
               "\nStatus: " + (score >= 60 ? "Pass" : "Fail");

console.log(report);

This works. But it's:

Hard to read (you have to mentally track + and " pairs)
Easy to mess up (a missing space inside quotes? typo city)
Painful to maintain (adding a new line means touching the whole chain)
Ugly for multi-line output (\n inside strings is visual noise)

The more complex your string, the worse this gets.

The Solution: Template Literal Syntax

Template literals use backticks (`) instead of quotes.

// That's it. This is a template literal.
const greeting = `Hello, World!`;

But the real power comes from two features packed inside: string interpolation and native multi-line support.

String Interpolation: `${}` Is Your New Best Friend

Embed any variable or expression using ${expression} inside the backticks:

const firstName = "Ananya";
const lastName = "Sharma";
const score = 98;
const subject = "JavaScript";

// ✅ Template literal approach
const report = `Student: ${firstName} ${lastName}
Subject: ${subject}
Score: ${score}/100
Status: ${score >= 60 ? "Pass" : "Fail"}`;

console.log(report);
// Student: Ananya Sharma
// Subject: JavaScript
// Score: 98/100
// Status: Pass

Same output. Completely different experience writing and reading it.

The `${}` Placeholder Accepts Any Expression

const a = 10;
const b = 5;

console.log(`Sum: ${a + b}`);         // Sum: 15
console.log(`Power: ${a ** b}`);      // Power: 100000
console.log(`Max: ${Math.max(a, b)}`); // Max: 10

// Functions inline
const shout = str => str.toUpperCase();
console.log(`Shout: ${shout("hello")}`); // Shout: HELLO

// Arrays
const fruits = ["Mango", "Papaya", "Guava"];
console.log(`Fruits: ${fruits.join(", ")}`); // Fruits: Mango, Papaya, Guava

// Objects
const user = { name: "Rahul", tier: "Pro" };
console.log(`User ${user.name} is on the ${user.tier} plan.`);
// User Rahul is on the Pro plan.

Multi-line Strings: Just Press Enter

No more \n. No more string concatenation across lines. With template literals, line breaks are literal:

// ❌ Old approach
const oldEmail = "Dear Vikram,\n\n" +
  "Thank you for joining Web Dev Cohort 2026.\n" +
  "Your first session starts on March 16.\n\n" +
  "Best regards,\nThe Team";

// ✅ New approach
const email = `Dear Vikram,

Thank you for joining Web Dev Cohort 2026.
Your first session starts on March 16.

Best regards,
The Team`;

The template literal version looks exactly like the output — no translation required.

Building HTML Fragments

This is where multi-line template literals really shine:

const product = {
  name: "Mechanical Keyboard",
  price: 3499,
  inStock: true,
  rating: 4.7
};

// ✅ Clean HTML template
const card = `
  <div class="product-card">
    <h3>${product.name}</h3>
    <p class="price">₹${product.price.toLocaleString("en-IN")}</p>
    <span class="badge ${product.inStock ? "in-stock" : "out-of-stock"}">
      ${product.inStock ? "In Stock" : "Out of Stock"}
    </span>
    <p>⭐ ${product.rating}/5</p>
  </div>
`.trim();

document.querySelector("#app").innerHTML = card;

Before vs After: The Visual Comparison

Here's a side-by-side that shows just how dramatic the improvement is:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  BEFORE: String Concatenation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  "Welcome, " + user + "! You have " + count
  + " message" + (count !== 1 ? "s" : "") + "."

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  AFTER: Template Literal
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  `Welcome, ${user}! You have ${count}
  message${count !== 1 ? "s" : ""}.`

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Same logic. The template literal version is scannable at a glance.

Nested Template Literals

Template literals can be nested — useful for generating lists from arrays:

const students = ["Arjun", "Priya", "Karan"];

const html = `
  <ul class="student-list">
    ${students.map(name => `<li>${name}</li>`).join("\n    ")}
  </ul>
`;

console.log(html);
// <ul class="student-list">
//   <li>Arjun</li>
//   <li>Priya</li>
//   <li>Karan</li>
// </ul>

Tagged Templates: The Advanced Feature

Tagged templates let you intercept template literal processing with a function. The tag function receives the static string parts and the interpolated values separately.

// Syntax: tagFunction`string ${value} more string`

function currencyINR(strings, ...values) {
  return strings.reduce((result, str, i) => {
    const value = values[i - 1];
    const formatted = typeof value === "number"
      ? `₹${value.toLocaleString("en-IN")}`
      : value;
    return result + (formatted ?? "") + str;
  });
}

const price = 149999;
const item = "MacBook Pro";

console.log(currencyINR`The ${item} costs ${price} after GST.`);
// The MacBook Pro costs ₹1,49,999 after GST.

Where Tagged Templates Are Used in the Wild

styled-components.com

// styled-components — CSS-in-JS
const Button = styled.button`
  background: ${props => props.primary ? "#0070f3" : "white"};
  color: ${props => props.primary ? "white" : "#0070f3"};
  padding: 0.5rem 1.25rem;
  border-radius: 6px;
`;

// GraphQL (Apollo / urql)
const GET_USER = gql`
  query GetUser($id: ID!) {
    user(id: $id) {
      name
      email
    }
  }
`;

// Lit HTML
const template = html`<p>Hello, ${name}!</p>`;

Tagged templates are one of the most powerful and underrated features in modern JavaScript.

String.raw — A Built-in Tag

JavaScript ships with String.raw, a built-in tag that prevents escape sequence processing:

// Regular template literal
console.log(`C:\new\folder`);
// C:
// ew
// older   ← \n and \f were interpreted!

// String.raw — preserves backslashes
console.log(String.raw`C:\new\folder`);
// C:\new\folder  ← exactly as written

Handy for Windows file paths, regex patterns, and LaTeX strings.

Real-World Use Cases Cheat Sheet

// 1. API endpoint construction
const getUser = (id) => `${API_BASE}/users/${id}/profile`;
const search = (q, page) => `${API_BASE}/search?q=${encodeURIComponent(q)}&page=${page}`;

// 2. Dynamic class names (React / Vanilla JS)
const btnClass = `btn ${isLoading ? "btn--loading" : ""} ${variant}`.trim();

// 3. Structured log messages
const log = (level, msg) =>
  `[${new Date().toISOString()}] [${level}] ${msg}`;

// 4. Error messages with context
throw new Error(`Expected type "string" but got "${typeof value}" at key "${key}".`);

// 5. SQL query building (static parts only — always parameterize user input!)
const query = `
  SELECT id, name, email
  FROM users
  WHERE role = 'admin'
  ORDER BY created_at DESC
  LIMIT ${pageSize} OFFSET ${page * pageSize}
`;

// 6. SVG generation
const circle = (cx, cy, r, color) =>
  `<circle cx="${cx}" cy="${cy}" r="${r}" fill="${color}" />`;

Common Pitfalls to Avoid

1. Unintended leading/trailing whitespace

const msg = `
  Hello
`;
// msg starts with \n and has trailing \n
// Use .trim() if you need to remove them

2. Nested backticks need escaping

// ❌ Syntax error
const str = `Click the `Run` button`;

// ✅ Escaped backtick
const str = `Click the \`Run\` button`;

3. XSS risk with innerHTML

// ⚠️ Don't do this with untrusted user input
element.innerHTML = `<p>${userInput}</p>`;

// ✅ Use textContent for plain text
element.textContent = userInput;

// ✅ Or sanitize with DOMPurify for HTML
element.innerHTML = DOMPurify.sanitize(`<p>${userInput}</p>`);

Feature Comparison Table

Feature	Old Concatenation	Template Literals
Syntax	`"" + var + ""`	`${var}`
Readability	❌ Cluttered	✅ Clean
Multi-line	❌ `\n` hacks	✅ Natural
Expressions	❌ Awkward `+`	✅ Inside `${}`
Nested structures	❌ Very messy	✅ Composable
Advanced processing	❌ Not possible	✅ Tagged templates
Raw strings	❌ Manual escape	✅ `String.raw`
Performance	Same	Same
Browser support	All	ES6+ / all modern

TL;DR — Everything in One Block

// ── Basic ─────────────────────────────────────
const name = "Dev";
const msg = `Hello, ${name}!`;

// ── Expression ────────────────────────────────
const tax = `Total: ₹${(price * 1.18).toFixed(2)}`;

// ── Multi-line ────────────────────────────────
const html = `
  <h1>${title}</h1>
  <p>${body}</p>
`;

// ── Ternary ───────────────────────────────────
const status = `${online ? "🟢 Online" : "🔴 Offline"}`;

// ── Nested ────────────────────────────────────
const list = `<ul>${items.map(i => `<li>${i}</li>`).join("")}</ul>`;

// ── Tagged ────────────────────────────────────
const safe = sanitize`User said: ${input}`;

// ── Raw ───────────────────────────────────────
const path = String.raw`C:\Users\Dev\Documents`;

Conclusion

Template literals aren't a gimmick — they solve a genuine pain point in JavaScript. Every time you use them, you're writing code that's cleaner, safer, and easier for others (including future you) to understand.

The switch from + concatenation is almost zero effort, and the payoff is immediate. If you're building anything with strings — and you always are — template literals belong in your default toolkit.

Found this helpful? Drop a ❤️, save it for reference, and share it with someone who's still typing "Hello " + name + "!".

Part of the Web Dev Cohort 2026 series — new JavaScript fundamentals every week.

Discussion

What's the most creative use of tagged templates you've seen in production?
Do you use template literals by default now, or do you still reach for quotes sometimes?

Let's talk in the comments 👇

Flattening Arrays in JavaScript — The Complete Visual Guide

Janmejai Singh — Sat, 09 May 2026 09:06:51 +0000

🪆 Flattening Arrays in JavaScript — The Complete Visual Guide

Imagine a Russian nesting doll. You open one, find another. Open that, find another. That's a nested array. Our job? Unpack them all into one flat row.

📦 What Are Nested Arrays?

A nested array is simply an array that contains other arrays as its elements. Arrays inside arrays. Boxes inside boxes.

// Simple flat array
const flat = [1, 2, 3, 4, 5];

// Nested array — arrays inside arrays
const nested = [1, [2, 3], [4, [5, 6]], [[[7]]]];

Visualizing the layers:

[1, [2, 3], [4, [5, 6]], [[[7]]]]
 ^   ^^^^^   ^^^^^^^^^^   ^^^^^^
 |   |        |            |
 |   depth 1  depth 1+2    depth 1+2+3
 depth 0 (top level)

These show up all the time in real code:

🌐 API responses — deeply nested JSON objects
🗃️ Database results — grouped or paginated data
📁 File system trees — folders containing folders
🧮 Matrix math — rows and columns
🗺️ Category trees — parent/child hierarchies

🤔 Why Flatten at All?

Here's the problem with nested arrays:

const scores = [[85, 92], [78, 95], [88, 71]];

// ❌ .includes() won't work as expected
scores.includes(85); // false — it's looking for [85, 92]

// ❌ .length is misleading
scores.length; // 3 — but there are 6 actual scores

// ❌ Can't sort all values directly
scores.sort(); // sorts sub-arrays, not values

After flattening:

const flat = scores.flat();
// → [85, 92, 78, 95, 88, 71]

flat.includes(85);  // ✅ true
flat.length;        // ✅ 6
flat.sort((a, b) => a - b); // ✅ [71, 78, 85, 88, 92, 95]

🧠 The Core Concept

Flattening = pulling all values out of their nested containers into a single flat array.

BEFORE:                        AFTER:
┌──────────────────────┐       ┌────────────────────────────┐
│ [                    │       │                            │
│   1,                 │       │  [ 1, 2, 3, 4, 5, 6, 7 ]  │
│   [2, 3],            │  ──►  │                            │
│   [4, [5, 6]],       │       └────────────────────────────┘
│   [[[7]]]            │
│ ]                    │
└──────────────────────┘

The key variable: how deep do you need to flatten?

Depth	What it does
`1`	Unwraps only the outermost arrays
`2`	Unwraps two levels
`Infinity`	Fully flattens everything

🛠️ Every Method, Explained

1️⃣ `Array.flat()` — The Native, Modern Way

flat() was introduced in ES2019 and is the most readable, idiomatic solution.

const arr = [1, [2, 3], [4, [5, 6]], [[[7]]]];

arr.flat();           // depth 1 (default)
// → [1, 2, 3, 4, [5, 6], [[[7]]]]

arr.flat(2);          // depth 2
// → [1, 2, 3, 4, 5, 6, [[[7]]]]

arr.flat(Infinity);   // flatten everything
// → [1, 2, 3, 4, 5, 6, 7]

Step-by-step for flat(1):

Input: [1, [2, 3], [4, [5, 6]]]

1         → not an array → keep: 1
[2, 3]    → array at depth 1 → unwrap: 2, 3
[4, [5,6]]→ array at depth 1 → unwrap: 4, [5,6]
                                     ↑ still nested (depth 2)

Output: [1, 2, 3, 4, [5, 6]]

✅ Use when: Working in modern codebases. Clean, expressive, handles depth.

2️⃣ `flatMap()` — Map + Flatten in One Pass

flatMap() maps each element and then flattens one level. It's like a supercharged .map().

const words = ["Hello World", "JS is great"];

words.map(w => w.split(" "));
// → [["Hello", "World"], ["JS", "is", "great"]]

words.flatMap(w => w.split(" "));
// → ["Hello", "World", "JS", "is", "great"]

Real-world: extract all tags from a blog array:

const posts = [
  { title: "Async Await", tags: ["js", "async"] },
  { title: "CSS Grid",    tags: ["css", "layout"] },
  { title: "Node.js",     tags: ["node", "js"] },
];

const allTags = posts.flatMap(p => p.tags);
// → ["js", "async", "css", "layout", "node", "js"]

const uniqueTags = [...new Set(allTags)];
// → ["js", "async", "css", "layout", "node"]

✅ Use when: You need to transform + flatten simultaneously. Only goes 1 level deep.

3️⃣ `reduce()` — The Foundational Approach

Before flat() landed in ES2019, reduce() was the standard approach. Still great to know.

const arr = [1, [2, 3], [4, 5]];

const flat = arr.reduce((acc, val) => acc.concat(val), []);
// → [1, 2, 3, 4, 5]

Step-by-step accumulation:

Initial:  acc = []

Item 1:   val = 1       → [].concat(1)        = [1]
Item 2:   val = [2, 3]  → [1].concat([2,3])   = [1, 2, 3]
Item 3:   val = [4, 5]  → [1,2,3].concat([4,5]) = [1, 2, 3, 4, 5]

For deep flattening with reduce — use recursion:

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

deepFlatReduce([1, [2, [3, [4]]]]);
// → [1, 2, 3, 4]

✅ Use when: You want custom logic while flattening (filter, transform, accumulate).

4️⃣ Recursive Flatten — The Interview Essential

This is the approach you must be able to write from scratch in interviews.

function flatten(arr) {
  const result = [];

  for (const item of arr) {
    if (Array.isArray(item)) {
      result.push(...flatten(item)); // recurse deeper
    } else {
      result.push(item);             // base case
    }
  }

  return result;
}

flatten([1, [2, [3, [4, [5]]]]]);
// → [1, 2, 3, 4, 5]

Call stack diagram for flatten([1, [2, [3]]]):

flatten([1, [2, [3]]])
├─ item = 1          → push 1
└─ item = [2, [3]]   → recurse:
      flatten([2, [3]])
      ├─ item = 2        → push 2
      └─ item = [3]      → recurse:
            flatten([3])
            └─ item = 3    → push 3
            return [3]
      return [2, 3]
   push ...2, 3
return [1, 2, 3]

✅ Use when: Interviews, learning, or environments without ES2019 support.

5️⃣ Iterative Stack — Recursion-Safe 🔐

Deep recursion can cause stack overflow for extremely nested arrays. This stack-based approach avoids that:

function flattenSafe(arr) {
  const stack = [...arr];
  const result = [];

  while (stack.length) {
    const item = stack.pop();

    if (Array.isArray(item)) {
      stack.push(...item); // push elements back to process
    } else {
      result.unshift(item); // prepend to maintain order
    }
  }

  return result;
}

flattenSafe([1, [2, [3, [4, [5]]]]]);
// → [1, 2, 3, 4, 5]

✅ Use when: Handling user-generated or untrusted deeply nested data.

📊 Quick Comparison

Method	Depth Control	ES Version	Best For
`flat()`	✅ Configurable	ES2019	Most use cases
`flatMap()`	1 level only	ES2019	Map + flatten
`reduce()`	With recursion	ES5	Custom logic
Recursion	✅ Full	ES5	Interviews
Stack iterative	✅ Full	ES5	Very deep nesting

🎯 Interview Questions You'll Actually Face

❓ "Write your own implementation of `flat()`"

Array.prototype.myFlat = function(depth = 1) {
  const result = [];

  function walk(arr, d) {
    for (const item of arr) {
      if (Array.isArray(item) && d > 0) {
        walk(item, d - 1);
      } else {
        result.push(item);
      }
    }
  }

  walk(this, depth);
  return result;
};

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

❓ "Flatten and remove duplicates"

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

[...new Set(arr.flat(Infinity))];
// → [1, 2, 3, 4]

❓ "Flatten only arrays, keep objects intact"

function flattenArraysOnly(arr) {
  return arr.reduce((acc, val) => {
    if (Array.isArray(val)) {
      acc.push(...flattenArraysOnly(val));
    } else {
      acc.push(val); // objects, strings, numbers — kept as-is
    }
    return acc;
  }, []);
}

flattenArraysOnly([1, [2, { a: 3 }], [[4]]]);
// → [1, 2, { a: 3 }, 4]

❓ "Find the max nesting depth"

function maxDepth(arr) {
  return Array.isArray(arr)
    ? 1 + Math.max(0, ...arr.map(maxDepth))
    : 0;
}

maxDepth([1, [2, [3, [4]]]]);
// → 4

❓ "Flatten and extract values from objects in an array"

const data = [
  { name: "Alice", hobbies: ["reading", "coding"] },
  { name: "Bob",   hobbies: ["gaming", "cooking"] },
];

data.flatMap(person => person.hobbies);
// → ["reading", "coding", "gaming", "cooking"]

🧾 Cheat Sheet

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

// ── Native flat ──────────────────────────────
arr.flat()            // [1, 2, [3, [4]]]     (depth 1)
arr.flat(2)           // [1, 2, 3, [4]]       (depth 2)
arr.flat(Infinity)    // [1, 2, 3, 4]         (full)

// ── flatMap ──────────────────────────────────
[[1,2],[3,4]].flatMap(x => x)  // [1, 2, 3, 4]

// ── reduce ───────────────────────────────────
arr.reduce((a,v) => a.concat(v), [])
// [1, 2, [3, [4]]]  (depth 1)

// ── recursive ────────────────────────────────
function df(a) {
  return a.reduce((acc, v) =>
    acc.concat(Array.isArray(v) ? df(v) : v), []);
}
df(arr)  // [1, 2, 3, 4]

🏆 Key Takeaways

🥇 flat(Infinity) is the cleanest way to fully flatten in modern JS
⚡ flatMap() is perfect when you're transforming data at the same time
🧠 Recursive flatten is a must-know for interviews — understand it cold
🔒 Iterative/stack approach is safest for arbitrarily deep or unknown nesting
🤔 Always ask yourself: "How many levels deep do I actually need?"

💻 Try It!

// Flatten, deduplicate, and sort
const challenge = [[5, 3], [1, [9, 2]], [[[8, 4]]]];

const result = [...new Set(challenge.flat(Infinity))]
  .sort((a, b) => a - b);

console.log(result);
// → [1, 2, 3, 4, 5, 8, 9]

If this helped, drop a ❤️ and share it with a fellow dev!

JavaScript Modules Explained: Import, Export, and Why Your Code Will Thank You

Janmejai Singh — Sat, 09 May 2026 07:31:54 +0000

Stop writing 1,400-line JavaScript files.

I've been there. You come back to a project after three weeks. One file. Everything in it. Functions calling other functions. Variables defined on line 847, used on line 12. You scroll up. You scroll down. You question your career choices.

That's the problem ES Modules solve. And they do it elegantly.

Let's get into it.

Why Modules Exist (The Problem First)

Before ES Modules were standard, JavaScript files shared a single global scope via <script> tags:

<script src="utils.js"></script>
<script src="cart.js"></script>
<script src="app.js"></script>

Every variable from every file lived in the same global bucket. The consequences were predictable:

// utils.js
var discount = 0;

// cart.js — loaded after utils.js
var discount = 0.15; // 💥 silently overwrote utils.js's variable

// app.js
console.log(discount); // 0.15 — but was this intentional?

This is global scope pollution. Files had no walls. Anything could overwrite anything. Debugging was archaeology.

The "solution" some teams used was dumping everything into one giant file. That solved collisions but created a different nightmare: no separation of concerns, no reusability, and merge conflict hell when multiple people edited it.

ES Modules fix both problems at once.

What Is an ES Module?

An ES Module is just a JavaScript file that uses import and export statements. Each module file gets its own private scope — variables and functions defined inside don't leak out unless you explicitly export them.

Before modules:               After modules:

  Global Scope                  file-a.js (own scope)
  ┌────────────────┐            ┌──────────────────┐
  │ var a = 1;     │            │ const a = 1;     │
  │ var b = 2;     │            │ export { a }     │
  │ function c(){} │            └──────────────────┘
  │ function d(){} │
  └────────────────┘            file-b.js (own scope)
    ↑ everything from           ┌──────────────────┐
      all files lands here      │ const b = 2;     │
                                │ export { b }     │
                                └──────────────────┘

Exporting: Making Things Available

Named Exports

Named exports let you share multiple things from a single file:

// math.js

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

export function subtract(a, b) {
  return a - b;
}

export const PI = 3.14159;

Or declare everything first, then export at the bottom (cleaner for larger files):

// math.js

function add(a, b) { return a + b; }
function subtract(a, b) { return a - b; }
const PI = 3.14159;

export { add, subtract, PI };

Both styles do the same thing.

Default Exports

Default exports are for when a file has one primary thing to offer:

// UserCard.js

export default function UserCard({ name, avatar }) {
  return `<div class="card">${name}</div>`;
}

A module can only have one default export. It represents "what this file is about."

Mixing Both

You can have one default and multiple named exports in the same file:

// api.js

export default async function fetchUser(id) {
  const res = await fetch(`/users/${id}`);
  return res.json();
}

export const BASE_URL = "https://api.example.com";
export function handleError(err) {
  console.error(err.message);
}

Importing: Pulling What You Need

Named Imports (curly braces, exact names)

import { add, PI } from './math.js';

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

Use aliases to avoid name conflicts:

import { add as addNumbers } from './math.js';

Default Imports (no curly braces, any name)

import UserCard from './UserCard.js';

// You can name it anything — it's the default export
import Card from './UserCard.js';
import MyCard from './UserCard.js';

Both at Once

import fetchUser, { BASE_URL, handleError } from './api.js';

Import Everything as a Namespace

import * as MathUtils from './math.js';

MathUtils.add(1, 2);  // 3
MathUtils.PI;          // 3.14159

Default vs Named: The Decision Framework

This trips people up. Here's when to use which:

Scenario	Export type
File represents one thing (component, class, main function)	Default
File provides multiple utilities	Named
You want better editor autocomplete	Named (IDEs resolve these more reliably)
You're building a shared library	Named (enables tree shaking)
React component files	Default (community convention)

A simple test: if you'd describe a file as "the ___ module" (singular), use default. If you'd say "a collection of ___ utilities," use named.

// ✅ Default — this file IS the AuthService
export default class AuthService { ... }

// ✅ Named — this file PROVIDES multiple string utils
export function capitalize(str) { ... }
export function truncate(str, len) { ... }
export function slugify(str) { ... }

⚠️ Red flag: if you write export default { util1, util2, util3 } — switch to named exports.

File Dependency Diagram

Here's what a modular project's dependency graph looks like:

main.js
  ├── App.js
  │     ├── Header.js
  │     │     └── logo.js
  │     ├── Cart.js
  │     │     ├── CartItem.js
  │     │     └── formatCurrency.js  ◄──────────────┐
  │     └── Checkout.js                              │
  │           ├── validateForm.js                    │
  │           └── formatCurrency.js  ────────────────┘
  └── router.js
        └── routes.js

formatCurrency.js is imported by two separate files. Written once, used everywhere, no duplication. That's the payoff of modular code.

Module Import/Export Flow

┌───────────────────────────────────────────┐
│               math.js                      │
│                                           │
│  function add(a, b) { return a + b }      │
│  function subtract(a, b) { return a-b }   │
│  const PI = 3.14159                       │
│                                           │
│  export { add, subtract, PI }  ←── public API
└───────────────────────────────────────────┘
                      │
                      │ module system resolves path
                      ▼
┌───────────────────────────────────────────┐
│               app.js                       │
│                                           │
│  import { add, PI } from './math.js'      │
│                                           │
│  // subtract stays private in math.js     │
│  // only add and PI cross the boundary    │
└───────────────────────────────────────────┘

You decide what's public. Everything else is encapsulated by default.

Benefits of Modular Code

1. Encapsulation
Implementation details stay private. Internal helper functions in calculateTax.js don't pollute global scope.

2. Reusability
Write formatDate.js once, import it in ten projects. No copy-pasting, no drift between versions.

3. Maintainability
When something breaks in payment processing, you open payment.js. Not a 3,000-line monolith. You know where to look.

4. Testability
Modules are isolated, which makes them easy to unit test:

// calculateTax.test.js
import { calculateTax } from './calculateTax.js';

test('applies 18% tax correctly', () => {
  expect(calculateTax(100, 0.18)).toBe(118);
});

5. Team Scalability
Two developers can work on Cart.js and Checkout.js simultaneously without touching the same file.

6. Tree Shaking
Bundlers like Vite analyze named imports and remove unused code from production builds. This only works with ES Module named exports — another reason to prefer them for libraries.

Using Modules in the Browser

No bundler required for simple projects. Just add type="module":

<script type="module" src="main.js"></script>

Key behaviors with type="module":

Runs in strict mode automatically
Deferred by default — won't block HTML parsing
Each file has its own scope (that's the whole point)
Requires a local server during dev — can't run from file://

Real-World Example: E-Commerce Cart

Let's put it all together:

// utils/currency.js
export function formatCurrency(amount, currency = 'USD') {
  return new Intl.NumberFormat('en-US', {
    style: 'currency',
    currency
  }).format(amount);
}

export function calculateTotal(items) {
  return items.reduce((sum, item) => sum + item.price * item.qty, 0);
}

// utils/tax.js
export const TAX_RATES = {
  standard: 0.18,
  reduced: 0.05
};

export function applyTax(amount, rate = TAX_RATES.standard) {
  return amount + amount * rate;
}

// Cart.js
import { formatCurrency, calculateTotal } from './utils/currency.js';
import { applyTax } from './utils/tax.js';

export default class Cart {
  constructor() {
    this.items = [];
  }

  add(item) {
    this.items.push(item);
  }

  getTotal() {
    const subtotal = calculateTotal(this.items);
    const withTax = applyTax(subtotal);
    return formatCurrency(withTax);
  }
}

// main.js
import Cart from './Cart.js';

const cart = new Cart();
cart.add({ name: 'Mechanical Keyboard', price: 89.99, qty: 1 });
cart.add({ name: 'USB-C Hub', price: 34.99, qty: 2 });

console.log(cart.getTotal()); // "$189.48"

Each file has exactly one job. currency.js formats money. tax.js handles tax logic. Cart.js manages cart state. main.js wires it together.

Quick Reference Cheat Sheet

// ─── EXPORTS ──────────────────────────────────

export const name = 'value';              // named inline
export function doThing() {}              // named inline
export { name, doThing };                 // named grouped
export { doThing as performAction };      // named with alias
export default function mainThing() {}    // default


// ─── IMPORTS ──────────────────────────────────

import { name, doThing } from './mod.js';         // named
import { doThing as action } from './mod.js';      // named with alias
import mainThing from './mod.js';                  // default
import mainThing, { name } from './mod.js';        // default + named
import * as Mod from './mod.js';                   // namespace
import './setup.js';                               // side-effect only

Key Takeaways

Every JS file can be a module — it just needs import/export
Named exports → multiple things from one file (use curly braces to import)
Default exports → one main thing per file (no curly braces when importing)
Modules give files private scope by default — nothing leaks unless you export it
Modular code is easier to test, debug, maintain, and reuse
No bundler required for modern browsers — just type="module" on your script tag

The shift from global-scope chaos to modular code is one of the best investments you can make in a codebase. Start small — pick one responsibility, extract it into its own file, export it, import it where needed. Repeat until your codebase has a shape you're proud of.

If this clicked for you, consider leaving a ❤️ or sharing it with someone learning JavaScript. Got questions or a different way you organize your modules? Drop a comment below — I'd love to hear your approach.

Linux File System Hunting: What Your OS Is Hiding in Plain Sight

Janmejai Singh — Wed, 22 Apr 2026 16:12:27 +0000

Stop running commands. Start reading the OS like a story.

Most engineers learn Linux by memorizing commands. But the real insight comes when you stop asking "what command does X?" and start asking "why does this file exist at all?"

This post is a field report from a deep dive into the Linux file system — not a command tutorial, but an investigation. Here's what I found, why it matters, and what it reveals about how Linux actually thinks.

1. `/etc/resolv.conf` — The DNS Brain of Your Machine

When your system needs to resolve google.com, it doesn't magically know where to look. It opens /etc/resolv.conf.

cat /etc/resolv.conf

nameserver 127.0.0.53
options edns0 trust-ad
search home

What's actually happening here?

On modern Ubuntu/Debian systems, the nameserver points to 127.0.0.53 — a loopback address handled by systemd-resolved, not a real external DNS server. This is a stub resolver. Your queries hit systemd-resolved first, which checks its cache, applies policies, and only then forwards upstream.

Why this matters for engineers: If you're debugging DNS failures inside a container or a VPN, this file is the first place to look — but remember, editing it directly on systemd-resolved systems often gets overwritten. The real config lives in /etc/systemd/resolved.conf.

Insight: Linux separates "who handles DNS" from "where DNS queries go". That layering enables caching, split-horizon DNS, and link-specific resolvers. Many DNS bugs in containerized apps trace back to not understanding this indirection.

2. `/proc/net/route` — Your Routing Table, Unfiltered

Everyone uses ip route to see routes. But that command is just reading from a file:

cat /proc/net/route

Iface   Destination Gateway  Flags RefCnt Use Metric Mask     MTU Window IRTT
eth0    00000000    0101A8C0  0003  0      0   100    00000000 0   0      0
eth0    0001A8C0    00000000  0001  0      0   100    00FFFFFF 0   0      0

The values are in little-endian hexadecimal. Decoding 0101A8C0: reverse the byte pairs → C0.A8.01.01 → 192.168.1.1. That's your default gateway.

Why this exists: The kernel exposes routing decisions through /proc as virtual files — no database, no daemon needed. Tools like ip, netstat, and route are essentially pretty-printers for this raw data.

Insight: The kernel routing table isn't stored anywhere on disk — it's computed in memory and exposed live through /proc. You're always reading the present state of the kernel's mind.

3. `/etc/passwd` and `/etc/shadow` — The Auth Split That Saved Linux Security

cat /etc/passwd | head -3

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin

Notice the x in the password field? That x is a pointer — it means "go look in /etc/shadow".

sudo cat /etc/shadow | head -1

root:$6$rounds=5000$xyz...:19200:0:99999:7:::

The hash prefix $6$ means SHA-512. The rounds= value controls iteration count — the computational cost of cracking.

Why the split exists: Originally, /etc/passwd held password hashes directly — but it had to be world-readable so programs could look up usernames. This meant anyone on the system could grab hashes and crack them offline. The fix: move hashes to /etc/shadow, readable only by root.

Insight: This is a textbook least-privilege design. Readable metadata in one file, sensitive secrets in another, permissions separating them. Vault, AWS SSM, and Kubernetes Secrets all follow the exact same principle.

4. `/proc/PID/fd/` — Every File Your Process Has Open

Pick any running process and inspect it live:

ls -la /proc/$$/fd

lrwxrwxrwx 1 user user 64 Apr 20 10:01 0 -> /dev/pts/0
lrwxrwxrwx 1 user user 64 Apr 20 10:01 1 -> /dev/pts/0
lrwxrwxrwx 1 user user 64 Apr 20 10:01 2 -> /dev/pts/0

File descriptors 0, 1, 2 are stdin, stdout, and stderr — symlinks to the terminal device.

Now try it on a running service:

ls -la /proc/$(pgrep nginx | head -1)/fd

You'll see open sockets, config files, log files, and PID files — everything that process is currently touching.

Why this matters: This is exactly how lsof and strace work under the hood. In incident response, checking /proc/PID/fd can reveal if a process is holding onto a deleted file (keeping disk space locked) or has unexpected outbound connections open.

5. `/etc/hosts` and `/etc/nsswitch.conf` — DNS That Predates DNS

cat /etc/hosts

127.0.0.1   localhost
127.0.1.1   myhostname
::1         localhost ip6-localhost ip6-loopback

This file is a relic from the ARPANET era — before DNS existed, machines shared a central HOSTS.TXT file. Today it's still consulted before DNS, governed by /etc/nsswitch.conf:

grep hosts /etc/nsswitch.conf
# hosts: files mdns4_minimal [NOTFOUND=return] dns

files comes first — meaning /etc/hosts wins over any DNS server.

Why engineers should care: Kubernetes, Docker, and many CI environments inject hostnames via this file. Understanding the lookup order explains why a DNS change doesn't take effect but a hosts file entry does — and why service resolution differs inside and outside a container.

6. `/etc/systemd/system/` — Where Services Are Born

cat /lib/systemd/system/ssh.service

[Unit]
Description=OpenBSD Secure Shell server
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Service]
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure

[Install]
WantedBy=multi-user.target

After= defines boot ordering. Restart=on-failure means systemd auto-restarts on crash. WantedBy=multi-user.target determines which boot stage activates the service.

The key insight: Everything in systemd is a declarative dependency graph — not a sequential boot script. The OS calculates start order at runtime from After= and Wants= relationships across all unit files. This is fundamentally different from old SysV init where order was hardcoded line by line.

7. `/var/log/auth.log` — Your Machine's Security Diary

sudo grep "Failed password" /var/log/auth.log | tail -5

Apr 20 03:14:22 host sshd[4821]: Failed password for root from 185.220.101.x port 52344 ssh2
Apr 20 03:14:25 host sshd[4821]: Failed password for root from 185.220.101.x port 52391 ssh2

If your machine is internet-facing, you almost certainly have hundreds of these every day — automated credential stuffing from bots scanning the entire IPv4 space.

What else lives here: Sudo usage, su attempts, PAM authentication events, and SSH key fingerprints from successful logins. Cross-referencing with /var/log/syslog gives you a full timeline of system behavior around any suspicious event.

Insight: Logs are only useful if you know what normal looks like. On a healthy server, SSH access comes from a handful of known IPs. Once you understand the baseline, anomalies are immediately obvious.

8. `/dev/null`, `/dev/zero`, `/dev/urandom` — The Kernel's Built-In Utilities

These aren't real files. They're character devices — kernel interfaces that behave like files.

# Silence all output
command 2>/dev/null

# Generate a 1MB file of zeros
dd if=/dev/zero of=zeros.bin bs=1M count=1

# Generate cryptographically secure random bytes
head -c 32 /dev/urandom | base64

/dev/null — a black hole. Writes disappear. Reads return EOF immediately.
/dev/zero — infinite stream of zero bytes. Used for zeroing disks and memory.
/dev/urandom — reads entropy from the kernel's CSPRNG, seeded by hardware interrupts, disk I/O timing, and network events.

Why /dev/urandom matters more than you think: When your Node.js app calls crypto.randomBytes() or Python calls secrets.token_hex(), they ultimately read from /dev/urandom. It's the root of all cryptographic randomness on Linux — every TLS handshake, every UUID, every session token traces back here.

9. `/proc/meminfo` — Why "Free Memory" Is a Lie

cat /proc/meminfo | grep -E "MemTotal|MemFree|Buffers|Cached|MemAvailable"

MemTotal:       16237568 kB
MemFree:          423108 kB
Buffers:          312440 kB
Cached:          5621700 kB
MemAvailable:    7840200 kB

MemFree is nearly always the wrong number to watch. The kernel holds Buffers + Cached memory for disk I/O caching — it shows as "used" but is immediately reclaimable. MemAvailable is the real number.

This is why a freshly booted server shows "high memory usage" — the kernel is aggressively using idle RAM for caching, which is the correct behavior.

Also worth checking:

cat /proc/cpuinfo | grep "model name" | uniq

On cloud VMs, CPU flags like vmx (Intel VT-x) or svm (AMD-V) reveal whether the machine supports hardware virtualization — useful for detecting nested virtualization environments.

10. `/boot/grub/grub.cfg` — The First Thing That Actually Runs

Before the kernel, before init, before systemd — GRUB runs. Its config:

sudo grep -A5 "menuentry" /boot/grub/grub.cfg | head -10

menuentry 'Ubuntu' {
    linux /boot/vmlinuz-6.5.0-generic root=UUID=xxxx ro quiet splash
    initrd /boot/initrd.img-6.5.0-generic
}

The linux line passes parameters directly to the kernel. quiet splash suppresses boot messages. ro mounts root read-only initially (remounted read-write after filesystem checks). root=UUID= tells the kernel which block device is the root filesystem.

Why this matters: Kernel parameters like init=/bin/bash (drop to shell), nomodeset (fix GPU issues), or systemd.unit=rescue.target (recovery mode) are configured here. Understanding GRUB is what separates engineers who can recover a broken system from those who reinstall it.

The Pattern Behind All of This

After this investigation, one theme is unmistakable: Linux exposes almost everything as a file.

What you want to inspect	Where it lives
Running processes	`/proc/PID/`
Hardware devices	`/dev/`
Live kernel settings	`/sys/`
Network & system config	`/etc/`
Service state	`/run/systemd/`

This isn't just a design quirk — it's a philosophy. If it's a file, you can read it, watch it with inotify, pipe it through grep, version-control it with git, and audit it with standard Unix tools. No proprietary APIs, no special SDKs, no vendor lock-in.

The Linux file system isn't just where your files live. It's the kernel's window into itself.

Going Deeper

If this sparked your curiosity, explore further:

/sys/class/net/ — live network interface stats including dropped packets per interface
/etc/cron.d/ — scheduled tasks; a favourite persistence location for attackers
/proc/net/tcp — all active TCP connections in raw hex format
/etc/ld.so.conf — controls which directories the dynamic linker searches for shared libraries
/proc/sys/kernel/ — live-tunable kernel parameters (also writable via sysctl)

The more you read the filesystem, the more the OS reveals itself — not as a black box, but as a transparent, well-documented machine that's been explaining itself all along. You just have to know where to look.

Part of the Web Dev Cohort 2026 — Linux File System Hunting.

your-hashnode-username.hashnode.dev

JavaScript Arrays 101: Everything a Beginner Needs to Know

Janmejai Singh — Sun, 15 Mar 2026 14:17:11 +0000

When you start learning JavaScript, you'll quickly run into a common problem: how do you manage a collection of related values without drowning in variables?

That's exactly where arrays come in.

In this article, you'll learn arrays from the ground up — what they are, how to create them, how to access and update values, and how to loop through them. By the end, you'll have a solid foundation to build on.

🤔 The Problem Arrays Solve

Say you want to store the names of five fruits. Without arrays, you might write:

let fruit1 = "Apple";
let fruit2 = "Banana";
let fruit3 = "Mango";
let fruit4 = "Orange";
let fruit5 = "Grapes";

This works for five fruits. But what about fifty? Or five hundred? Your code becomes impossible to manage.

Arrays solve this by storing multiple values inside a single variable:

let fruits = ["Apple", "Banana", "Mango", "Orange", "Grapes"];

Clean, organized, and scalable. ✅

📦 What Is an Array?

An array is an ordered collection of values stored in a single variable. Each value is called an element, and each element has a numbered index that determines its position.

Arrays are one of JavaScript's most used data structures — you'll find them everywhere.

🛠️ How to Create an Array

Use square brackets [] to create an array. Separate values with commas.

// Array of numbers
let scores = [95, 87, 74, 100];

// Array of strings
let colors = ["Red", "Blue", "Green"];

// Mixed types (valid, but not recommended)
let mixed = ["Jai", 24, true];

💡 Best practice: Keep arrays consistent — store the same type of data in each array for predictability and cleaner code.

🔢 Accessing Elements with Index

Every element in an array has an index — a number representing its position.

⚠️ Important: Array indexes start at 0, not 1.

let fruits = ["Apple", "Banana", "Mango"];

Index	Value
`0`	`Apple`
`1`	`Banana`
`2`	`Mango`

Access individual elements using bracket notation:

console.log(fruits[0]); // "Apple"
console.log(fruits[1]); // "Banana"
console.log(fruits[2]); // "Mango"

Trying to access an index that doesn't exist returns undefined:

console.log(fruits[5]); // undefined

Visualizing an Array in Memory

Index:  [0]      [1]       [2]      [3]
      +--------+---------+-------+--------+
      | Apple  | Banana  | Mango | Orange |
      +--------+---------+-------+--------+

Each block is a slot in memory holding one value.

✏️ Updating Array Elements

You can update any element by assigning a new value to its index:

let fruits = ["Apple", "Banana", "Mango"];

fruits[1] = "Pineapple";

console.log(fruits);
// Output: ["Apple", "Pineapple", "Mango"]

Notice how "Banana" at index 1 was replaced with "Pineapple".

📏 The `length` Property

Arrays come with a built-in length property that returns the total number of elements:

let fruits = ["Apple", "Banana", "Mango", "Orange"];

console.log(fruits.length); // 4

💡 Pro tip: Use fruits[fruits.length - 1] to always access the last element, regardless of how long the array is.

console.log(fruits[fruits.length - 1]); // "Orange"

🔁 Looping Through Arrays

Loops let you process every element in an array automatically — no manual indexing required.

Using a `for` Loop

let fruits = ["Apple", "Banana", "Mango", "Orange"];

for (let i = 0; i < fruits.length; i++) {
  console.log(fruits[i]);
}

// Output:
// Apple
// Banana
// Mango
// Orange

How it works:

i starts at 0 (first index)
The loop continues while i < fruits.length
i++ increments the index on each iteration

Using `for...of` (Cleaner Syntax)

for (let fruit of fruits) {
  console.log(fruit);
}

for...of is simpler when you don't need the index — just the values.

🎬 Putting It All Together: Assignment Example

Here's a complete, practical example using everything covered above:

// Step 1: Create an array of 5 favorite movies
let movies = ["Inception", "Interstellar", "Avengers", "Joker", "Titanic"];

// Step 2: Print the first and last movie
console.log("First movie:", movies[0]);
console.log("Last movie:", movies[movies.length - 1]);

// Step 3: Update one movie
movies[2] = "Spider-Man";
console.log("Updated array:", movies);

// Step 4: Loop through all movies
console.log("\n🎬 My Movie List:");
for (let i = 0; i < movies.length; i++) {
  console.log(`${i + 1}. ${movies[i]}`);
}

Output:

First movie: Inception
Last movie: Titanic
Updated array: ["Inception", "Interstellar", "Spider-Man", "Joker", "Titanic"]

🎬 My Movie List:
1. Inception
2. Interstellar
3. Spider-Man
4. Joker
5. Titanic

✅ Quick Reference Cheat Sheet

Concept	Syntax	Example
Create array	`let arr = [val1, val2]`	`let nums = [1, 2, 3]`
Access element	`arr[index]`	`nums[0]` → `1`
Update element	`arr[index] = newVal`	`nums[1] = 99`
Array length	`arr.length`	`nums.length` → `3`
Last element	`arr[arr.length - 1]`	`nums[nums.length - 1]` → `3`
Loop (for)	`for (let i = 0; i < arr.length; i++)`	Iterate with index
Loop (for...of)	`for (let item of arr)`	Iterate values directly

🎯 Key Takeaways

Arrays store multiple values in a single variable
Elements are accessed using a zero-based index
Use array[index] = value to update elements
The length property tells you how many elements an array has
Loops let you process every element efficiently

Arrays are foundational in JavaScript. Once you're comfortable with these basics, you'll be ready to explore powerful array methods like .map(), .filter(), .reduce(), and more.

📚 What's Next?

Now that you understand the basics, here's where to go next:

Array Methods — .push(), .pop(), .shift(), .unshift()
Higher-Order Functions — .map(), .filter(), .forEach()
Nested Arrays — Arrays inside arrays (2D arrays)
Array Destructuring — A clean ES6 syntax for extracting values

This article is part of the **Web Dev Cohort 2026* series. Follow along as we cover JavaScript fundamentals from the ground up.*

Did this article help you? Drop a ❤️, leave a comment with your questions, or share it with someone just getting started with JavaScript!

Function Declaration vs Function Expression in JavaScript: The Complete Guide

Janmejai Singh — Sun, 15 Mar 2026 14:11:52 +0000

JavaScript functions are the backbone of every application you'll ever build. But early on, many developers stumble on a subtle yet important question:

What's the difference between a Function Declaration and a Function Expression?

They look similar. They both create functions. But they behave differently in ways that will catch you off guard if you don't understand them.

By the end of this article, you'll know exactly when to use each one — and why it matters.

🧠 Why Functions Exist (Quick Recap)

Before diving in, let's make sure we're aligned on why functions matter.

Imagine you need to calculate a discount price across 50 different products. Without a function, you'd copy-paste logic 50 times — a maintenance nightmare.

// ❌ Without a function — repetitive and fragile
let price1 = 100 - (100 * 0.1);
let price2 = 250 - (250 * 0.1);
let price3 = 80 - (80 * 0.1);

// ✅ With a function — clean and reusable
function applyDiscount(price, rate) {
  return price - (price * rate);
}

console.log(applyDiscount(100, 0.1)); // 90
console.log(applyDiscount(250, 0.1)); // 225
console.log(applyDiscount(80, 0.1));  // 72

Functions make your code DRY (Don't Repeat Yourself), readable, and easy to maintain.

Now let's look at the two main ways to define them.

📌 Function Declaration

A Function Declaration defines a named function using the function keyword as a standalone statement.

Syntax

function functionName(parameters) {
  // code to execute
  return value;
}

Example

function greet(name) {
  return `Hello, ${name}!`;
}

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

Simple, familiar, and widely used for utility functions.

📌 Function Expression

A Function Expression assigns a function — often anonymous — to a variable.

Syntax

const variableName = function(parameters) {
  // code to execute
  return value;
};

Example

const greet = function(name) {
  return `Hello, ${name}!`;
};

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

The output is identical, but how JavaScript treats this behind the scenes is completely different.

⚡ The Critical Difference: Hoisting

This is where most developers get tripped up.

Hoisting is JavaScript's behavior of moving declarations to the top of their scope before the code runs. Function Declarations and Function Expressions are hoisted very differently.

✅ Function Declaration — Fully Hoisted

// Called BEFORE it's defined — works perfectly
console.log(multiply(3, 4)); // 12

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

JavaScript moves the entire function definition to the top of the scope during compilation. You can call it anywhere in the scope, even before it's written.

❌ Function Expression — NOT Fully Hoisted

// Called BEFORE assignment — throws an error
console.log(multiply(3, 4)); // ❌ ReferenceError

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

ReferenceError: Cannot access 'multiply' before initialization

Why? Because only the variable declaration (const multiply) is hoisted — not the function assigned to it. The variable exists in a Temporal Dead Zone (TDZ) until the assignment line is reached.

📊 Side-by-Side Comparison

Feature	Function Declaration	Function Expression
Syntax	`function name() {}`	`const name = function() {}`
Hoisting	✅ Fully hoisted	❌ Not fully hoisted
Call before definition	✅ Works	❌ Throws ReferenceError
Naming	Must be named	Can be anonymous
Use in callbacks	Possible but verbose	✅ Natural fit
Use in closures	Less common	✅ Ideal
Flexibility	Less flexible	✅ Highly flexible

🔍 Execution Flow Visualized

Understanding the order in which JavaScript processes your code helps everything click:

┌─────────────────────────────────────────────┐
│              COMPILATION PHASE              │
│                                             │
│  ✅ Function Declarations → Hoisted fully   │
│  ⚠️  Variable names (const/let) → Hoisted   │
│     but values are NOT assigned yet         │
└─────────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────────┐
│              EXECUTION PHASE                │
│                                             │
│  Code runs line by line                     │
│  Function Expressions get assigned here     │
│  They're callable only AFTER assignment     │
└─────────────────────────────────────────────┘

🎯 When to Use Each

Use Function Declaration when:

You need a simple, reusable utility function
You want the function to be available anywhere in the file
You're building named top-level functions (helpers, handlers, etc.)

// ✅ Great as a utility function
function formatCurrency(amount) {
  return `₹${amount.toFixed(2)}`;
}

Use Function Expression when:

Passing a function as a callback
Working with event listeners
Building higher-order functions
Creating closures or IIFEs (Immediately Invoked Function Expressions)
You want to conditionally assign a function

// ✅ Callbacks
const numbers = [5, 1, 8, 3];
const sorted = numbers.sort(function(a, b) { return a - b; });
// Or with arrow functions (also a function expression):
const sortedArrow = numbers.sort((a, b) => a - b);

// ✅ Event listeners
button.addEventListener("click", function() {
  console.log("Clicked!");
});

// ✅ Conditional assignment
let process;
if (isAdmin) {
  process = function() { return "Admin access granted"; };
} else {
  process = function() { return "Standard access"; };
}

🚀 Bonus: Arrow Functions Are Also Function Expressions

Arrow functions, introduced in ES6, are a concise form of Function Expression:

// Traditional function expression
const square = function(n) {
  return n * n;
};

// Arrow function expression — same behavior, shorter syntax
const square = (n) => n * n;

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

Key things to know about arrow functions:

They are not hoisted (same as regular function expressions)
They do not have their own this — great for callbacks inside classes/objects
They cannot be used as constructors

💡 Quick Summary

// ─── Function Declaration ───────────────────────
sayHello(); // ✅ Works — hoisted!

function sayHello() {
  console.log("Hello from Declaration!");
}

// ─── Function Expression ────────────────────────
sayBye(); // ❌ ReferenceError — not hoisted!

const sayBye = function() {
  console.log("Goodbye from Expression!");
};

sayBye(); // ✅ Works after assignment

🧩 Key Takeaways

Function Declaration → Use for named, reusable, top-level functions. Fully hoisted, available anywhere in scope.
Function Expression → Use for callbacks, closures, conditional logic, and event handlers. Not hoisted — must be defined before calling.
Arrow functions are Function Expressions with a compact syntax and lexical this.
When in doubt, understand when in the execution cycle you need the function available — that's your deciding factor.

📚 What to Learn Next

Now that you understand how functions are defined, here are some natural next steps:

Arrow Functions & this binding — How arrow functions differ in OOP contexts
Closures — How function expressions "remember" their outer scope
IIFEs — Immediately Invoked Function Expressions and why they're useful
Higher-Order Functions — map, filter, reduce under the hood
var vs let vs const hoisting — How variable declarations affect execution

Found this helpful? Drop a ❤️ and share it with someone learning JavaScript. Have a question or correction? Let's discuss in the comments below!

Object-Oriented Programming in JavaScript: The Blueprint Factory You Never Knew You Needed

Janmejai Singh — Sun, 15 Mar 2026 14:06:27 +0000

"Good code is like a well-organized factory — everything has its place, and every worker knows their job."

Modern software development isn't just about writing code — it's about organizing code so it's reusable, scalable, and maintainable. That's exactly what Object-Oriented Programming (OOP) gives you.

If you're learning JavaScript, understanding OOP is a game-changer. Let's break it down the right way — with real-world analogies, clean diagrams, and code you can actually use.

📌 Table of Contents

What is OOP?
The Blueprint Analogy
Classes in JavaScript
The Constructor Method
Adding Methods to Classes
Encapsulation — Keeping Things Tidy
Hands-On Example: Student Class
Why OOP Actually Matters

What is OOP? {#what-is-oop}

Object-Oriented Programming (OOP) is a paradigm where you design software using objects — self-contained units that bundle together related data and behavior.

Instead of scattering variables and functions across your codebase, OOP groups everything logically.

Real-World Entity	Programming Object
🚗 Car	`Car` object with `brand`, `color`, `start()`
🎓 Student	`Student` object with `name`, `age`, `enroll()`
🏦 Bank Account	`Account` object with `balance`, `deposit()`, `withdraw()`
📱 Phone	`Phone` object with `model`, `battery`, `call()`

Every object has:

Properties — what it is (data/state)
Methods — what it does (functions/behavior)

The Blueprint Analogy {#the-blueprint-analogy}

Here's the mental model that makes OOP click for most developers:

Imagine you're running a car factory.

Before manufacturing a single car, your engineers design a blueprint. That blueprint defines the shape, engine type, wheel count, and color options.

But here's the key insight — the blueprint is not a car. It's just the template.

From that one blueprint, your factory then produces:

📄 Blueprint (Class)
        │
        ├──────────────────────────────────────┐
        │                                      │
        ▼                                      ▼
🚗 Car #1: Red Tesla    🚙 Car #2: Blue BMW    🚕 Car #3: Black Audi

In JavaScript terms:

Factory Concept	OOP Concept
Blueprint	Class
Car produced	Object (Instance)
Manufacturing process	`new` keyword

This is the entire foundation of OOP — one blueprint, unlimited objects.

Classes in JavaScript {#classes-in-javascript}

A class is JavaScript's way of defining a blueprint.

class ClassName {
  constructor() {
    // Initialize properties here
  }

  methodName() {
    // Define behavior here
  }
}

Let's create our Car class:

class Car {
  constructor(brand, color) {
    this.brand = brand;
    this.color = color;
  }
}

Now let's manufacture some cars using the new keyword:

let car1 = new Car("Tesla", "Red");
let car2 = new Car("BMW", "Blue");

console.log(car1); // Car { brand: 'Tesla', color: 'Red' }
console.log(car2); // Car { brand: 'BMW', color: 'Blue' }

Two completely different objects, one shared blueprint. ✅

The Constructor Method {#the-constructor-method}

The constructor is a special method that runs automatically the moment you create a new object.

Think of it as the assembly line worker who sets up each car as it rolls off the production line.

class Person {
  constructor(name, age) {
    this.name = name; // Assigns 'name' to this specific object
    this.age = age;   // Assigns 'age' to this specific object
  }
}

let person1 = new Person("Rahul", 22);
let person2 = new Person("Anita", 24);

console.log(person1.name); // "Rahul"
console.log(person2.age);  // 24

The this keyword refers to the current object being created. It's how each object gets its own unique property values.

💡 Quick Rule: Every class should have a constructor. It's where you set up the initial state of your object.

Adding Methods to Classes {#adding-methods-to-classes}

Properties define what an object is. Methods define what an object does.

class Car {
  constructor(brand, color) {
    this.brand = brand;
    this.color = color;
  }

  // Method — defines behavior
  start() {
    console.log(`${this.brand} car has started. 🚀`);
  }

  stop() {
    console.log(`${this.brand} car has stopped.`);
  }

  describe() {
    console.log(`This is a ${this.color} ${this.brand}.`);
  }
}

Using the methods:

let car1 = new Car("Tesla", "Red");

car1.start();    // Tesla car has started. 🚀
car1.describe(); // This is a Red Tesla.
car1.stop();     // Tesla car has stopped.

Each object calls its own methods and accesses its own properties via this. No conflicts, no collisions.

Encapsulation — Keeping Things Tidy {#encapsulation}

Encapsulation is one of OOP's core principles. It simply means: keep related data and behavior bundled together inside a class.

Instead of having a balance variable floating around globally and separate deposit/withdraw functions scattered across files, you organize everything in one place:

class BankAccount {
  constructor(owner, initialBalance) {
    this.owner = owner;
    this.balance = initialBalance;
  }

  deposit(amount) {
    this.balance += amount;
    console.log(`✅ Deposited ₹${amount}. New balance: ₹${this.balance}`);
  }

  withdraw(amount) {
    if (amount > this.balance) {
      console.log("❌ Insufficient funds.");
      return;
    }
    this.balance -= amount;
    console.log(`💸 Withdrew ₹${amount}. New balance: ₹${this.balance}`);
  }

  getBalance() {
    console.log(`💰 ${this.owner}'s balance: ₹${this.balance}`);
  }
}

let myAccount = new BankAccount("Rahul", 5000);

myAccount.deposit(2000);   // ✅ Deposited ₹2000. New balance: ₹7000
myAccount.withdraw(1500);  // 💸 Withdrew ₹1500. New balance: ₹5500
myAccount.getBalance();    // 💰 Rahul's balance: ₹5500

Benefits of Encapsulation:

✅ Organization — related code lives together
✅ Security — data is protected from unintended modification
✅ Reusability — create as many accounts as you need from one class
✅ Debuggability — issues are isolated inside the class

Hands-On Example: Student Class {#hands-on-example}

Let's put everything together with a practical, real-world example.

Step 1 — Define the Class

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

  printDetails() {
    console.log(`
    ─────────────────────────
    👤 Name   : ${this.name}
    🎂 Age    : ${this.age}
    📚 Course : ${this.course}
    ─────────────────────────
    `);
  }

  greet() {
    console.log(`Hello! I'm ${this.name} and I'm studying ${this.course}.`);
  }
}

Step 2 — Create Student Objects

let student1 = new Student("Aman",  21, "Computer Science");
let student2 = new Student("Riya",  22, "Data Science");
let student3 = new Student("Karan", 20, "Web Development");

Step 3 — Use the Objects

student1.printDetails();
student2.greet();
student3.printDetails();

Output:

─────────────────────────
👤 Name   : Aman
🎂 Age    : 21
📚 Course : Computer Science
─────────────────────────

Hello! I'm Riya and I'm studying Data Science.

─────────────────────────
👤 Name   : Karan
🎂 Age    : 20
📚 Course : Web Development
─────────────────────────

One class. Three students. Zero repeated code. That's the power of OOP.

          CLASS: Student
    ─────────────────────────
    name
    age
    course
    printDetails()
    greet()
          │
    ──────┴──────────────────
    │           │           │
    ▼           ▼           ▼
 student1    student2    student3
 Aman        Riya        Karan
 21          22          20
 CS          DS          Web Dev

Why OOP Actually Matters {#why-oop-matters}

You might be thinking: "I could do all this with regular functions." And you're right — for small scripts.

But here's what OOP gives you at scale:

Challenge	Without OOP	With OOP
Managing 50 students	50 separate variable sets	One `Student` class
Adding a new feature	Update code in 50 places	Update the class once
Debugging	Hunt across the entire codebase	Isolate the specific class
Code sharing across teams	Copy-paste chaos	Import and reuse the class

OOP is used everywhere in serious development:

🌐 Web Development — React components, Node.js services
🎮 Game Development — Game entities, physics engines
📱 Mobile Apps — User models, API clients
🏢 Enterprise Software — Domain models, business logic layers

🔑 Key Takeaways

Class      →  The blueprint / template
Object     →  An instance created from the class
Constructor →  Sets up initial state when an object is created
Method     →  A function that defines what an object can do
this       →  Refers to the current object
new        →  The keyword that creates a new object from a class
Encapsulation → Bundling data + behavior together inside a class

🚀 Your Challenge

Try building this on your own:

Create a Book class with:

Properties: title, author, pages
Method describe() that prints all details
Method isLong() that returns true if pages > 300

Create at least 3 book objects and call both methods on each.

Drop your solution in the comments below — I'd love to see what you build! 👇

What's Next?

This is just the beginning of OOP in JavaScript. In the next articles, we'll cover:

🔗 Inheritance — How classes can extend other classes
🔒 Private fields — True data hiding in modern JavaScript
🧩 Polymorphism — One interface, many behaviors
🏭 Abstract patterns — Real-world design patterns

If this helped you, drop a ❤️ and follow for more JavaScript fundamentals explained clearly. No fluff, just code that makes sense.

Understanding Variables and Data Types in JavaScript

Janmejai Singh — Sun, 15 Mar 2026 14:00:17 +0000

JavaScript Variables & Data Types Explained — The Complete Beginner's Guide

Imagine walking into a kitchen with no containers: no jars, no bowls, no bottles.

Flour on the floor. Milk on the counter. Sugar... everywhere.

That's what writing JavaScript without variables looks like.

Variables are containers for your data. They hold values so your program can use them anywhere, anytime — without chaos.

In this guide, you'll learn:

✅ What variables are and why they matter
✅ How to declare variables using var, let, and const
✅ All primitive data types in JavaScript
✅ What scope is and why it matters
✅ Best practices used by real developers

Let's get into it.

📦 What Are Variables and Why Do You Need Them?

A variable is a named storage location that holds a value. You give it a name, assign it data, and use that name to reference the data throughout your code.

let name = "Jai";
let age = 24;

console.log("My name is " + name); // My name is Jai
console.log("My age is " + age);   // My age is 24

Without variables, you'd have to repeat raw values everywhere — and updating them across a large program would be a nightmare.

Why Variables Are Essential

Benefit	Description
Reusability	Write a value once, use it many times
Readability	`userName` is clearer than `"Jai"` hardcoded everywhere
Maintainability	Change the value in one place, it updates everywhere
Dynamic behavior	Programs can respond to user input and changing data

🛠️ How to Declare Variables: `var`, `let`, and `const`

JavaScript gives you three keywords to declare variables. Knowing when to use each one is crucial.

1. `var` — The Old Way (Avoid in Modern Code)

var city = "Kanpur";

var has been around since the beginning of JavaScript. However, it comes with a quirk called function scoping (more on scope below) that leads to confusing bugs.

⚠️ Avoid var in modern JavaScript. It's still valid, but let and const solve its problems cleanly.

2. `let` — For Values That Change

let score = 100;
score = 200; // ✅ Allowed — value updated
console.log(score); // 200

Use let when you need to reassign the variable later — for example, a score that increases, a counter that increments, or a status that toggles.

3. `const` — For Values That Stay Fixed

const pi = 3.14159;
pi = 3; // ❌ TypeError: Assignment to constant variable

const declares a variable whose binding cannot be reassigned. Use it for values that should never change — configuration, constants, fixed references.

💡 Pro Tip: Default to const. Switch to let only when you know the value needs to change. Never use var.

Quick Comparison Table

Feature	`var`	`let`	`const`
Reassignable	✅ Yes	✅ Yes	❌ No
Redeclarable	✅ Yes	❌ No	❌ No
Scope	Function	Block	Block
Hoisted	✅ Yes (as `undefined`)	⚠️ Yes (TDZ)	⚠️ Yes (TDZ)
Modern Usage	Rare	Common	Very Common

🔢 Primitive Data Types in JavaScript

A data type defines what kind of value a variable can hold. JavaScript has 7 primitive types, but as a beginner, these 5 are the ones you'll use constantly.

1. 🔤 String

A string stores text. Wrap it in single quotes, double quotes, or backticks.

let language = "JavaScript";
let greeting = 'Hello, World!';
let message = `Welcome, ${language}!`; // Template literal

Strings support a rich set of built-in methods like .toUpperCase(), .trim(), .includes(), and more.

2. 🔢 Number

JavaScript uses a single Number type for both integers and decimals.

let age = 24;        // integer
let price = 199.99;  // decimal (float)
let negative = -50;  // negative number

Unlike some languages, there is no separate int or float type in JavaScript.

3. ✅ Boolean

A boolean holds one of exactly two values: true or false.

let isLoggedIn = true;
let isStudent = false;

Booleans are the backbone of conditions and logic:

if (isLoggedIn) {
  console.log("Welcome back!");
} else {
  console.log("Please log in.");
}

4. 🚫 Null

null represents an intentionally empty value. You set it yourself to signal "this has no value right now."

let selectedUser = null; // no user selected yet

Think of it as an empty jar — the jar exists, but it's empty on purpose.

5. ❓ Undefined

undefined means a variable has been declared but never assigned a value.

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

JavaScript sets it automatically. You don't usually assign undefined yourself.

`null` vs `undefined` — The Key Difference

This trips up many beginners:

let a = null;      // You explicitly said "empty"
let b;             // JavaScript said "not assigned yet"

console.log(a);    // null
console.log(b);    // undefined
console.log(typeof a); // "object" (quirky legacy behavior!)
console.log(typeof b); // "undefined"

	`null`	`undefined`
Set by	You, intentionally	JavaScript, automatically
Meaning	Intentionally empty	No value assigned yet
`typeof`	`"object"` (historical quirk)	`"undefined"`

🌐 Understanding Scope (Beginner-Friendly)

Scope determines where in your code a variable is accessible.

Think of it like a WiFi signal. Inside the coverage zone — you're connected. Step outside — no signal.

Block Scope (`let` and `const`)

A block is any code wrapped in curly braces {}.

{
  let message = "Hello, block!";
  console.log(message); // ✅ Works here
}

console.log(message); // ❌ ReferenceError: message is not defined

let and const are block scoped — they live and die inside their block.

Function Scope (`var`)

var is scoped to the nearest function, not the block. This is why it causes bugs:

function example() {
  if (true) {
    var x = 10; // var leaks out of the if block
  }
  console.log(x); // ✅ 10 — accessible outside the if block
}

With let, this would correctly throw an error. That's the behavior you want.

Scope Rules at a Glance

var   → function scoped  (unpredictable, avoid)
let   → block scoped     (predictable, modern)
const → block scoped     (predictable, modern)

🗺️ Concept Mind Map

JavaScript Variables
│
├── What Is a Variable?
│     ├── Named storage container
│     ├── Holds a value
│     └── Reusable across the program
│
├── Declaration Keywords
│     ├── var  → old, function-scoped, avoid
│     ├── let  → modern, block-scoped, reassignable
│     └── const → modern, block-scoped, fixed binding
│
├── Primitive Data Types
│     ├── string    → text
│     ├── number    → integers & decimals
│     ├── boolean   → true / false
│     ├── null      → intentionally empty
│     └── undefined → not yet assigned
│
└── Scope
      ├── Where a variable is accessible
      ├── Block scope (let, const)
      └── Function scope (var)

✅ Best Practices Summary

Follow these rules and your code will be cleaner and more professional from day one:

Always use const by default. If the value needs to change, switch to let.
Never use var. It's legacy code and scoping behavior leads to bugs.
Use descriptive names. userAge beats x. isLoggedIn beats flag.
Use camelCase for variable names: firstName, totalPrice, isActive.
Understand null vs undefined. One is intentional; the other is automatic.

🎯 Key Takeaways

Variables are named containers that store data.
Use const for fixed values, let for changing values, and avoid var.
JavaScript has 5 core primitive types: string, number, boolean, null, and undefined.
Scope controls where a variable can be accessed — let and const are block scoped.
Clean variable practices = readable, maintainable, professional code.

🚀 What's Next?

Now that you understand variables and data types, the next logical steps are:

Operators — arithmetic, comparison, logical
Conditionals — if, else, switch
Loops — for, while, forEach
Functions — reusable blocks of logic

These all build directly on top of what you just learned. Stick with it — you're building real foundations now.

Found this helpful? Drop a ❤️ and follow for more JavaScript fundamentals explained clearly. Got questions? Ask in the comments — happy to help.

DEV Community: Janmejai Singh

How WhatsApp Works Without Internet: Offline Messaging and Sync Explained

The Scenario: Sending a Message in Airplane Mode

Local Storage and Message Persistence

The Message Queue

Syncing When Connectivity Returns

Delivery States: Sent, Delivered, Read

Handling Media While Offline

Conflict Resolution and Message Ordering

Why Offline-First Matters

The Full Lifecycle in One Diagram

Building This in React Native

Key Takeaways

What to Explore Next

How Instagram, WhatsApp, Uber & Netflix Would Be Built Today Using Expo Router

Why Social Media Apps Need Efficient Media Storage

How Photos and Videos Are Stored Before Upload

What Happens When a User Saves a Draft

Local Storage vs. Cloud Storage

Uploading Large Media Files Efficiently

1. Chunked / Resumable Uploads

2. Background Uploads

The Upload Queue

Media Processing and Compression

Compression Concepts

Thumbnail Generation and Previews

How Thumbnails Are Created

Low-Quality Image Placeholders (LQIP)

Caching Frequently Viewed Content

Multi-Level Cache Architecture

What Gets Cached

Prefetching: Getting Ahead of the User

Cache Invalidation

Content Delivery Using CDNs

How CDN Delivery Works

Adaptive Bitrate Streaming (ABR)

Managing Storage, Performance, and User Experience

Device Storage Management

Adaptive Behavior Based on Context

Full Architecture: End-to-End

Key Takeaways for Mobile Developers

Wrapping Up

How React's Virtual DOM Works Under the Hood

How React's Virtual DOM Works Under the Hood

The Problem: Why Direct DOM Manipulation Is Slow

The Solution: Virtual DOM as a Lightweight Proxy

Step 1 — Initial Render

Step 2 — State or Props Change

Step 3 — New Virtual DOM Tree is Created

Step 4 — Diffing (Reconciliation)

Different element types → rebuild the subtree

Keys → stable identity for list items

Step 5 — Commit Phase: Minimal Real DOM Updates

Why This Improves Performance

The Full Lifecycle — Visual Summary

Quick Reference: Key Concepts

Things to Know (But Out of Scope Here)

Wrapping Up

How DNS Resolution Works: From `dig . NS` to Your Browser Loading Google

Why Name Resolution Exists

Meet dig — Your DNS Diagnostic Tool

The DNS Hierarchy at a Glance

Layer 1: Root Name Servers — dig . NS

Layer 2: TLD Name Servers — dig com NS

Layer 3: Authoritative Name Servers — dig google.com NS

The Full Resolution — dig google.com

Breaking It Down

The Step-by-Step Flow (Uncached)

Recursive Resolvers: The Unsung Heroes

Why Caching Matters

Popular Public Recursive Resolvers

Mapping dig Commands to DNS Stages

DNS in the Context of Real Browser Requests

Quick Reference Card

Key Takeaways

Resources

Template Literals in JavaScript — From Messy Concatenation to Clean, Modern Strings

Template Literals in JavaScript — From Messy Concatenation to Clean, Modern Strings

The Problem with String Concatenation

The Solution: Template Literal Syntax

Meet `dig` — Your DNS Diagnostic Tool

Layer 1: Root Name Servers — `dig . NS`

Layer 2: TLD Name Servers — `dig com NS`

Layer 3: Authoritative Name Servers — `dig google.com NS`

The Full Resolution — `dig google.com`

Mapping `dig` Commands to DNS Stages

String Interpolation: `${}` Is Your New Best Friend

The `${}` Placeholder Accepts Any Expression

1️⃣ `Array.flat()` — The Native, Modern Way

2️⃣ `flatMap()` — Map + Flatten in One Pass

3️⃣ `reduce()` — The Foundational Approach

❓ "Write your own implementation of `flat()`"

1. `/etc/resolv.conf` — The DNS Brain of Your Machine

2. `/proc/net/route` — Your Routing Table, Unfiltered

3. `/etc/passwd` and `/etc/shadow` — The Auth Split That Saved Linux Security

4. `/proc/PID/fd/` — Every File Your Process Has Open

5. `/etc/hosts` and `/etc/nsswitch.conf` — DNS That Predates DNS

6. `/etc/systemd/system/` — Where Services Are Born

7. `/var/log/auth.log` — Your Machine's Security Diary

8. `/dev/null`, `/dev/zero`, `/dev/urandom` — The Kernel's Built-In Utilities

9. `/proc/meminfo` — Why "Free Memory" Is a Lie

10. `/boot/grub/grub.cfg` — The First Thing That Actually Runs