DEV Community: Masudur Rahman Sourav

Everything You Need To Know About DNS (Domain Name System)

Masudur Rahman Sourav — Sat, 12 Sep 2026 15:48:54 +0000

Imagine trying to memorize the phone number of every person you’ve ever met. Instead, you use a contacts app you type "Jhon," and your phone dials 555-0199. The Domain Name System (DNS) is the internet's contacts app. It translates human-friendly domain names (like netflix.com) into the machine-friendly IP addresses (like 192.0.2.1) that computers use to route data globally.

The Real-World Analogy: Navigating a Mega-City
Think of finding a website like searching for a specific specialty store in a massive, unfamiliar city:

Local Cache: First, you check your own pockets (Browser or OS cache) to see if you have the address written down from a previous visit.

Recursive Resolver: If you don't, you ask a local hotel concierge ( ISP ) to find it for you.

Root Server: The concierge doesn't know, so they call the city's central directory. The central directory points them to the commercial district manager.

TLD Server: The district manager (who handles all .com commerce) points the concierge to the building's specific property manager.

Authoritative Server: The property manager checks their official tenant ledger and gives the concierge the exact suite number.

1.Check Local Cache:Browser and OS Level.

Before asking the internet, your browser checks its own memory. If the IP isn't there, it asks your computer's Operating System cache. If you've visited the site recently, the journey ends here in milliseconds.

2.Query the Recursive Resolver:Usually your ISP.

If the OS doesn't know, it sends the request to a DNS Resolver (often run by your Internet Service Provider, or a public one like Google's 8.8.8.8). This server acts as your personal detective, taking on the heavy lifting of tracking down the IP address.

3.Ask the Root Server:The top of the internet hierarchy.

The resolver asks one of the 13 logical Root Name Servers worldwide. The root server doesn't know the exact IP, but it reads the very end of your URL (the .com or .org part) and directs the resolver to the correct Top-Level Domain server.

4.Ask the TLD Server:Top-Level Domain Manager.

The resolver now queries the specific .com TLD server. This server manages all .com domains globally. It checks its records for your specific domain name (e.g., netflix.com) and points the resolver to the domain's Authoritative Name Server.

5.Query the Authoritative Name Server:The final answer.

The resolver reaches the Authoritative Name Server (managed by whoever hosts the domain's DNS, like AWS Route53 or Cloudflare). This server holds the exact, official DNS records. It hands over the final IP address.

6.Return and Cache:Speeding up future visits.

The resolver returns the IP address to your web browser so it can load the page. Crucially, the resolver, your OS, and your browser all save (cache) this answer for a set period known as the Time-to-Live (TTL)—to skip this entire process next time.

The DNS Record Toolkit

Why System Designers & Software Engineers Must Master DNS

To an everyday user, DNS is just a lookup tool. To a system designer, DNS is the frontline traffic cop of a global architecture.

Global Load Balancing and Latency DNS isn't static. Advanced DNS setups use geolocation routing to analyze where a user is calling from. If a user in Tokyo requests your app, DNS can intelligently hand them the IP address of your Japanese data center, while giving a New York user the IP of your US East data center. This slashes latency before the user even connects to a server.

High Availability and Failover If a hurricane takes out your primary data center, your app goes down. An engineer with strong DNS knowledge will configure automated health checks and failover routing. If the primary IP stops responding, the DNS server instantly stops giving out that IP and seamlessly redirects all new traffic to a backup facility.

The TTL Trap (Time-to-Live) Every DNS record has a TTL—a timer dictating how long devices should cache the answer. If a system designer is planning a major server migration but leaves the TTL set to 24 hours, users' browsers will stubbornly try to connect to the old, dead server for a full day. Mastering TTL is the difference between a zero-downtime migration and a catastrophic outage.

Microservice Discovery Inside modern cloud applications, hundreds of tiny, independent services (like a payment service and a shopping cart service) need to talk to each other. Because containers spin up and down constantly, their internal IP addresses change by the minute. Internal DNS allows "Service A" to find "Service B" simply by calling its name, completely abstracting away the chaotic IP swapping underneath.

Security Posture DNS is a major attack vector. Attackers use "DNS Spoofing" (cache poisoning) to trick a resolver into saving a fake IP address, silently redirecting your users to a malicious clone of your app. Engineers must understand how to implement DNSSEC (DNS Security Extensions) to cryptographically sign their records, guaranteeing users are truly talking to the authoritative source.

Security

Imagine a world where anyone could swap out the street signs in your neighborhood. You try to drive to your bank, but a fake sign directs you to a perfect replica of the bank run by thieves. That’s the exact vulnerability built into the original design of DNS.

Because DNS was built in the 1980s an era of high trust and low security it assumed every answer it received was honest. Today, system designers and engineers must build defenses against this assumption.

The Threat: DNS Spoofing (Cache Poisoning)

When your local resolver (like your ISP) asks the internet for the IP address of mybank.com, it waits for a response. In a DNS Spoofing attack, a hacker races to answer the resolver before the legitimate authoritative server can.

If the hacker wins the race, they hand the resolver a fake IP address pointing to their malicious server. Worse, the resolver caches (memorizes) this fake answer. Now, every single person using that ISP who types in mybank.com is silently redirected to the hacker's fake login page.

The Shield: DNSSEC (DNS Security Extensions)

To stop someone from forging street signs, you need a way to prove who put the sign there. DNSSEC acts like a digital wax seal on every DNS answer.

Instead of just returning the IP address (the A Record), a DNSSEC-enabled server returns the IP address and a cryptographic signature (the RRSIG record).

Here is how the chain of trust works:

The Zone Signing Key (ZSK): Your DNS provider uses a private key to mathematically sign your DNS records.

The Key Signing Key (KSK): To prove the ZSK is legitimate, a stronger key (the KSK) signs the ZSK.

The Chain of Trust: Your KSK is verified by the Top-Level Domain (like .com), which is verified by the Root Server.

When a user's resolver receives the answer, it uses public keys to verify the signature. If a hacker tries to spoof the answer, they won't have your private key. The signature will fail, the resolver will reject the fake IP, and the user is protected.

Engineering Reality Check: Implementing DNSSEC isn't a simple toggle switch. It requires careful key management. If your keys expire or roll over incorrectly, resolvers will reject your legitimate records, effectively deleting your website from the internet.

How DNS handles load balancing?

If you build a blazing-fast application but host it exclusively in New York, a user in Tokyo will still experience a sluggish, frustrating delay. The speed of light is a hard physical limit, and every network hop adds latency.

To solve this, system designers deploy applications globally and use two powerful DNS techniques to ensure users are always connected to the server closest to them: Geographic Routing and DNS Anycast.

1. Geographic Routing (Geo-DNS): The Smart Operator

Think of Geo-DNS like calling a national pizza delivery number. You dial one central number, but the system looks at your area code and connects you to the specific franchise five minutes from your house.

Instead of an area code, Geo-DNS looks at the IP address of the user's recursive resolver.

When the DNS query reaches your authoritative server, the server doesn't just hand out a static answer. Instead, it:

Compares the user's IP against a massive, continuously updated GeoIP database.

Determines the user is located in Tokyo.

Looks at your routing policy and returns the specific IP address of your Tokyo data center, rather than your New York or London facilities.

This happens at the application logic layer of DNS. The DNS server is actively making a decision to hand out different answers (different IP addresses) based on who is asking.

2. DNS Anycast: The Network Illusion

If Geo-DNS is a smart operator handing out different addresses, Anycast is an illusion where multiple physical locations share the exact same address.

Think of the emergency number "911". There isn't just one giant 911 call center for the entire country. There are thousands. But you dial the exact same number everywhere, and the underlying phone network routes you to the closest one.

Anycast does this for IP addresses using the internet's core routing protocol, BGP (Border Gateway Protocol).

Unicast (Standard): One IP address points to exactly one physical server.
Anycast: Multiple physical servers across the globe announce to the internet that they are the destination for a single IP address (like Google's famous 8.8.8.8 DNS resolver).

When a user's computer sends a packet to an Anycast IP, the internet's core routers look at the map and simply send the packet down the shortest physical path. The user naturally hits the server closest to them without the DNS server needing to perform any GeoIP lookups.

Why Engineers Love Anycast for Security

Anycast isn't just about speed; it is the ultimate defense against Distributed Denial of Service (DDoS) attacks.

If a massive botnet tries to flood a Unicast IP with malicious traffic, that single server gets overwhelmed and dies. If a botnet attacks an Anycast IP, the malicious traffic from a compromised computer in Brazil goes to the Brazilian server, while the attack traffic from Germany goes to the German server. The attack is naturally fragmented and absorbed by your global edge network, rather than concentrating on a single point of failure.

How BGP Actually Calculates The Shortest Path?

The internet is not a single, giant cloud; it is a massive patchwork quilt of smaller, independent networks. These networks run by ISPs (like Comcast or Vodafone), tech giants (like Google or AWS), and large universities—are called Autonomous Systems (AS).

If you want to send data from an AS in London to an AS in Tokyo, you need a way to figure out which overlapping patches of the quilt to cross. That is exactly what BGP (Border Gateway Protocol) does. It is the postal sorting system of the internet.

How BGP Routes Traffic: The "AS Path"

nside your home network, your router uses protocols that measure connection speeds, bandwidth, or latency to find the fastest path. BGP does not care about any of that.

BGP is a Path Vector Protocol. Its primary metric for determining the "best" or "shortest" route is simply counting the number of Autonomous Systems the data has to jump through. This list of hops is called the AS_PATH.

The Announcement: A router in AS-500 tells its neighbor, "Hey, I can reach IP address 1.1.1.1."
The Propagation: That neighbor (AS-400) tells its neighbor, "I can reach 1.1.1.1, and the path is [AS-400, AS-500]."
The Decision: Your local ISP router (AS-100) might receive two announcements for 1.1.1.1.

Path A: AS-200, AS-300, AS-400, AS-500
Path B: AS-600, AS-500

Your router looks at the AS_PATH length, sees that Path B has fewer hops, and updates its routing table to send all traffic for 1.1.1.1 toward AS-600.

BGP Meets Anycast: The Shortest Path Wins

In a standard setup, only one AS in the world announces a specific IP address. But in an Anycast setup (used by Cloudflare, AWS Route53, and Google DNS), multiple data centers across the globe announce the exact same IP address simultaneously.

Because BGP is fundamentally designed to find the shortest AS_PATH to a given destination, Anycast exploits this feature perfectly:

Data Center A (New York) announces it hosts 8.8.8.8.
Data Center B (Tokyo) announces it hosts 8.8.8.8.
Data Center C (London) announces it hosts 8.8.8.8.

When a user in Paris tries to reach 8.8.8.8, their ISP's BGP router looks at the global routing tables. It sees that the AS_PATH to London is only 2 hops, New York is 5 hops, and Tokyo is 8 hops. BGP automatically sends the Parisian user's traffic to London.

BGP Anycast Routing Simulator

Why Engineers Must Understand BGP

While Anycast and BGP provide incredible resilience, they rely on a system built in 1989 that operates entirely on "trust."

If an engineer misconfigures a BGP router in a small ISP in Brazil and accidentally announces, "I have a 1-hop path to Google's servers," the global internet might believe them. This is called a BGP Route Leak or BGP Hijacking. Traffic intended for Google will suddenly flood into that small Brazilian ISP, crashing their network and taking Google offline for millions of users.

Understanding BGP means understanding that the internet's core routing is a fragile web of trust, and deploying Anycast requires extreme care in how you announce your IP addresses to the global backbone.

How do we prevent BGP Hijacking?

BGP was built on a handshake system if a router claims it owns an IP address, the rest of the internet generally believes it. This trust model is what enables a BGP Hijack: a malicious (or misconfigured) network simply announces to the world, "I am the shortest path to Google's IP addresses." Without verification, global traffic blindly reroutes into the hijacker's network.

RPKI (Resource Public Key Infrastructure) is the cryptographic upgrade the internet needs to fix this. It replaces blind trust with mathematically verifiable proof of ownership.

How RPKI Secures the Route

Think of RPKI like a digital passport control for BGP route announcements.

Before an Autonomous System (AS) can legitimately announce an IP prefix to the internet, the true owner of that IP block must create a cryptographic certificate. This certificate is called a ROA (Route Origin Authorization).

A ROA explicitly states two things:

The IP Prefix: (e.g., 192.0.2.0/24)

The Origin AS: The exact Autonomous System Number (e.g., AS65005) authorized to announce it.

Route Origin Validation (ROV) in Action

When a major ISP (like Comcast or AT&T) runs a BGP router with RPKI enforced, it performs Route Origin Validation (ROV) on every announcement it receives.

Here is how the router filters the traffic:

Valid: The BGP announcement says AS65005 originates 192.0.2.0/24. The router checks the global RPKI database, finds a matching ROA, and accepts the route. Traffic flows normally.
Invalid (The Hijack): A malicious network, AS65002, suddenly announces 192.0.2.0/24. The router checks the RPKI database. The ROA says only AS65005 is allowed to announce those IPs. The router instantly marks the malicious announcement as Invalid and drops it. The hijack is blocked.
Unknown: If the IP owner hasn't created a ROA yet, the route is marked "Unknown." Most routers will still accept this to avoid breaking the internet, but they will prefer "Valid" routes if a conflict arises.

BGP Hijack & RPKI Protection Simulator

Why RPKI Matters to System Designers

For a software engineer or system designer, understanding RPKI is critical for protecting the application layer:

DDoS Mitigation: Attackers often use BGP route leaks to sinkhole your traffic or overwhelm a small segment of your network. Registering your IPs with strict ROAs ensures that major transit providers will drop malicious reroutes before they impact your users.
Compliance & Trust: If you are designing fintech, healthcare, or government systems, traffic interception is a catastrophic breach. RPKI guarantees that your data physically reaches the correct data center and isn't silently diverted to a rogue network for packet sniffing.
The "Fat Finger" Defense: Most BGP leaks aren't malicious; they are typos by tired engineers. RPKI ensures that if an engineer at a regional ISP accidentally announces your IP space, the global internet will cryptographically reject the typo, preventing an accidental global outage.

How BGP Relates To CDNs?

Without a CDN, every single user across the globe has to travel to your one "Origin Server" (let's say, in New York) to fetch a website's images, videos, and HTML. A user in Sydney might wait 300 milliseconds just for the data to travel back and forth.

CDNs like Cloudflare, Fastly, and Akamai solve this by building hundreds of mini data centers called Points of Presence (PoPs) or Edge Servers—in almost every major city on Earth. They tie all of these servers together using BGP Anycast.

The CDN + Anycast Workflow

When you put your application behind a CDN, you configure your DNS so that yourwebsite.com resolves to an Anycast IP address provided by the CDN (e.g., 104.16.124.96).

Every single CDN Edge Server in the world announces to the internet that it is 104.16.124.96.

Here is exactly what happens when a user in Sydney types in your URL:

1.BGP Routes to the Edge:The Sydney user's ISP looks at the BGP routing tables. It sees that the shortest physical path to 104.16.124.96 is the CDN's Sydney Edge Server, not the one in New York or London. The user is instantly connected to a server in their own city.

2.Check the Cache (Cache Hit):Blazing fast response.The Sydney Edge Server checks its local hard drives: "Do I have a copy of yourwebsite.com/logo.png?" If another user in Sydney recently loaded that image, the Edge Server will have it saved (a Cache Hit). It sends the image to the user in 10 milliseconds. The request never even touches your New York server.

3.Contact the Origin (Cache Miss):Fetching the master copy.If the Sydney Edge Server does not have the image (a Cache Miss), it acts as a proxy. The Edge Server opens a dedicated, high-speed connection back to your New York Origin Server, fetches the image, sends it to the user, and saves a copy for the next person in Sydney.

Why System Designers Rely on CDNs

Deploying a CDN isn't just about making images load faster; it fundamentally changes the architecture and economics of scaling a global application.

React Compound Components: The "Build Your Own Adventure" Pattern

Masudur Rahman Sourav — Mon, 16 Feb 2026 11:07:40 +0000

If you've ever bought a piece of furniture from a certain Swedish store, you know the drill. You don't buy a pre-assembled "Sitting Unit." You buy a frame, cushions, legs, and maybe a weird little wrench, and you put it together yourself.
Compound Components are the Ikea furniture of React.

Instead of building one giant, monolithic component that takes 500 props (), you build a set of smaller components that work together like magic. They share state behind the scenes, but you decide where everything goes.

Let's dive into the pattern that makes libraries like Radix UI and Headless UI possible.

🎨 The Graphical Explanation

Imagine you are building a Tabs component.

The "Mega-Prop" Way (The Old Way) 🦖

You pass a giant configuration object. The component decides the layout. You have zero control. If you want to move the "Tab List" below the "Panels," you have to rewrite the library.


       +-----------------------------+
       |      <Tabs config={...} />  |
       +-----------------------------+
       | [Tab 1] [Tab 2] [Tab 3]     |  <-- Hardcoded position
       |                             |
       |  Content for Tab 1...       |
       +-----------------------------+

The Compound Component Way (The Flexible Way) 🤸

You export a parent (Tabs) and several children (Tab, Panel). The Parent holds the state (which tab is active), but the User decides the layout.

       <Tabs>
          <TabList>  <-- You put this where YOU want
             <Tab>One</Tab>
             <Tab>Two</Tab>
          </TabList>

          <TabPanels>
             <Panel>Content 1</Panel>
             <Panel>Content 2</Panel>
          </TabPanels>
       </Tabs>

The Parent (Tabs) secretly passes state to the children using Context. They communicate telepathically. 🧠✨

💻 The Code: From "Prop Hell" to "Component Heaven"

Let's build a simple Accordion (toggle sections).

1. The Setup (Creating the Context)

First, we need a secret channel for our components to talk.

import React, { createContext, useContext, useState } from 'react';

// 1. Create the Context
const AccordionContext = createContext();

// 2. Create the Parent Component
const Accordion = ({ children }) => {
  const [openIndex, setOpenIndex] = useState(0);

  // The toggle function logic
  const toggleIndex = (index) => {
    setOpenIndex(prev => (prev === index ? null : index));
  };

  return (
    <AccordionContext.Provider value={{ openIndex, toggleIndex }}>
      <div className="accordion-wrapper">
        {children}
      </div>
    </AccordionContext.Provider>
  );
};

2. The Children (Consuming the Context)

Now we create the sub-components. Notice they don't accept isOpen or onClick as props from the user. They grab it from the Context!

// 3. The Item Component (Just a wrapper, usually)
const AccordionItem = ({ children }) => {
  return <div className="accordion-item">{children}</div>;
};

// 4. The Trigger (The clickable part)
const AccordionHeader = ({ children, index }) => {
  const { toggleIndex, openIndex } = useContext(AccordionContext);
  const isActive = openIndex === index;

  return (
    <button 
      className={`accordion-header ${isActive ? 'active' : ''}`}
      onClick={() => toggleIndex(index)}
    >
      {children} {isActive ? '🔽' : '▶️'}
    </button>
  );
};

// 5. The Content (The hidden part)
const AccordionPanel = ({ children, index }) => {
  const { openIndex } = useContext(AccordionContext);

  if (openIndex !== index) return null;

  return <div className="accordion-panel">{children}</div>;
};

// Attach sub-components to the Parent for cleaner imports (Optional but cool)
Accordion.Item = AccordionItem;
Accordion.Header = AccordionHeader;
Accordion.Panel = AccordionPanel;

export default Accordion;

3. Usage (The Magic Moment) 🪄

Look how clean this API is. No complex config objects. Just JSX.

import Accordion from './Accordion';

const FAQ = () => (
  <Accordion>

    <Accordion.Item>
      <Accordion.Header index={0}>Is React hard?</Accordion.Header>
      <Accordion.Panel index={0}>
        Only until you understand `useEffect`. Then it's just chaotic.
      </Accordion.Panel>
    </Accordion.Item>

    <Accordion.Item>
      <Accordion.Header index={1}>Why use Compound Components?</Accordion.Header>
      <Accordion.Panel index={1}>
        Because passing 50 props is bad for your blood pressure.
      </Accordion.Panel>
    </Accordion.Item>

  </Accordion>
);

🏆 Why Should You Do This? (Use Cases)

1. UI Libraries (Tabs, Selects, Menus)

If you are building a design system, this is mandatory. Users will want to put an icon inside the Tab, or move the Label below the Input. Compound components let them do that without bugging you to add a renderLabelBottom prop.

2. Implicit State Sharing

Notice how Accordion.Header automatically knew how to toggle the panel? The user didn't have to wire up onClick={() => setIndex(1)} manually. It "Just Works".

3. Semantic Structure

It reads like HTML. <List><Item /><Item /></List>. It’s declarative and beautiful.

🕳️ The Pitfalls (The "Gotchas")

1. The "Single Child" Restriction

If you try to wrap a child in a <div> that blocks the Context (rare with Context API, but common with the older React.Children.map approach), things break.

Fix: Stick to the Context API pattern shown above. It penetrates through divs like X-rays.

2. Over-Engineering

Don't use this for a simple Button. If a component doesn't have internal state that needs to be shared among multiple distinct children, you probably just need regular props.

3. Name Pollution

If you export Accordion, AccordionItem, AccordionHeader, AccordionPanel, your imports get messy.

Fix: Attach them to the main component: Accordion.Item. It keeps the namespace clean and makes you look like a pro.

🏁 Conclusion
The Compound Component Pattern is the difference between giving someone a fish (a rigid component) and teaching them to fish (a flexible set of tools).

It requires a bit more setup code for you (the library author), but it creates a delightful experience for the developer using your component. And isn't that what we all want? To be loved by other developers? (Please validate me). 🥺🤝

React Form Patterns: Controlled vs. Uncontrolled Components

Masudur Rahman Sourav — Fri, 06 Feb 2026 05:57:38 +0000

If React components were people, Controlled Components would be that friend who plans every minute of their vacation in an Excel spreadsheet. Uncontrolled Components would be the friend who shows up at the airport without a ticket, wearing flip-flops, saying, "The universe will provide."

Handling forms in React forces you to choose a side. Do you want to micro-manage every keystroke? Or do you want to let the DOM do its thing and just check the results later?

Let's break down the battle between Controlled and Uncontrolled forms.

🎮 The Controlled Component (The Micro-Manager)

In a Controlled setup, React is the single source of truth. The DOM input doesn't breathe without React's permission.

How it works:

The User types 'A'.
React says, "Hold on, let me update my State first."
React updates State to 'A'.
React tells the Input: "Okay, now you can display 'A'."

It’s a tight feedback loop. It’s secure. It’s predictable. It’s also a little exhausting.

🎨 The Graphical Explanation


    User Types 'H'
           |
           v
  +------------------+
  |  Event Handler   |  "Hey React, they typed H!"
  +--------+---------+
           |
           v
  +------------------+
  |   React State    |  "Updating state to 'H'..."
  +--------+---------+
           |
           v
  +------------------+
  |   Input Value    |  "Displaying 'H' as ordered, sir!"
  +------------------+

💻 The Code

import React, { useState } from 'react';

const ControlFreakForm = () => {
  const [name, setName] = useState('');

  const handleChange = (e) => {
    const value = e.target.value;
    // We can intercept! NO LOWERCASE ALLOWED! 👮‍♂️
    setName(value.toUpperCase());
  };

  return (
    <form>
      <label>Name (Screaming only):</label>
      <input 
        type="text" 
        value={name} 
        onChange={handleChange} 
      />
      <p>Current State: {name}</p>
    </form>
  );
};

✅ Use Case: When you need instant validation (password strength meters), dynamic formatting (credit card spacing), or conditional disabling of the submit button.

🐎 The Uncontrolled Component (The "It Is What It Is")

In an Uncontrolled setup, the data lives in the DOM, not in React state. React is like a landlord who owns the building but doesn't have a key to your apartment. When React needs the data (like on submit), it has to knock on the door (using a ref) and ask, "Hey, what did you write in there?"

How it works:

The User types 'A'.
The Input displays 'A'.
React is asleep.
User hits "Submit".
React wakes up and checks the Ref to see what happened.

🎨 The Graphical Explanation

      User Types 'H'
           |
           v
  +------------------+
  |   DOM Input      |  "I got this. I'll hold the 'H'."
  +------------------+
           |
           | (React ignores this part)
           |
      User Clicks Submit
           |
           v
  +------------------+
  |    React Ref     |  "Yo DOM, what's the value?"
  +------------------+

💻 The Code

import React, { useRef } from 'react';

const WildWestForm = () => {
  const nameInputRef = useRef(null);

  const handleSubmit = (e) => {
    e.preventDefault();
    // Knocking on the DOM's door ✊
    alert(`Welcome, ${nameInputRef.current.value}!`);
  };

  return (
    <form onSubmit={handleSubmit}>
      <label>Name (I don't care until you submit):</label>
      <input 
        type="text" 
        defaultValue="" 
        ref={nameInputRef} 
      />
      <button type="submit">Submit</button>
    </form>
  );
};

✅ Use Case: When you are migrating legacy code, integrating with non-React libraries (like jQuery plugins... shudder), or building simple forms where you don't need instant validation.

🥊 The Showdown: Comparison

Feature	Controlled	Uncontrolled
Source of Truth	React State	The DOM
Data Access	Instant (on every keystroke)	On Demand (usually submit)
Validation	Real-time (as you type)	On Submit
Performance	Re-renders on every keystroke	Only re-renders on submit
Code Volume	More boilerplate (handlers, state)	Less boilerplate (refs)

🕳️ The Pitfalls (Gotchas)

1. The "File Input" Exception 📁

In React, an is always uncontrolled because its value can only be set by a user, not by code (security reasons). If you try to control a file input value, React will yell at you. Just use a Ref.

2. The Performance Myth 🐌

People say Controlled components are slower because they re-render on every keystroke. Unless you are pasting the entire script of The Bee Movie into a text area on a low-end Android phone from 2015, it usually doesn't matter. React is fast. Don't optimize prematurely.

3. The null vs undefined Trap 🪤

If you initialize a controlled input with value={undefined} (or null) and then switch it to a string later, React will scream: "A component is changing an uncontrolled input of type text to be controlled."
Fix: Always initialize state with an empty string useState('').

🏁 Conclusion

So, which one should you choose?

Controlled is the standard. It’s robust, "React-y," and allows you to do cool things like disable the submit button if the email is invalid. It’s high-maintenance but high-reward.

Uncontrolled is the quick-and-dirty. It’s great for quick hacks, simple forms, or when you just don't want to write a handleChange function for the 100th time today.

The Container & Presentational Pattern: Separation of Concerns in React

Masudur Rahman Sourav — Wed, 04 Feb 2026 05:23:14 +0000

If you’ve been writing React for a while, you’ve probably created a "God Component." You know the one. It fetches data, manages fifty state variables, handles form validation, calculates the Fibonacci sequence for some reason, and also renders the HTML. It’s a messy, co-dependent relationship where everyone is screaming.

Enter the Container/Presentational Pattern (also known as Smart vs. Dumb components, though we try to be nicer about the naming these days). It’s couples therapy for your code.

🎨 The Graphical Explanation

Imagine a high-end restaurant.

The Container ( The Chef / Manager ): Sweating in the back. Dealing with suppliers (APIs), managing inventory (State), and screaming about hygiene standards (Business Logic). They don't care what the plate looks like; they just care that the food exists.

The Presentational ( The Waiter / Plater ): Takes the prepared food, arranges it beautifully, and smiles at the customer. They don't know how the sausage is made, and frankly, they don't want to know.

Here is how it looks in your app structure:

   +-------------------------+
   |   CONTAINER COMPONENT   |
   |  (The Brains / Logic)   |
   +-------------------------+
   | 1. Fetches Data (API)   |
   | 2. Manages State        |
   | 3. Defines Handlers     |
   +-----------+-------------+
               |
    (Passes Data via Props)
               |
               v
   +-------------------------+
   | PRESENTATIONAL COMPONENT|
   |  (The Looks / UI)       |
   +-------------------------+
   | 1. Receives props       |
   | 2. Renders JSX / CSS    |
   | 3. Looks Fabulous       |
   +-------------------------+

💻 The Code: A Tale of Two Components

Let's look at a classic example: A list of Crypto Currencies.

1. The Presentational Component (The "Pretty" One)

This component is pure. It has no idea where the data comes from. It just takes props and turns them into pixels. It has zero anxiety.


// CryptoList.jsx
import React from 'react';

const CryptoList = ({ coins, isLoading, onRefresh }) => {
  if (isLoading) {
    return <div className="spinner">Loading your digital gold...</div>;
  }

  return (
    <div className="crypto-card">
      <h2>🚀 To The Moon!</h2>
      <ul>
        {coins.map((coin) => (
          <li key={coin.id} className="coin-row">
            <strong>{coin.name}</strong>: ${coin.price.toFixed(2)}
          </li>
        ))}
      </ul>
      <button onClick={onRefresh}>Refresh Prices</button>
    </div>
  );
};

export default CryptoList;

2. The Container Component (The "Smart" One)

This component does the heavy lifting. It doesn't care about CSS classes. It cares about useEffect, fetch, and handling errors without crying.

// CryptoListContainer.jsx
import React, { useState, useEffect } from 'react';
import CryptoList from './CryptoList';

const CryptoListContainer = () => {
  const [coins, setCoins] = useState([]);
  const [loading, setLoading] = useState(true);

  const fetchCoinData = async () => {
    setLoading(true);
    // Simulating an API call because I don't have an API key handy
    setTimeout(() => {
      setCoins([
        { id: 1, name: 'Bitcoin', price: 45000 },
        { id: 2, name: 'Ethereum', price: 3200 },
        { id: 3, name: 'Doge', price: 0.12 },
      ]);
      setLoading(false);
    }, 1000);
  };

  useEffect(() => {
    fetchCoinData();
  }, []);

  // Notice: No HTML here, just passing data down!
  return (
    <CryptoList 
      coins={coins} 
      isLoading={loading} 
      onRefresh={fetchCoinData} 
    />
  );
};

export default CryptoListContainer;

🏆 Why Should You Do This? (Use Cases)

1. Reusability (The Outfit Change)

You can use the same CryptoList UI to display data from a different source (like a "Favorites" list vs "All Coins" list) without rewriting the styling logic.

2. Separation of Concerns (Mental Health)

When you need to fix a styling bug (margin issues, ugh), you open the Presentational file. When the data isn't loading, you open the Container. You don't have to scroll past 400 lines of logic to find the

tag.

3. Designer/Developer Harmony

If you have a designer on your team who knows HTML/CSS but is scared of useEffect, they can work safely in the Presentational files without accidentally creating an infinite render loop that crashes the browser.

🕳️ The Pitfalls (The "Gotchas")

1. The "Hook" Twist

Plot twist! Since React Hooks (useCustomHook) came out in 2019, strictly creating "Container Components" (class-style) is less common.
Nowadays, the Container is often replaced by a Custom Hook.

Old Way:
Container Component wraps UI Component.
New Way:
UI Component calls useCryptoData() hook.
Verdict:
The concept (separation of logic/view) is still king, but the implementation has shifted.

2. Over-Engineering

Don't create a Container/Presenter pair for a simple "Submit Button." If a component is 10 lines of code, splitting it into two files just makes you look pretentious. Keep it simple.

3. Prop Drilling Hell

If you have containers inside containers inside containers, passing props down becomes a nightmare. If you find yourself passing user={user} down 15 levels, stop. Get help. Use Context.

🏁 Conclusion

The Container/Presentational pattern is like separating your laundry into "Whites" and "Colors." It takes a little extra effort upfront, but it prevents your codebase from turning into a muddy, grey mess later on.

Keep your UI dumb and your logic smart, and your React app will be a happy place. 🚀

Understanding Hoisting in JavaScript: Why Can We Use `var` Before Declaration?

Masudur Rahman Sourav — Tue, 25 Mar 2025 19:37:37 +0000

Hoisting is a fundamental concept in JavaScript that often confuses beginners. You might have seen situations where a variable declared using var is accessed even before it is defined in the code, without throwing an error. How does that work?

To understand this, let's dive into hoisting, the JavaScript execution context, and how the JavaScript engine processes code.

What is Hoisting?

Hoisting is JavaScript’s default behavior of moving variable and function declarations to the top of their scope before execution. This means JavaScript allocates memory for variables and functions during the creation phase of execution, making them available before the code actually runs.

But there’s an important distinction:

Function declarations are hoisted with their definitions, meaning you can call a function before declaring it.
Variables declared with var are hoisted but initialized with undefined, meaning you can reference them before declaration, but they won't hold their actual value until the assignment line is executed.
let and const variables are hoisted but not initialized, so accessing them before declaration results in a ReferenceError.

The JavaScript Execution Context and Hoisting

If don't know what is JavaScript Execution Context or doesn't have a full understanding of it read my this article :

Behind the Scenes of JavaScript: How Execution Works with Execution Context & Call Stack

JavaScript executes code in two phases inside the Execution Context:

Creation Phase (Memory Allocation)

The JavaScript engine scans the code and sets up the execution context.
It allocates memory for variables and functions.
Functions are stored with their full definitions.
Variables declared with var are set to undefined.
let and const variables are stored but are not initialized, causing the Temporal Dead Zone (TDZ) error if accessed before declaration.

Execution Phase (Code Execution)

JavaScript runs the code line by line.
Variable values get assigned during execution.
Function calls are executed where they appear.

Example: Hoisting with `var`

console.log(x); // Output: undefined
var x = 10;
console.log(x); // Output: 10

Behind the Scenes (How JavaScript Executes It)

During the Creation Phase, JavaScript sees var x = 10; and does the following:

Declares x and assigns it undefined in memory.
The console.log(x); at the top executes, printing undefined.
When the execution reaches x = 10;, it assigns 10 to x.
The second console.log(x); prints 10.

The hoisting behavior explains why console.log(x) doesn’t throw an error but prints undefined instead.

Why Doesn’t `let` and `const` Work the Same Way?

console.log(y); // ReferenceError: Cannot access 'y' before initialization
let y = 20;

Here, y is hoisted, but it remains uninitialized in a Temporal Dead Zone (TDZ) until the execution reaches let y = 20;. This protects developers from accidental errors by ensuring variables cannot be accessed before assignment.

Hoisting with Functions

Unlike var, function declarations are fully hoisted with their definitions.

greet(); // Output: Hello, World!

function greet() {
    console.log("Hello, World!");
}

JavaScript hoists the entire function definition, so calling greet() before its declaration works perfectly.

Notes:

Hoisting moves variable and function declarations to the top of their scope before execution.
var variables are hoisted and initialized as undefined, allowing access before declaration.
let and const are hoisted but remain uninitialized, causing a ReferenceError if accessed before declaration.
Function declarations are fully hoisted, meaning they can be called before being defined.
Hoisting helps JavaScript interpret code efficiently but can lead to unexpected behavior if not understood properly.

Best Practices to Avoid Hoisting Issues

Always declare variables at the beginning of their scope.
Prefer let and const over var to avoid unintended undefined values.
Declare and initialize variables at the same time to avoid unexpected results.
Use arrow function (const func = () => {}) instead of function declarations if you don’t want them to be hoisted.

Behind the Scenes of JavaScript: How Execution Works with Execution Context & Call Stack

Masudur Rahman Sourav — Sat, 22 Mar 2025 04:18:08 +0000

Since there’s a lot to cover, grab a coffee and stay focused! Each section connects to the next, so if you skip one, you might miss something important. Let’s dive in and make sense of it all together!

Execution of JavaScript:

JavaScript runs code one step at a time because it's a synchronous, single-threaded language. But how does it manage everything?

It all comes down to the execution context, which is like a backstage manager for your code. JavaScript uses the call stack to keep track of what’s running. Every piece of code gets its own execution context, starting with a global execution context and adding temporary ones as needed.

So, what exactly is an execution context, and how does it work? Let’s break it down!

Execution Context in JavaScript:

It is a container or box-like model consisting of two blocks. The first block manages memory allocation for variables and functions, using a key-value pair mapping. This is also known as the variable environment. The second block handles line-by-line code execution and is referred to as the thread of execution. It's important to note that JavaScript can only execute one line or command at a time. Upon running JavaScript code, an execution context is immediately created to facilitate program execution.

notes:

Memory block also known as Variable Environment.
Code block also known as the thread of execution.

Example for in-depth exploration:
Here I will use the example which is most commonly used to understand execution context of JavaScript:

1. var n = 2;
2. function square(num) {
3.         var squareValue = num * num;
4.         return squareValue;
5. }
6. var squareOfTwo = square(n);
7. var squareOfThree = square(3);

Execution context have two phases:

Memory creation phase
Code execution phase

Phase 1: Memory Creation

Here all variables name will be the key and stored on the memory as code execution isn't happened yet all the values of the variable will be undefined. The functions name and body will be stored on the memory block as it is.

notes:

All variables value will be undefined in this phase
Functions will be stored in memory without any change of it's body.

*Phase 2: Code Execution
*
Here all the command or statement of the code executed line by line top to bottom. While executing line by line it assign the value of the key in the memory block and skip the body of a function until it invoked on the code. Function is a beautiful entity in JavaScript. In JavaScript for every function there will be a function execution context or temporally execution context.

Here, we can see in that after executing the 1st line of the code n is not undefined anymore it gets replaced by 2.

After executing 1st line the code execution skip the function and try to execute the 6th line and here this encounter a function invoke. So, as I said before a new functional or temporally execution context will be created. There will be also 2 phases as global execution context. When a functional execution context encounter a return the it get deleted from the call stack.

Here, memory creation phase happened on functional execution context and as parameter also a variable of the function. Then it stored in memory as undefined initially. After the memory creation phase the code execution phase start. The value of num = n so, num = 2 and squareValue = num * num so, squareValue = 2 * 2 = 4.

After this on code execution in functional execution context encounter return. As I said previously if code execution in a function encounter return the functional execution context of that function deleted immediately.So for our code the functional execution context get deleted and it returns the value to the global execution context. In the line of 6 after invoke the function we get the value of squareOfTwo or squareOfTwo = 4

Now, you know what happen while executing the 7th line of the code. Here, is another function invoke.Another functional execution context will be created and it will go through all two phases of execution context and finally get deleted. You can try it by your own. Now the mystery is how JavaScript handle all those complex global and functional execution? Simply with the call stack of JavaScript.

Handling Execution context with Call Stack:

The Call Stack is like a to-do list for your code, built with execution contexts. Think of it as a stack of boxes. The bottom box is the Global Execution Context – the starting point. When a function runs, a new box (its Function Execution Context) gets stacked on top. Once that function finishes, its box is removed, or 'popped' off. This keeps happening until all function boxes are gone, and finally, the Global box is also removed, signaling the end of your program's run.

I hope this explanation helped you understand how JavaScript runs. It's like a neat little dance of boxes and lists, right? If you still don't think JavaScript is interesting, maybe you just haven't seen all it can do yet. Try learning more about it – you might find it's cooler than you thought.

After this article read the article below to know about JavaScript hoisting :

Understanding Hoisting in JavaScript: Why Can We Use var Before Declaration?

How Make Text-Formatter with Download functionality with JS

Masudur Rahman Sourav — Wed, 05 Jan 2022 18:54:32 +0000

Hey,
Hope you all are doing good. Today we are going to learn how to make a Text-Formatter or Case converter with JS and little bit of HTML and CSS. First what is a text-formatter or case converter. It is a simple application which will format your text in a proper way. TextFormatter is the text engine that provides services for formatting text and breaking text lines. TextFormatter can handle different text character formats and paragraph styles, and includes support for international text layout.

What we will need for this. We just need a input field and some button and we will write some logic with JS to make those proper.

first start with the HTML.Here is my HTML code:

index.html

<!Doctype html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Case Converter</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
<div class="title"><h1>Case Converter</h1></div>
<div class="text">
    <textarea></textarea>
</div>
<div class="buttons">
    <button id="upper-case">Upper Case</button>
    <button id="lower-case">Lower Case</button>
    <button id="proper-case">Proper Case</button>
    <button id="sentence-case">Sentence Case</button>
    <button id="save-text-file">Save The File</button>
</div>
<script src="main.js"></script>
</body>
</html>

The HTML looks so simple right? Yes, this project will also very easy for you. Let discuss about the HTML first. Here we have a textarea and five buttons. The first button which called Uppercase will convert all letters to uppercase. The button which called lowercase will convert all case to lower case .Proper case will make fist letter of every word capital or uppercase and Sentence case will make all the text to sentence case. What about the Save the file button ? With this you can download your converted text into a .txt file.

We added our main.js file at script tag and we link our CSS style sheet with the link tag inside the head. I hope you understand what I did into the HTML file.

Now we will add some style init.You can style your application how you like. Here is my style file:

style.css

@import url('https://fonts.googleapis.com/css2?family=Roboto+Slab&display=swap');
button{
    background-color: #FFA07A;
    padding: 0.7rem;
    border: none;
    border-radius: 0.3rem;
    margin: 1rem;
    font-size: large;
}
.buttons{
    text-align: center;
}
textarea{
    width: 70rem;
    height: 27rem;
    border-radius: 1rem;
    padding: 1rem;
    outline: none;
    font-size: 2rem;
    font-family: 'Roboto Slab', serif;
}
.text{
    text-align: center;
}
.title{
    text-align: center;
}
@media only screen and (max-width:  480px) {
    textarea{
     height: 10rem;
     width: 25rem;
    }
  }
  @media only screen and (max-width:  1080px) {
    textarea{
     height: 15rem;
     width: 30rem;
    }
  }

  @media only screen and (max-width:  1480px) {
    textarea{
     height: 45rem;
     width: 22rem;
    }
  }

I added some media query also I hope you know why we add media query. media query is for make the application or webpage responsive for many device.

Now, Add some logic with JS or we can say add some brain to our application. Without brain human can't do anything neither our webpage or application.

first we have to get the input from the user

let input = document.querySelector("textarea");

by this we are selecting textarea to get data form here in future. After that it is time to add some functionality in our uppercase button.

document.getElementById("upper-case").addEventListener("click",function (){
    let string = input.value;
    input.value = string.toUpperCase();
 });

here we used pre-built function is .toUpperCase() which make all letter of string to the uppercase.

The lowercase button functionality also same

document.getElementById("lower-case").addEventListener("click",function (){
     let string = input.value;
     input.value = string.toLowerCase();
 });

here we used pre-built function is .toLowerCase() which make all letter of string to the uppercase.

Here the full of my JavaScript code:

main.js

let input = document.querySelector("textarea");
document.getElementById("upper-case").addEventListener("click",function (){
    let string = input.value;
    input.value = string.toUpperCase();
 });
 document.getElementById("lower-case").addEventListener("click",function (){
     let string = input.value;
     input.value = string.toLowerCase();
 });
 function properCase (str) {
     if ((str===null) || (str===''))
         return false;
     else
         str = str.toString();

     return str.replace(/\w\S*/g,
         function(txt){return txt.charAt(0).toUpperCase() +
             txt.substr(1).toLowerCase();});
 }

 document.getElementById("proper-case").addEventListener("click",function (){
     let string = input.value;
     let newString = properCase(string);
     input.value = newString;
 });

 function sentenceCase(theString) {
     let newString = theString.toLowerCase().replace(/(^\s*\w|[\.\!\?]\s*\w)/g,function(c){return c.toUpperCase()});
     return newString;
 }
 document.getElementById("sentence-case").addEventListener("click",function (){
     let string = input.value;
     let newString = sentenceCase(string);
     input.value = newString;
 });

 function download(filename, text) {
     let element = document.createElement('a');
     element.setAttribute('href', 'data:text/plain;charset=utf-8,' + encodeURIComponent(text));
     element.setAttribute('download', filename);

     element.style.display = 'none';
     document.body.appendChild(element);

     element.click();

     document.body.removeChild(element);
 }
 document.getElementById("save-text-file").addEventListener("click",function () {
     let string = input.value;
     download("text.txt" , string);
 });

Thank you for reading this.

My project's live site : Live
Project's Source file : Source

Follow me on

Twitter
LinkedIn
GitHub
Website

How to Create a IP Finder Web Application With JS

Masudur Rahman Sourav — Sun, 02 Jan 2022 18:58:35 +0000

Hey,
If you are new in JavaScrip it will be interesting for you. Here you can learn to use API on JS. It will be a very very easy project for you. First you have to learn what is an API. API stands for Application Programming Interface pretty messy right but it is a fun thing. In easy way API will send you some data you just have to show them in your Webpage you have to just learn how to fetch a API and how to show the data on your webpage. If you want to learn more about the API just click here and watch the video. It will explain you in a easy way. But again you don't have to learn the internal processing of an API.

First, We have to write some code for our HTML page. Here is a simple code which I used you can use this or write by your own :

Index.html

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Find Your IP</title>
    <link rel="stylesheet" href="style.css">
</head>

<body>
    <div class="main-items">
        <div class="main-text">
            <h1>Here Is Your IP :</h1>
            <h2 class="ip"></h2>
            <h1>Your ISP is :</h1>
            <h2 class="isp"></h2>
            <h1>Your Location :</h1>
            <h2 class="location"></h2>
        </div>
    </div>
    <script src="main.js"></script>
</body>

</html>

It will look so simple without any styles you probably know that HTML without CSS it almost like a man without cloths. So, let's put some cloths on our HTML webpage. HA! HA! HA!,
Here is my CSS style file but here again you can style your own webpage in your own way.

style.css

@import url('https://fonts.googleapis.com/css2?family=Fira+Sans:ital,wght@1,500&display=swap');
body {
    font-family: 'Fira Sans', sans-serif;
    background-image: linear-gradient(90deg, rgba(2, 0, 36, 1) 0%, rgba(9, 9, 119, 1) 24%, rgba(9, 9, 121, 1) 35%, rgba(0, 212, 255, 1) 100%);
}

h1 {
    color: rgb(42, 81, 209);
}

.main-text {
    width: 25em;
    background-color: aliceblue;
    text-align: center;
    border: 1em solid rgb(73, 167, 230);
    border-radius: 2em;
}

.main-text h1 {
    margin: .5em;
}

.main-items {
    display: flex;
    justify-content: center;
    align-content: center;
    margin-top: 7em;
}

Now we will add some brain on our webpage which call JavaScript. First we will have to fetch the API if you don't know how to fetch a API watch the video he explained this clearly Click here . get your own API link from ipify . Then fetch the API in this way :

fetch('Your URL provided by ipify')
  .then(response => response.json())
  .then(data => changeTheDom(data));

here fetch getting response from ipify API and .json making this as json . Then you data is sending on changeTheDom function.

Here the changeTheDom function code:

function changeTheDom(data) {
    let IP = data.ip;
    let dom1 = document.querySelector('.ip');
    dom1.innerHTML = IP;
    let ISP = data.isp;
    let dom2 = document.querySelector('.isp');
    dom2.innerHTML = ISP;
    let dom3 = document.querySelector('.location');
    dom3.innerHTML = data.location.city + ' , ' + data.location.region + ' , ' + data.location.country;
}

in this piece of function we are changing the DOM we are getting the ip element by data.ip. We selected the ip class by querySelector and replacing its innerHTML value with IP.And in this way we changed other values also.

Thanks for reading .
My project's live site : Live
Project's Source file : Source

Follow me on

Twitter
LinkedIn
GitHub
Website

DEV Community: Masudur Rahman Sourav

Everything You Need To Know About DNS (Domain Name System)

The DNS Record Toolkit

Why System Designers & Software Engineers Must Master DNS

Security

The Threat: DNS Spoofing (Cache Poisoning)

The Shield: DNSSEC (DNS Security Extensions)

How DNS handles load balancing?

1. Geographic Routing (Geo-DNS): The Smart Operator

2. DNS Anycast: The Network Illusion

Why Engineers Love Anycast for Security

How BGP Actually Calculates The Shortest Path?

How BGP Routes Traffic: The "AS Path"

BGP Meets Anycast: The Shortest Path Wins

BGP Anycast Routing Simulator

Why Engineers Must Understand BGP

How do we prevent BGP Hijacking?

How RPKI Secures the Route

Route Origin Validation (ROV) in Action

BGP Hijack & RPKI Protection Simulator

Why RPKI Matters to System Designers

How BGP Relates To CDNs?

The CDN + Anycast Workflow

Why System Designers Rely on CDNs

React Compound Components: The "Build Your Own Adventure" Pattern

React Form Patterns: Controlled vs. Uncontrolled Components

🎮 The Controlled Component (The Micro-Manager)

🐎 The Uncontrolled Component (The "It Is What It Is")

🥊 The Showdown: Comparison

🕳️ The Pitfalls (Gotchas)

🏁 Conclusion

The Container & Presentational Pattern: Separation of Concerns in React

🎨 The Graphical Explanation

💻 The Code: A Tale of Two Components

🏆 Why Should You Do This? (Use Cases)

🕳️ The Pitfalls (The "Gotchas")

🏁 Conclusion

Understanding Hoisting in JavaScript: Why Can We Use `var` Before Declaration?

What is Hoisting?

The JavaScript Execution Context and Hoisting

Example: Hoisting with var

Why Doesn’t let and const Work the Same Way?

Hoisting with Functions

Notes:

Best Practices to Avoid Hoisting Issues

Behind the Scenes of JavaScript: How Execution Works with Execution Context & Call Stack

Execution of JavaScript:

How Make Text-Formatter with Download functionality with JS

How to Create a IP Finder Web Application With JS

Example: Hoisting with `var`

Why Doesn’t `let` and `const` Work the Same Way?