In our last session, we gathered our data (Variables) and learned how to do the math and comparisons (Operators). But right now, our code is a bit..... dumb. It just runs straight from line 1 to line 100 without thinking.

Real applications don't work like that. If you click a "Submit" button with empty fields, the app shouldn't just crash, it should say, "Hey, fill this out first!" To make our code actually think and make decisions, we use Control Flow.

Instead of our RPG game from last time, let's look at something we all know too well. Imagine we are building the backend for a brand new EdTech platform called Masterji. We need to automate the logic for giving out course certificates, bounties, and goodies. Let's write the logic!

1. if Statement

The if statement is the simplest way to make a decision. You give JavaScript a condition (using the Operators we learned last time!). If the condition is true, it runs the code inside the block {}. If it's false, it completely ignores it.

Let's check if a student is ready to graduate:

let courseProgress = 100;

// Masterji checks the progress...
if (courseProgress === 100) {
  console.log("Congratulations! Your JS Certificate is in your inbox.");
}

// If progress is 99, JavaScript just skips the block and says nothing.

2. else Statement

Just using if is great, but what if the student isn't at 100%? We shouldn't just leave them hanging in silence. We need a fallback plan. That’s where else comes in.

Think of else as the default response when the if condition fails.

let assignmentScore = 45;
let passingMarks = 50;

if (assignmentScore >= passingMarks) {
  console.log("Awesome job! You passed the assignment. 🎉");
} else {
  console.log("Masterji says: Beta, you need to study more. Try again!");
}

Notice how there is no condition next to else? It simply catches EVERYTHING that didn't pass the if test.

3. else if Ladder

Okay, now let's build the fun part: The Masterji Reward System.

What if we have more than two outcomes? Pass or Fail isn't enough. We want to give a Mechanical Keyboard to top scorers, a T-shirt to good scorers, and just stickers to the rest.

We chain conditions together using else if. JavaScript will check them one by one, from top to bottom. As soon as it finds one that is true, it runs that code and skips the rest.

let testScore = 92;

if (testScore >= 95) {
  console.log("Bounty Unlocked: Mechanical Keyboard!");
} else if (testScore >= 80) {
  console.log("Goodie Unlocked: Exclusive Masterji T-Shirt!");
} else if (testScore >= 60) {
  console.log("Goodie Unlocked: Laptop Stickers!");
} else {
  console.log("You passed, but no goodies this time. Just my blessings.");
}

Bro, order matters here! If we put testScore >= 60 at the very top, a student with 99 marks would hit that first condition, get some stickers, and the code would stop running. They’d miss out on their keyboard! Always check your highest/strictest conditions first.

4. switch Statement

The else if ladder is great for checking ranges (like >= 80). But what if a student is selecting a specific learning track on their Masterji dashboard?

If we have 5 different tracks, writing else if (track === "Frontend"), else if (track === "Backend"), over and over again gets messy and annoying to read.

When you have a single variable and you want to check it against a bunch of exact matches, use a switch statement!

let selectedTrack = "DevOps";

switch (selectedTrack) {
  case "Frontend":
    console.log("Roadmap loaded: HTML, CSS, React. Have fun making buttons!");
    break;

  case "Backend":
    console.log("Roadmap loaded: Node.js, Express, Databases. Welcome to the shadows.");
    break;

  case "DevOps":
    console.log("Roadmap loaded: Docker, AWS, CI/CD. You love pain, don't you? 🐳");
    break;

  default:
    console.log("Track not found. Are you just here for the free chai?");
}

break Trap!

Did you notice the break keyword at the end of every case? This is crucial. If you forget to write break, JavaScript suffers from something called "Fall-through".

If we removed the breaks and selected "Frontend", Masterji would print the Frontend roadmap... AND the Backend roadmap... AND the DevOps roadmap. It literally executes every line below it until it hits the end. Always use break to tell JS: "We found our match, stop checking!"

Shortcut (Ternary Operator)

Sometimes, you just want to do a simple if/else on one single line. Devs hate typing, remember?

Let's check if a user gets premium access. Instead of writing 5 lines of if/else, we use the Ternary Operator (? :).

It reads exactly like plain English: Condition ? If True : If False

let hasPaidSubscription = true;

// Is it true ? Yes do this : No do this
let accessLevel = hasPaidSubscription ? "Premium Videos Unlocked" : "Show Ads";

console.log(accessLevel);

Makes you look like a senior dev.

What's Next?

Look at us! We are officially controlling how our code thinks. Masterji is now fully operational, handing out bounties and kicking out students who fail their if checks.

But right now, if we want to grade 100 students, we'd have to write our logic 100 times. That violates the #1 rule of coding: DRY (Don't Repeat Yourself).

In our next JS Exploration, we are going to learn how to pack our code into reusable chunks. We are tackling Functions (Declaration vs. Expressions).

Grab some water, review your switch cases, and I'll catch you in the next one!

To make a game or any web app actually work, we need to calculate scores, compare levels, and make decisions. We need Operators.

Forget the boring math textbook definitions. Imagine it’s 2 AM, and me (Mayur), Alok, and Abhinav just booted up a multiplayer game. Here is how JavaScript operators are secretly running our entire gaming session.

1. Scoreboard (Arithmetic Operators)

Every time we play, the game has to constantly update our points. This is where basic math operators come in: + (Add), - (Subtract), * (Multiply), and / (Divide).

let mayurScore = 100;
let alokScore = 100;

// I got a headshot!
mayurScore = mayurScore + 50; 

// Alok fell off the map (classic Alok) 💀
alokScore = alokScore - 20; 

The Loot Split (And the % trick): We just defeated a boss and a chest dropped 100 gold coins. There are 3 of us. If we use division (100 / 3), JavaScript gives us 33.333333333333336. Nobody wants 0.33 of a digital coin.

Enter the Modulo (%) operator! Beginners always think % means percentage. It doesn’t! It means: "If I divide these numbers, what is the remainder?"

let totalGold = 100;
let players = 3;

let leftoverGold = totalGold % players; 
console.log(leftoverGold); // Output: 1

Everyone gets 33 coins, and since 100 % 3 = 1, there is exactly 1 coin left over. (And obviously, since I'm hosting the lobby, I'm keeping it).

2. "I'm Too Lazy to Type" Update (Assignment Operators)

Writing mayurScore = mayurScore + 50 every single time I get a kill is exhausting. Developers are inherently lazy (we call it being "efficient").

Instead of writing the variable name twice, JavaScript gives us Assignment Operators like +=, -=, and *=.

// The old, boring way
mayurScore = mayurScore + 50;

// The Pro-Gamer way
mayurScore += 50; 
alokScore -= 20;  // Alok fell off the map again...

The Ultimate Shortcut (++ and --): What if we just want to count how many matches we've played by adding exactly 1 each time?

let matchesPlayed = 5;

// Adds exactly 1 to the current value
matchesPlayed++; 
console.log(matchesPlayed); // Output: 6

3. Who is the Boss? (Comparison Operators)

You can't have a multiplayer game without a little toxicity and comparing stats. JavaScript lets us compare variables using <, >, <=, and >=. These always return a Boolean (true or false).

let myLevel = 50;
let abhinavLevel = 45;

console.log(myLevel > abhinavLevel); // true (I'm the boss here)
console.log(myLevel <= 50);          // true (I am exactly 50 or less)

Bomb: == vs ===

This is the most important rule in JavaScript comparison.

Let's say to join the VIP server, your level must be exactly 50.

• == (Loose Equality) is like a terrible, sleepy bouncer at a club. If the server needs the Number 50, but you give it the String "50", the == bouncer says, "Eh, looks close enough, go on in."

• === (Strict Equality) is the strict, terrifying bouncer. It checks both the Value AND the Data Type. If you bring a String "50", it kicks you out.

let requiredLevel = 50;    // Number
let playerInput = "50";    // String

console.log(requiredLevel == playerInput);  // true  (Terrible! Don't use this)
console.log(requiredLevel === playerInput); // false (Perfect! Security is tight)

Rule of thumb: Always, ALWAYS use ===. Pretend == doesn't exist.

4. Squad Logic (Logical Operators)

This is real-life gamer logic. Before we queue up for a match, we have rules about who we play with. JavaScript handles this using Logical Operators: && (AND), || (OR), and ! (NOT).

&& (AND) Operator: Both sides MUST be true. I will only play the super-sweaty Ranked mode if BOTH Alok AND Abhinav are online.

let isAlokOnline = true;
let isAbhinavOnline = true;

let playRanked = isAlokOnline && isAbhinavOnline; 
console.log("Playing Ranked? ", playRanked); // true! Both are here.

|| (OR) Operator: Only ONE side needs to be true. I'll play casual matches if Alok OR Tasnish is online. I just need one of them.

let isAlokOnline = false;
let isTasnishOnline = true;

let playCasual = isAlokOnline || isTasnishOnline;
console.log("Playing Casual? ", playCasual); // true! At least Tasnish is here.

! (NOT) Operator (Uno Reverse Card): You know that one friend who always says, "Nah bro, I'm not playing tonight"? We don't accept that logic. The ! operator flips a boolean completely. If he says false, we make it true.

let abhinavWantsToPlay = false;

// If he says no, hit him with the ! to make it a yes. Force him into the lobby!
let forceIntoLobby = !abhinavWantsToPlay; 

console.log("Is Abhinav playing? ", forceIntoLobby); // Output: true 😂

What's Next?

Now you know how to do the math, compare the stats, and set up the squad logic.

But right now, our code just runs straight from top to bottom. What if we want the game to say "If Mayur wins, show a victory screen, ELSE show a game over screen"?

In the next post, we are diving into Control Flow (If, Else, and Switch) so we can finally let our code make its own decisions. Grab a fresh chai, and I'll see you there!

How hard could it be, right?

It turns out, handling massive, concurrent checkout traffic without overselling your inventory or crashing your server is one of the hardest problems in backend engineering. This is the story of how I built the Distributed-Flash-Sale-Engine, hit a massive brick wall, and completely re-architected my system to survive the chaos.

Chapter 1: The Naive Beginnings (Nov 22 - 24)

I started where most developers start: I built a standard monolithic API using Node.js and Express, connected it to MongoDB, and wrote a simple /buy endpoint.

But I immediately ran into my first major logic bug: The Race Condition.

Imagine two users, Mayur and Prerana, clicking "Buy" at the exact same millisecond. The server checks the database for both of them simultaneously.

• "Are there any iPhones left?" -> Yes, 1 left.

• Both users pass the check.

• Both users decrement the stock.

• The stock becomes -1. I just sold a phone I don't have.

To fix this, I had to drop down to the database level and implement strict ACID transactions to ensure that checking the stock and buying the item happened sequentially, never overlapping.

Chapter 2: Caching & Crashing (Nov 30 - Dec 6)

The database was safe, but it was slow. Checking MongoDB for every single click was heavy. To speed things up, I integrated Redis.

Instead of a two-step "check then buy" process, I used Redis atomic locks (specifically the DECR command). This allowed the system to decrease the stock and check the new number in a single, unbreakable memory cycle. If the result was negative, the system threw an "Out of Stock" error instantly.

(Side note: I ran into a horrible infinite reconnect bug with Redis due to how I mounted my Docker volumes, but eventually squashed it!)

Feeling confident, I wrote a "Nuclear" load testing script using k6 to simulate a massive spike in traffic.

The result? The system absolutely burned to the ground.

Why did it crash? Because I was using a Monolithic Architecture. Everything, user registration, stock checking, and order processing, lived inside one big Node.js process. When thousands of simulated users tried to register for the sale, hashing their passwords (bcrypt) ate 100% of the CPU. The server was so exhausted doing math that it couldn't process a simple stock check.

The checkout system wasn't broken; it was just starved of CPU by the authentication system.

Chapter 3: The Great Migration (Dec 19 - 21)

I realized that to scale the "Order" feature in a monolith, I had to duplicate the entire application, which wastes a ton of RAM. I needed to split the code up.

I spent the next few days tearing the monolith apart into a Microservices Architecture.

I built a Node.js API Gateway to route traffic and separated the core logic into three distinct apps:

1. Auth Service

2. Stock Service

3. Order Service

In theory, this was beautiful. In practice, making these separate Docker containers talk to each other over a virtual network was a nightmare. I spent hours debugging inter-service HTTP calls and fixing Docker environment variable injections. But eventually, the services were communicating.

Chapter 4: Kubernetes & The Final Boss (Dec 22 - 23)

Docker Compose is great for local development, but to handle a real Flash Sale, I needed serious infrastructure. I moved the entire ecosystem into a local Kubernetes (K8s) cluster using Docker Desktop. I wanted to see exactly how much traffic my own machine could orchestrate before breaking.

The secret weapon here was the HPA (Horizontal Pod Autoscaler). I gave Kubernetes a simple rule: "If any service uses more than 50% of its CPU, instantly create a clone of it to handle the load."

It was time for the final boss. I fired up the k6 stress test: 200 concurrent users relentlessly hitting the system for 2 minutes straight.

The terminal logs were insane. The Auth Service got hit so hard by the heavy cryptography of password hashing that its CPU usage spiked to an unbelievable 1439%!

But the system didn't crash.

Kubernetes saw the Auth Service screaming for help and instantly scaled it from 1 pod to 5 pods (the max limit I set).

Benchmarking revealed exactly when the system needed help:

• The heavy Auth Service required a new server every ~9 requests per second.

• The complex Order Service scaled up every ~12 RPS.

• The lightweight Stock Service scaled up every ~14 RPS.

Because the domains were isolated, the chaos in the Auth service didn't affect the rest of the app. While Auth was fighting for its life, the Stock Service was casually serving requests with a lightning-fast 10ms latency and a 100% success rate.

Conclusion

Building this engine was a massive reality check. It taught me that writing the code is only half the battle.

Real backend engineering is about assuming that traffic will spike, servers will choke, and things will break. Moving from a fragile Monolith to a K8s Distributed System taught me the true value of Decoupling. When you isolate your services, a massive traffic spike on your login page won't prevent your active users from checking out.

The Flash Sale Engine survived, and I walked away with a profound respect for system design. 🚀

You know how it is, whenever you look up JavaScript variables online, you usually find the same boring examples like let x = 10 or let apple = "fruit". But come on, we aren't here to build a fruit basket. We are here to build actual, complex applications.

So, put on your developer armor. Today, we are managing pirate ships, RPG hero stats, and magical inventories to really understand Variables and Data Types in JavaScript. Grab your chai, and let's get into it. ☕

1. Storage Containers: var, let, and const

Think of variables like those treasure chests we keep hoarding in RPG games. You label the chest and stash something inside so you can easily find it later. In JavaScript, we have three ways to label our chests: var, let, and const.

The Modern Standard: let and const

Honestly, 99% of the time, you will only use these two.

let is used for values that you know will change (mutate) over time. Honestly, let is like your ex, can change at any time without warning! 😂

let crewCount = 12;
console.log("crew count: ", crewCount); // 12

// We recruited more sailors!
crewCount = 14; 
console.log("crew count: ", crewCount); // 14

const is used for values that should never be reassigned. It literally stands for "constant". Think of const like your brothers and your daily cutting chai, they never leave you and they absolutely cannot be changed! ☕🤝

const captainName = "Jack Sparrow";
console.log("Captain Name: ", captainName);

// This will crash the ship (throw an error)! Don't even try it.
// captainName = "Dipesh"; 

The Ghost of the Past: var

Before 2015, JavaScript only had var. It does the same job, but bro, it has a massive flaw: It doesn't respect block scope. Imagine hiding your treasure inside a secure room (like an if statement block). With let or const, the treasure stays locked in that room. With var, it magically leaks out through the walls.

if (true) {
  var leakyTreasure = "Gold coins";
}

// var ignores the {} walls! How did this get out?!
console.log(leakyTreasure); // Output: "Gold coins"

My advice? Always use let and const. Leave var at the bottom of the ocean. (Speaking of the ocean, have you explored our "From Wire to Web" series yet? 😉🌊)

2. Primitive Data Types

A "Data Type" just tells the JavaScript engine what kind of data is inside your chest. Is it text? A number? A simple Yes/No?

Here are the absolute basics (Primitives) you'll use every day:

• String (Text wrapped in quotes):

  const weaponName = "Flame Sword";
  console.log("Weapon: ", weaponName, "| type: ", typeof weaponName);
  

• Number (Integers or decimals):

  const attackPower = 75;
  const attackUpgrade = 1.5;
  

• BigInt (For massive numbers that normal Numbers just can't handle):

  console.log(typeof 42n); // Notice the 'n' at the end!
  

• Boolean (true or false):

  const isLoggedIn = true;
  

• Undefined (A chest you created, but forgot to put anything inside):

  let bonusEffect;
  console.log(typeof bonusEffect); // Output: undefined
  

• Null (An intentional empty chest. You explicitly told JS, "there is nothing here"):

  let curseStatus = null;
  let weatherApiResponse = null;
  

• Symbol (Creates a unique, hidden identifier—even if the names look identical):

  const uniqueRuneId = Symbol("rune_of_fire");
  const uniqueRuneId2 = Symbol("rune_of_fire");
  // These two are NOT the same!
  

3. Non-Primitive Data Types

Primitive types hold just one piece of value. But what if you need to store an entire character's profile, or a whole list of items? That's where we use Non-Primitives (also known as Reference Types).

Objects (Key-Value pairs)

Objects let us group related data together using labels (keys). Super useful.

const heroStats = {
  name: "Deepak",
  level: 12,
  class: "Ranger",
};
console.log("Hero: ", heroStats, " | type: ", typeof heroStats);

Arrays (Ordered Lists)

Arrays are perfect for your lists. Under the hood, they are technically just objects, but they use numbered indexes (starting at 0) instead of named keys.

const inventory = ["Flame Sword", "Health Potion", "Shield"];
console.log("Inventory: ", inventory, " | type: ", typeof inventory);

Functions (Reusable Code)

Yep, in JavaScript, functions are technically a data type (an object) too!

function castSpell() {
  return "Fireball";
}
console.log("Spell Type ", typeof castSpell); // Output: "function"

4. Value vs. Reference (Listen closely to this one!)

Bro, if there is one thing you take away from this blog, let it be this. This is where 90% of beginners mess up. Pay close attention to how JavaScript copies data.

Copying Primitives (Pass by Value) When you copy a primitive (like a Number), JS makes a completely independent, safe clone.

let originalHP = 100;
let cloneHP = originalHP;

cloneHP = 80; // Only the clone took damage!

console.log("Original HP: ", originalHP); // 100 (Safe and sound)
console.log("Cloned HP: ", cloneHP);      // 80

Copying Non-Primitives (Pass by Reference) When you copy an Object or Array, JS does not copy the data. It literally just copies the address pointing to the original chest.

const originalSword = { name: "Flame Sword", damage: 75 };
const cloneSword = originalSword; 

cloneSword.damage = 100; // We upgrade the clone...

// WAIT, WHAT?!
console.log("Original Sword: ", originalSword.damage); // Output: 100

Because both variables point to the exact same object in memory, changing one secretly changes the other!

How to actually clone an Object without breaking things:

1. Shallow Copy (The Spread Operator ...): Perfect for simple objects.

   const armorOriginal = { name: "Iron Plate", defence: 80 };
   const armorCopy = { ...armorOriginal }; 
   

2. Deep Copy (structuredClone): Use this if your object has other objects hidden inside of it (nested).

   const potionOriginal = { name: "Health", effects: { heal: 40, mana: 30 } };
   const potionCopy = structuredClone(potionOriginal);
   

5. JavaScript's Weird Historical Quirks

We can use the typeof operator to check what's inside a variable. But JS has a few historical bugs that are just too ingrained in the web to fix now. You just have to memorize them and laugh:

console.log(typeof "chaicode"); // "string"
console.log(typeof 42);         // "number"
console.log(typeof undefined);  // "undefined"

// 🚨 THE WEIRD ONES 🚨
console.log(typeof null);       // "object" -> (Wait, what? Yep, famous JS bug!)
console.log(typeof []);         // "object" -> (Arrays are technically objects)

Pro-tip: Since typeof [] just tells you it's an "object", the actual right way to check if something is an array is using Array.isArray(inventory)!

What's Next?

Alright, that's enough for today. You now know how to build your storage chests (Variables), what kind of loot to stash inside them (Data Types), and how to avoid that deadly "Pass by Reference" trap.

But right now, our code doesn't really do much. In the next post of our JS Exploration series, we are going to look at JavaScript Operators—how to add, subtract, and compare all this data to make actual things happen.

Catch you in the next one!

1. Element Selector

This is the most basic tool. You target the Tag Name.

p {
  color: red;
}

• What it does: It finds EVERY SINGLE <p> tag on your website and paints it red.

• The Problem: It’s messy. You usually don't want every paragraph to look the same.

• Analogy: "Hey everyone in the room, stand up!" (Everyone stands up).

2. Class Selector (.)

This is your best friend. You will use this 90% of the time. You give an HTML element a class attribute, and then target it with a dot ..

HTML:

<button class="primary-btn">Click Me</button>
<button class="primary-btn">Submit</button>

CSS:

.primary-btn {
  background-color: blue;
}

• What it does: It targets only elements wearing the "primary-btn" nametag.

• The Superpower: You can reuse it! Multiple elements can have the same class.

• Analogy: "Hey, everyone wearing a Red Hat, stand up!" (Only the red hat group stands up).

3. The Passport: ID Selector (#)

This is the strict one. An ID must be Unique. You can only have ONE element with a specific ID on a page. You target it with a hash #.

HTML:

<nav id="main-header">Logo</nav>

CSS:

#main-header {
  height: 50px;
}

• What it does: It finds that one specific guy.

• The Rule: Never reuse an ID. If you have two #main-headers, your code is broken.

• Analogy: "Hey Rahul Sharma with Passport #123, stand up!" (Only one person stands up).

4. Group Selector (,)

Sometimes you want the same style for different things. Instead of writing code twice, you group them with a comma.

h1, h2, p {
  font-family: Arial;
}

• What it does: "I want the h1 AND the h2 AND the paragraph to use Arial."

• Analogy: "Everyone in the front row AND the back row, stand up!"

5. Descendant Selector (Space)

This is where it gets cool. You can target something inside something else. You use a Space.

div p {
  color: green;
}

• Read it Right to Left: "Target any <p> that is inside a <div>."

• Result:

  • <p> inside a div? Green.

  • <p> outside a div? Not Green.

• Analogy: "Target the Chair... but only the chair inside the Kitchen."

6. Who Wins? (Specificity)

What happens if you have a conflict?

p { color: red; }      /* Element */
.text { color: blue; } /* Class */
#unique { color: green; } /* ID */

If one element has all three... who wins?

The Hierarchy of Power:

1. ID (#) - The Boss. (Strongest)

2. Class (.) - The Manager. (Medium)

3. Element (p) - The Intern. (Weakest)

So, Green (#ID) wins. If you want to override a Class, use an ID. If you want to override an ID... rethink your life choices (or use !important, but don't do that yet).

Wrap Up

CSS is all about pointing.

• Use Element for defaults.

• Use Class for reusable components (Buttons, Cards).

• Use ID for unique layouts (Header, Footer).

• Use Descendants for specific contexts.

That's it for today! We are slowly building. I have a lot more ideas for this series, we will dive and eventually the beast itself: JavaScript.

So stay tuned and follow for more. Catch you in the next one!

Stop right there. If I ask you right now—"What is the exact difference between a Tag and an Element?"—and you stumble? You will fail the interview. HTML isn't just about memorizing tags. It's about structure. If your HTML is trash, your CSS will be a nightmare. Let's strip it down to the basics.

1. The Skeleton

Think of a human body.

HTML is the Skeleton. It’s the bones. Without it, you are just a pile of goo.

CSS is the Skin and Clothes. It makes you look human.

JS is the Muscles/Brain. It lets you walk and think.

You can have a skeleton without skin (scary, but works). But you can't have skin without a skeleton. It would just collapse. HTML gives your website structure. It tells the browser: "This isn't just text. This is a Heading. This is a Button."

2. Tag vs. Element

This is where beginners get confused. Let’s look at this line:

<h1> Hello World </h1>

People call the whole thing a "Tag." That is wrong. Let's use the Burger Analogy.

• The Opening Tag (<h1>): This is the Top Bun. It starts the container.

• The Content ("Hello World"): This is the Patty/Veggie. The actual stuff inside.

• The Closing Tag (</h1>): This is the Bottom Bun. It ends the container. Notice the slash /.

So, what is an Element? The Element is the Whole Burger. Element = Top Bun + Patty + Bottom Bun.

If someone asks "Change the h1 tag," they mean change the < > part. If someone asks "Change the h1 element," they mean delete the whole line.

3. Void Elements (Self-Closing)

Most elements follow the Burger rule. Open, stuff inside, Close. But some elements are loners. They don’t have content. Take the Image tag:

<img src="cat.jpg" />

There is no closing </img>. Why? Because you can't put text inside an image. The image is the content. These are called Void Elements (or Self-Closing).

• <br> (Break line)

• <hr> (Horizontal line)

• <input> (The text box)

They are just one slice of bread. No burger.

4. Block vs. Inline

This is the #1 reason your CSS layout breaks. HTML elements have two personalities: Introverts and Extroverts.

Type A: Block-Level Elements (The Egoistic Ones) These guys have huge egos.

• They always start on a new line.

• They take up the full width of the screen (100%), even if they don't need it.

• They push everyone else to the next line.

• Who are they? <h1>, <p>, <div>, <ul>, <li>.

• Think of them like a brick wall. Stacked one on top of another.

Type B: Inline Elements (The Friendly Ones) These guys are chill.

• They only take up as much space as they need.

• They sit happily next to other elements on the same line.

• Who are they? <span>, <a> (Links), <b> (Bold), <img>.

• Think of them like words in a sentence. They flow left to right.

Why does this matter? If you try to put two <div>s next to each other, they won't do it. They will stack. Because they are Block-level. You have to force them with CSS to behave differently.

Wrap Up

So, next time you write HTML, don't just type tags blindly. Visualize the boxes.

• Is this a Block taking the full width?

• Is this an Inline sitting inside the text?

• Did I close my Tag properly?

Now that you know the difference between a Tag and an Element, you might be thinking: "Do I really have to type <div class="container"> every single time? That takes forever."

No, you don't. Pros don't type brackets. They use Cheat Codes. What if I told you that you can type div.box and hit TAB, and the code writes itself?

In the next blog, we will learn Emmet

What if I told you there is a way to type div.container and have the code write itself? Welcome to Emmet.

1. What is Emmet?

Emmet is a plugin (built into VS Code) that acts like a Translator. You speak in "Shorthand," and Emmet translates it into full "HTML."

• You type: h1 + Tab

• Emmet writes: <h1></h1>

It’s not a new language. It’s just a faster way to write the HTML you already know.

2. How to use it?

If you use VS Code, good news: You already have it! It comes pre-installed. Just open an HTML file, type a shortcut, and hit TAB (or Enter).

• Note: If it doesn't work, make sure your file is saved as .html.

3. Tags, Classes, and IDs

The Simple Tag Stop typing brackets. Just type the name.

• Input: button

• Output: <button></button>

The Class (.) Use a dot, just like in CSS.

• Input: .box (Defaults to div)

• Output: <div class="box"></div>

• Input: p.text

• Output: <p class="text"></p>

The ID (#) Use a hash/pound sign.

• Input: #header

• Output: <div id="header"></div>

• Input: nav#main-nav

• Output: <nav id="main-nav"></nav>

4. The Power Moves: Nesting & Multiplication

Nesting (>) This is where Emmet shines. You can create a parent and a child at the same time using the "Greater Than" symbol.

• Input: div>ul>li

• Output:

<div>
    <ul>
        <li></li>
    </ul>
</div>

Multiplication (*) Need a list with 5 items? Don't copy-paste. Multiply it.

• Input: li*5

• Output:

<li></li>
<li></li>
<li></li>
<li></li>
<li></li>

The Combo (Nesting + Multiplication) Let's go crazy. A list with 3 items inside a nav.

• Input: nav>ul>li*3

5. Adding Content & Attributes

Content ({}) You can even add text inside the tag using curly braces.

• Input: h1{Hello World}

• Output: <h1>Hello World</h1>

Attributes ([]) Need a specific link or type? Use square brackets.

• Input: a[href="google.com"]

• Output: <a href="google.com"></a>

• Input: input[type="password"]

• Output: <input type="password" name="" id="">

6. Boilerplate (!)

This is the first thing every developer does when starting a project. Instead of typing <html>, <head>, <body> manually... Just type:

• Input: !

• Action: Hit Tab.

Output:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
</head>
<body>

</body>
</html>

Boom. Your entire project structure is ready in 1 second.

Conclusion Emmet is optional, but so is running, you could just walk everywhere, but it would take forever. Start using these shortcuts today:

1. ! for setup.

2. . for classes.

3. * for lists.

Your fingers will thank you

Now you can generate thousands of lines of HTML in seconds. That’s great. But your website still looks like a Word document from 1995. Black text, white background. Boring.

We need to add CSS to make it beautiful. But here is the problem: How do you tell the browser to style only the button and not the heading?

In the next blog, we will learn about CSS Selectors

I used to think the browser was just one single app that "opens websites." You click Chrome, type a URL, and boom, Facebook appears. But after digging into the internals, I realized it’s actually a collection of huge components working together like a factory. It’s not just one thing; it’s a team.

What is a Browser, Actually? So, let's break down this "team." When you look at the diagram (the black one with the boxes), you see the User Interface at the top. That’s the part you click on, the address bar, the back button, the bookmarks. That’s just the dashboard. But the real boss is the Browser Engine. This guy sits in the middle and manages everything. He takes orders from you (the UI) and tells the Rendering Engine what to do.

The Rendering Engine is the star of the show today. In Chrome, it's called "Blink" (part of Chromium), and in Firefox, it's "Gecko." Its only job is to take your code, the HTML and CSS and paint it onto the screen. It also talks to other small workers like Networking (who fetches the images) and the JS Interpreter (who runs the JavaScript logic). But mostly, it’s about drawing pixels.

Step 1: HTML to DOM So, how does it actually draw? Imagine the browser receives your HTML file. To the computer, it’s just a long string of text and numbers. It means nothing. The browser has to "parse" it, which is just a fancy word for translating. It reads the file character by character. It sees a < tag, then div, then >, and realizes, "Oh, this is a box."

It takes all these tags and builds a tree structure called the DOM (Document Object Model). I like to think of the HTML as the script for a movie, and the DOM is the director organizing the actors. The browser creates a "Node" for every element, a node for the <body>, a node for the <div>, a node for the text inside. By the end, it has a full family tree of your content.

Step 2: CSS to CSSOM But a movie script is boring without costumes. While the browser is building the DOM, it finds a link to your CSS file. It screams, "Hey Networking, go get this file!" Once the CSS arrives, the browser reads it just like the HTML.

It builds another tree called the CSSOM (CSS Object Model). This tree is all about style. If the DOM says "There is a Headline here," the CSSOM says "The Headline is Red and 50px big." It attaches these rules to the nodes. It’s like the costume department measuring the actors and deciding what they will wear.

Step 3: Render Tree Now comes the marriage. The browser combines the DOM (content) and the CSSOM (style) into something called the Render Tree. This is important because the Render Tree only contains things that will actually appear on the screen.

For example, if you have a div that says display: none, the DOM has it, but the Render Tree ignores it. It’s invisible. The Render Tree is the final list of "Actors who are going on stage right now."

Step 4: Layout Now the actors are in costume and ready, but where do they stand? This step is called Layout (or Reflow). The browser looks at your screen size (the viewport). It does the math. It calculates exactly where every box goes.

It says, "Okay, this Header is 100% width, so it goes all the way across. This button is 20px from the left." It draws a geometry map of the page. It’s like the set designer using a measuring tape to mark exactly where the furniture goes on the stage so nobody bumps into each other.

Step 5: Paint Finally, we have the Paint stage. This is where the pixels actually light up on your screen. The browser takes that geometry map and fills it in. It draws the text, colors the background, adds the shadows, and renders the images.

This happens incredibly fast. And the crazy part? If you change something, like if you resize the window or hover over a button, the browser might have to run through this whole process again. It has to re-calculate the Layout and Re-Paint the pixels. That’s why complex animations can sometimes make your laptop fan spin!

Conclusion So that’s it. That’s the journey. It starts as a text file, turns into a DOM tree, gets dressed up by CSSOM, gets measured in the Layout, and finally gets Painted as pixels. It’s a messy, complex factory running inside your computer, and it does all of this in milliseconds just so you can see a meme. Pretty cool, right?

Now that we know how the browser processes code, we need to learn how to write it. We know the browser builds a DOM Tree... but what are the branches made of? They are made of HTML Tags.

In the next blog, we start a new series! We will stop talking about theory and start coding.

• Part 1: We learned how data travels from the ocean to your router.

• Part 2 & 3: We learned how dig finds the IP address of the server.

Now, we are standing at the door of the server. We have the address. But how do we talk to it? Most of us use a Browser (Chrome/Brave). But as developers, sometimes we don't need the buttons and images. Sometimes, we just want to send a raw message to the server. That is where cURL comes in.

What is cURL? cURL (Client URL) is a command-line tool that lets you transfer data to or from a server.

• The Browser: It’s like a restaurant with a waiter, a menu with pictures, and nice music. You point at a picture to order.

• cURL: It’s like a walkie-talkie connected directly to the kitchen. You press a button and say, "Give me a burger." No waiter, no pictures, just raw communication.

Why do programmers need it?

1. Debugging: If your API isn't working, the browser might hide the real error message behind a "404 Page." cURL shows you the exact raw response.

2. Automation: You can't write a script to "click a button" in Chrome easily. But you can write a script to run a cURL command 1,000 times in a second.

3. No UI Needed: When you are working on a remote server (backend), there is no screen. cURL is your only way to talk to the internet.

Making Your First Request Let’s try the simplest command. We will fetch the Google homepage. Open your terminal and type:

curl google.com

What happened? You probably saw a huge mess of code on your screen. That is HTML. When you visit google.com in Chrome, the browser takes this code and paints it into a nice search bar. cURL doesn't paint. It just dumps the raw data. (Proof that the browser is just a fancy cURL wrapper!)

Understanding the Conversation (Request & Response) Computers are polite. They follow a conversation structure:

1. Request (You): "Hey, give me this page."

2. Response (Server): "Okay, here is the data."

To see this "Handshake," use the -v (verbose) flag.

curl -v google.com

Look at the output. Lines starting with > are your Request. Lines starting with < are the Server's Response. You will see something like HTTP/1.1 200 OK.

• 200: This is the Status Code. It means "Success!"

• 301: "Moved Permanently" (Go look somewhere else).

• 404: "Not Found" (I don't have that).

• 500: "Server Error" (I crashed).

Talking to APIs (GET vs POST) cURL is mostly used to talk to APIs (Application Programming Interfaces). There are two main ways to talk:

1. GET (Asking for data) This is the default. You are just retrieving information.

curl https://jsonplaceholder.typicode.com/posts/1

• You get a nice JSON response (data), not HTML.

2. POST (Sending data) This is when you want to create something, like posting a Tweet or submitting a form. You need to send data to the server.

curl -X POST https://jsonplaceholder.typicode.com/posts \
     -d "title=My First Post&body=Hello World"

• -X POST: Tells cURL "I am sending data, not just asking."

• -d: Stands for "Data". This is the message you are sending.

Common Mistakes Beginners Make

1. Forgetting https://: If you just type curl google.com, some servers might ignore you. Always use the full URL.

2. Not using Quotes: When sending data (-d), always use quotes "like this". If you don't, the terminal gets confused by spaces.

3. Fear of the Terminal: The output looks scary (lots of text). Don't panic. Scroll up and look for the specific HTTP code (200, 404, etc).

Conclusion Congratulations! You have completed the "From Wire to Web" journey.

1. We traced the Undersea Cables.

2. We looked up the DNS Records.

3. We used dig to find the IP.

4. And now, we used curl to talk to the server.

You now understand the "Invisible Internet" better than 90% of people. Go build something awesome!
In the next series, we are opening the Browser's Black Box. We will look at how the Rendering Engine( stop saying display, rendering is for devs ) paints pixels on your screen.

In the last blog, we learned that TCP is the "Safe Mode" of the internet (like driving a Thar carefully). But how does it actually guarantee safety?

If I send a meme to my friend, how does TCP make sure the top half doesn't arrive after the bottom half?

The answer lies in The Handshake and The Sequence.

1. The 3-Way Handshake

TCP is extremely polite. It never sends data without asking first. It uses a 3-step process called the 3-Way Handshake.

Imagine calling your friend:

Step 1: SYN (The Dial)

• You (Client): "Hello? Can you hear me?"

• Technical: You send a packet with the SYN flag (Synchronize, it’s just jargon) and a random number (e.g., 100). This is your ID.

Step 2: SYN-ACK (The Answer)

• Friend (Server): "Yes, I hear you (ACK 101). Can you hear me? (SYN 5000)"

• Technical: The server ACKs your number (100 + 1) and sends its own SYN number (5000). Now both have IDs.

Step 3: ACK (The Confirmation)

• You (Client): "Yes, I hear you perfectly (ACK 5001). Let's talk."

• Technical: You ACK the server's number (5000 + 1). The connection is ESTABLISHED.

2. Data Transfer

Now the connection is open. We need to send the data.

But the internet is chaotic. Packets can arrive late, out of order, or duplicate.

TCP solves this using Sequence Numbers.

Think of it like moving houses. You don't just throw boxes into a truck. You label them: "Box 1 of 10", "Box 2 of 10".

• The Sender: Sends "Packet #1 (Bytes 0-100)".

• The Receiver: Gets it and sends back "ACK 101".

  • Translation: "I got everything up to 100. Send me byte 101 next."

• The Sender: Sends "Packet #2 (Bytes 101-200)".

Ordering: If "Packet #3" arrives before "Packet #2", TCP holds it in a waiting room (Buffer). It waits for #2 to arrive, puts them in the right order (1 → 2 → 3), and then gives it to the application.

3. Handling Loss

What if a packet disappears?

• Sender: "I sent Packet #2... waiting for confirmation..."

• Receiver: (Silence)

• Sender: "Okay, it's been 200ms. No ACK. It must be lost."

• Action: The sender Retransmits Packet #2.

This is why TCP is "Reliable". It doesn't give up until the other side confirms receipt.

4. Closing the Connection

UDP just stops talking. But TCP is polite—it says goodbye properly.

This is a 4-Way Termination.

1. You: "I'm done talking." (FIN)

2. Server: "Okay, I heard you." (ACK)

   • (The Server might still have some final data to send to you. You wait.)

3. Server: "Okay, I'm done too. Bye." (FIN)

4. You: "Bye." (ACK)

The connection is now closed.

Conclusion: The Unsung Hero

TCP is heavy. It has handshakes, acknowledgments, timers, and sequence numbers.

But this "heaviness" is exactly why you can load a webpage without missing words, or download a zip file without it being corrupted.

It works hard in the background so you don't have to.

We have built the road (Cables), found the address (DNS), and established a secure connection (TCP). The journey is complete. Now, we are standing at the server's front door. It's time to actually ask for the website.

In the final part of this series, we will stop using the browser and learn how to talk to the server manually using the command line tool cURL.

Welcome back to the "From Wire to Web" series!

• Part 1: We built the road (Undersea Cables).

• Part 2 & 3: We found the address using the GPS (DNS).

Now, we need to actually drive to the destination to deliver the message. We are driving the heavy-duty SUV of the internet: The Thar.

But here is the catch: This car has two driving modes.

1. TCP Mode (Safe & Reliable & Normal mode)

2. UDP Mode (Fast & Furious & 4X4 mode)

Which one should you use? Let's find out.

1. TCP: "City Drive"

TCP (Transmission Control Protocol) is like taking my family on a trip in my Thar. Safety is the #1 priority.

How it works (The 3-Way Handshake):

Before you even start the engine, you call your friend at the destination.

• You (SYN): "Hello! I am coming over. Are you home?"

• Server (SYN-ACK): "Yes, I am home! Come over."

• You (ACK): "Okay, starting the car now."

The Journey:

You drive carefully. The data packets are your family members.

• Numbering: Everyone has a specific seat number.

• Reliability: If "Chintu" (Packet #5) falls out of the car, the whole car stops. You go back, pick him up (Retransmission), and then continue.

• Conclusion: The data always arrives perfectly, exactly in order.

When to use TCP?

• Websites (HTTP/HTTPS): You don't want a webpage to load with missing text.

• Emails: You don't want half a letter.

• File Downloads: You don't want a corrupted game file.

In chat infrastructure, TCP is always used to make sure to delivery each message in order.

2. UDP: "Off-Road"

UDP (User Datagram Protocol) is like entering your Thar in a desert rally. Speed is the only thing that matters.

How it works (No Handshake):

You don't call. You don't check if the friend is home. You just drive towards home.

The Journey:

You are flying over speed bumps at 120 km/h.

• No Order: The packets arrive whenever they arrive.

• Unreliable: If a suitcase falls off the roof rack? Forget it. We don't stop. The show must go on.

When to use UDP?

• Video Calls (Zoom/Meet): Have you ever seen a video call glitch for a second? That was a lost packet. The app didn't pause to find it; it just skipped to the next frame.

• Online Gaming (BGMI/Valorant): If a bullet is fired, you need to know now. You don't care about the bullet fired 3 seconds ago.

3. Comparison Table

4. Where does HTTP fit? (The Passenger)

A common confusion for beginners is: "Is HTTP better than TCP?"

That’s like asking: "Is the family member better than the Car?"

• TCP is the Thar (The vehicle transporting the goods).

• HTTP is the Family member inside (The actual message/content).

HTTP relies on TCP to get it there safely. HTTP says, "I have this HTML file. Please drive it to the user's laptop safely." TCP says, "Don't worry, I will wear my seatbelt."

Conclusion

So, next time you are building an app, ask yourself:

• Do I need Safety (TCP)? (Like sending a bank transfer).

• Do I need Speed (UDP)? (Like live streaming a cricket match).

Both modes are useful. You just need to know when to switch gears.

We decided that for web browsing, we almost always use the safe TCP Mode. But how exactly does the driver ensure safety? How does it number the seats? And how does it politely say goodbye when the trip is over?

In the next blog, we will go behind the scenes and look at the system of the 3-Way Handshake and Reliability.

When you type a URL, your browser doesn't magically know the IP. It has to ask someone. And if that person doesn't know, they ask someone else. This chain of asking is called DNS Resolution.

Today, we are going to be "Detectives". We will use a special command called dig to manually track down an IP address, step by step.

What is DNS Resolution?

Think of it like this: You want to find "Mayur's House" (google.com), but you don't know the address.

1. You first ask the Global Chief (Root). He says, "I don't know, but I know the manager of .com."

2. Then you ask the .com Manager (TLD). He says, "I don't know, but I know who manages google."

3. Again you ask the Google Manager (Authoritative). He says, "Yes! Here is the address."

This chain is how the internet works.

dig

To see this happening live, developers use a command called dig (Domain Information Groper). It is a Linux command that lets us talk directly to DNS servers. (Note for Windows users: This tool isn't installed by default, so we usually run this in a Linux terminal or Cloud Shell).

Let’s start our investigation.

Root Name Servers

The journey starts at the very top. The Root Servers. These are the most important servers on the internet. There are 13 logical root servers in the world.

Command:

dig . NS

• . means "Root" (The starting point).

• NS means "Tell me the Name Servers" (Who is the boss?).

Terminal Output:

What happened?
We asked "Who runs the internet?". The response gave us a list from a.root-servers.net to m.root-servers.net. These are the Watchman. They don't know where google.com is, but they know who runs .com.

TLD Name Servers

Now that we know the Root, we need to find who manages the .com ending. These are called Top-Level Domain (TLD) Servers.

Command:

dig com NS

Terminal Output:

What happened?
The Root server pointed us to the gTLD servers (Global Top-Level Domain). These servers manage every single website that ends in .com.

Authoritative Name Servers

We are getting closer. The TLD server knows about .com, so now we ask it: "Who specifically handles google.com?" This takes us to the Authoritative Name Server. This is the specific server that the owner (Google) configured to handle their traffic.

Command:

dig google.com NS

Terminal Output:

What happened?
The TLD manager said, "Go ask ns1.google.com. They have the final list."

Final Answer (Full Resolution)

Now we are at the final destination. We ask the Authoritative Server: "Give me the IP address for google.com."

Command:

dig google.com

(Note: By default, dig asks for the 'A Record')

Terminal Output:

Result: We found it! The IP addresses like 74.125.68.100…

Recursive vs. Iterative:

You might be thinking, "Wait, my browser does all 4 steps every time I click a link?" No. That would be too slow.

There are two ways to resolve a name:

1. Iterative (What we just did): You run around asking Root -> TLD -> Auth yourself.

2. Recursive (The Real World): Your laptop asks one server (usually your ISP or Google 8.8.8.8) and says, "Bro, go find this for me."

Your browser is the "Lazy Friend" (Recursive). It asks the ISP. The ISP does the hard work (Iterative) of running around the internet to find the answer, and then just gives the final IP to your browser.

Conclusion

So, DNS Resolution is basically a chain of referrals.

• Root (.) says: "Ask .com"

• TLD (.com) says: "Ask Google"

• Authoritative (google.com) says: "Here is the IP: 142.250..."

It’s a beautiful system that keeps the internet organized. Next time your internet is slow, just remember the poor ISP server running around asking all these managers for directions!

Now that we have the IP address, we need to travel there to deliver our data. But how do we drive? Do we take the safe, slow family car? Or the fast, off-road rally jeep?

In the next blog, we will learn about TCP vs UDP using a Mahindra Thar analogy.

Problem: Computer’s don’t speak English “names like google.com“. Speaks Math, only numbers what they understand. In internet each device or online webpage have IP addresses like 142.250.1.1, So that they can uniquely identify each distinct resources ( devices, webpages, etc. ).

DNS (Domain Name System)

A DNS record is an information stored on a DNS server that tells the internet how to handle a domain. It’s like phonebook of internet, maintains the domain name of along with the IP addresses. Phonebook of internet is called Authoritative DNS Servers.
This stores instructions like:

• If the domain is google.com then point to 142.250.1.1 IP address.

• How to handle request for that domain, via all the DNS records.

DNS is what maintains and helps in navigate the IP addresses. Using DNS records we can set instruction that, which domain to point on which IP.

Let’s explore DNS record types !

A & AAAA Records

The ‘A’ stands for ‘address‘, not for any house. A record indicates the IP address of a given domain name.
For example: If you search google.com, the A record of google.com will point to 142.250.1.1 IP address.
A records only holds IPv4 addresses. If a website has an IPv6 address, it will instead use an ‘AAAA‘ record.

The ‘AAAA‘ is new way to address the domains.
AAAA records hold IPv6 addresses, why not IPv4 ? It was old way to address the domains, and we ran out of it. IPv4 addresses are no more available for new domains.

CNAME Record

So, we stopped at Cloudflare. Let’s say I have a blog hosted on Hashnode, but I bought my domain mayurbadgujar.me from Namecheap. I want people to type blog.mayurbadgujar.me and see my Hashnode blog.

This is where the CNAME Record saves the day. CNAME stands for "Canonical Name," which is just a fancy way of saying "Alias" or "Nickname." It maps one domain name to another domain name, not an IP address.

Why do we do this? Imagine if Hashnode changes their server's IP address tomorrow. If I used an A Record (pointing to their IP), my website would break, and I would have to manually update it. But with a CNAME, I just point blog.mayurbadgujar.me to hashnode.network. Now, Hashnode manages the IP addresses in the background, and I don't have to worry about anything. It’s like telling the internet, "I don't know where Hashnode lives, just go ask them."

MX Record

Now, let's talk about emails. You have a website at mayurbadgujar.me, but you also want to receive emails at hello@mayurbadgujar.me. Does the email go to the same server as your website? Usually, no.

That is why we need the MX Record (Mail Exchange). This record tells the internet exactly which server handles emails for your domain. It is responsible for receiving mails.

Think of it like this: Your A Record is your home address where you live (your webpage). Your MX Record is your P.O. Box at the post office where your letters go (your email). If someone tries to deliver a letter to your house, the MX record tells them, "No, don't leave it here. Take it to the Gmail server down the street." Without this record, your domain cannot receive emails.

TXT Record

Next up is the TXT Record. This one is literally what it sounds like, Text. It holds text notes.

At first, I wondered, Why do I need to leave text notes on my domain? The biggest use case is Verification. Let’s say you want to connect your site to Google Search Console (Login with google). Google needs to know you actually own the domain. They will give you a code and say, "Go paste this in your TXT records." Once you do that, Google checks your DNS, sees the code, and knows you are the real owner. It’s like leaving a sticky note on your front door that says, "Verified Owner: Mayur," so the security guard knows it's actually your house.

NS Record

Finally, we have the NS Record (Name Server). This is the Manager of your domain.

These records point to the authoritative server where all your other records (A, CNAME, MX) are actually stored. When you buy a domain from GoDaddy but you want to manage it on Cloudflare, you change the NS Records. You are essentially telling the internet, "I bought this domain at GoDaddy, but Cloudflare is my manager now. Go ask them for my IP address." Without correct NS records, none of the other records we talked about will work because the browser won't know who to ask.

Conclusion

So, that is the full journey of the "Internet's Phonebook."

• A Record: The actual House Address (IP address of webpage).

• CNAME: The Nickname or Alias (subdomains).

• MX: The Post Office for emails.

• TXT: The Sticky Note for verification.

• NS: The Manager who holds the list.

Now we have the Phonebook (Records), but who actually looks up the number? In the next blog, we will become Detectives and use the dig command to track down an IP address step-by-step.

Go let’s start the trip “From Wires to Web”

Deep Blue Origin (Undersea Cables & AS)

Undersea wires (Fiber Optics Cables) are backbone of network. Large organizations manage them, like Tata Communication (they connects 240+ countries and territories, own major share of global backbone traffic).

Autonomous Systems (AS) is a network under one single administrative control, identified by an unique Autonomous System Number (ASN) and using the Border Gateway Protocol (BGP) to exchange the routes.

What do AS (Autonomous Systems) do ?

They have there own network through wires or rent wires.
Tier-1 ASes don’t buy internet from anyone.
They do Peering (free or settlement-free), Paid peering, Transit (paid), exchange of routes.
They reach to whole world and connects they world

Examples of Tier-1 ASes (Autonomous Systems):
Tata Communications
AT&T
Verizon
NTT

Border Control (BGP & ISP)

Finally, cable hits land. But still they need to know where to go next.
This is where Border Gateway Protocol (BGP) comes in picture.
The Border Gateway Protocol (BGP), exchanges routing information between Autonomous Systems to determine the best path for traffic. BGP allows ASes to interconnect.

An ISP provides last-mile connectivity and IP routing services to end users, connecting customer networks to the global Internet.

Wires bring data from different sources under oceans to land, Then BGP helps to decides the paths data should take between networks.
BGP decides where data should go, but time to send that data to real user. So ISP comes in, helps route data to particular address.

Modem / ONT

ISP wire (fiber or copper) reach to your home. Copper/coax and Fiber cables carries electrical / RF and optical signals, but devices speak digital data.
This problem is solved by the Modem/ONT. Modem/ONT do signal conversion, they translate signals.

Demodulation: Incoming signals from cable gets converted into digital data usable by the home network.
Modulation: Device sends back the digital data, digital data gets converted into analog/optical signals.

Modem VS ONT (Optical Network Terminal):
Modem do modulation and demodulation and ONT do signal conversion. Works on different technologies.
Modem: Handles copper wire / coax cable. These cables bring electrical / RF signals, modem converts that into digital data.
ONT: Handles Fiber optics cable. These cables bring light signals, ONT converts that into digital data.

Router

Once digital data enters the home through the Modem or ONT, it reaches the Router.
The router acts as the boss of the home network, deciding how data should flow between devices and the Internet.
Router connects two different networks:

The external network (ISP / Internet)
The internal network (your home LAN)

What does a Router do?
The router share data packets between networks using the IP addresses.

• Incoming Data : Routed to the correct device.

• Outgoing Data : Routed to internet.

For assigning the IP address and routing the data packets to the particular address, The NAT(Network Address Translation) and DHCP(Automatic IP Assignment) are responsible.

NAT (Network Address Translation)
Home devices use private IP addresses that are not visible on the Internet.

• Router replaces private IPs with one public IP

• Keeps a translation table to send responses back to the correct device

NAT allows multiple devices to share a single Internet connection

DHCP (Automatic IP Assignment)
Instead of manually assigning IPs to every device:

• Router runs a DHCP server

• Automatically assigns:

  • IP address

  • Subnet mask

  • Gateway

  • DNS

“Wi-Fi connect ho gaya” = DHCP succeeded

Switch vs. Hub

Hub (Old Technology)

• Sends incoming data to every connected device

• No intelligence, no filtering

• Causes collisions and wasted bandwidth

Result: Slow and inefficient

Switch (Modern Technology)

• Sends data only to the destination MAC address

• Learns which device is on which port

• Reduces collisions and improves performance

Result: Fast and efficient

Firewall

Once the traffic passes the Router, we need security. The Internet is full of malicious requests, hackers, and bots. A Firewall is a network security device that monitors incoming and outgoing network traffic and decides whether to allow or block specific traffic based on a defined set of security rules.

What does a Firewall do?

• Packet Filtering: It inspects data packets. If a packet comes from a suspicious IP or tries to enter a blocked Port, the Firewall rejects it.

• Stateful Inspection: It remembers active connections. If you didn't ask for a video, it won't let a random video stream enter your network.

Load Balancer

Now, let's look at the other side, where the website lives (like Google or Netflix). When millions of users hit a website at the same time, one single server cannot handle the pressure. It will crash. A Load Balancer acts as a "traffic cop" sitting in front of your servers and distributing client requests across all servers capable of fulfilling those requests.

Why do we need it?

It ensures no single server bears too much demand.

If one server goes down, the Load Balancer detects it and redirects traffic to the remaining online servers.

Conclusion, The Full Journey

So, that is the physical journey of the Internet

1. Deep Sea: Data travels through Undersea Cables.

2. Border: BGP decides the route between countries.

3. Entry: Modem/ONT translates the signal (Light/Analog to Digital).

4. Distribution: Router assigns an IP and directs the packet.

5. Security: Firewall checks if the packet is safe.

6. Delivery: Switch delivers it to your specific device.

Now that we are connected physically, there is one big problem left. Computers don't speak English. They don't know what google.com is, they only know IP addresses like 142.250.1.1.

So, how does your browser translate a name into an IP address? That is where the Phonebook of the Internet (DNS) comes in.

But here is the truth I found while digging into Git internals: Git is literally just a Linked List.

When we learn about Linked Lists in college, it feels theoretical. But every time you type git commit, you are adding a Node to the most famous Linked List in the world.

The Behind The Scenes(BTS) Logic

If you look at the raw data inside the .git folder, the mapping is crazy accurate:

The Node: Your Commit is the Node. It holds your metadata or user data (author, message).

The Pointer: Every commit has a Parent Hash. This is literally the prev pointer in a Linked List. It points to the commit that came before it.

The Head: You know how we have a head pointer in DSA to track the start? In Git, HEAD is a pointer that always points to the last node you worked on.

Secret Part: SHA-1 & Trees

This is where it gets cool. How does Git actually save your code inside that Node?

It uses SHA-1 Hashing.

Every time you save a file, Git takes the raw content, runs it through an algorithm, and spits out a 40-character unique ID (like a1b2c3 . . .).

• Git doesn't care about the filename here. It only cares about the content.

• If two files have the exact same code, they share the exact same Hash, Efficiency level: 100.

So how does it remember folder structures?

Enter the Tree Object.

Think of a Tree Object as a simple directory list. It maps your filenames to those SHA-1 hashes.

• "index.html" - > points to Blob e4f2 . . .

• "styles/" - > points to another Tree 89a1 . . .

How Changes Spread

When you make a new Commit (node), Git doesn't copy all your files.

1. It creates a new Tree representing the current state of your folder.

2. If you only changed one file, Git generates a new SHA-1 for that file.

3. The new Tree points to the new file hash, but keeps pointing to the old hashes for everything else that didn't change.

The Conclusion

Stop treating Git like magic. It’s just a database of nodes (Commits) pointing to maps (Trees) pointing to data (Blobs).

If you can reverse a Linked List in an interview, you already understand how Git history works. We are just traversing nodes, bro!

That system is Git.

What is Git?

This is the Time Machine. It allows you to go back to yesterday’s code if today’s code breaks. It tracks each line you changed on your laptop itself.

Game Changer: It is Distributed The tracked history can be shared online on the cloud (GitHub).

If anyone loses the code, you still have the entire project history on your laptop, and all other team members also have that project history.

Problem solved: It tracks each line, so now you know what updated and when.

Still an issue: How do others see the projects? We will see this later. First, let’s setup the Git config.

First-Time Setup

The setup creates the identity of the developer. We need to answer the manager's question: “Who wrote this code?”

1. Set your Name This is what appears when you make any changes.

Bash

git config --global user.name "Mayur"

2. Set your Email Important: This must match your GitHub email if you want those green contribution squares in your profile!

git config --global user.email "mayur@example.com"

3. Verify it worked

git config --list

Note: The --global flag means “apply to every project on my laptop”. You only do this once!

Problem solved: Now the manager can see the names and emails of the developers on each contribution.

Initializing vs Cloning a Project

How to initialize a new Git repo (git init) To track your project, Git needs to "see" your project from the local code editor (VS Code). Allow Git to see your project by the command:

git init

The .git folder is added to your project. It's hidden from you, but all your history is stored inside it.

How to clone an existing Git repo (git clone) If your teammate has already initiated the repo (project) on the cloud (GitHub), you don't init. You use:

git clone <repo url>

git clone is used to create a copy of the version which is already updated on the cloud.

Saving Changes: The "Wedding Photo" Analogy

Now that you have a repository, you can save file changes. Beginners often get confused about why we need add before commit.

Think of a Wedding Photographer.

1. The Hall (Working Directory) The wedding hall with all the guests. Some are new, some are eating.

• Command to check the hall:

    git status
  

2. The Stage (git add) You call specific people to the stage. You are arranging the group for the picture.

• Command to stage files:

    git add filename.js
    # OR to add everyone
    git add .
  

3. The Shutter Click (git commit) You freeze that moment forever in your camera's memory.

• Command to save:

    git commit -m "Added the login feature"
  

4. Uploading (git push) You upload that photo to Instagram (GitHub) so the family can see it.

• Command to sync:

    git push origin main
  

Viewing History

Git tracks its own history locally. You can walk through the history of the project anytime.

• Command to see the Time Machine:

    git log
  

It shows every version, who made it, and when.

Summary: Git vs GitHub

They are totally different:

• Git helps you track your code locally in the project itself.

• GitHub is the online service where you push code so that others can collaborate asynchronously with you.

Next Article: How Git Works Internally

What was the problem previously? Let's look at the Pendrive Era.

Why We Stopped Using Pendrives ?

Imagine we start a new project. It's assigned to a team of 3 developers, and the company is paying them $50/hour each.

They discuss the architecture. They even give it an internal name Project Monkey.

1. Dev-1 starts working on the landing page. He completes it roughly in an hour.

2. To let the other 2 devs review the code, he makes a first_v1.zip folder and shifts the zip folder into the pendrive.

3. Finally, they get to read the code from the pendrive and copy the zip folder to work further on top of that.

The Cost

While the first dev was writing code, the other 2 devs were waiting for the pendrive.

The company is burning $100/hour for zero output.

This Inactive time kills the delivery time of the project.

After an hour, they share the pendrive again.

• Third dev passed the pendrive to First dev.

• First dev was confused: "Bro, you coded a lot, but what changed?"

• First dev passed the pendrive to Second dev.

• Second dev was again confused: "Guys there’s lots of code, which code is written by whom?"

Issue #1: Tracking & Accountability

Dev: "Who wrote this bug?"
Manager: "How should I pay them? I don’t know who contributed and how."

🛑 Impact: Wasted Salaries, We are paying for work we can't track.

Issue #2: Collaboration and Time

This is the Serial vs Parallel problem.

Dev: "If someone fixed an error, I need to wait for the updated code so I can code further!"
Manager: "Why is only one dev working at a time?"

🛑 Impact: Delivery Time & Code Quality.

By chance, if they started working parallelly, they are still out of sync! If we have 5 or 10 devs in a team, think about the amount of time they will take just to share code.

Issue #3: Versioning and Backups

While sharing, everyone is creating an "updated zip folder." It is hard to know which is the correct and newer version.

Dev: "An error occurred! I need the old version... but where is it?"
Manager: "There is no recovery and no backups?"

🛑 Impact: High Risk. One corrupted pendrive kills the project.

What’s the solution?

We realized we can't scale with pendrives. We need a system that can:

1. Track every line: When was it updated? Who updated it?

2. Enable Parallel Work: Allow everyone to see updated code every second.

3. Auto-Backup: Save history by tracking every single update.

We needed a way to let 100 developers work on the same project at the exact same second, without costing the company a lot in money and time.

That system is Git.

Next Article: What actually is Git?