Forem: Mohd Asif Ansari

CSS Selectors 101

Mohd Asif Ansari — Sat, 31 Jan 2026 16:03:48 +0000

You've written some HTML. Now you want to make it look good with CSS. But how do you tell CSS which elements to style?

That's where selectors come in.

Why Do We Need CSS Selectors?

Imagine you're in a classroom and you want to give instructions:

Without selectors:
"Everyone, stand up!"

With selectors:
"Students wearing red shirts, stand up!"
"Student named John, stand up!"
"Students in row 3, stand up!"

CSS selectors work the same way. They let you target specific HTML elements and apply styles to them.

Without selectors: You can't style anything
With selectors: You control exactly what gets styled

Basic HTML for Our Examples

Let's use this HTML throughout the blog:

<body>
  <h1>Welcome</h1>
  <p>This is a paragraph.</p>
  <p class="highlight">This is highlighted.</p>
  <p id="special">This is special.</p>
  <div class="box">
    <p>Paragraph inside box</p>
  </div>
</body>

Now let's see how to select different parts.

1. Element Selector

The element selector targets all elements of a specific type.

Syntax:

tagname {
  /* styles */
}

Example:

p {
  color: blue;
}

What this does:
Targets ALL <p> elements and makes them blue.

Result:

"This is a paragraph." → Blue
"This is highlighted." → Blue
"This is special." → Blue
"Paragraph inside box" → Blue

Use when: You want to style all elements of one type.

More Examples

Style all headings:

h1 {
  font-size: 32px;
  color: darkblue;
}

Style all divs:

div {
  background-color: lightgray;
  padding: 10px;
}

2. Class Selector

The class selector targets elements with a specific class.

Syntax:

.classname {
  /* styles */
}

Notice the dot (.) before the class name.

Example:

.highlight {
  background-color: yellow;
}

What this does:
Targets only <p class="highlight"> and gives it a yellow background.

Result:

"This is highlighted." → Yellow background
Other paragraphs → No yellow background

Use when: You want to style specific elements that share a purpose or style.

Multiple Classes

An element can have multiple classes:

<p class="highlight bold">Text</p>

Target it:

.highlight {
  background-color: yellow;
}

.bold {
  font-weight: bold;
}

Both styles apply!

Classes vs Elements

Element selector (all paragraphs):

p {
  color: blue;
}

Every <p> becomes blue.

Class selector (specific paragraphs):

.highlight {
  color: red;
}

Only <p class="highlight"> becomes red.

3. ID Selector

The ID selector targets a single unique element.

Syntax:

#idname {
  /* styles */
}

Notice the hash (#) before the ID name.

Example:

#special {
  font-size: 20px;
  color: red;
}

What this does:
Targets only <p id="special"> and makes it red with larger text.

Result:

"This is special." → Red, 20px font
Other paragraphs → No change

Important: IDs should be unique. Only ONE element should have a specific ID.

Class vs ID

Class:

Use for multiple elements
Starts with .
Example: class="button"

ID:

Use for one unique element
Starts with #
Example: id="header"

HTML example:

<!-- Multiple elements can share a class -->
<button class="btn">Click</button>
<button class="btn">Submit</button>

<!-- Only one element should have an ID -->
<div id="main-content">...</div>

CSS:

.btn {
  background-color: blue;
}

#main-content {
  width: 80%;
}

4. Group Selectors

Group selectors let you apply the same styles to multiple selectors.

Syntax:

selector1, selector2, selector3 {
  /* styles */
}

Use commas to separate selectors.

Example:

h1, h2, h3 {
  color: navy;
  font-family: Arial;
}

What this does:
All <h1>, <h2>, and <h3> elements get navy color and Arial font.

Another example:

p, .highlight, #special {
  line-height: 1.5;
}

All paragraphs, elements with class "highlight", AND the element with id "special" get line-height of 1.5.

Use when: Multiple different selectors need the same styling.

5. Descendant Selectors

Descendant selectors target elements inside other elements.

Syntax:

parent child {
  /* styles */
}

Use a space between selectors.

Example:

div p {
  color: green;
}

What this does:
Targets <p> elements that are inside <div> elements.

Given this HTML:

<p>Outside div</p>
<div>
  <p>Inside div</p>
</div>

Result:

"Outside div" → Not green (not inside a div)
"Inside div" → Green (inside a div)

More Examples

Target links inside navigation:

nav a {
  color: white;
  text-decoration: none;
}

Target paragraphs inside a specific class:

.box p {
  font-size: 14px;
}

Deeper nesting:

div ul li {
  list-style: square;
}

Targets <li> elements inside <ul> inside <div>.

Combining Selectors

You can combine different selector types for precision.

Class inside element:

div .highlight {
  background-color: yellow;
}

Targets elements with class "highlight" inside <div>.

Element with class:

p.highlight {
  color: red;
}

Targets <p> elements that have class "highlight" (no space between p and .highlight).

ID inside element:

section #special {
  font-weight: bold;
}

Selector Priority (Specificity)

What happens if multiple selectors target the same element?

Simple rule: More specific selector wins.

Priority order (low to high):

Element selectors (p)
Class selectors (.highlight)
ID selectors (#special)

Example:

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

p {
  color: blue;
}

.text {
  color: green;
}

#intro {
  color: red;
}

Result: Text is red because ID has highest priority.

Simple to remember:

ID beats class
Class beats element
More specific beats less specific

Practical Examples

Example 1: Simple Blog Post

/* All paragraphs */
p {
  line-height: 1.6;
  color: #333;
}

/* Main heading */
h1 {
  font-size: 36px;
  color: #000;
}

/* Highlighted quotes */
.quote {
  background-color: #f0f0f0;
  border-left: 4px solid blue;
  padding: 10px;
}

/* Author section */
#author {
  font-style: italic;
  color: gray;
}

Example 2: Navigation Menu

/* Style all nav links */
nav a {
  color: white;
  text-decoration: none;
  padding: 10px;
}

/* Active link */
.active {
  background-color: blue;
}

Example 3: Card Layout

/* All cards */
.card {
  border: 1px solid #ddd;
  border-radius: 8px;
  padding: 20px;
}

/* Card titles */
.card h2 {
  color: #333;
  margin-bottom: 10px;
}

/* Card paragraphs */
.card p {
  color: #666;
  line-height: 1.5;
}

Before and After Examples

HTML:

<h1>My Website</h1>
<p>Welcome to my site.</p>
<p class="important">This is important!</p>

Before CSS (no styling):

My Website
Welcome to my site.
This is important!

After CSS:

h1 {
  color: blue;
  font-size: 32px;
}

p {
  color: gray;
}

.important {
  color: red;
  font-weight: bold;
}

Result:

"My Website" → Blue, 32px
"Welcome to my site." → Gray
"This is important!" → Red, bold

Quick Reference

Selector	Syntax	Example	What it targets
Element	`tagname`	`p`	All `<p>` elements
Class	`.classname`	`.highlight`	Elements with class="highlight"
ID	`#idname`	`#header`	Element with id="header"
Group	`sel1, sel2`	`h1, h2`	All h1 AND all h2
Descendant	`parent child`	`div p`	`<p>` inside `<div>`

Common Beginner Mistakes

1. Forgetting the dot for classes

/* Wrong */
highlight {
  color: red;
}

/* Right */
.highlight {
  color: red;
}

2. Forgetting the hash for IDs

/* Wrong */
header {
  width: 100%;
}

/* Right */
#header {
  width: 100%;
}

3. Using IDs for multiple elements

<!-- Wrong: Same ID used twice -->
<div id="box">Box 1</div>
<div id="box">Box 2</div>

<!-- Right: Use classes -->
<div class="box">Box 1</div>
<div class="box">Box 2</div>

Summary

CSS Selectors = Ways to target HTML elements for styling

Main types:

Element → p (all paragraphs)
Class → .highlight (elements with that class)
ID → #special (one unique element)
Group → h1, h2, h3 (multiple selectors)
Descendant → div p (p inside div)

Priority:
ID > Class > Element

Remember:

Use . for classes
Use # for IDs
Use space for descendant selectors
Use comma for group selectors

Selectors are the foundation of CSS. Master these, and you can style anything!

Emmet for HTML

Mohd Asif Ansari — Sat, 31 Jan 2026 14:53:08 +0000

Writing HTML can feel slow and repetitive. Typing <div></div>, <p></p>, opening and closing tags over and over...

What if you could type div and instantly get <div></div>? That's what Emmet does.

What is Emmet?

Emmet is a shortcut tool built into most code editors. It lets you write HTML super fast using abbreviations.

Simple example:

You type: p
Press Tab
You get: <p></p>

That's it. Emmet turns short codes into full HTML.

Why Use Emmet?

Without Emmet:

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

You type all of this manually. Lots of typing, lots of time.

With Emmet:

div.container>ul>li*3

Press Tab, and you get the same HTML instantly!

Benefits:

Write HTML 10x faster
Fewer typos (no missing closing tags)
Less repetitive work
Focus on structure, not syntax

How Emmet Works

Emmet is built into most modern code editors:

VS Code (built-in)
Sublime Text (built-in)
Atom (built-in)
WebStorm (built-in)

How to use it:

Type an Emmet abbreviation
Press Tab or Enter
It expands into HTML

That's all you need to know to get started!

Basic Emmet Syntax

Let's learn the fundamentals one by one.

1. Creating Simple Elements

Type the tag name and press Tab.

Example 1:

div → Tab

Result:

<div></div>

Example 2:

p → Tab

Result:

<p></p>

Example 3:

h1 → Tab

Result:

<h1></h1>

Easy! Just type the tag name.

2. Adding Classes

Use a dot (.) to add a class.

Example:

div.container → Tab

Result:

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

Multiple classes:

div.card.shadow → Tab

Result:

<div class="card shadow"></div>

3. Adding IDs

Use a hash (#) to add an ID.

Example:

div#header → Tab

Result:

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

Class and ID together:

div#header.navbar → Tab

Result:

<div id="header" class="navbar"></div>

4. Adding Attributes

Use square brackets [] to add custom attributes.

Example:

a[href="https://google.com"] → Tab

Result:

<a href="https://google.com"></a>

Multiple attributes:

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

Result:

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

5. Adding Text Content

Use curly braces {} to add text inside elements.

Example:

p{Hello World} → Tab

Result:

<p>Hello World</p>

With class:

h1.title{Welcome} → Tab

Result:

<h1 class="title">Welcome</h1>

Creating Nested Elements

Use > to create child elements (nesting).

Example 1:

div>p → Tab

Result:

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

Example 2:

ul>li → Tab

Result:

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

Deeper nesting:

div>ul>li → Tab

Result:

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

With classes:

div.container>h1.title → Tab

Result:

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

Repeating Elements with Multiplication

Use * to create multiple copies.

Example 1:

li*3 → Tab

Result:

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

Example 2:

div.box*4 → Tab

Result:

<div class="box"></div>
<div class="box"></div>
<div class="box"></div>
<div class="box"></div>

With nesting:

ul>li*5 → Tab

Result:

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

Combining Everything

Now let's combine what we learned.

Example 1: Navigation menu

nav>ul>li*4>a → Tab

Result:

<nav>
  <ul>
    <li><a href=""></a></li>
    <li><a href=""></a></li>
    <li><a href=""></a></li>
    <li><a href=""></a></li>
  </ul>
</nav>

Example 2: Card layout

div.container>div.card*3>h2+p → Tab

Result:

<div class="container">
  <div class="card">
    <h2></h2>
    <p></p>
  </div>
  <div class="card">
    <h2></h2>
    <p></p>
  </div>
  <div class="card">
    <h2></h2>
    <p></p>
  </div>
</div>

Note: + creates sibling elements (elements at the same level).

Creating Siblings with +

Use + to create elements next to each other (siblings).

Example:

h1+p → Tab

Result:

<h1></h1>
<p></p>

Multiple siblings:

h1+p+p → Tab

Result:

<h1></h1>
<p></p>
<p></p>

Complex example:

header>h1+nav>ul>li*3 → Tab

Result:

<header>
  <h1></h1>
  <nav>
    <ul>
      <li></li>
      <li></li>
      <li></li>
    </ul>
  </nav>
</header>

HTML Boilerplate with Emmet

The most useful Emmet shortcut: creating the full HTML structure.

Just type:

! → Tab

You get:

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

Instant complete HTML page structure!

Alternative (same result):

html:5 → Tab

Practical Examples

Example 1: Blog Post Structure

article>h1.title+p.meta+div.content>p*3 → Tab

Result:

<article>
  <h1 class="title"></h1>
  <p class="meta"></p>
  <div class="content">
    <p></p>
    <p></p>
    <p></p>
  </div>
</article>

Example 2: Form

form>input[type="text"]+input[type="email"]+button{Submit} → Tab

Result:

<form>
  <input type="text">
  <input type="email">
  <button>Submit</button>
</form>

Example 3: Table

table>tr*3>td*4 → Tab

Result:

<table>
  <tr>
    <td></td>
    <td></td>
    <td></td>
    <td></td>
  </tr>
  <tr>
    <td></td>
    <td></td>
    <td></td>
    <td></td>
  </tr>
  <tr>
    <td></td>
    <td></td>
    <td></td>
    <td></td>
  </tr>
</table>

Emmet Cheat Sheet

Basic:

tagname → <tagname></tagname>
div → <div></div>

Classes and IDs:

.classname → <div class="classname"></div>
#idname → <div id="idname"></div>
div.class#id → <div class="class" id="id"></div>

Attributes:

a[href] → <a href=""></a>
img[src alt] → <img src="" alt="">

Text:

p{text} → <p>text</p>

Nesting:

div>p → Parent > Child
div+p → Siblings

Multiplication:

li*3 → Creates 3 <li> elements

Boilerplate:

! or html:5 → Full HTML template

Tips for Beginners

1. Start simple
Just practice basic tags first: div, p, h1

2. Use it daily
The more you use Emmet, the faster you get

3. Don't memorize everything
Learn what you use most often

4. Try each example
Open VS Code and actually type these shortcuts

5. Emmet is optional
You can still write HTML normally. Emmet just makes it faster

Common Mistakes

Forgetting to press Tab

Type the abbreviation
Then press Tab to expand it

Typos in abbreviation

dvi.container → Won't work
div.container → Works!

Not checking the result
Always check what Emmet generated and adjust if needed

Summary

Emmet = Shortcuts for writing HTML fast

How it works:

Type abbreviation
Press Tab
Get full HTML

Key symbols:

. for classes
# for IDs
> for children (nesting)
+ for siblings
* for repetition
[] for attributes
{} for text
! for HTML boilerplate

Most useful shortcuts:

! → Full HTML template
div.container>ul>li*5 → Quick structures
form>input[type]*3 → Forms

Start using Emmet today, and you'll wonder how you ever coded without it!

Understanding HTML Tags and Elements

Mohd Asif Ansari — Sat, 31 Jan 2026 14:42:27 +0000

If you're starting web development, HTML is the first thing you'll learn. But what exactly are tags and elements? Let's break it down simply.

What is HTML?

HTML (HyperText Markup Language) is the skeleton of every webpage.

Think of it like:

HTML = Structure (skeleton)
CSS = Styling (skin, clothes)
JavaScript = Behavior (movement, actions)

Example:
Without HTML, there's no webpage. Without CSS, it looks plain. Without JavaScript, it's static.

HTML gives structure: headings, paragraphs, links, images, buttons.

What is an HTML Tag?

A tag is a marker that tells the browser "this is a heading" or "this is a paragraph."

Simple analogy: Tags are like labels on boxes. They tell you what's inside.

Syntax:

<tagname>

Tags usually come in pairs: opening and closing.

Opening Tag, Closing Tag, and Content

Most tags have three parts:

<p>This is a paragraph</p>

Breaking it down:

<p> = Opening tag (starts the paragraph)
This is a paragraph = Content (what's inside)
</p> = Closing tag (ends the paragraph)

Another example:

<h1>Welcome to My Website</h1>

<h1> = Opening tag
Welcome to My Website = Content
</h1> = Closing tag

What is an HTML Element?

An element is the whole thing: opening tag + content + closing tag.

<p>Hello World</p>

This entire thing is an element.

Tag vs Element:

Tag: <p> or </p> (just the marker)
Element: <p>Hello World</p> (the complete package)

Simple way to remember:

Tag = The label
Element = Label + Content

Common HTML Tags

Let's look at some basic tags you'll use all the time.

Headings

<h1>Main Heading</h1>
<h2>Subheading</h2>
<h3>Smaller Heading</h3>

h1 is the biggest, h6 is the smallest
Use h1 for page title, h2 for sections

Paragraph

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

For regular text content

Links

<a href="https://google.com">Click here</a>

href tells where the link goes
Text between tags is what you click

Images

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

src is the image file
alt describes the image

Div (Container)

<div>
  <h1>Title</h1>
  <p>Some text</p>
</div>

Groups content together
Used for layout and styling

Span (Inline Container)

<p>This is <span>highlighted</span> text</p>

For styling small parts of text
Doesn't break the line

Self-Closing (Void) Elements

Some elements don't have content, so they don't need a closing tag.

Examples:

<img src="photo.jpg" alt="Photo">
<br>
<hr>
<input type="text">

Why no closing tag?
These elements don't contain text or other elements. They're complete on their own.

Common self-closing tags:

<img> - Images
<br> - Line break
<hr> - Horizontal line
<input> - Form inputs
<meta> - Metadata
<link> - External resources

Note: You might see <img /> or <br /> - the / is optional in HTML5.

Block-Level vs Inline Elements

This is important for understanding how elements behave on the page.

Block-Level Elements

Take up the full width available and start on a new line.

Example:

<div>First block</div>
<div>Second block</div>
<p>Third block</p>

Result:

┌─────────────────────┐
│ First block         │
└─────────────────────┘
┌─────────────────────┐
│ Second block        │
└─────────────────────┘
┌─────────────────────┐
│ Third block         │
└─────────────────────┘

Each one takes the full width and stacks vertically.

Common block elements:

<div>, <p>, <h1>-<h6>, <ul>, <li>, <section>

Inline Elements

Only take up as much width as needed and don't start a new line.

Example:

<p>This is <span>inline</span> and <strong>also inline</strong> text.</p>

Result:

This is inline and also inline text.

Everything stays on the same line.

Common inline elements:

<span>, <a>, <strong>, <em>, <img>

Visual Comparison

Block elements (stack vertically):

<div>Box 1</div>
<div>Box 2</div>

┌────────┐
│ Box 1  │
└────────┘
┌────────┐
│ Box 2  │
└────────┘

Inline elements (flow horizontally):

<span>One</span><span>Two</span><span>Three</span>

OneTwoThree

Practical Example

Let's build a simple webpage:

<!DOCTYPE html>
<html>
  <head>
    <title>My First Page</title>
  </head>
  <body>
    <h1>Welcome to My Website</h1>
    <p>This is my first webpage. I'm learning HTML!</p>

    <p>I'm a <strong>student</strong> learning web development.</p>

    <a href="https://google.com">Visit Google</a>

    <hr>

    <img src="photo.jpg" alt="My photo">
  </body>
</html>

Breaking it down:

<html> - Root element (contains everything)
<head> - Metadata (not visible on page)
<title> - Page title (shows in browser tab)
<body> - Visible content
<h1>, <h2> - Headings
<p> - Paragraphs
<strong> - Bold text (inline)
<a> - Link
<hr> - Horizontal line (self-closing)
<img> - Image (self-closing)

Tag vs Element - Final Clarity

Tag:

<p>  or  </p>

Just the markers with angle brackets.

Element:

<p>This is a paragraph</p>

The complete thing: opening tag + content + closing tag.

Think of it like:

Tag = Quotation marks (" ")
Element = The entire quoted sentence

Try This Yourself

Open any webpage, right-click, and select "Inspect" (or press F12).

You'll see the HTML structure. Look for:

Opening and closing tags
Block vs inline elements
Self-closing tags
Nested elements (elements inside elements)

This is the best way to learn!

Common Beginner Mistakes

1. Forgetting closing tags

<!-- Wrong -->
<p>Text

<!-- Right -->
<p>Text</p>

2. Incorrect nesting

<!-- Wrong -->
<p><strong>Text</p></strong>

<!-- Right -->
<p><strong>Text</strong></p>

3. Using block elements inside inline elements

<!-- Wrong -->
<span><div>Content</div></span>

<!-- Right -->
<div><span>Content</span></div>

Quick Reference

Block Elements (stack vertically):

<div>, <p>, <h1>-<h6>, <ul>, <li>, <section>

Inline Elements (flow horizontally):

<span>, <a>, <strong>, <em>, <img>

Self-Closing:

<img>, <br>, <hr>, <input>, <meta>, <link>

Most Used Tags:

Headings: <h1> to <h6>
Paragraph: <p>
Link: <a>
Image: <img>
Container: <div>
Inline text: <span>
Bold: <strong>
Italic: <em>

Summary

HTML = Structure of webpages

Tag = Marker like <p> or </p>

Element = Complete package: <p>Content</p>

Block elements = Stack vertically, take full width

Inline elements = Flow horizontally, take only needed width

Self-closing = No content, no closing tag needed

Start with these basics, and you'll understand 90% of HTML. The rest is just learning more tags for specific purposes.

How a Browser Works

Mohd Asif Ansari — Sat, 31 Jan 2026 14:30:45 +0000

You type "google.com" in your browser and press Enter. A webpage appears. But what actually happened in those few seconds?

Let's peek behind the curtain and see how browsers work.

What is a Browser, Really?

A browser is more than just "something that opens websites."

Simple definition: A browser is a software that fetches web content, understands it, and displays it as a visual page.

Think of it as: A translator that takes code (HTML, CSS, JavaScript) and turns it into the webpage you see.

Popular browsers: Chrome, Firefox, Safari, Edge

The Big Question

What happens when you type a URL and press Enter?

Let's break it down step by step.

Main Parts of a Browser

A browser has several components working together:

User Interface (what you see and interact with)
    ↓
Browser Engine (coordinates everything)
    ↓
Rendering Engine (turns code into visuals)
    ↓
Networking (fetches resources from internet)
    ↓
JavaScript Engine (runs JS code)
    ↓
Data Storage (cookies, cache, etc.)

Let's understand each part.

1. User Interface (UI)

This is everything you see and click:

Address bar (where you type URLs)
Back/Forward buttons
Refresh button
Bookmarks bar
Tabs

Key point: The UI is NOT the webpage itself. It's the browser's controls around the webpage.

2. Browser Engine

The browser engine is like a coordinator. It connects the UI with the rendering engine.

What it does:

Takes your input (URL, clicks)
Tells the rendering engine what to display
Manages the flow between components

Examples:

Chrome/Edge use Blink
Firefox uses Gecko
Safari uses WebKit

You don't need to remember these names. Just know the browser engine coordinates everything.

3. Rendering Engine

The rendering engine is the star of the show. It turns HTML and CSS into what you see.

Main job:

HTML + CSS → Visual Webpage

Popular rendering engines:

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

4. Networking Component

The networking component fetches resources from the internet.

What it fetches:

HTML files
CSS files
JavaScript files
Images, videos, fonts

How it works:

You type "google.com"
Networking component sends HTTP request
Server responds with HTML
Browser receives it and passes to rendering engine

The Journey: From URL to Webpage

Now let's trace the complete flow.

Step 1: You Type a URL

You type: https://example.com
Browser's networking component sends request

Step 2: HTML Arrives

Server responds with HTML:

<html>
  <head>
    <title>My Page</title>
    <link rel="stylesheet" href="style.css">
  </head>
  <body>
    <h1>Hello World</h1>
    <p>Welcome to my page</p>
  </body>
</html>

Step 3: Parsing HTML → Creating DOM

The rendering engine parses (reads and understands) the HTML.

What is parsing? Breaking something complex into understandable parts.

Simple example:

Sentence: "The cat sat on the mat"
Parsing breaks it into:
- Subject: The cat
- Verb: sat
- Where: on the mat

For HTML:

<body>
  <h1>Hello</h1>
  <p>World</p>
</body>

Becomes a DOM (Document Object Model) tree:

body
 ├── h1 ("Hello")
 └── p ("World")

DOM = Tree structure representing the HTML

Step 4: CSS Arrives and Gets Parsed

Browser sees <link rel="stylesheet" href="style.css"> and fetches the CSS file:

h1 {
  color: blue;
  font-size: 24px;
}
p {
  color: gray;
}

This gets parsed into CSSOM (CSS Object Model):

h1: color=blue, font-size=24px
p: color=gray

CSSOM = Tree structure representing CSS rules

Step 5: Combining DOM and CSSOM

Browser combines DOM and CSSOM to create the Render Tree.

Render Tree = What actually needs to be displayed

Render Tree:
body
 ├── h1 ("Hello") - blue, 24px
 └── p ("World") - gray

Note: Only visible elements go in the render tree. Things like <script> or display: none elements are skipped.

Step 6: Layout (Reflow)

Now the browser calculates where everything goes on the screen.

Layout (Reflow) = Calculating position and size of each element

h1: starts at (0, 0), width: 100%, height: 30px
p: starts at (0, 30), width: 100%, height: 20px

This is like measuring where furniture goes in a room before placing it.

Step 7: Painting

Painting = Actually drawing pixels on the screen

The browser paints each element:

Draw blue text "Hello" at position (0, 0)
Draw gray text "World" at position (0, 30)

Step 8: Display

Finally, the painted content is displayed on your screen. You see the webpage!

Complete Flow Visualized

1. Type URL
   ↓
2. Fetch HTML (Networking)
   ↓
3. Parse HTML → Create DOM
   ↓
4. Fetch CSS (Networking)
   ↓
5. Parse CSS → Create CSSOM
   ↓
6. Combine DOM + CSSOM → Render Tree
   ↓
7. Layout (Calculate positions)
   ↓
8. Paint (Draw pixels)
   ↓
9. Display on screen

What About JavaScript?

When the browser encounters <script>, it pauses HTML parsing and runs the JavaScript.

JavaScript Engine (like V8 in Chrome) executes the code:

document.querySelector('h1').style.color = 'red';

This modifies the DOM, which triggers:

Render tree update
Layout recalculation
Repaint

That's why heavy JavaScript can slow down page loading.

Simple Parsing Example

Let's understand parsing with a math expression:

Input: 3 + 4 * 2

Parsing breaks it into a tree:

Why? The browser needs to understand the structure before calculating (multiplication first, then addition).

Similarly, HTML like <div><p>Text</p></div> becomes:

div
 └── p
      └── "Text"

Parsing = Understanding structure

Browser Architecture Summary

┌─────────────────────────────────────┐
│       User Interface (UI)           │
│  (Address bar, buttons, tabs)       │
└─────────────────────────────────────┘
              ↓
┌─────────────────────────────────────┐
│       Browser Engine                │
│  (Coordinates components)           │
└─────────────────────────────────────┘
              ↓
┌─────────────────────────────────────┐
│       Rendering Engine              │
│  (HTML/CSS → Visual page)           │
└─────────────────────────────────────┘
       ↓              ↓
┌─────────────┐  ┌──────────────────┐
│ Networking  │  │ JavaScript Engine│
│ (Fetch data)│  │ (Run JS code)    │
└─────────────┘  └──────────────────┘
       ↓
┌─────────────────────────────────────┐
│       Data Storage                  │
│  (Cookies, cache, localStorage)     │
└─────────────────────────────────────┘

Key Takeaways

What a browser does:

Fetches HTML, CSS, JS from server
Parses HTML → Creates DOM
Parses CSS → Creates CSSOM
Combines them → Render Tree
Calculates layout (where things go)
Paints (draws on screen)
Displays the webpage

Important terms:

DOM = Tree of HTML elements
CSSOM = Tree of CSS rules
Render Tree = What to display
Layout = Where to place things
Paint = Actually drawing pixels
Parsing = Understanding structure

Remember: You don't need to memorize all this. Just understand the flow: fetch → parse → render → display.

Why This Matters for Developers

Understanding browser internals helps you:

Write faster websites - Minimize DOM changes, optimize CSS

Debug issues - Know why things are slow or look broken

Optimize performance - Reduce reflows and repaints

Interviews - Common question in frontend interviews

Next time you load a webpage, you'll know all the magic happening behind the scenes!

TCP Working: 3-Way Handshake & Reliable Communication

Mohd Asif Ansari — Sat, 31 Jan 2026 14:17:46 +0000

Ever wondered how your computer makes sure data actually arrives when you browse the web? That's TCP doing its magic.

Let's understand how TCP works and why it's so important.

What Happens Without Rules?

Imagine sending messages with no rules:

Some messages arrive, some don't
Messages arrive in random order
No way to know if someone received your message
Duplicate messages arrive

Result: Chaos. Your webpage would be jumbled, downloads would fail, and nothing would work properly.

We need rules. That's where TCP comes in.

What is TCP?

TCP (Transmission Control Protocol) ensures data gets delivered reliably.

What it guarantees:

Data arrives (no loss)
Data arrives in order
No duplicate data
Connection is established before sending

Think of it like: A phone call. You dial, they pick up, you both confirm you can hear each other, then you talk.

Problems TCP Solves

Problem 1: How do we know the receiver is ready?

Solution: 3-way handshake before sending data

Problem 2: What if data gets lost on the internet?

Solution: Acknowledgments and retransmission

Problem 3: What if data arrives out of order?

Solution: Sequence numbers

Problem 4: How do we end the connection properly?

Solution: Connection termination process

The TCP 3-Way Handshake

Before sending any data, TCP establishes a connection. This is called the 3-way handshake.

Simple analogy:

You: "Hey, can you hear me?" (SYN)
Friend: "Yes, can you hear me?" (SYN-ACK)
You: "Yes, I can!" (ACK)
Now you both talk.

Step-by-Step Handshake

Step 1: Client sends SYN

Client → Server: "I want to connect. My starting number is 100."

SYN = Synchronize
Client picks a random starting sequence number (say 100)

Step 2: Server responds with SYN-ACK

Server → Client: "Got it! I'm ready. My starting number is 300. I acknowledge your 100."

SYN = Server also wants to connect
ACK = Acknowledges client's SYN
Server picks its own sequence number (say 300)

Step 3: Client sends ACK

Client → Server: "Got it! I acknowledge your 300. Let's start."

ACK = Acknowledges server's SYN
Connection is now established
Data transfer can begin

Visual flow:

Client                          Server
   |                               |
   |-------- SYN (seq=100) ------->|
   |                               |
   |<----- SYN-ACK (seq=300) ------|
   |      (ack=101)                |
   |                               |
   |-------- ACK (ack=301) ------->|
   |                               |
   [Connection Established]

Why 3 Steps? Why Not 2?

Why not just:

Client: "I want to connect"
Server: "OK, connected"

Problem: The server doesn't know if the client received the "OK"

With 3-way handshake:

Both sides confirm they can send AND receive
Both agree on starting sequence numbers
Both are ready for data transfer

How Data Transfer Works

Once connected, data flows with sequence numbers and acknowledgments.

Example: Sending "HELLO WORLD"

Client → Server: "Here's data bytes 100-104 (HELLO)"
Server → Client: "Got it! I received up to byte 104. Send more."
Client → Server: "Here's data bytes 105-109 (WORLD)"
Server → Client: "Got it! I received up to byte 109."

Key points:

Each byte gets a sequence number
Receiver acknowledges what it received
If acknowledgment doesn't come, sender resends

How TCP Ensures Reliability

1. Acknowledgments (ACK)

Every piece of data is acknowledged.

Sender: "I sent bytes 100-110"
Receiver: "Got it! Send from 111 onwards"

If no ACK comes back, sender knows something went wrong.

2. Retransmission

If data gets lost, TCP resends it.

Client: Sends packet with bytes 100-110
[Packet gets lost on internet]
Client waits for ACK...
No ACK received after timeout
Client: Resends bytes 100-110
Server: "Got it! ACK 111"

3. Sequence Numbers Keep Order

Data might arrive out of order. Sequence numbers fix this.

Server receives: Packet 3, Packet 1, Packet 2
Server reorders: Packet 1, Packet 2, Packet 3
Server delivers data in correct order

4. Checksums Detect Errors

Each packet has a checksum to detect corruption.

If checksum doesn't match:
- Packet is dropped
- No ACK is sent
- Sender retransmits

Complete Data Transfer Example

Sending "HI":

1. Client → Server: 
   "Data: bytes 100-101 (HI), checksum: XYZ"

2. Server checks:
   - Checksum valid? ✓
   - In order? ✓

3. Server → Client:
   "ACK: Got up to byte 102"

4. If ACK doesn't arrive:
   Client waits (timeout)
   Client resends bytes 100-101

How TCP Connections Close

Just like establishing a connection needs a handshake, closing it needs a proper goodbye.

Connection Termination (4 steps):

Step 1: Client wants to close

Client → Server: "FIN - I'm done sending data"

Step 2: Server acknowledges

Server → Client: "ACK - I got your FIN"

Step 3: Server is done too

Server → Client: "FIN - I'm also done"

Step 4: Client acknowledges

Client → Server: "ACK - Got it, closing"

Visual:

Client                          Server
   |                               |
   |-------- FIN ---------------->|
   |                               |
   |<------- ACK -----------------|
   |                               |
   |<------- FIN -----------------|
   |                               |
   |-------- ACK ---------------->|
   |                               |
   [Connection Closed]

Why 4 steps?

Server might still have data to send
Both sides need to confirm they're done

TCP Connection Lifecycle

Complete flow:

1. Establish Connection
   3-Way Handshake (SYN → SYN-ACK → ACK)

2. Transfer Data
   Send data with sequence numbers
   Receive ACKs
   Retransmit if needed

3. Close Connection
   4-Way termination (FIN → ACK → FIN → ACK)

Why This Matters

When you visit a website:

TCP handshake establishes connection
Your browser sends HTTP request over TCP
Server sends webpage data reliably
TCP ensures every byte arrives correctly
Connection closes when done

Without TCP:

Webpages would be incomplete
Downloads would fail randomly
No way to know if data arrived

With TCP:

Guaranteed delivery
Correct order
Error detection
Reliable web browsing

Quick Summary

TCP 3-Way Handshake:

SYN - "Let's connect"
SYN-ACK - "Agreed, let's connect"
ACK - "Connection established"

Reliable Communication:

Sequence numbers - Keep data in order
Acknowledgments - Confirm receipt
Retransmission - Resend lost data
Checksums - Detect errors

Connection Closing:

FIN - "I'm done"
ACK - "Got it"
FIN - "Me too"
ACK - "Bye"

Key Takeaway: TCP is like a careful delivery service. It makes sure everything arrives safely, in order, and without errors. That's why your web browsing just works.

TCP vs UDP: When to Use What

Mohd Asif Ansari — Sat, 31 Jan 2026 14:05:17 +0000

When you send data over the internet, there are rules that make sure it gets where it needs to go. Two important ones are TCP and UDP.

Let's understand what they are and how they relate to HTTP.

The Internet Needs Rules

Sending data is like sending a package - you need rules for how it's delivered.

TCP and UDP are two different delivery methods with different trade-offs.

What is TCP?

TCP (Transmission Control Protocol) = Reliable delivery

Key features:

Guarantees data arrives
Arrives in correct order
Checks for errors
Slower (because of all the checking)

Analogy: Like a phone call. You know the other person is listening. If something's unclear, you repeat it.

What is UDP?

UDP (User Datagram Protocol) = Fast delivery

Key features:

Does NOT guarantee delivery
Might arrive out of order
No error checking
Much faster

Analogy: Like shouting announcements. Quick, but you don't know who heard it or if they heard correctly.

TCP vs UDP: Quick Comparison

	TCP	UDP
Speed	Slower	Faster
Reliability	Guaranteed	Not guaranteed
Order	In order	Might be jumbled
Use when	Accuracy matters	Speed matters

Simple version:

TCP = Reliable but slower (registered mail)
UDP = Fast but risky (shouting across a room)

When to Use TCP

Use TCP when you can't lose data.

Examples:

Web browsing - Need complete webpages
Email - Can't lose parts of messages
File downloads - Need every byte
Online banking - Transactions must complete
Chat apps - Messages need correct order

When to Use UDP

Use UDP when speed matters more than perfection.

Examples:

Video calls (Zoom) - Few dropped frames are okay
Live streaming - Small glitches beat buffering
Online gaming - Need instant updates, lag is worse than missed data
DNS lookups - Quick requests, can retry if needed
VoIP calls - Tiny audio glitches are fine, delay ruins conversation

Real-World Examples

Streaming a live match:

UDP is used
A few pixelated frames? No problem
Buffering to get perfection? Ruins the experience

Downloading a PDF:

TCP is used
Every page must be perfect
Worth waiting a bit longer

Playing an online game:

UDP is used
Player position updates need to be instant
Missing one update is better than lag

What is HTTP?

HTTP (HyperText Transfer Protocol) is how web browsers talk to web servers.

When you visit a website:

Browser sends HTTP request
Server sends HTTP response
Browser displays the page

Key point: HTTP is NOT a transport protocol. It's an application-level protocol.

The Confusion: Is HTTP the Same as TCP?

No! They work at different levels.

Think of it like this:

TCP = The delivery truck
HTTP = The package inside the truck

Layers (simplified):

Application Layer:  HTTP, FTP, DNS
    ↓
Transport Layer:    TCP, UDP
    ↓
Internet Layer:     IP

How HTTP and TCP Work Together

HTTP runs ON TOP of TCP.

When you visit a website:

1. Browser creates HTTP request
   (GET /index.html)

2. TCP breaks it into packets
   (Ensures reliable delivery)

3. Packets sent over internet

4. Server's TCP reassembles packets

5. Server processes HTTP request

6. Server sends HTTP response via TCP

7. Your browser receives it and displays page

Visual:

HTTP Request
    ↓
TCP Connection (reliable delivery)
    ↓
Internet
    ↓
TCP at Server (reassembles)
    ↓
HTTP Response

Why HTTP Needs TCP

HTTP needs reliable, ordered delivery:

Webpages must load completely
Images can't be half-downloaded
Text must appear in correct order

That's why HTTP uses TCP, not UDP.

Quick Summary

TCP:

Reliable, ordered, error-checked
Use for: web, email, downloads

UDP:

Fast, no guarantees
Use for: video calls, gaming, streaming

HTTP:

Application protocol for web communication
Runs ON TOP of TCP (not instead of)
Defines how browsers and servers talk

Key Relationship:

HTTP (what to say)
  runs on
TCP (how to deliver it reliably)

Getting Started with cURL

Mohd Asif Ansari — Sun, 18 Jan 2026 11:33:43 +0000

If you're learning backend development, you've probably heard "just cURL it." But what is cURL?

Let me explain it simply.

What is a Server?

A server is a computer that waits for requests and sends back responses.

Example:

You type "google.com"
Browser asks Google's server for the page
Server sends back the webpage
Browser shows it

What is cURL?

cURL is a tool that lets you talk to servers from your terminal.

Simple version:

Browser talks to servers by clicking and typing URLs
cURL talks to servers through commands

Why use cURL?

Test your API quickly
See raw data servers send back
Faster than opening a browser
Good for learning how HTTP works

Your First cURL Command

Open your terminal and type:

curl https://example.com

You'll see HTML code. That's it! You just fetched a webpage.

What happened:

cURL asked example.com for the page
Server sent back HTML
cURL showed it in terminal

Request and Response

Every cURL command has two parts:

Request: What you send to the server

Response: What the server sends back

Your Terminal → Request → Server
Server → Response → Your Terminal

Using cURL with APIs

APIs send back data (usually JSON) instead of webpages.

GET Request (Getting Data)

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

You'll get:

{
  "id": 1,
  "name": "Leanne Graham",
  "email": "leanne@example.com"
}

That's API data!

POST Request (Sending Data)

curl -X POST https://jsonplaceholder.typicode.com/posts \
  -H "Content-Type: application/json" \
  -d '{"title":"My Post","body":"Hello"}'

What this means:

-X POST - We're creating something
-H - Telling server we're sending JSON
-d - The actual data

GET vs POST

GET - Asking for data

curl https://api.com/users

POST - Sending data

curl -X POST https://api.com/users -d '{"name":"John"}'

Simple rule:

Fetching info? Use GET
Creating/updating? Use POST

Useful Examples

Check if website is working:

curl https://google.com

Save response to a file:

curl https://api.com/data > output.json

See detailed info:

curl -v https://example.com

Common Mistakes

1. Forgetting quotes around JSON:

# Wrong
curl -d {title:test} https://api.com

# Right
curl -d '{"title":"test"}' https://api.com

2. Not using POST for creating data:

# Add -X POST when creating
curl -X POST https://api.com/users -d '{"name":"John"}'

3. Missing Content-Type for JSON:

curl -X POST https://api.com/data \
  -H "Content-Type: application/json" \
  -d '{"key":"value"}'

When to Use cURL

Testing your API:

curl http://localhost:3000/api/users

Checking if an API works:

curl https://api.github.com/users/octocat

Quick debugging:

curl https://yourapp.com/endpoint

Quick Reference

Basic request:

curl https://example.com

POST with JSON:

curl -X POST https://api.com/data \
  -H "Content-Type: application/json" \
  -d '{"key":"value"}'

Save to file:

curl https://example.com > file.html

Summary

cURL = Tool to send requests from terminal

Two main types:

GET - Get data
POST - Send data

Basic pattern:

curl [URL]

Start simple. Try fetching a page. Then try an API. Build from there.

How DNS Resolution Works

Mohd Asif Ansari — Sun, 18 Jan 2026 11:26:41 +0000

Ever wondered what happens when you type "google.com" and hit enter? Let's find out using a tool called dig.

What is DNS?

DNS (Domain Name System) is the internet's phonebook.

Computers use IP addresses (like 142.250.192.46), but we prefer names like "google.com".

DNS translates names to IP addresses.

The `dig` Command

dig (Domain Information Groper) lets you see exactly how DNS works.

Basic use:

dig example.com

This asks "what's the IP for example.com?"

DNS Works in Layers

DNS is organized in three layers:

Root Servers (.)
    ↓
TLD Servers (.com, .org, .net)
    ↓
Authoritative Servers (google.com, facebook.com)

When you look up "google.com":

Ask root servers: "Who handles .com?"
Ask .com servers: "Who handles google.com?"
Ask google.com servers: "What's the IP?"

Let's see this with dig.

Step 1: Root Name Servers

Command:

dig . NS

Asks: "Who are the root name servers?"

Output:

.    IN  NS  a.root-servers.net.
.    IN  NS  b.root-servers.net.
...

What this means:

The . is the DNS root
13 root server systems (a through m)
They know about all TLDs (.com, .org, etc.)

Key point: Root servers don't know websites. They just direct you to the right TLD.

Step 2: TLD Name Servers

Command:

dig com NS

Asks: "Who handles .com domains?"

Output:

com.  IN  NS  a.gtld-servers.net.
com.  IN  NS  b.gtld-servers.net.
...

What this means:

These manage all .com domains
They know which servers handle each .com domain

Key point: TLD servers say "for google.com, ask Google's servers"

Step 3: Authoritative Name Servers

Command:

dig google.com NS

Asks: "Who are the authoritative servers for google.com?"

Output:

google.com.  IN  NS  ns1.google.com.
google.com.  IN  NS  ns2.google.com.
...

What this means:

These are Google's DNS servers
They have the actual records
They're the final source of truth

Key point: Authoritative servers have the real IP addresses.

Step 4: Full Resolution

Command:

dig google.com

Asks: "What's the IP for google.com?"

Output:

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

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

;; Query time: 23 msec

Breaking it down:

Question: What's google.com's IP?
Answer: 142.250.192.46
Time: 23 milliseconds

Complete DNS Resolution Flow

Here's what happens behind the scenes:

1. Your computer asks DNS resolver (8.8.8.8):
   "What's google.com?"

2. Resolver asks root server:
   "Where are .com servers?"

3. Resolver asks TLD server:
   "Where are google.com servers?"

4. Resolver asks authoritative server:
   "What's the IP?"
   Answer: "142.250.192.46"

5. Your browser connects to that IP

Visual flow:

Your Computer
    ↓
DNS Resolver (8.8.8.8)
    ↓
Root Server (.)
    ↓
TLD Server (.com)
    ↓
Authoritative Server (ns1.google.com)
    ↓
Returns IP to Your Computer

Recursive Resolver

The recursive resolver (like 8.8.8.8) does all the work:

Takes your DNS query
Asks root, TLD, and authoritative servers
Caches results
Returns the final answer

You ask once. The resolver handles everything.

DNS Caching Makes It Fast

DNS caches at multiple levels:

Browser cache
OS cache
DNS resolver cache
ISP cache

Example:

First visit: Root → TLD → Authoritative (~50ms)
Second visit: Cached! (~1ms)

That's why repeat visits are faster.

Practical `dig` Examples

Basic lookup:

dig google.com

Use specific DNS server:

dig @8.8.8.8 google.com

Trace full path:

dig +trace google.com

Get just the IP:

dig +short google.com

Check email servers:

dig google.com MX

What Are NS Records?

NS (Name Server) records say "this server has authority for this domain"

Chain of trust:

Root: "For .com, trust these TLD servers"
TLD: "For google.com, trust these authoritative servers"
Authoritative: "Here's the actual IP"

Real Browser Flow

When you visit a website:

Browser checks cache
OS checks cache
DNS resolver checks cache
If no cache: root → TLD → authoritative
Browser gets IP
Connects and loads page

Happens in milliseconds!

Why Developers Need This

Debugging: Use dig to check DNS issues

Performance: Understand caching to reduce latency

Deployment: Know DNS propagation when changing records

Interviews: DNS is a common system design question

Quick Summary

DNS Hierarchy:

Root → Know about TLDs
TLD → Know about domains
Authoritative → Have actual IPs

Commands:

dig . NS → Root servers
dig com NS → TLD servers
dig google.com NS → Authoritative servers
dig google.com → Get IP

Flow:
Your computer → Resolver → Root → TLD → Authoritative → Back with IP

Key Points:

NS records point to name servers
Resolvers do the work
Caching makes it fast
Each layer delegates to the next

Now you know exactly what happens when you visit a website!

DNS Record Types Explained

Mohd Asif Ansari — Sun, 18 Jan 2026 11:18:28 +0000

You type "google.com" in your browser and it loads. But how does your computer know where Google actually is?

That's DNS (Domain Name System) - the internet's phonebook. It has different types of records for different purposes.

Let me break down the main ones.

What Are DNS Records?

DNS records answer one question: "Where should this request go?"

Different record types give different answers:

"Here's the IP address" (A Record)
"Go ask that other domain" (CNAME Record)
"Send email here" (MX Record)
"These servers control this domain" (NS Record)

1. A Record: The Basic Address

What it does: Maps a domain name to an IP address.

Example:

example.com  →  192.168.1.1

When someone types "example.com", DNS says "go to 192.168.1.1"

Real use: You point your domain to your server's IP address.

Key point: A records work with IPv4 addresses (like 192.168.1.1).

2. CNAME Record: The Alias

What it does: Points one domain name to another domain name.

Example:

www.example.com  →  example.com
blog.example.com  →  example.com

Real use:

Make www.yoursite.com and yoursite.com go to the same place
Use blog.yoursite.com but host on Medium
Route traffic through a CDN

Key point: CNAME redirects to another domain, which then has an A record pointing to the IP.

A Record vs CNAME

A Record: Points directly to an IP

example.com  →  192.168.1.1

CNAME: Points to another domain

www.example.com  →  example.com  →  192.168.1.1

Important: You can't use CNAME for your root domain (example.com). Only subdomains can be CNAMEs.

3. MX Record: Email Routing

What it does: Tells email servers where to send emails for your domain.

Example:

example.com  →  mail.example.com  (priority: 10)
example.com  →  backup-mail.example.com  (priority: 20)

How it works:

Someone emails you@example.com
Their email server checks MX records
Email goes to the server with lowest priority number

Real use: Point your domain's email to Gmail or Outlook servers.

Key point: Lower priority number = tried first. If it fails, tries the next one.

4. NS Record: Who's in Control

What it does: Says which DNS servers control your domain.

Example:

example.com  →  ns1.cloudflare.com
example.com  →  ns2.cloudflare.com

Real use: You buy a domain from GoDaddy but use Cloudflare for DNS. You change NS records to Cloudflare's servers.

Key point: NS records determine who manages all your other DNS records.

NS vs MX: The Difference

NS Record: Which servers control ALL DNS for this domain

MX Record: Which servers handle EMAIL only

How They Work Together

Real example for company.com:

A Record:
company.com  →  93.184.216.34

CNAME Records:
www.company.com  →  company.com
blog.company.com  →  company.com

MX Records:
company.com  →  smtp.google.com  (priority: 10)

NS Records:
company.com  →  ns1.cloudflare.com

What this means:

Main site is at that IP
www and blog point to the same server
Emails go to Google
Cloudflare manages the DNS

Complete Flow for www.company.com

Browser asks: "What's www.company.com?"
DNS checks NS records: "Ask Cloudflare"
Cloudflare checks CNAME: "It's an alias for company.com"
Cloudflare checks A record: "That's 93.184.216.34"
Browser connects to that IP

Happens in milliseconds!

Common Setups

Simple Website:

yoursite.com      →  192.168.1.1  (A)
www.yoursite.com  →  yoursite.com  (CNAME)

Website + Email:

yoursite.com      →  192.168.1.1  (A)
www.yoursite.com  →  yoursite.com  (CNAME)
yoursite.com      →  mail.google.com  (MX)

Using CDN:

yoursite.com      →  192.168.1.1  (A)
www.yoursite.com  →  yoursite.cdn.com  (CNAME)
yoursite.com      →  ns1.cloudflare.com  (NS)

Why Developers Need This

You'll use DNS records for:

Deploying sites: Point domain to server IP
Subdomains: Create api.yoursite.com or dev.yoursite.com
Email setup: Configure business email
CDNs: Route through Cloudflare or AWS
Debugging: Check DNS when sites don't load

Interview tip: Know A vs CNAME and what MX/NS records do.

Quick Summary

A Record: Domain → IP address
CNAME Record: Domain → Another domain (alias)
MX Record: Where emails go (with priority)
NS Record: Which servers control DNS

Remember:

A points to IPs, CNAME points to domains
MX is for email, NS is for DNS control
Lower MX priority number = higher priority
Can't use CNAME on root domain

Understanding DNS helps you deploy sites, fix issues, and ace interviews.

Understanding Network Devices: A Beginner's Guide

Mohd Asif Ansari — Sun, 18 Jan 2026 11:07:24 +0000

Ever wondered what happens when you click a link and a webpage loads? There's a bunch of devices working behind the scenes to make it happen.

I kept hearing terms like "router," "firewall," and "load balancer" but never really got what they do. So I figured it out, and here's the simple explanation.

How Internet Reaches You

Think of the internet as a huge highway. Your ISP (Internet Service Provider) connects your home to that highway. But you need some devices to make it all work.

Here's the basic flow:
Internet → Modem → Router → Switch → Your Devices

Let's see what each one does.

1. Modem: Connects You to the Internet

What it does: The modem converts signals from your ISP into data your devices can use.

Simple analogy: It's like a translator. Your ISP speaks one language, your computer speaks another. The modem translates between them.

Key point: Without a modem, you can't access the internet.

2. Router: Directs Traffic

What it does: The router decides where data should go. Should this go to your laptop? Your phone? Your TV? It figures it out.

It gives each device a local address (like 192.168.1.5) and keeps track of which device asked for what data.

Simple analogy: Think of it like a post office. When mail arrives, it checks the address and delivers it to the right house. When you send mail, it makes sure there's a return address.

Key point: The router manages traffic between your local network and the internet. It's also what creates your Wi-Fi.

3. Switch vs Hub: Local Network Devices

Hub: The Old Way

A hub just broadcasts data to every device connected to it. It's like shouting in a crowded room - everyone hears it, but only one person responds.

Problem: Super inefficient. Everyone has to check if the message is for them.

Switch: The Smart Way

A switch learns which devices are connected where and only sends data to the device that needs it.

Simple analogy:

Hub: Teacher shouts to the whole class for one student
Switch: Teacher walks to that student's desk

Key point: Switches are way better. Hubs are outdated. Always use a switch.

4. Firewall: Security Guard

What it does: Checks all incoming and outgoing traffic and blocks suspicious stuff based on security rules.

Simple analogy: Like a security guard at a building. They check IDs and stop anyone who looks suspicious or isn't allowed in.

What it blocks:

Suspicious incoming traffic
Known bad websites
Weird traffic patterns that might be attacks

Key point: Firewalls protect you from hackers and viruses. When you deploy apps, you'll set up firewall rules to allow only the traffic you want.

5. Load Balancer: Spreads the Work

What it does: Splits incoming traffic across multiple servers so no single server gets overwhelmed.

Simple analogy: Imagine a highway toll booth. One booth = huge traffic jam. Ten booths with someone directing cars = smooth traffic. The load balancer is that director.

Why it matters:

If one server crashes, others keep working
You can add more servers as traffic grows
No single server gets overloaded

Key point: Every big website (Netflix, Amazon, Google) uses load balancers to handle millions of users.

How They Work Together

Let's say someone visits your website. Here's what happens:

Request goes through their modem → onto the internet
Hits your firewall → "Is this safe? Yes, okay."
Reaches your load balancer → sends request to one of your servers
Server responds → goes back through load balancer
Response travels back → through internet, user's modem, router, to their device

Simple Setup Flow:

Internet
   ↓
Firewall (blocks bad stuff)
   ↓
Load Balancer (spreads traffic)
   ↓
Server 1, Server 2, Server 3

Home Network:

Internet
   ↓
Modem (connects to ISP)
   ↓
Router (manages your network)
   ↓
Switch (connects devices)
   ↓
Your laptop, phone, printer, etc.

Why Developers Should Know This

You might think, "I'm a coder, why do I care about network stuff?"

Here's why:

Debugging: Is your app broken, or is the firewall blocking it?
Deployment: You'll set up firewalls and load balancers on AWS or other cloud platforms
Security: Understanding firewalls helps you build secure apps
Performance: Knowing this stuff helps you optimize your code

Quick Summary

Modem: Connects you to internet
Router: Sends data to the right device
Switch: Manages local devices efficiently
Hub: Old, inefficient (don't use)
Firewall: Blocks bad traffic
Load Balancer: Splits traffic across servers

These devices work together to make the internet fast and secure.

Inside Git: How It Works and the Role of the .git Folder

Mohd Asif Ansari — Thu, 15 Jan 2026 16:10:57 +0000

You know git add and git commit. But what actually happens when you run these commands?

Let's look inside Git and understand how it really works.

The .git Folder: Git's Brain

When you run git init, Git creates a hidden .git folder. This folder is where Git stores everything about your project.

See it:

ls -la    # On Linux/Mac
dir /a    # On Windows

Inside .git

.git/
├── HEAD              # Points to current branch
├── config            # Repository settings
├── objects/          # All your data (commits, files)
├── refs/             # Branch pointers
├── index             # Staging area
└── logs/             # Change history

Most important:

objects/: Where Git stores all data
refs/: Where branch pointers live
HEAD: Shows your current position
index: Your staging area

Rule: Never manually edit files in .git. Let Git handle it.

Git Objects: The Three Types

Git stores everything as objects. Three types matter:

1. Blob (File Content)

Stores file content only. No filename, no folders—just content.

Example:
File index.html with content "Hello World" becomes a blob containing just "Hello World".

2. Tree (Directory Structure)

Stores folder structure. Lists files and their locations.

Example:
"This folder has index.html (blob abc123) and style.css (blob def456)."

3. Commit (Snapshot)

Stores project snapshot: which tree, who made it, when, and why.

Example:
"Project looked like this. Author: John. Date: Jan 15. Message: Add homepage."

How They Connect

Commit
  ↓ points to
Tree (folder)
  ↓ contains
Blobs (files)

Real example:

Your project:
├── index.html  ("Hello")
└── style.css   ("body { margin: 0; }")

Git stores:
Commit abc123 → Tree xyz789 → Blob aaa111 ("Hello")
                            → Blob bbb222 ("body { margin: 0; }")

Git Uses Hashes

Every object gets a unique 40-character ID called a hash.

Example:
"Hello World" always creates hash: 980a0d5f19a64b4b30a87d4206aade58726b60e3

Why?

Different content = different hash
Content changes? Hash changes
Git knows immediately if data is corrupted
Same content stored only once

What Happens: git add

You run:

git add index.html

Git does:

Reads file content
Creates blob object with hash
Stores blob in .git/objects/
Updates index (staging area)

Result: File is staged, ready to commit.

The file content is now safely stored in Git, but not committed yet.

What Happens: git commit

You run:

git commit -m "Add homepage"

Git does:

Creates tree object from staging area
Creates commit object pointing to tree
Adds metadata: author, date, message, parent commit
Generates commit hash
Updates branch pointer to new commit

Result: Your changes are permanently saved.

How Git Tracks Changes

Common myth: Git stores the differences between versions.

Truth: Git stores complete snapshots.

But doesn't that waste space?

No! Here's why:

Reuses unchanged files: If a file doesn't change, Git points to the old blob
Compression: Git compresses everything
Smart storage: Git packs objects efficiently

Example:

Commit 1:
- index.html (blob aaa)
- style.css (blob bbb)

Commit 2: (only index.html changed)
- index.html (blob ccc) ← new
- style.css (blob bbb) ← reused!

The Staging Area (Index)

The index is a file at .git/index containing your next commit.

Why have staging?

Control. You can:

Stage only some files
Review before committing
Build thoughtful commits

Example:

# Edit two files
echo "New" > file1.txt
echo "More" > file2.txt

# Stage only file1
git add file1.txt

# Commit only file1
git commit -m "Update file1"

# file2 remains uncommitted

HEAD: Your Position

HEAD is a pointer showing where you are.

Location: .git/HEAD

Content:

ref: refs/heads/main

Means: "You're on the main branch."

Switch branches:

git checkout feature

HEAD updates to: ref: refs/heads/feature

Branches Are Just Pointers

A branch is a file containing a commit hash.

Location: .git/refs/heads/main

Content:

f3a8d91c8a7d4e5f6b2c3d4e5f6a7b8c9d0e1f2a

That's it. Just the latest commit hash.

Creating a branch:

git branch feature

Git creates a new file with the current commit hash. Super fast.

Complete Flow

1. Edit file:

echo "Hello" > readme.txt

File in working directory.

2. Stage it:

git add readme.txt

Git creates blob, updates index.

3. Commit:

git commit -m "Add readme"

Git creates tree and commit objects, updates branch pointer.

Visual:

Working Directory
      ↓ (git add)
Staging Area
      ↓ (git commit)  
Repository
      ↓
Branch updated

Try It Yourself

# Create repo
git init test-repo
cd test-repo

# Create file
echo "Test" > file.txt
git add file.txt

# Find the blob hash
git ls-files -s
# Shows: 100644 <hash> 0 file.txt

# View blob content
git cat-file -p <hash>
# Shows: Test

# Commit and explore
git commit -m "First commit"
git log --oneline  # Get commit hash
git cat-file -p <commit-hash>  # View commit object

Key Takeaways

.git stores everything - Your entire history is here
Three objects: blob, tree, commit - Foundation of Git
Hashes identify content - Same content = same hash
Staging prepares commits - Build commits carefully
Branches are pointers - Lightweight and fast
Git stores snapshots - Not differences

Mental Model

Think of Git as a tree:

        C3 (main)
        |
        C2
       /  \
     C1   C1' (feature)

Circles = commits
Each commit points to a tree
Each tree points to blobs
Branches = labels on commits

Why This Matters

Understanding internals helps you:

Debug problems confidently
Use advanced features
Recover lost work
Explain Git to others
Stop fearing Git

Final Thoughts

Git is elegant underneath:

Files → blobs
Folders → trees
Snapshots → commits
Labels → branches

Once you see this, Git makes sense.

You're not memorizing commands anymore. You understand what they do.

Resources:

Git Book: git-scm.com/book
Experiment with git cat-file -p
Break things in test repos (best way to learn!)

Git for Beginners: Basics and Essential Commands

Mohd Asif Ansari — Thu, 15 Jan 2026 15:57:29 +0000

If you're starting your coding journey, Git is one of the first tools you need to learn. It's not optional anymore it's as essential as knowing how to code itself.

Let's learn Git from scratch, in simple terms.

What is Git?

Git is a version control system. Think of it as a time machine for your code.

Simple explanation:

Git tracks every change you make to your files
You can go back to any previous version anytime
Multiple people can work on the same project without breaking things
Everything is saved with a complete history

Created by: Linus Torvalds (the creator of Linux) in 2005

Type: Distributed Version Control System (DVCS)

What "distributed" means: Every developer has the complete project history on their computer. If one computer breaks, nothing is lost.

Why Use Git?

1. Track Changes
Know exactly what changed, when, and why.

2. Undo Mistakes
Broke something? Go back to when it worked.

3. Collaborate Safely
Multiple people can work together without overwriting each other's code.

4. Experiment Freely
Try new ideas without fear. If it fails, just discard it.

5. Professional Standard
Every company uses Git. It's a must-have skill.

Core Concepts You Need to Know

Before jumping into commands, understand these basics:

Repository (Repo)

A folder that Git tracks. It contains your project and its entire history.

Two types:

Local repository: On your computer
Remote repository: On GitHub, GitLab, etc.

Commit

A snapshot of your project at a specific moment. Think of it as a save point in a video game.

Each commit has:

A unique ID (hash)
Author name
Date and time
A message describing what changed

Branch

A separate version of your code. Like parallel universes for your project.

Common branches:

main or master: The main version
feature-login: Working on login feature
bugfix-header: Fixing a header bug

Staging Area

A waiting room for changes before they're committed. You decide which changes to include in the next commit.

HEAD

A pointer that shows which commit you're currently on. Usually points to the latest commit on your current branch.

Working Directory

The actual files you see and edit on your computer.

The Three States of Git

Understanding this is crucial:

Working Directory → Staging Area → Repository

1. Modified:  You changed files but haven't saved them to Git
2. Staged:    You marked changed files to be committed
3. Committed: Changes are saved in Git history

Flow:

Edit files (Modified state)
Add files to staging (Staged state)
Commit files (Committed state)

Essential Git Commands

Let's learn the commands you'll use every day.

1. Setup Git (First Time Only)

Tell Git who you are:

git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

Check your settings:

git config --list

2. Starting a New Project

Create a new Git repository:

# Navigate to your project folder
cd my-project

# Initialize Git
git init

This creates a hidden .git folder that stores all Git data.

3. Checking Status

See what's happening in your repo:

git status

This shows:

Which files changed
Which files are staged
Which branch you're on

Example output:

On branch main
Changes not staged for commit:
  modified:   index.html

Untracked files:
  style.css

4. Adding Files to Staging

Add specific file:

git add index.html

Add multiple files:

git add index.html style.css

Add all changes:

git add .

What this does: Moves files from "Modified" to "Staged" state.

5. Committing Changes

Save your staged changes:

git commit -m "Add homepage design"

The -m flag adds a message describing what you did.

Good commit messages:

"Add user login feature"
"Fix navigation bar bug"
"Update contact page content"

Bad commit messages:

"Changes"
"Update"
"asdfgh"

6. Viewing History

See all commits:

git log

Shorter version:

git log --oneline

Example output:

a3b4c5d Add login page
f6e7d8c Fix header styling
b9c8d7e Initial commit

7. Working with Branches

See all branches:

git branch

Create a new branch:

git branch feature-login

Switch to a branch:

git checkout feature-login

Create and switch in one command:

git checkout -b feature-login

Delete a branch:

git branch -d feature-login

8. Merging Branches

Merge a branch into current branch:

# Switch to main branch
git checkout main

# Merge feature branch into main
git merge feature-login

9. Connecting to Remote Repository

Add a remote repository:

git remote add origin https://github.com/username/repo.git

Check remote connections:

git remote -v

10. Pushing and Pulling

Push your code to remote:

git push origin main

Pull latest code from remote:

git pull origin main

First time push:

git push -u origin main

The -u flag sets up tracking.

11. Cloning a Repository

Download an existing repository:

git clone https://github.com/username/repo.git

12. Other Useful Commands

See changes in files:

git diff

Undo changes (not committed):

git restore index.html

Unstage a file:

git restore --staged index.html

See commit details:

git show commit-id

Basic Developer Workflow

Here's how you'll use Git daily:

Starting Your Day

# 1. Pull latest changes
git pull origin main

# 2. Create a new branch for your task
git checkout -b feature-add-footer

# 3. Start coding!

While Working

# 4. Check what changed
git status

# 5. Add your changes
git add .

# 6. Commit with a clear message
git commit -m "Add footer with social links"

# 7. Keep committing as you make progress

Finishing Your Work

# 8. Push your branch to remote
git push origin feature-add-footer

# 9. Create a Pull Request on GitHub (done in browser)

# 10. After approval, merge and delete branch
git checkout main
git pull origin main
git branch -d feature-add-footer

Common Mistakes to Avoid

1. Forgetting to commit regularly
Commit after each small change. Don't wait until end of day.

2. Bad commit messages
Write clear messages. Your future self will thank you.

3. Working directly on main
Always create a branch for new features.

4. Not pulling before pushing
Always pull latest changes first to avoid conflicts.

5. Adding everything blindly
Don't do git add . without checking git status first.

Quick Reference Cheat Sheet

# Setup
git config --global user.name "Name"
git config --global user.email "email"

# Start
git init                    # Create new repo
git clone <url>            # Copy existing repo

# Basic workflow
git status                 # Check status
git add <file>            # Stage file
git add .                 # Stage all files
git commit -m "message"   # Commit changes
git log                   # View history

# Branches
git branch                # List branches
git branch <name>         # Create branch
git checkout <name>       # Switch branch
git checkout -b <name>    # Create and switch
git merge <name>          # Merge branch

# Remote
git remote add origin <url>  # Add remote
git push origin <branch>     # Push to remote
git pull origin <branch>     # Pull from remote

# Undo
git restore <file>           # Undo changes
git restore --staged <file>  # Unstage file

Next Steps

Now that you know Git basics:

Practice daily: Use Git for every project
Learn GitHub: Create an account and push your code
Explore branching: Practice creating and merging branches
Study conflicts: Learn how to resolve merge conflicts
Read documentation: Git has excellent docs at git-scm.com

Final Thoughts

Git seems complicated at first, but it's just:

Make changes
Stage them
Commit them
Push them

That's 90% of what you'll do daily.

The other 10%? You'll learn as you go.

Start using Git today. Create a repo. Make commits. Push to GitHub. The best way to learn Git is by using it.

Resources:

Official Git documentation: git-scm.com
Interactive tutorial: learngitbranching.js.org
GitHub guides: guides.github.com