DEV Community: Rajat Yadav

CSS Selectors 101: Targeting Elements with Precision

Rajat Yadav — Thu, 12 Feb 2026 20:04:02 +0000

When you write CSS, you’re always answering one important question:

“Which elements do I actually want to style?”

Because honestly… without a way to point at specific elements in your HTML, you couldn’t change colors, fonts, spacing etc. Everything would just look default and boring.

That’s where CSS selectors comes inn.

Selectors are simply the way you choose which elements get which styles.

We’ll use a simple “addressing people in a room” analogy, and also show small before/after examples so you can actually see what’s happening.

Why CSS Selectors Are Needed

The Basic Problem

Your HTML page has:

headings
paragraphs
buttons
links
lists
sections
and many more things

Your CSS needs to say things like:

“Make all paragraphs blue.”
“Make this button red.”
“Make everything inside the sidebar smaller.”

If you had no way to target specific elements, then either:

You style everything the same
Or you don’t style anything

Selectors are what lets you say:

“Apply these styles to these elements not all of them.”

Real-World Analogy: Addressing People

Imagine a room full of people.

“Everyone named John” → selecting by name (like element selector)
“Everyone wearing red shirt” → selecting by class
“The person with badge #42” → selecting by ID
“Everyone named John sitting in the left corner” → selecting by location (descendant selector)

CSS selectors work exactly like this. They are just different ways of addressing elements.

The Structure of a CSS Rule

Every CSS rule has two parts:

selector {
  property: value;
}

Selector → which elements
Declaration block → what styles to apply

If you don’t understand selectors, you can’t control where styles go. So honestly, selectors are foundation of CSS.

1. Element Selector – Style by Tag Name

What It Does

An element selector (also called type selector) selects every element that matches a given HTML tag.

You just write the tag name. No dot. No hash.

Syntax

elementname {
  /* styles */
}

Example

Select all paragraphs:

p {
  color: blue;
  font-size: 16px;
}

Select all <h1>:

h1 {
  color: darkgreen;
  font-size: 2rem;
}

Now every <p> becomes blue. Every <h1> becomes dark green. You didn’t touch the HTML at all.

When To Use It

Use element selector when you want every instance of that tag to look same.

It’s broad and simple.

2. Class Selector – Style by Class Name

What It Does

A class selector selects every element that has a specific class.

In HTML:

<p class="highlight">Important text</p>

In CSS, you target class using a dot (.).

Syntax

.classname {
  /* styles */
}

The dot means “this is a class”.

Example

HTML:

<p class="highlight">This is important.</p>
<p>This is normal.</p>
<p class="highlight">This is important too.</p>

CSS:

.highlight {
  background-color: yellow;
  font-weight: bold;
}

Now only the paragraphs with class="highlight" get yellow background.

The middle one stays normal.

Multiple Classes

You can do:

class="button primary"

Then in CSS:

.button.primary { }

This means:

Only elements that have BOTH classes.

Or:

.primary { }

This means:

Any element that has class primary.

Classes are flexible. Many elements can share one class.

When To Use Class

Use class when you want to style:

A group of elements
Reusable components
Things like buttons, cards, highlights

Think:

Class = “this type of thing”

3. ID Selector – Style by ID

What It Does

An ID selector selects the one element that has a specific id.

ID should be unique on the page.

In CSS, ID uses hash (#).

Syntax

#idvalue {
  /* styles */
}

Example

HTML:

<header id="main-header">Welcome</header>

CSS:

#main-header {
  background-color: navy;
  color: white;
  padding: 1rem;
}

Only that one header gets styled.

Class vs ID (Simple Table)

Feature	Class	ID
Symbol	`.`	`#`
Can reuse?	Yes	No (should be unique)
Use for	Group	One specific element

Rule of thumb:

Use class for reusable styling
Use ID for one specific section

4. Group Selectors – Style Multiple Things

Sometimes you want same style for multiple selectors.

Instead of repeating:

h1 { color: #333; }
h2 { color: #333; }
h3 { color: #333; }

You can group:

h1,
h2,
h3 {
  color: #333;
}

Comma means:

Apply to all of these.

Less code. Cleaner CSS. Easier to maintain.

You can mix types too:

h1,
.intro,
#main-title {
  color: navy;
}

5. Descendant Selectors – Style Inside Something

Now things get little more interesting.

A descendant selector targets elements inside another element.

Syntax

ancestor descendant {
  /* styles */
}

Space means:

Inside

Example

HTML:

<article>
  <p>Inside article</p>
</article>

<p>Outside article</p>

CSS:

article p {
  color: blue;
}

Only the paragraph inside <article> becomes blue.

The outside one stays normal.

So now location matters.

Deeper Nesting

header nav ul li a {
  color: white;
}

This means:

<a>
inside <li>
inside <ul>
inside <nav>
inside <header>

You can be very specific.

But careful — too much nesting can become messy.

Visual Flow (Conceptual)

HTML Element
     ↓
Match ID selector? → Yes → Apply ID styles
     ↓ No
Match Class selector? → Yes → Apply class styles
     ↓ No
Match Element selector? → Yes → Apply element styles

6. Basic Selector Priority (Specificity)

Now important question:

What happens when two rules conflict?

Example:

p { color: blue; }
.highlight { color: red; }

If a paragraph has class highlight, which color wins?

Answer: Class wins.

Strength Order (High Level)

From weakest to strongest:

Element selector
Class selector
ID selector

So:

ID > Class
Class > Element

Example

HTML:

<p id="intro" class="highlight">Hello</p>

CSS:

p { color: blue; }
.highlight { color: red; }
#intro { color: green; }

Final color?

Green.

Because ID wins.

Same Strength Case

If specificity is equal:

.highlight { color: red; }
.highlight { color: blue; }

The last rule wins.

So order matters too.

Final Complete Example

HTML:

<header id="site-header">
  <h1>My Blog</h1>
  <p class="tagline">Thoughts and code.</p>
</header>

<main>
  <article>
    <h2>First Post</h2>
    <p>Content here.</p>
    <p class="highlight">Key point.</p>
  </article>
</main>

CSS:

p {
  font-size: 1rem;
  color: #333;
}

.highlight {
  background-color: #ffc;
  padding: 0.25rem;
}

#site-header {
  background-color: #333;
  color: white;
  padding: 1rem;
}

#site-header p {
  font-size: 0.9rem;
  color: #ccc;
}

main h1,
main h2 {
  font-family: Georgia, serif;
  color: #222;
}

And now you can see:

All paragraphs get base style
.highlight gets extra styling
Header gets unique style
Only paragraphs inside header become smaller
Headings inside main get specific font

Everything is controlled by selectors.

Final Thoughts

If you really think about it, CSS is not first about colors or animations or flexbox.

It’s about:

“Who am I styling?”

Selectors are how you answer that.

Once you understand element, class, ID, grouping, and descendant selectors you’ve already understood the core of CSS. Rest things builds on this only.

Happy styling

Emmet for HTML: A Beginner’s Guide to Writing Faster Markup

Rajat Yadav — Thu, 12 Feb 2026 10:36:46 +0000

Let me ask you something honestly…

Have you ever felt tired just by looking at HTML?

You open your editor.
You start typing.
Open tag. Close tag.
Indent. Nest. Repeat.

And suddenly a “simple” navbar becomes 10 lines of code and 5 chances to mess up something.

Let’s see the problem first.

The Problem: Writing HTML is Slow (And Sometimes Painful)

Imagine you're building a simple navigation bar. You need:

A <nav>
Inside it a <ul>
Inside that 5 <li>
Each <li> with an <a>
Each <a> with class and href

Without Emmet, you’d type something like this:

<nav>
  <ul>
    <li><a href="#" class="nav-link">Home</a></li>
    <li><a href="#" class="nav-link">About</a></li>
    <li><a href="#" class="nav-link">Services</a></li>
    <li><a href="#" class="nav-link">Portfolio</a></li>
    <li><a href="#" class="nav-link">Contact</a></li>
  </ul>
</nav>

That’s multiple lines.
Multiple opening and closing tags.
Multiple places where you can forget something.

Now look at this:

nav>ul>li*5>a.nav-link[href="#"]{Link}

Press Tab.

Boom.....;..

Full structure generated instantly.

This is what Emmet does. And once you start using it, you can’t go back, seriously.

What is Emmet? (In Very Simple Words)

Emmet is like shortcut language for HTML and CSS.

You know how on your phone:

“omw” → becomes “On my way!”
“brb” → becomes “Be right back!”

Same concept.

You type short code → it expands into full HTML.

Examples:

div

Press Tab →

<div></div>

div.container

Press Tab →

<div class="container"></div>

ul>li*3

Press Tab →
3 <li> elements inside a <ul>.

And the crazy part?
It’s already built into editors like VS Code. You probably used it without knowing what it is called.

Why Emmet is a Game Changer (Especially for Beginners)

1. Speed

You write HTML almost 10x faster. Not even exaggerating.

2. Fewer Mistakes

No missing closing tags. No broken structure. Emmet generates valid HTML automatically.

3. You Understand Structure Better

When you type div>p, you're literally thinking in parent-child relationships. It trains your brain.

4. Focus on Thinking, Not Typing

Instead of wasting energy typing repetitive tags, you think about layout and logic.

5. Professional Workflow

Most developers use Emmet daily. Learning this early is honestly a small unfair advantage.

How Emmet Actually Works

Let’s see the flow:

You type: div.container

↓

Editor detects Emmet pattern

↓

You press Tab

↓

Emmet expands it

↓

<div class="container"></div>

It feels like magic at first. Then it becomes normal. Then it becomes addiction.

Basic Emmet Symbols (This is Where Fun Starts)

Here’s the cheat sheet you’ll use daily:

Symbol	Meaning	Example
`>`	Child (nested inside)	`div>p`
`+`	Sibling	`div+p`
`*`	Repeat	`li*3`
`^`	Go up one level	`div>p^span`
`()`	Grouping	`(div>p)*2`

Understanding with Simple Diagrams

1. Child (`>`)

div>p

Structure:

div
 └── p

Result:

<div>
  <p></p>
</div>

2. Sibling (`+`)

div+p

Structure:

div
p

Result:

<div></div>
<p></p>

3. Repeat (`*`)

li*3

Result:

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

Adding Classes and IDs

Classes use `.`

div.container

→ <div class="container"></div>

button.btn.btn-primary

→ <button class="btn btn-primary"></button>

IDs use `#`

div#header

→ <div id="header"></div>

Combine Both

div#main.container.wrapper

→ <div id="main" class="container wrapper"></div>

Small note: ID first, then classes. It just feels cleaner that way.

Adding Attributes with `[ ]`

Anything inside square brackets becomes an attribute.

a[href="#"]

→ <a href="#"></a>

img[src="photo.jpg"][alt="Photo"]

→ <img src="photo.jpg" alt="Photo" />

input[type="text"][placeholder="Enter name"]

→ <input type="text" placeholder="Enter name" />

Very powerful, very simple.

Nesting Elements Like a Pro

Simple Nesting

div>p

div
 └── p

Multiple Levels

div>ul>li

div
 └── ul
      └── li

Multiple Children

div>p+span+button

div
 ├── p
 ├── span
 └── button

This is where your brain start thinking in structure instead of lines.

Repeating Structures

Simple Repeat

li*5

5 <li> elements.

Nested Repeat

ul>li*3

ul
 ├── li
 ├── li
 └── li

Complex Repeat

div.card*4>h2+p+button

You instantly get 4 card components with content inside.

This is where Emmet really saves time.

Adding Text Content `{}`

Use curly braces.

p{Hello World}

→ <p>Hello World</p>

With Nesting

div>h1{Welcome}+p{This is a paragraph}

Numbered Content with `$`

ul>li*3{Item $}

Result:

<ul>
  <li>Item 1</li>
  <li>Item 2</li>
  <li>Item 3</li>
</ul>

The $ automatically increments numbers. It feels smart honestly.

The Magic Shortcut: Full HTML Boilerplate

Open a blank file.

Type:

Press Tab.

You instantly get full HTML5 structure:

<!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>

That alone saves so much time.

Real World Example: Navigation Bar

Emmet:

nav.navbar>ul.nav-list>li.nav-item*5>a.nav-link[href="#"]{Link $}

Mental structure:

nav.navbar
 └── ul.nav-list
      ├── li.nav-item
      │     └── a.nav-link
      ├── li.nav-item
      │     └── a.nav-link
      └── ...

This is how you think like a developer. Structure first, typing later.

Visual Guide: What Happens Internally

┌──────────────────────────────┐
│ You Type: div.container>p*3 │
└──────────────────────────────┘
                ↓
┌──────────────────────────────┐
│ Emmet understands structure │
│ - div with class container  │
│ - 3 p elements inside       │
└──────────────────────────────┘
                ↓
┌──────────────────────────────┐
│ You press Tab               │
└──────────────────────────────┘
                ↓
┌──────────────────────────────┐
│ HTML is generated instantly │
└──────────────────────────────┘

Feels simple. But it's powerful.

Patterns You’ll Use Almost Daily

div.wrapper>h1+p
ul>li*5
button.btn.btn-primary{Click Me}
a[href="/page"]{Link}
section#about>div.container>h2+p

If you master just these, your HTML workflow becomes smooth.

Practice (Do This Seriously)

Try building:

Header with logo and nav

   header>div.logo+nav>ul>li*4>a

Article layout

   article>h1+div.meta>span.author+span.date+p

Footer with 3 columns

   footer>div.column*3>h3+p*2

Table

   table>tr*3>td*4

Full page Start with ! then add header, main, footer.

Practice this once. You’ll never write plain HTML the same way again.

Final Thoughts

You still need to know HTML properly. But Emmet removes the boring part. And honestly, coding becomes more enjoyable when you're not fighting with closing tags all the time.

If you’re a beginner, start using it today.

Happy Coding.

Understanding HTML Tags and Elements

Rajat Yadav — Thu, 12 Feb 2026 06:27:06 +0000

So we will start with basics what is HTML?

When you open any website in your browser maybe YouTube, maybe LinkedIn, maybe your own project what you see (text, buttons, images, links) is built on top of HTML.

Without HTML, a webpage would be just raw text thrown randomly on the screen. No structure. No meaning. Just chaos.

And if you're learning web development (like seriously learning it, not just watching tutorials), understanding HTML properly is the first real step.

So let’s break it down in a simple way. No over-complicated words. No confusion.

What Is HTML and Why Do We Use It?

The Basic Idea

HTML stands for HyperText Markup Language.

Now that sounds fancy. But actually it’s very simple.

Markup = you mark parts of your content
(“This is a heading.” “This is a paragraph.” “This is a link.”)
Language = a set of rules the browser understands.

So HTML is just a way of marking up content so the browser knows how to display it.

You're not just typing text.

You're describing what that text is.

HTML Is the Skeleton of a Webpage

Think of a webpage like a human body:

HTML = Skeleton (structure)
CSS = Skin & clothes (design, colors, layout)
JavaScript = Muscles & nerves (movement and behavior)

If there is no skeleton, nothing else can exist properly.

You can’t style something that doesn’t have structure.
You can’t add behavior to something that doesn’t exist.

So HTML is the foundation.

It tells the browser:

This is a heading.
This is a paragraph.
This is a list.
This is an image.

Everything starts here.

Why Do We Use HTML?

We use HTML because:

Browsers understand it. Every website is built from HTML (or something that generates HTML).
It gives structure. It organizes content clearly.
It improves accessibility. Screen readers rely on proper HTML structure.
It’s the web standard. The internet is built on HTML.

When you write HTML, you’re not just writing code.

You’re defining the structure of a document that millions of devices can understand.

What Is an HTML Tag?

Tags Are Like Labels

An HTML tag is a label you put around content.

It tells the browser what that content is.

Think of it like this:

Opening tag → “Start of paragraph.”
Content → The actual text.
Closing tag → “End of paragraph.”

Example:

<p>This is a paragraph.</p>

Breakdown:

<p> = opening tag
This is a paragraph. = content
</p> = closing tag

The / means “closing.”

Visual Diagram: Tag Structure

Opening Tag      Content             Closing Tag

   <p>      This is a paragraph.        </p>

          └──────── Entire Element ────────┘

The opening tag + content + closing tag together form something called an element.

And this is where many beginners get confused.

Tag vs Element (Important Difference)

Many beginners think tag and element are same. But they are not exactly same.

Tag = the syntax like <p> or </p>
Element = the whole thing → <p>Hello</p>

Think of it like a box:

Tags = the box edges
Content = what’s inside
Element = the full box with everything

Diagram:

ELEMENT (Whole thing)

┌───────────────────────────────┐
│  <p>  Hello world  </p>      │
│   ↑         ↑        ↑       │
│ Opening   Content   Closing  │
│  Tag                 Tag     │
└───────────────────────────────┘

The browser thinks in elements.
We write tags to create them.

Self-Closing (Void) Elements

Now here’s something interesting.

Not all elements have content inside them.

Some elements don’t wrap text. They just do one thing.

For example:

Line break
Image
Horizontal line

These are called void elements (sometimes casually called self-closing).

Examples:

<br>
<img src="photo.jpg" alt="A photo">
<hr>

Notice something?

There is no closing tag like </br> or </img>.

Because they don’t wrap content.

They just exist.

Common void elements:

Tag	Purpose
`<br>`	Line break
`<hr>`	Horizontal line
`<img>`	Image
`<input>`	Form input
`<meta>`	Page metadata

So remember:

Void element = one tag, no content, no closing tag.

Block-Level vs Inline Elements

This part is very important for layout understanding.

HTML elements behave in two main ways:

Block level
Inline

Block-Level Elements

Block elements:

Start on a new line
Take full width available
Stack vertically

Examples:

<p>
<div>
<h1> to <h6>
<section>
<ul>
<li>

Diagram:

Block 1  ─────────────────────────

Block 2  ─────────────────────────

Block 3  ─────────────────────────

Each block sits below the previous one.

Like stacking boxes.

Inline Elements

Inline elements:

Do NOT start on new line
Take only as much width as needed
Sit inside text

Examples:

<span>
<a>
<strong>
<em>

Example sentence:

This is a <span>word</span> and <a href="#">a link</a>.

They stay in the same line.

Diagram:

Text Text Inline1 Inline2 Inline3 Text

They flow like normal words.

Common Mistake

You should not put a block element inside an inline element.

Wrong:

<a href="#"><p>Don't do this</p></a>

Correct:

<p>Read <a href="#">this link</a>.</p>

Blocks are for structure.
Inlines are for parts inside structure.

Commonly Used HTML Tags

Let’s see the most important ones you’ll use daily.

Headings & Text

<h1>Main Title</h1>
<h2>Sub Title</h2>
<p>This is a paragraph.</p>

<h1> is biggest heading.
<h6> is smallest.

Containers

<div>This is a block container</div>
<span>This is inline container</span>

<div> → block container
<span> → inline container

They don’t add meaning. They just help structure or styling.

Links & Images

<a href="https://example.com">Visit site</a>
<img src="photo.jpg" alt="Description">

href and src are called attributes.

Attributes give extra information.

Lists

Unordered list:

<ul>
  <li>First item</li>
  <li>Second item</li>
</ul>

Ordered list:

<ol>
  <li>Step one</li>
  <li>Step two</li>
</ol>

Emphasis & Meaning

<strong>Important</strong>
<em>Emphasized text</em>

Use <strong> when something is important.
Use <em> for emphasis.

It’s not just styling, it adds meaning.

Minimal HTML Page Structure

Every HTML page usually looks like this:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>My Page</title>
</head>
<body>
  <h1>Welcome</h1>
  <p>This is my first page.</p>
</body>
</html>

Breakdown:

<!DOCTYPE html> → tells browser this is HTML5
<html> → root element
<head> → metadata (not visible)
<body> → visible content

You don’t have to memorize everything today.

Start small.

<p>
<h1>
<div>
<span>
<a>
<img>

Then slowly expand.

Inspect HTML in the Browser (Very Powerful Trick)

Here’s something I wish I understood earlier.

Every website is just HTML underneath.

Right click → Inspect

You will see:

Opening and closing tags
Nested elements
Structure
Parent-child relationships

Hover over elements in inspector and browser highlights them.

This is how you really understand how websites are built.

Just reading theory is not enough. You need to observe real websites.

Final Thoughts

Many people rush it.

They jump to React. Or animations. Or fancy frameworks.

But if your HTML foundation is weak, everything else feels confusing later.

HTML is simple. But simple doesn’t mean unimportant.

It’s the base of everything on the web.

Take your time.

Write small pages.
Inspect websites.
Break things.
Fix them.

And slowly, things start making sense.

Happy coding guyzzz 🙂

How a Browser Works: A Beginner-Friendly Guide to Browser Internals

Rajat Yadav — Wed, 11 Feb 2026 18:59:33 +0000

You’re sitting at your computer.
You type:

https://chaicode.com

You press Enter.

And boom the website appears.

But what actually happened in that tiiny moment?
It feels intant, but behind the scenes ur browser just did alot of work. Like seriously a lot.

It contacted servers, downloaded files, parsed code, built trees, calculated layouts, painted pixels and finally showed it to you.

Let’s break it down slowly and visually.

First, What Even Is a Browser?

Most beginners think:

“Browser? It opens websites.”

Technically true. But that’s like saying:

“Chef? He just makes food.”

Not enough.

A browser is more like a translator + manager + artist + delivery system all combined together.

When you visit a website, your browser:

Fetches files from a server
Understands (parses) HTML, CSS, JavaScript
Builds internal structures
Calculates layout
Paints pixels
Displays everything on your screen

It’s doing way more than we realise, honestly.

The Main Parts of a Browser (Restaurant Analogy 🍽️)

Think of a browser like a restaurant.

┌─────────────────────────────────────────┐
│         USER INTERFACE                   │
│  (Dining Area - What You See)            │
│  - Address bar, tabs, buttons            │
└─────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────┐
│         BROWSER ENGINE                   │
│  (Manager - Coordinates Everything)      │
└─────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────┐
│         RENDERING ENGINE                 │
│  (Chef - Creates the Visual Output)      │
│  - Parses HTML/CSS                       │
│  - Builds DOM & CSSOM                    │
│  - Renders the page                      │
└─────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────┐
│         NETWORKING LAYER                 │
│  (Delivery Service - Gets Files)         │
│  - HTTP requests                         │
│  - Downloads resources                   │
└─────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────┐
│         JAVASCRIPT ENGINE                │
│  (Waiter - Adds Interaction)             │
│  - Executes JS                           │
│  - Handles interactivity                 │
└─────────────────────────────────────────┘

Each part has a specific job. Let’s understand them one by one.

1. User Interface (UI)

This is the part you interact with:

Address bar
Tabs
Back/Forward buttons
Bookmarks
Settings

This is just the “face” of the browser.

Like steering wheel of a car.
You control it, but the engine is inside.

2. Browser Engine vs Rendering Engine (This Confuses Everyone)

Browser Engine → The Manager

Coordinates everything
Controls communication between parts
Decides what to do next

Rendering Engine → The Artist

Parses HTML & CSS
Builds structures
Paints pixels on screen

Some real rendering engines used today:

Blink (Chrome, Edge, Opera)
Gecko (Firefox)
WebKit (Safari)

The browser engine manages everything, but rendering engine does the visual heavy work.

3. Networking — How Files Are Fetched

Now let’s walk through what happens when you type a URL.

You type:

https://chaicode.com

Here’s what happens:

Step 1: Break URL
Protocol → https
Domain   → chaicode.com
Path     → /

Step 2: DNS Lookup

Your browser asks:

“What is the IP address of chaicode.com?”

DNS replies:

93.184.216.34

Now browser knows where to go.

Step 3: HTTP Request

Browser sends request to that IP:

“Please send me the HTML file.”

Server responds with HTML.

But HTML isn’t the only thing needed.

Inside HTML, browser finds:

CSS files
JavaScript files
Images
Fonts

Then it downloads all of them in parallel (simultaneously).

That’s why modern websites load fast.

4. HTML Parsing & DOM Creation

Now browser has HTML.

Example:

<html>
  <head>
    <title>My Page</title>
  </head>
  <body>
    <h1>Welcome</h1>
    <p>Hello world!</p>
  </body>
</html>

Browser does something called parsing.

What is Parsing?

Parsing means breaking text into meaningful structure.

Like reading a math expression:

2 + 3 * 4

It builds a tree:

HTML works same way.

Browser builds a tree:

        html
       /    \
    head    body
     |      /  \
   title   h1   p
     |      |    |
  "My Page" "Welcome" "Hello world!"

This tree is called:

🌳 DOM (Document Object Model)

Every HTML element becomes a node.

Why DOM matters?

JavaScript uses it
Browser uses it
Changes in DOM update the screen

Without DOM, nothing works.

5. CSS Parsing & CSSOM Creation

At the same time, browser parses CSS.

Example:

body {
  font-size: 16px;
  color: black;
}

h1 {
  color: blue;
}

Browser builds another tree called:

CSSOM (CSS Object Model)

        StyleSheet
             │
      ┌──────┴──────┐
      │             │
    body{}         h1{}
      │             │
  font-size       color
  color

Important thing:

Browser cannot render until CSSOM is ready
Because styles affect layout.

6. DOM + CSSOM = Render Tree

Now browser combines both trees.

DOM Tree        CSSOM Tree
    │                │
    └──── Combine ───┘
             ↓
         Render Tree

Render Tree contains:

Only visible elements
With computed styles attached

Not included:

<head>
<script>
Hidden elements

Render Tree is basically blueprint of what will be shown.

7. Layout (Reflow)

Now browser calculates positions.

Questions browser asks:

How wide is this element?
Where should it go?
How much space does it need?
Does it wrap to next line?

Example:

Before Layout:

Header
Nav   Main
Footer

After Layout:

┌─────────────────┐
│ Header (100%)   │
├─────────────────┤
│ Nav │ Main      │
├─────────────────┤
│ Footer (100%)   │
└─────────────────┘

Now browser knows exact pixel positions.

8. Painting

Layout tells where to draw.

CSS tells what to draw.

Painting fills in pixels:

Background colors
Borders
Text
Images
Shadows

Think like paint-by-numbers.

Layers:

Background
Borders
Text
Images
Overlays

9. Display

Finally:

Render Tree
   ↓
Layout
   ↓
Paint
   ↓
Graphics Card
   ↓
Monitor
   ↓
Your Eyes 👀

And you see the webpage.

All of this usually happens in less than a second.

Crazy right?

Complete Flow (From URL to Pixels)

1. You type URL
        ↓
2. DNS lookup
        ↓
3. HTTP request
        ↓
4. Receive HTML
        ↓
5. Download CSS/JS/Images
        ↓
6. Build DOM
        ↓
7. Build CSSOM
        ↓
8. Create Render Tree
        ↓
9. Layout (Reflow)
        ↓
10. Paint
        ↓
11. Display on screen

Final Thoughts

Next time you open a website, just remember:

Your browser didn’t “just open it”.

It:

Talked to servers
Downloaded multiple files
Built tree structures
Calculated layouts
Painted millions of pixels
Coordinated multiple engines
And then showed you result

All in milliseconds.

Sometimes we think frontend is just HTML & CSS.

But honestly, the browser is doing so much heavy lifting behind the scenes and we dont even realise it properly.

once you understand this flow deeply, performance optimization and debugging becomes way more logical.

Happy Learning..

Understanding Network Devices

Rajat Yadav — Wed, 11 Feb 2026 18:25:05 +0000

When we open our browser and type google.com, it feels instant. You press Enter… and boom, the page loads.

But behind that one click, a lot of hardware devices are silently working together. You’ve probably heard words like router, modem, firewall, or even load balancer — but honestly, most people don’t clearly know what each one actually does. And sometimes we just say “modem” for everything..

In this article, we’ll break down the essential networking hardware that makes the internet work in simple language, with real examples, and diagrams.

We’ll cover:

Modem – How your network connects to the internet
Router – How traffic gets directed
Switch vs Hub – How local networks actually work
Firewall – Where security lives
Load Balancer – Why scalable systems need it
How all of these work together in real-world setups

Let’s start with the big picture.

How the Internet Reaches You

Before going deep into each device, let’s understand the journey of a single packet.

Internet 
   ↓
Modem 
   ↓
Router 
   ↓
Switch 
   ↓
Your Device

Think of it like mail delivery:

Internet = The global postal system
Modem = Your mailbox
Router = The mail sorter
Switch = The delivery person inside the building
Your Device = The person receiving the mail

Each one has a specific job. If even one fails, things stop working. And then we start restarting router again and again

1. What is a Modem?

The Problem: Different “Languages”

Your home network speaks one language (Ethernet/Wi-Fi signals).

Your ISP (Internet Service Provider) speaks another language (cable, DSL, fiber signals).

They don’t understand each other directly.

A modem (Modulator-Demodulator) is basically a translator.

What it does:

Modulation → Converts digital data into signals that can travel over cable/fiber
Demodulation → Converts incoming signals back into digital data

Diagram:

Your Computer (Digital Data)
        ↓
      Modem
        ↓
Cable/Fiber Signal
        ↓
        ISP

Important Things About Modem

Connects to ISP
Provides usually one public IP
Does NOT route traffic
It’s the boundary between your network and the internet

Many people call their router a modem. But they are not same. A modem connects you to the internet. A router manages traffic inside your network.

That difference is small but very important.

2. What is a Router?

The Problem: Where Should Data Go?

Once data enters your network, how does it know where to go?

You might have:

Laptop
Phone
Smart TV
IoT devices
Gaming console

A router decides:

This packet is for Laptop → Send there
This one goes to Internet → Send to modem
This one is internal → Keep inside

Diagram:

               Router
            /    |     \
         PC    Phone    TV

The router maintains something called a routing table — basically a map of where things are.

What Router Actually Does

Maintains routing table
Assigns local IPs (via DHCP)
Separates local network from internet
Often provides Wi-Fi
Routes packets between networks

Router vs Modem (Simple Table)

Modem	Router
Connects to ISP	Connects devices
Translates signals	Routes traffic
One public IP	Many local IPs
Physical/Data layer	Network layer

In most homes today, you actually use a combo device. One box that does modem + router + switch + Wi-Fi.

But logically, they are separate components.

3. Switch vs Hub – How Local Networks Work

Let’s say you want to connect 20 devices.

Your router has only 4 ports.

What now?

You add a switch.

But before switch, there was something called a hub.

What is a Hub? (Old Technology)

A hub is very simple and kind of dumb.

It receives a packet → sends it to ALL ports.

Computer A → Hub → Sends to B, C, D, E (everyone)

Everyone sees the packet, even if not meant for them.

This creates unnecessary traffic and collisions.

Think of hub like shouting in a classroom. Everyone hears you even if you’re talking to one person.

That’s inefficient.

What is a Switch? (Modern Way)

A switch is smarter.

It learns which device is connected to which port.

When Computer A sends to Computer B:

Computer A → Switch → Only Computer B

Other devices don’t even know it happened.

Much cleaner. Much faster.

Hub vs Switch

Hub	Switch
Broadcasts to all	Sends to specific port
Causes collisions	Avoids collisions
Layer 1	Layer 2
Obsolete	Standard today

Today, hubs are almost dead. Switches are everywhere.

4. What is a Firewall?

Now comes security.

Your network is connected to the internet. That means:

Good traffic can come
Bad traffic can also come

A firewall acts like a security guard.

It inspects every packet and decides:

Allow
Block

Diagram:

Internet
   ↓
Firewall
   ↓
Your Network

What Firewall Checks

Source IP
Destination IP
Port number
Protocol

Common Rules

Allow HTTP (80), HTTPS (443)
Block unknown incoming traffic
Allow outgoing DNS (53)
Deny by default

Firewall can be:

Hardware device
Software (like iptables, Windows Firewall)

Without firewall, your network would be exposed. And that is not good at all.

5. What is a Load Balancer?

Now imagine your website becomes popular.

Day 1 → 100 users
Day 100 → 10,000 users
Day 1000 → 1 million users

One server can’t handle everything.

So you add more servers.

But how do users get distributed across them?

You use a load balancer.

Diagram:

            Load Balancer
           /      |       \
       Server A  Server B  Server C

Load balancer:

Receives request
Decides best server
Forwards request
Removes unhealthy servers
Can terminate SSL

Algorithms

Round Robin
Least Connections
IP Hash

It ensures:

No single server gets overloaded
High availability
Scalability

Load balancer is one of first components added in production systems.

6. How Everything Works Together (Real Setup)

Home Setup

Internet
   ↓
Modem
   ↓
Router (with Firewall)
   ↓
Switch (optional)
   ↓
Devices

Flow when you open google.com:

Device sends request
Router checks firewall rules
Router sends to modem
Modem sends to ISP
Response comes back same path

Simple but powerful.

Office/Data Center Setup

Internet
   ↓
Firewall
   ↓
Load Balancer
   ↓
Router
   ↓
Switch
   ↓
Servers

Flow:

User types domain
DNS resolves to load balancer IP
Firewall checks request
Load balancer selects server
Router forwards
Switch delivers
Server responds

Everything follows reverse path back.

7. Cloud Version (Modern Infrastructure)

In cloud (AWS, GCP, Azure), hardware becomes virtual.

Internet
   ↓
WAF
   ↓
Load Balancer
   ↓
Security Groups
   ↓
Route Tables
   ↓
Virtual Instances

Concepts are same. Only implementation is software-defined.

And honestly, if you understand the physical version first, cloud becomes very easy to understand.

Final Thoughts

As a software engineer, especially if we are into backend or system design, we should know:

Where firewall sits
Where load balancer fits
How routing works
Why switches matter
Why modem and router are not same

When production breaks, these concepts help us debug faster. Otherwise we just say “server down maybe” without knowing real cause

The internet looks like magic. But it’s not magic.

Good systems are built from small, clear responsibilities.

Happy Learning guys...

TCP Working: 3-Way Handshake & Reliable Communication

Rajat Yadav — Wed, 11 Feb 2026 18:14:23 +0000

When two computers talk over the internet, they don’t send data in one big file.
They break it into small pieces called packets.

Now here’s the problem.

Those packets don’t always behave nicely. They can:

Arrive late
Arrive out of order
Arrive twice
Or never arrive at all

If we just throw packets into the internet without rules, things would be chaos.

You would see:

Half loaded websites
Broken downloads
Messages missing some words in the middle
Random glitches everywhere

So obviously… we need some system.

That system is called TCP.

What is TCP and Why Do We Need It?

TCP (Transmission Control Protocol) is a set of rules that makes communication reliable.

Its job is simple (but very powerful):

Make sure data reaches
Make sure it reaches in correct order
Make sure it is not corrupted
And make sure both sides agree when starting and ending

Think of TCP like a very disciplined courier service.
Not fast-fast, but very safe.

Without TCP, the internet would technically work… but very badly.

What Problems TCP Solves

TCP mainly handles three big problems:

1. Packet Loss

Sometimes packets just disappear in the network.

TCP fixes this by:

Numbering packets
Waiting for confirmation (ACK)
Resending if confirmation doesn’t come

2. Out-of-Order Delivery

Internet doesn’t guarantee packets take same route.

So packet #3 can arrive before packet #1.

TCP solves this using sequence numbers.
Receiver rearranges them before giving data to application.

So your browser only sees clean, ordered data.

3. Data Corruption

Sometimes packets get damaged during transmission.

TCP uses something called a checksum.

If checksum fails:

Packet is rejected
Sender resends it

So data integrity is maintained.

The TCP 3-Way Handshake (Before Data Starts)

TCP does not just start sending data randomly.

First, both sides confirm they are ready.

This process is called the 3-Way Handshake.

It uses three steps:

SYN
SYN-ACK
ACK

Let’s understand this slowly.

Conversation Analogy

Imagine calling someone.

You: “Hey, can we talk?”
Friend: “Yes, I can hear you. Can you hear me?”
You: “Yes, I can hear you. Let’s talk.”

Now both sides know connection is good.

Same happens in TCP.

Step-by-Step: SYN → SYN-ACK → ACK

Let’s assume:

Client = Your browser
Server = Web server

Step 1: SYN

Client sends a packet with SYN flag.

Meaning:

“I want to start a connection.”
“Here is my starting sequence number.”

Diagram:

Client Server
| ---- SYN ----> |

Step 2: SYN-ACK

Server replies with SYN-ACK.

This means two things:

SYN → “Yes, I also want to connect.”
ACK → “I received your SYN.”

Diagram:

Client Server
| ---- SYN ----> |
| <--- SYN-ACK --- |

Step 3: ACK

Client sends final ACK.

Meaning:

“I received your response. Now we’re ready.”

Diagram:

Client Server
| ---- SYN ----> |
| <--- SYN-ACK --- |
| ---- ACK ----> |

Connection established ✅

Now actual data can start.

How Data Transfer Works in TCP

After handshake, data flows.

TCP treats data as a stream of bytes, not messages.

Example:

Suppose client sends:

HELLO WORLD

TCP might split it like:

Packet 1 → Bytes 1000–1005
Packet 2 → Bytes 1006–1010

Each byte has a sequence number.

Receiver uses those numbers to reassemble everything properly.

Application just sees:

HELLO WORLD

It never sees the splitting.

Sequence Numbers and ACKs (Simple Idea)

Sender sends:

Bytes 1000–1499

Receiver replies:

ACK 1500

Which means:

“I got everything till 1499. Send next from 1500.”

This is called cumulative acknowledgement.

It keeps things simple and efficient.

What Happens If Packet Is Lost?

Suppose sender sends:

Bytes 1000–1499

But packet gets lost.

Receiver never sends ACK.

Sender waits for some time…

No ACK?

Sender assumes packet lost.

Resends:

Bytes 1000–1499

This is called retransmission.

Application doesn’t even know this happened.

TCP hides all this complexity.

What About Out-of-Order Packets?

Suppose:

Packet 1500–1999 arrives
But 1000–1499 hasn’t arrived yet

Receiver will:

Store 1500–1999 temporarily
Still send ACK 1000 (Meaning: I’m still waiting for 1000 onwards)

Sender understands missing part and resends it.

Everything gets fixed silently.

How TCP Ensures Correctness

TCP ensures correctness using:

Sequence numbers → ordering
ACKs → confirmation
Retransmissions → reliability
Checksums → corruption detection

It’s like a very strict teacher checking every homework twice 😅

How TCP Connection Is Closed

Starting needs handshake.
Ending also needs proper closing.

TCP uses:

FIN (Finish)
ACK

Let’s say client wants to close.

Step 1: Client sends FIN

“I’m done sending data.”

Client Server
| ---- FIN ----> |

Step 2: Server sends ACK

“Okay, I know you’re done.”

Client Server
| ---- FIN ----> |
| <--- ACK ---- |

Server might still send remaining data.

Step 3: Server sends FIN

“I’m also done sending.”

Client Server
| ---- FIN ----> |
| <--- ACK ---- |
| <--- FIN ---- |

Step 4: Client sends ACK

“Got it. Now we’re fully done.”

Client Server
| ---- FIN ----> |
| <--- ACK ---- |
| <--- FIN ---- |
| ---- ACK ----> |

Connection closed ✅

TCP Lifecycle Summary

You can think TCP in three phases:

1. Establish

SYN → SYN-ACK → ACK

2. Transfer

Data + Sequence numbers + ACKs + Retransmissions

3. Close

FIN → ACK → FIN → ACK

Simple structure. Very powerful system.

Why TCP Matters for You (As a Developer)

Even if you don’t write TCP manually:

HTTP runs on TCP
APIs use TCP
Database connections use TCP
Backend services depend on TCP

When you debug:

Slow APIs
Timeout errors
Connection reset issues

TCP is involved somewhere.

Understanding TCP makes you stronger backend engineer.

Final Thoughts

Without TCP, internet would feel broken and unstable.

It is slow sometimes, yes.
But it is reliable.

And in networking, reliability matters more than speed in many cases.

Happy learning..........

Getting Started with cURL

Rajat Yadav — Wed, 11 Feb 2026 17:40:26 +0000

Before jumping into tools like cURL, we need to understand something more important:

Who are we even talking to?

That “someone” is called a server.

What Is a Server? (In Very Simple Words)

A server is just a computer that gives something when you ask for it.

It can:

send you a website
give you data
store your files
save your login info

When you open Instagram, submit a form, or fetch API data you are talking to a server.

You (your browser, your app, your terminal) are called the client.

So the basic idea is:

Client  →  Server  →  Response

You ask.
Server processes.
Server replies.

That’s it.

Does a Server Look Special?

Not really.

A server is also a computer, just like yours.
It has:

CPU
Memory
Storage
Operating System (Ubuntu, Windows Server, etc.)

The only difference?

It is always running and always ready to respond to requests.

Types of Servers

There are different kinds of servers depending on what they provide.

1. Web Server

Delivers websites (HTML, CSS, JavaScript, images).

Example flow:

Browser → Web Server → HTML page

2. File Server

Stores and manages files.

Client → File Server → File Download

3. Mail Server

Handles sending and receiving emails.

Email App → Mail Server → Inbox

4. Database Server

Stores structured data (like users, products, orders).

Backend App → Database Server → Data

Now that we understand servers…

Let’s talk about how we can speak to them without a browser.

What is cURL? (Very Simple Explanation)

cURL is a command-line tool that lets you send requests to a server directly from your terminal.

Instead of clicking buttons in a browser,
you type a command.

That’s it.

cURL stands for Client URL.

Meaning:

You are the client
You send something to a URL
You get a response back

How cURL Communicates

Here’s what happens when you use cURL:

Terminal (You)
      ↓
cURL builds HTTP request
      ↓
Server receives request
      ↓
Server sends response
      ↓
cURL prints response in terminal

No UI.
No fancy design.
Just raw communication.

Your First cURL Command

The simplest possible example:

curl https://example.com

What just happened?

cURL sent a GET request to the server.
The server processed it.
The server sent back a response.
cURL printed the response (HTML) in your terminal.

You just fetched a webpage without opening a browser.

Feels small… but it’s powerful.

What Exactly Is a Request and Response?

Every HTTP communication has two parts:

Request  →  Response

The Request (What You Send)

A request usually contains:

URL (where you’re sending it)
Method (GET or POST)
Headers (extra info)
Body (data, sometimes)

The Response (What Server Sends Back)

A response has three main parts:

1. Status Code

Tells you what happened.

200 → Success
404 → Not Found
500 → Server Error

2. Headers

Extra information like content type, date, etc.

3. Body

The actual data (HTML, JSON, text, etc.)

If you want to see everything (status + headers + body), use:

curl -i https://example.com

You’ll see something like:

HTTP/2 200
content-type: text/html

Then the HTML.

200 means it worked.

GET vs POST (Only These Two for Now)

Don’t overload yourself with too many methods.

Just understand these two.

GET → “Give me data.”

Used to fetch or read something.

Default in cURL.

Example:

curl https://api.example.com/users

This means:

“Hey server, send me users.”

POST → “Here is data. Do something with it.”

Used when sending data to the server.

Example:

curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{"name":"Alice"}'

What this does:

-X POST → use POST method
-H → sending extra information
-d → sending actual data

Don’t worry about remembering everything now. Just understand the idea.

Using cURL to Talk to APIs

APIs are just URLs that send back data (usually JSON).

Example:

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

You’ll get something like:

{
  "userId": 1,
  "id": 1,
  "title": "...",
  "body": "..."
}

That’s an API response.

You just interacted with a backend system directly.

Browser vs cURL (Conceptual Difference)

Both send HTTP requests.

But:

Browser:
Request → Server → Response → Render UI

cURL:
Request → Server → Raw Response in Terminal

Browser shows design.
cURL shows truth.

That’s why backend developers love it.

Common Mistakes Beginners Make

Let me save you some frustration 😅

1. Forgetting quotes

If URL has spaces or special characters:

curl "https://example.com?name=John Doe"

2. Wrong Content-Type

If sending JSON, always add:

-H "Content-Type: application/json"

3. Typos in URL

http vs https
Missing slash
Wrong domain

Happens more than you think.

4. Ignoring Status Code

Always check:

HTTP/2 200

Use -i if needed.

Where cURL Fits in Backend Development

If you’re building backend APIs:

You build endpoint
      ↓
You test with cURL
      ↓
You verify response
      ↓
Frontend connects later

It’s fast.
No need for frontend.
No need for Postman (at least initially).

Also used in:

Automation scripts
Cron jobs
Health checks
Debugging production issues

Final Thought

cURL is not complicated.

It just looks scary because it’s raw.

But once you understand this flow:

Client → Request → Server → Response

Everything becomes logical.

Start small.
Use simple GET requests.
Slowly add headers and POST.

Confidence first. Depth later.

DNS & DNS Record Types Explained

Rajat Yadav — Wed, 11 Feb 2026 17:12:56 +0000

When You Type `autmnit.github.io`, How Does Your Browser Know Where It Lives?

When you enter:

autmnit.github.io

into your browser, something interesting happens behind the scenes.

Your browser doesn’t understand names like humans do.
It only understands IP addresses numbers like:

203.0.113.10

So the real question is:

How does the browser convert a name into a number?

That translation is handled by something called DNS.

What Is DNS? (The Internet’s Phonebook)

Let’s keep it very simple.

The internet runs on IP addresses, but humans prefer names.

Instead of remembering:

203.0.113.10

we type:

autmnit.github.io

DNS (Domain Name System) is the system that converts:

Name → IP address

You can think of DNS like your phone contacts.

You tap on “Mom”, but your phone actually dials a number.
You don’t see the number — but it’s there.

Same thing here.

Simple Flow Diagram

You type: autmnit.github.io

Browser → DNS: "What is the IP of autmnit.github.io?"

DNS → "It is 203.0.113.10"

Browser → Connects to 203.0.113.10
Website loads.

That’s DNS in action.

Why DNS Records Are Needed

DNS is not just one big list.

It’s more like a structured database with different types of records, and each type answers a different question.

For example:

Where is the website hosted?
Where should emails be delivered?
Who is responsible for managing this domain?
Is this domain verified with Google or some service?

Each of these has a specific DNS record type.

One domain → Many records.

Just like one contact in your phone can have:

Mobile number
Office number
Email
Notes

A domain can have:

A record
AAAA record
CNAME
MX
NS
TXT
And more

Let’s understand them slowly, one by one.

NS Record – Who Is Responsible for This Domain?

NS stands for Name Server.

An NS record answers this question:

“Who is managing the DNS for this domain?”

It does not tell the IP address of the website.

Instead, it tells the world:

“If you want DNS information about autmnit.github.io, ask these servers.”

Example (conceptually):

autmnit.github.io
NS → ns1.dns-provider.com
NS → ns2.dns-provider.com

That means:

All DNS questions should go to those name servers.

Simple NS Diagram

Internet: "Where do I ask about autmnit.github.io?"

Answer: "Ask ns1.dns-provider.com"

Think of it like paperwork.

NS = the office that manages all the records.

A Record – Name → IPv4 Address

This is one of the most important records.

An A record maps a domain name to an IPv4 address.

Example:

autmnit.github.io → 203.0.113.10

When your browser asks:

“Where is autmnit.github.io?”

The A record answers:

“It’s at 203.0.113.10.”

Diagram for A Record

autmnit.github.io
        ↓
   203.0.113.10

That’s it. Direct mapping.

If you remember just one DNS record, this is usually the one beginners think about.

AAAA Record – Name → IPv6 Address

An AAAA record works just like an A record.

But instead of IPv4, it maps to IPv6.

IPv6 addresses look like:

2001:db8:85a3::8a2e:370:7334

So:

autmnit.github.io → 2001:db8:85a3::8a2e:370:7334

You don’t need to go deep into IPv6 right now.

Just remember:

A     = IPv4
AAAA  = IPv6

Same purpose, different address type.

CNAME Record – One Name Points to Another Name

CNAME stands for Canonical Name.

It does NOT point to an IP.

It points to another domain name.

Example:

www.autmnit.github.io → autmnit.github.io

This means:

“To find www.autmnit.github.io, just look up autmnit.github.io.”

CNAME Diagram

www.autmnit.github.io
        ↓
autmnit.github.io
        ↓
203.0.113.10

So CNAME is like a nickname.

Important beginner confusion:

A vs CNAME

A record:

Name → IP directly

CNAME:

Name → Another name

Also:

A CNAME cannot point to an IP.
Usually a domain has either A or CNAME for the same name, not both.

MX Record – How Emails Find the Mail Server

MX stands for Mail Exchange.

It answers this question:

“Where should emails for this domain be delivered?”

Example:

autmnit.github.io → MX → mail.autmnit.github.io

Now imagine someone sends:

hello@autmnit.github.io

The sending mail server asks DNS:

“Where do I send mail for autmnit.github.io?”

DNS replies:

“Send it to mail.autmnit.github.io.”

Then DNS looks up:

mail.autmnit.github.io → 203.0.113.20

And the email gets delivered.

Email Flow Diagram

Email sent to: hello@autmnit.github.io

Mail server → DNS: "Where to deliver?"

DNS → MX: mail.autmnit.github.io
DNS → A: 203.0.113.20

Mail server → connects to 203.0.113.20
Email delivered.

NS vs MX (Common Confusion)

NS:

Who manages DNS for this domain?

MX:

Where should emails go?

They solve completely different problems.

TXT Record – Extra Info and Verification

TXT records store text information.

They are widely used for:

SPF (which servers can send email)
DKIM / DMARC (email authentication)
Domain verification (Google, AWS, etc.)

Example:

autmnit.github.io → TXT → "v=spf1 include:_spf.google.com ~all"

TXT records don’t route traffic.

They add rules, proof, or verification.

Think of them like sticky notes attached to your domain.

How All Records Work Together (Complete Setup Example)

Let’s imagine a full setup for:

autmnit.github.io

Example DNS Structure

1. NS Records

NS → ns1.dns-provider.com
NS → ns2.dns-provider.com

These manage everything.

2. A Record (Website)

autmnit.github.io → 203.0.113.10

Website lives here.

3. AAAA Record (Optional)

autmnit.github.io → 2001:db8:85a3::8a2e:370:7334

IPv6 version.

4. CNAME (www version)

www.autmnit.github.io → autmnit.github.io

Alias for main domain.

5. Mail Server Setup

mail.autmnit.github.io → 203.0.113.20
autmnit.github.io → MX → mail.autmnit.github.io

Emails delivered correctly.

6. TXT Records

TXT → SPF rule
TXT → Domain verification code

Security and verification handled.

Complete Website Loading Flow

When you open autmnit.github.io

Browser → DNS: "IP of autmnit.github.io?"

DNS:
   NS → Responsible name server
   A  → 203.0.113.10

Browser → Connects to 203.0.113.10
Website loads.

When someone sends email

Mail server → DNS: "MX for autmnit.github.io?"

DNS:
   MX → mail.autmnit.github.io
   A  → 203.0.113.20

Mail server → Connects to 203.0.113.20
Email delivered.

Quick Recap of All Records

Record	What It Solves	Simple Meaning
NS	Who manages DNS?	Official DNS authority
A	Where is website (IPv4)?	Name → IPv4
AAAA	Where is website (IPv6)?	Name → IPv6
CNAME	Alias for another name	Nickname
MX	Where do emails go?	Mail server
TXT	Extra info & verification	Notes & rules

Final Thoughts

DNS sounds complex at first, but honestly it’s just:

A system that converts names into IP addresses
A set of small records, each solving one specific problem

If you remember:

A / AAAA → website location
CNAME → alias
MX → email routing
NS → who manages DNS
TXT → extra rules and verification

Then you already understand DNS better than many beginners.

From here, the best thing you can do is:

Open your domain DNS settings and just observe each record type.
Slowly it stops feeling like magic and starts feeling like logic.

And once that happens, you’re in control.

Happy learning guys..

TCP vs UDP: When to Use What, and How TCP Relates to HTTP

Rajat Yadav — Wed, 11 Feb 2026 13:48:07 +0000

When we make two computers communicate over the internet, they don't just throwing data at each other at random. They must follow some rules. Otherwise packets might get lost, arrive out of order, get duplicated, or completely overload the other machine.

That’s why the internet uses protocols agreed-upon rules for communication.

At the transport layer, two of the most important protocols are:

TCP (Transmission Control Protocol)
UDP (User Datagram Protocol)

On top of these, we have HTTP, which your browser and web servers use to exchange web data. But here’s something many beginners misunderstand:

HTTP does not replace TCP.
It runs on top of it.

Let’s break this down slowly and clearly.

The Internet Needs Rules to Send Data

The basic problem

Imagine your computer wants to:

Load a webpage
Send a message
Stream a video
Call someone on a video app

Between you and the other computer, the network can:

Drop packets
Deliver them in the wrong order
Duplicate them
Get congested

If there were no rules to handle this chaos, communication would be unreliable and messy.

So the internet uses different layers of protocols. At the transport layer, the main rules for sending data from point A to point B are TCP and UDP.

Two Different Philosophies

You can think of TCP and UDP as two different mindsets.

TCP mindset:

“I want everything delivered correctly, in order, and nothing should be lost.”

Like a registered courier or a phone call where you confirm every message.

UDP mindset:

“I want speed. If something gets lost, that’s okay.”

Like a live announcement where you don’t pause to confirm every word.

Neither one is “better.” They just solve different problems.

What Are TCP and UDP? (High-Level View)

TCP : Safe and Reliable

TCP stands for Transmission Control Protocol.

It is:

Connection-oriented
Reliable

Connection oriented means:

Before sending actual data, both sides establish a connection. This is done using the famous 3-way handshake.

Basically:

“Hey, can we talk?”
“Yes, we can.”
“Okay, let’s start.”

Reliable means:

TCP guarantees:

Data arrives
Data arrives in order
Data is not corrupted

It uses:

Acknowledgements (ACKs)
Retransmissions
Flow control

You can think of TCP like a phone call:

You establish the call.
You confirm the other person heard you.
If something is unclear, you repeat it.
You speak at a pace the other person can handle.

Trade-off

All this safety adds overhead:

Extra headers
Handshakes
Retransmissions

So TCP can be slower and heavier compared to UDP.

UDP – Fast but Risky

UDP stands for User Datagram Protocol.

It is:

Connectionless
Best-effort

Connectionless means:

No handshake. No setup. You just send packets.

Best-effort means:

There are no guarantees.

Packets may:

Get lost
Arrive out of order
Be duplicated

UDP does not fix this for you.

Think of UDP like a live broadcast:

No handshake with each listener
No confirmation messages
No waiting for slow receivers
Just send and move on

Trade-off

Less overhead = lower latency.

UDP is faster and lighter, but less reliable.

Key Differences Between TCP and UDP

Aspect	TCP	UDP
Connection	Connection-oriented (handshake)	Connectionless
Reliability	Reliable (ACK + retransmit)	No guarantee
Order	Guaranteed	Not guaranteed
Speed	Slower	Faster
Overhead	Higher	Lower
Analogy	Phone call	Broadcast announcement

Simplified Flow Comparison

TCP

Client → Server

SYN →
SYN-ACK ←
ACK →
Data →
ACK ←
FIN →

There is setup, confirmation, and proper closing.

UDP

Client → Server

Packet
Packet
Packet

No handshake. No acknowledgements.

Just send.

When Should You Use TCP?

Use TCP when correctness matters more than speed.

Examples:

Loading a webpage
Downloading a file
Sending an email
API calls
Database connections

If even one byte is missing, the result becomes wrong or broken.

Mental model:

“Better to wait slightly longer and get the correct data.”

When Should You Use UDP?

Use UDP when low latency matters more than perfect delivery.

Examples:

Video calls
Online games
Live streaming
VoIP
DNS queries (usually first attempt)

In real-time systems, late data is useless.

If a video frame arrives too late, there is no point replaying it.

Mental model:

“Better to get most of the data quickly than all of it too late.”

Real-World Examples

TCP Examples

Web browsing (HTTP/HTTPS)
Email (SMTP, IMAP)
File transfer (FTP, SFTP)
REST APIs
gRPC over HTTP

UDP Examples

Video conferencing
Online gaming
Live sports streaming
Voice calls
DNS lookups

Where Does HTTP Fit In?

Now comes the part where many people get confused.

HTTP Is NOT a Transport Protocol

HTTP stands for HyperText Transfer Protocol.

It is an application-layer protocol.

It defines:

What a request looks like
What a response looks like
Methods like GET and POST
Status codes like 200 OK

But it does NOT define how bytes move across the network.

That’s TCP’s job.

How the Layers Stack

Very simplified model:

Application layer → HTTP, HTTPS, SMTP, DNS
Transport layer → TCP, UDP
Network layer → IP
Link layer → Ethernet, Wi-Fi

So when you load a webpage:

TCP establishes a connection.
TCP guarantees reliable delivery.
HTTP sends: GET /page
Server responds: 200 OK + HTML

HTTP speaks over a reliable TCP connection.

Simple Analogy

TCP = The phone line
HTTP = The language you speak over that phone line

TCP ensures:

No missing words
Correct order

HTTP defines:

What you are saying
What it means

Why HTTP Does Not Replace TCP

HTTP depends on TCP.

HTTP does not:

Retransmit lost packets
Reorder packets
Handle flow control

TCP already does that.

If HTTP tried to replace TCP, it would need to reimplement reliability from scratch which makes no sense.

So instead:

TCP handles delivery
HTTP handles meaning

Common Beginner Confusion

“Is HTTP the same as TCP?”

No.

TCP:

Deals with connections and reliable transport
Knows nothing about URLs or HTML

HTTP:

Deals with requests and responses
Assumes a reliable stream is already provided

Different layers. Different responsibilities.

One Important Note (Modern Twist)

Traditional HTTP (HTTP/1.1 and HTTP/2) runs over TCP.

But HTTP/3 runs over QUIC, which itself runs over UDP.

That’s a more advanced topic, but it shows how layers can evolve while keeping the same logical separation.

Final Summary

The internet needs rules to handle unreliable networks.
TCP provides reliable, ordered communication.
UDP provides fast, low-latency communication without guarantees.
HTTP is an application protocol that runs on top of TCP (usually).
TCP is the delivery system; HTTP is the language.

Once you clearly separate these layers in your mind, networking becomes much easier to understand.

And honestly, this clarity helps a lot when you start learning:

HTTPS
APIs
WebSockets
HTTP/2 and HTTP/3
Microservices
System design

Because almost everything on the internet builds on these foundations.

Happy learning.......

How DNS Resolution Works

Rajat Yadav — Wed, 11 Feb 2026 13:38:51 +0000

Every single time we use the internet, DNS is working for you even if you never realized it existed.

When you type google.com in your browser and hit Enter, our computer doesn’t magically know where Google live. In the background, a system has to answer one basic question:

“What IP address belongs to google.com?”

That system is DNS, and dig is a tool that helps us look inside this process instead of treating it like black magic.

In this article, we’ll understand:

What DNS is and why name resolution is needed
What the dig command does and why engineers use it
How DNS lookup happens step by step: root → TLD → authoritative
How commands like dig . NS, dig com NS, dig google.com NS, and dig google.com all fit together

I’ll keep the language simple and practical.

1. What Is DNS? (The Internet’s Phonebook Idea)

1.1 Names vs numbers

Humans are comfortable with names:

google.com
facebook.com
myblog.dev

Computers don’t work like that. They talk using numbers called IP addresses, such as:

142.250.72.14
2404:6800:4004:81b::200e

Now imagine trying to remember IP addresses for every website you use. That would be painful and honestly impossible.

That’s why DNS exists.

DNS (Domain Name System) is basically a distributed phonebook for the internet.

You ask:

“What is the IP for google.com?”

DNS replies:

“Here it is.”

This process converting a domain name into an IP address is called name resolution.

1.2 Why name resolution is important

Name resolution exists for some very practical reasons:

Humans prefer names, not numbers
Servers and IP addresses can change over time
We want stable domain names even if infrastructure changes

DNS also enables some powerful features:

Load balancing - one domain can point to multiple IPs
High availability – traffic can move if a server goes down
Geo routing – users get routed to the nearest server

So DNS isn’t just a lookup table. It’s an abstraction layer that makes the internet flexible and scalable.

2. What Is `dig` and Why Do People Use It?

dig stands for Domain Information Groper. The name sounds funny, but the tool itself is serious.

2.1 What `dig` actually does

dig is a command-line utility that lets you directly question DNS servers.

For example:

dig google.com

This command shows you:

What question was asked
What DNS server answered
Which records came back
Extra DNS details that browsers usually hide

With dig, you can ask things like:

“What IP does this domain resolve to?”
“Which name servers manage this TLD?”
“Who is authoritative for this domain?”

2.2 When `dig` is useful in real life

You usually reach for dig when:

A website isn’t loading and DNS might be the issue
You updated DNS records and want to check propagation
You’re learning networking or backend systems
You’re working in DevOps, cloud, or infrastructure

If curl is essential for HTTP debugging, dig plays the same role for DNS.

3. DNS Is Hierarchical (This Part Is Very Important)

DNS is not flat. It is organized in layers.

Think of it like a tree structure:

Root (.) – the top of everything
TLDs – .com, .org, .net, .in, .io, etc
Domains – google.com, example.com
Subdomains – www.google.com, api.example.com

Each layer knows just enough and points you to the next one.

3.1 Who knows what?

Root servers
Know which servers handle each TLD
TLD servers (.com, .org, etc.)
Know which servers handle domains under them
Authoritative servers
Know the actual DNS records for a domain

Your recursive resolver (ISP DNS, 8.8.8.8, 1.1.1.1, etc.) walks through these layers on your behalf.

4. `dig . NS` – Starting at the Root

Let’s begin from the very top.

dig . NS

4.1 What this command is asking

. means the root of DNS
NS asks for Name Server records

So the question is:

“Which name servers are responsible for the DNS root?”

4.2 What you’ll see

You’ll get results like:

a.root-servers.net
b.root-servers.net
…
m.root-servers.net

There are 13 logical root servers, but each one is backed by many physical servers around the world.

4.3 Why root servers matter

Root servers:

Don’t know IPs for websites
Don’t know google.com directly
Only know who manages TLDs like .com

They basically say:

“I don’t know the answer, but I know who to ask next.”

5. `dig com NS` – The TLD Layer

Now let’s move one level down.

dig com NS

5.1 What this means

You’re asking:

“Which name servers are responsible for the .com domain?”

5.2 Typical output

You’ll see servers like:

a.gtld-servers.net
b.gtld-servers.net
…

These are TLD name servers for .com.

5.3 What TLD servers do

TLD servers don’t store IP addresses for every website.

Instead, they know:

Which servers are authoritative for google.com
Which servers are authoritative for facebook.com

So their answer is basically:

“I don’t know the IP, but these servers are allowed to answer for google.com.”

6. `dig google.com NS` – Authoritative Name Servers

Now we reach the domain itself.

dig google.com NS

6.1 What this command asks

“Which name servers are authoritative for google.com?”

6.2 What you’ll see

Usually something like:

ns1.google.com
ns2.google.com
ns3.google.com
ns4.google.com

These servers are controlled by Google and are the source of truth for that domain.

6.3 Why authoritative servers are important

Authoritative servers store real DNS records:

A / AAAA → IP addresses
MX → mail servers
TXT → verification, SPF, etc
CNAME → aliases

When asked:

“What is the IP for google.com?”

They can answer directly.

From a system design view, this is where your domain configuration actually lives.

7. `dig google.com` – The Complete DNS Lookup

Now the most common command.

dig google.com

7.1 What happens behind the scenes

When you run this:

Your recursive resolver checks cache
If not found, it asks root servers
Then it asks .com TLD servers
Then it asks google.com authoritative servers
It returns the final IP

dig then prints:

QUESTION section
ANSWER section
Sometimes AUTHORITY and ADDITIONAL info

7.2 Why you don’t see all steps by default

Normally, recursive resolvers hide this complexity.

To force every step to be shown, you can use:

dig +trace google.com

This displays the full root → TLD → authoritative journey.

8. How Recursive Resolvers Tie Everything Together

Assume nothing is cached.

Browser needs google.com
OS asks the recursive resolver
Resolver asks root
Root points to .com
.com points to google.com NS
Authoritative server gives IP
Resolver caches it (TTL)
Browser connects using TCP/TLS

DNS finishes before HTTP even starts.

9. Why This Matters in Real Systems

DNS directly affects:

Website performance
Application availability
CDN routing
Multi-region architectures
Failover strategies

A broken DNS setup can make a perfectly healthy server look “down”.

Understanding DNS and dig makes you better at:

Debugging
Designing scalable systems
Working with cloud and infra

10. Final Recap

DNS maps domain names to IP addresses
Name resolution exists for usability and flexibility
dig helps inspect DNS behavior
DNS works in layers:
- Root → dig . NS
- TLD → dig com NS
- Authoritative → dig google.com NS
- Final IP → dig google.com
Recursive resolvers walk these layers for you

To practice, try running:

dig . NS
dig com NS
dig google.com NS
dig google.com

Slowly, step by step.

Once this clicks, DNS stops feeling confusing and starts feeling logical.

Happy learning....

Mastering Redux-Saga: The Missing Piece for Async Redux Flows

Rajat Yadav — Thu, 02 Oct 2025 16:50:20 +0000

Subtitle: Learn how Redux-Saga simplifies complex async logic, why it's better than Thunk for certain use cases, and how to use its powerful effects.

Introduction

If you've worked with Redux, you already know its biggest strength: predictability. But as soon as you try to handle asynchronous logic like API calls, retries, or debounced search it can get messy.

The default recommendation is Redux Thunk, which lets you write async code inside action creators. That works fine for small projects, but as your app grows, you’ll find yourself tangled in a web of callback-like async flows that are hard to test, cancel, or control.

This is where Redux-Saga really shines. I recently worked with it and found it both powerful and straightforward to apply. Redux-Saga acts like a background worker or “smart assistant” it listens for specific actions, executes side effects such as API calls, and then dispatches new actions accordingly. By leveraging JavaScript’s generator functions, it enables writing asynchronous code in a way that feels synchronous, making complex workflows much easier to manage.

Let’s dive in.

What is Redux-Saga?

Redux-Saga is a middleware library for Redux that manages side effects, such as:

API requests
Delays, throttling, and debouncing
Background tasks (polling, websockets, syncing)
Complex async flows (cancellation, retries, races)

It uses generator functions (function*) to make async flows look synchronous and testable.

Install it with:

npm install redux-saga

At its core, a saga is just a generator function that listens for actions and performs work:

function* fetchUserSaga(action) {
  const data = yield call(api.fetchUser, action.payload);
  yield put({ type: 'FETCH_USER_SUCCESS', payload: data });
}

Why Use Redux-Saga?

Redux itself only handles synchronous state changes. If you want to:

Fetch data from an API
Cancel an ongoing request
Retry on failure
Debounce a search input

…you need middleware.

👉 Thunk works for simple cases.
👉 Saga provides first-class helpers for cancellation, retries, and concurrency.

In short:

Thunk = good enough for small apps
Saga = robust, testable async layer for large apps

How Redux-Saga Works (Big Picture)

Component dispatches an action → { type: "FETCH_USER_REQUEST", payload: 42 }
Saga watches for that action using helpers like takeEvery or takeLatest
Saga runs async logic (API call, debounce, retry)
Saga dispatches another action → { type: "FETCH_USER_SUCCESS", payload: data }
Reducer updates state

Think of Saga as the async middleman between your actions and reducers.

Generator Functions in Sagas

A saga is always a generator function:

function* mySaga() {
  console.log("Saga started");
  yield "hello"; // pause here until middleware resumes
  console.log("Saga ended");
}

Key point: when you yield, you’re not executing the effect directly. Instead, you return an effect object that Redux-Saga interprets.

Example:

yield put({ type: "USER_FETCH_SUCCESS", payload: data });

This doesn’t immediately dispatch the action it tells Redux-Saga:

“When you resume me, dispatch this action.”

Core Saga Effects

1. Core Side-Effect Creators

call(fn, ...args) → Call a function and wait for the result
put(action) → Dispatch an action
select(selector) → Read from the Redux store
delay(ms) → Pause for a duration

2. Listening / Watching for Actions

take(pattern) → Wait for a specific action
takeEvery(pattern, saga) → Run saga for every action
takeLatest(pattern, saga) → Cancel previous, run latest
throttle(ms, pattern, saga) → Run saga at most once per interval
debounce(ms, pattern, saga) → Run saga only after inactivity

3. Concurrency & Task Control

all([...effects]) → Run multiple effects in parallel
race({...effects}) → Compete between tasks
fork(saga) → Run saga in background, non-blocking
cancel(task) → Cancel a forked saga
retry(count, delayMs, fn, ...args) → Retry with backoff

Real-World Example: Search with Debounce + Cancellation

Let’s say you’re building a search bar that should:
✅ Wait until the user stops typing (debounce)
✅ Cancel any previous requests if the user types again (cancellation)

With Redux-Saga, this is straightforward:

import { call, put, debounce } from 'redux-saga/effects';

// worker saga
function* searchSaga(action) {
  try {
    const response = yield call(fetch, `/api/search?q=${action.payload}`);
    const results = yield response.json();
    yield put({ type: 'SEARCH_SUCCESS', payload: results });
  } catch (error) {
    yield put({ type: 'SEARCH_FAILURE', error });
  }
}

// watcher saga with debounce
function* watchSearch() {
  yield debounce(500, 'SEARCH_QUERY', searchSaga);
}

Usage in a component:

dispatch({ type: 'SEARCH_QUERY', payload: 'redux saga' });

What happens:

If the user types “redux” quickly, previous requests are cancelled.
Only after 500ms of no typing, searchSaga executes.

👉 Clean, declarative, and testable.

This kind of flow is painful with Thunk but trivial with Saga.

Saga vs Reducer: Who Does What?

Think of Redux like a factory:

State / Slice = The storage room (where data lives)
Reducer = Workers who update inventory (pure synchronous updates)
Action = Instruction notes sent to workers
Saga = Special robots that handle complicated async tasks before sending new instructions

So:

Reducers → change state
Sagas → perform async work, then ask reducers to update state

They don’t replace each other they complement each other.

Redux Thunk vs Redux-Saga

Feature	Redux Thunk	Redux-Saga
API Calls	✅ Simple	✅ Powerful
Cancellation	❌ Hard	✅ Built-in
Retry/Backoff	❌ Manual	✅ Built-in
Debounce/Throttle	❌ Manual	✅ Built-in
Testing	Medium	Easy
Best For	Small apps	Large/complex apps

Key Takeaways

Redux-Saga is a middleware that makes async Redux flows declarative, testable, and powerful.
It uses generator functions and effects (call, put, takeEvery, etc.) to manage side effects.
It handles cancellation, retry, debounce, and concurrency out of the box—things that are painful with Thunk.
It doesn’t replace reducers it complements them as the async layer.

👉 For apps with complex async needs, Saga is a better long-term investment.

Once you get comfortable with generators, Redux-Saga feels like giving Redux a brain that thinks asynchronously.

🛠️ pdf-parse ENOENT Error Explained: Fixing the “05-versions-space.pdf” Crash in Node.js

Rajat Yadav — Wed, 04 Jun 2025 10:13:58 +0000

TL;DR: If you're seeing ENOENT related to 05-versions-space.pdf while using pdf-parse in Node.js - it's not your fault. It's hidden debug logic inside the library. Here's the fix.

🧩 The Problem: A Mysterious Crash
I was building a pdf parsing backend in Node.js. Everything was working until I added pdf-parse to extract text from uploaded PDFs.
My code was clean:

import fs from "fs/promises";
import pdfParser from "pdf-parse";
const buffer = await fs.readFile("uploads/file.pdf");
const data = await pdfParser(buffer);
console.log(data.text);

Then suddenly… boom:

Error: ENOENT: no such file or directory, open 'C:\\...\\test\\data\\05-versions-space.pdf'

What file? What path? I never wrote that!

🤯 The Real Culprit
The problem isn't your code - it's debug logic inside pdf-parse itself.
If you peek inside node_modules/pdf-parse/index.js, you'll find this block:

let isDebugMode = !module.parent;
if (isDebugMode) {
  const filePath = path.join(__dirname, "test/data/05-versions-space.pdf");
  const dataBuffer = fs.readFileSync(filePath);
  ...
}

🟥 If this runs, and the file doesn't exist (and it won't), the app crashes.

✅ The Fixes
🔧 Option 1: Create the Missing File
Quickest workaround:
1- Create this folder:

mkdir -p node_modules/pdf-parse/test/data

2- Add any valid PDF file to it and name it:

05-versions-space.pdf

✅ Done. Your app won't crash anymore.

🛡️ Option 2: Permanently Disable Debug Mode (Recommended)
You can patch the module to prevent future issues:
1- Install patch-package:

npm install patch-package

2- Edit node_modules/pdf-parse/index.js:
Change this line:

let isDebugMode = !module.parent;

To:

let isDebugMode = false;

3- Save the file and run:

npx patch-package pdf-parse

4- Add this to your package.json scripts to ensure the patch survives reinstalls:

"scripts": {
  "postinstall": "patch-package"
}

💡 Lessons Learned

Not all bugs are in your code.
Always check a library's index.js if you're getting unexpected behavior.
Defensive code matters. Production libraries should avoid running debug logic by default.

🧠 Final Thoughts
If you're building a backend using pdf-parse, make sure you:
❌ Disable the debug mode
📁 Handle file paths using path.resolve() to avoid OS path issues
🛡️ Always wrap file reads in try/catch

Like this post? Bookmark it or share with your dev group - because these "WTF" bugs deserve visibility.

Have you faced a similar issue with another library? Drop a comment, and let's debug together.

DEV Community: Rajat Yadav

CSS Selectors 101: Targeting Elements with Precision

Why CSS Selectors Are Needed

The Basic Problem

Real-World Analogy: Addressing People

The Structure of a CSS Rule

1. Element Selector – Style by Tag Name

What It Does

Syntax

Example

When To Use It

2. Class Selector – Style by Class Name

What It Does

Syntax

Example

Multiple Classes

When To Use Class

3. ID Selector – Style by ID

What It Does

Syntax

Example

Class vs ID (Simple Table)

4. Group Selectors – Style Multiple Things

5. Descendant Selectors – Style Inside Something

Syntax

Example

Deeper Nesting

Visual Flow (Conceptual)

6. Basic Selector Priority (Specificity)

Strength Order (High Level)

Example

Same Strength Case

Final Complete Example

Final Thoughts

Emmet for HTML: A Beginner’s Guide to Writing Faster Markup

The Problem: Writing HTML is Slow (And Sometimes Painful)

What is Emmet? (In Very Simple Words)

Why Emmet is a Game Changer (Especially for Beginners)

1. Speed

2. Fewer Mistakes

3. You Understand Structure Better

4. Focus on Thinking, Not Typing

5. Professional Workflow

How Emmet Actually Works

Basic Emmet Symbols (This is Where Fun Starts)

Understanding with Simple Diagrams

1. Child (>)

2. Sibling (+)

3. Repeat (*)

Adding Classes and IDs

Classes use .

IDs use #

Combine Both

Adding Attributes with [ ]

Nesting Elements Like a Pro

Simple Nesting

Multiple Levels

Multiple Children

Repeating Structures

Simple Repeat

Nested Repeat

Complex Repeat

Adding Text Content {}

With Nesting

Numbered Content with $

The Magic Shortcut: Full HTML Boilerplate

Real World Example: Navigation Bar

Visual Guide: What Happens Internally

Patterns You’ll Use Almost Daily

Practice (Do This Seriously)

Final Thoughts

Understanding HTML Tags and Elements

What Is HTML and Why Do We Use It?

The Basic Idea

HTML Is the Skeleton of a Webpage

Why Do We Use HTML?

What Is an HTML Tag?

Tags Are Like Labels

Visual Diagram: Tag Structure

Tag vs Element (Important Difference)

1. Child (`>`)

2. Sibling (`+`)

3. Repeat (`*`)

Classes use `.`

IDs use `#`

Adding Attributes with `[ ]`

Adding Text Content `{}`

Numbered Content with `$`