Object-Oriented Programming, or OOP, is a way of organising code so that related data and behaviour live together in one place. It is not a JavaScript-specific concept. It is a way of thinking about code that exists across many programming languages.

The core idea is simple: instead of having loose variables and functions floating around, we model our program around things, and each thing has its own data and its own actions.

The Blueprint Analogy

Before we write a single line of code, let's think about how a car factory works.

An architect draws one blueprint for a car. That blueprint defines what every car made from it will look like. It says every car will have a brand, a colour, and a model. It also defines what every car can do, like start, stop, and accelerate.

From that one blueprint, the factory produces hundreds of individual cars. Each car is its own separate thing. One car might be red, another might be blue. But they were all created from the same blueprint.

In JavaScript, a class is the blueprint. An object is the car that gets created from it. We write the class once, and we can create as many objects from it as we need.

What is a Class?

A class is a template that defines what an object will look like and what it can do. We use the class keyword to create one.

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

Let's break this down piece by piece.

class Student defines a new class called Student. By convention, class names always start with a capital letter.

constructor is a special method that runs automatically every time we create a new object from this class. It is where we set up the initial data for the object.

this.name and this.age are properties being attached to the object being created. The this keyword refers to the specific object that is being built at that moment.

Creating Objects from a Class

Once we have a class, we create objects from it using the new keyword. Each object created from a class is called an instance.

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

let student1 = new Student("Gurjeet", 22);
let student2 = new Student("Priya", 21);
let student3 = new Student("Rahul", 23);

console.log(student1.name); // Gurjeet
console.log(student2.age);  // 21
console.log(student3.name); // Rahul

We wrote the Student class once. From that single template, we created three completely separate student objects. Each one has its own name and age. Changing one does not affect the others.

This is exactly like the car factory. One blueprint, multiple cars, each one independent.

Adding Methods to a Class

A class does not just hold data. It can also hold functions that work with that data. Functions inside a class are called methods.

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

  introduce() {
    console.log("Hi, my name is " + this.name + " and I am studying " + this.course);
  }

  birthday() {
    this.age += 1;
    console.log(this.name + " is now " + this.age + " years old");
  }
}

let student1 = new Student("Gurjeet", 22, "Web Development");

student1.introduce();
// Hi, my name is Gurjeet and I am studying Web Development

student1.birthday();
// Gurjeet is now 23 years old

The introduce method uses this.name and this.course to print a message specific to that student. The birthday method updates this.age for that particular object.

Notice that this inside a method always refers to the object the method is being called on. When we call student1.introduce(), this is student1. The method works with that specific student's data.

The Idea of Encapsulation

One of the core concepts behind OOP is encapsulation. The word sounds complicated but the idea is straightforward.

Encapsulation means keeping an object's data and the functions that work with that data together in one place. The outside world does not need to know how the object works internally. It just needs to know what it can do.

Think of a TV remote. We press the volume button and the volume goes up. We do not know what circuit gets triggered inside. We do not care. We just know that pressing the button does the job.

In code, this looks like:

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

  deposit(amount) {
    this.balance += amount;
    console.log(this.owner + " deposited " + amount + ". New balance: " + this.balance);
  }

  withdraw(amount) {
    if (amount > this.balance) {
      console.log("Insufficient balance");
    } else {
      this.balance -= amount;
      console.log(this.owner + " withdrew " + amount + ". New balance: " + this.balance);
    }
  }
}

let account = new BankAccount("Gurjeet", 5000);

account.deposit(1000);
// Gurjeet deposited 1000. New balance: 6000

account.withdraw(2000);
// Gurjeet withdrew 2000. New balance: 4000

account.withdraw(10000);
// Insufficient balance

The logic for how deposits and withdrawals work lives inside the class. Anyone using this class just calls deposit() or withdraw() without needing to know how the balance is being calculated internally. That is encapsulation in action.

Why OOP Matters

When we are writing small programs, OOP might feel like extra work. But as our programs grow, the benefits become obvious.

Instead of having random variables and functions spread everywhere, everything is organised into classes that represent real things in our program. A User, a Product, an Order, a Cart. Each one has its own data and its own behaviour. When something breaks, we know exactly where to look.

OOP also makes code reusable. We write the Student class once and create as many student objects as we need. Any change to the class automatically applies to all objects created from it.

This is the thinking behind how most real JavaScript applications, especially those built with frameworks like React, are structured. Getting comfortable with classes, constructors, methods, and the concept of encapsulation is a solid step towards writing code that is clean, organised, and built to scale.

Now imagine trying to store all of that in JavaScript using what we know so far. We could use separate variables:

let name = "Gurjeet";
let age = 22;
let course = "Web Development";
let city = "Amritsar";

This works for one person. But the moment we need to handle ten students, or a hundred, this approach falls apart completely. There is no connection between these variables. Nothing groups them together and says "these four things all belong to the same person."

That is exactly the problem objects solve.

What is an Object?

An object in JavaScript is a way to group related data together under one name. Instead of storing values by position, objects store values by name. Each value gets a label, and that label tells us exactly what the value means.

That label is called a key, and the data it points to is called a value. Together, they form a key-value pair. An object is just a collection of these key-value pairs.

let student = {
  name: "Gurjeet",
  age: 22,
  course: "Web Development",
  city: "Amritsar"
};

Now every piece of data has a name attached to it. name, age, course, and city are the keys. "Gurjeet", 22, "Web Development", and "Amritsar" are the values. Each key-value pair is called a property of the object.

Anyone reading this code immediately understands what each value represents. That clarity is what makes objects so useful.

Accessing Properties

There are two ways to access the properties of an object: dot notation and bracket notation.

Dot notation is the one we will use most of the time. We write the object name, followed by a dot, followed by the key.

let student = {
  name: "Gurjeet",
  age: 22,
  course: "Web Development"
};

console.log(student.name);   // Gurjeet
console.log(student.age);    // 22
console.log(student.course); // Web Development

Bracket notation works the same way, but we pass the key as a string inside square brackets.

console.log(student["name"]);   // Gurjeet
console.log(student["course"]); // Web Development

Both give the same result. Dot notation is cleaner and more commonly used. Bracket notation becomes useful when the key is stored in a variable or when the key has spaces in it.

let key = "age";
console.log(student[key]); // 22

Here we stored the key name in a variable and used bracket notation to access the property dynamically. This is something we cannot do with dot notation.

Updating Object Properties

Updating a property works exactly like creating one. We just assign a new value to an existing key.

let student = {
  name: "Gurjeet",
  age: 22,
  course: "Web Development"
};

student.age = 23;
student.course = "Full Stack Development";

console.log(student.age);    // 23
console.log(student.course); // Full Stack Development

We targeted the key using dot notation and assigned a new value. The rest of the object stays exactly as it was.

Adding and Deleting Properties

We are not limited to the properties we define when we first create an object. We can add new ones at any time.

let student = {
  name: "Gurjeet",
  age: 22
};

student.city = "Amritsar";
student.isEnrolled = true;

console.log(student);
// { name: "Gurjeet", age: 22, city: "Amritsar", isEnrolled: true }

We simply assigned a value to a key that did not exist before, and JavaScript added it to the object automatically.

To remove a property, we use the delete keyword.

delete student.isEnrolled;

console.log(student);
// { name: "Gurjeet", age: 22, city: "Amritsar" }

The isEnrolled property is gone. The rest of the object remains untouched.

Arrays vs Objects

A question that comes up naturally at this stage is: when do we use an object and when do we use something else to store data?

The clearest way to think about it is this. When we have a list of similar items where order matters, we use an array. When we are describing a single thing with multiple different characteristics, we use an object.

A list of city names is a collection of similar items. A single person with a name, age, and city is one thing with multiple characteristics.

// A list of cities — order matters, items are similar
let cities = ["Amritsar", "Delhi", "Mumbai", "Bangalore"];

// A single person — multiple characteristics describing one thing
let person = {
  name: "Gurjeet",
  age: 22,
  city: "Amritsar"
};

In real programs, these two are often combined. An array of objects is one of the most common patterns in JavaScript.

let students = [
  { name: "Gurjeet", age: 22 },
  { name: "Priya", age: 21 },
  { name: "Rahul", age: 23 }
];

console.log(students[0].name); // Gurjeet
console.log(students[1].age);  // 21

We access the array element using its index, then access the object property using dot notation. This pattern shows up constantly in real JavaScript projects, especially when working with data coming from a server or an API.

Looping Through Object Keys

Sometimes we want to go through all the properties of an object and do something with each one. The for...in loop is built exactly for this purpose.

let student = {
  name: "Gurjeet",
  age: 22,
  course: "Web Development",
  city: "Amritsar"
};

for (let key in student) {
  console.log(key + ": " + student[key]);
}

// Output:
// name: Gurjeet
// age: 22
// course: Web Development
// city: Amritsar

On each iteration, key holds the name of the current property. We use bracket notation with student[key] to get its value because the key is stored in a variable, and dot notation does not work with variables.

This becomes very practical whenever we want to display all the details of an object, check what properties exist, or process each value one by one without hardcoding every key manually.

Once we understand this properly though, and once we see how call(), apply(), and bind() work alongside it, a lot of JavaScript code that previously looked confusing starts to make complete sense.

What Does this Mean?

The simplest way to think about this is this: it refers to whoever is calling the function at that moment.

It is not fixed. It does not always point to the same thing. It changes based on the context in which a function is called. That is what makes it tricky at first, but also what makes it powerful once we get the hang of it.

Let's start with the most common place we see this, inside an object.

this Inside an Object

When a function is defined inside an object and called on that object, this refers to that object.

let student = {
  name: "Gurjeet",
  age: 22,
  introduce: function() {
    console.log("My name is " + this.name + " and I am " + this.age + " years old");
  }
};

student.introduce();
// My name is Gurjeet and I am 22 years old

When we call student.introduce(), JavaScript sets this to student because student is the one calling the function. So this.namebecomes student.name, which is "Gurjeet".

Now let's create another object and see what happens:

let teacher = {
  name: "Mr. Singh",
  age: 35,
  introduce: function() {
    console.log("My name is " + this.name + " and I am " + this.age + " years old");
  }
};

teacher.introduce();
// My name is Mr. Singh and I am 35 years old

Same function structure, different object, different result. this adapts to whoever is calling it. That is the core behaviour to understand.

The Problem this Creates

Here is where things get interesting. What if we have a function on one object but we want to use it on a different object that does not have that function?

let student = {
  name: "Gurjeet",
  age: 22,
  introduce: function() {
    console.log("My name is " + this.name + " and I am " + this.age);
  }
};

let anotherStudent = {
  name: "Priya",
  age: 21
};

anotherStudent does not have an introduce method. We could copy the function over, but that is repetitive and messy. This is exactly the problem that call(), apply(), and bind() solve.

call()

call() lets us borrow a function from one object and use it on another. We call the function and explicitly tell JavaScript what this should be.

student.introduce.call(anotherStudent);
// My name is Priya and I am 21

We took the introduce function from student and called it with anotherStudent as the context. JavaScript set this to anotherStudentfor that call, so this.name became "Priya" and this.age became 21.

We can also pass additional arguments after the object:

let student = {
  name: "Gurjeet",
  greet: function(city, course) {
    console.log("Hi, I am " + this.name + " from " + city + ", studying " + course);
  }
};

let anotherStudent = { name: "Priya" };

student.greet.call(anotherStudent, "Delhi", "Design");
// Hi, I am Priya from Delhi, studying Design

The first argument to call() is always the object we want this to be. Everything after that gets passed as regular arguments to the function.

apply()

apply() works exactly like call(). The only difference is how we pass the arguments. With call() we pass them one by one. With apply() we pass them as an array.

student.greet.apply(anotherStudent, ["Delhi", "Design"]);
// Hi, I am Priya from Delhi, studying Design

Same result as before. The difference is purely in the syntax. call() takes individual arguments separated by commas. apply()takes a single array containing all the arguments.

A practical way to remember this: call uses commas, apply uses an array.

When would we actually use apply() over call()? When our arguments are already sitting in an array and we do not want to unpack them manually.

let args = ["Mumbai", "Full Stack Development"];

student.greet.apply(anotherStudent, args);
// Hi, I am Priya from Mumbai, studying Full Stack Development

bind()

bind() is a little different from call() and apply(). Instead of calling the function immediately, bind() returns a new function with this permanently set to whatever we specify. We can then call that new function whenever we want.

let student = {
  name: "Gurjeet",
  introduce: function() {
    console.log("My name is " + this.name);
  }
};

let anotherStudent = { name: "Priya" };

let priyanIntroduce = student.introduce.bind(anotherStudent);

priyanIntroduce();
// My name is Priya

We used bind() to create a new function called priyanIntroduce where this is permanently set to anotherStudent. Now we can call priyanIntroduce() anywhere in our code and it will always use anotherStudent as the context.

This is useful when we want to pass a function around, store it for later use, or use it as a callback, but we need to make sure it always runs with the right this.

call vs apply vs bind

All three let us control what this is inside a function. The difference is in how and when they execute:

call() runs the function immediately and accepts arguments one by one.

apply() runs the function immediately and accepts arguments as an array.

bind() does not run the function immediately. It returns a new function with this locked in, ready to be called later.

let person = {
  name: "Gurjeet",
  sayHello: function(greeting, punctuation) {
    console.log(greeting + ", I am " + this.name + punctuation);
  }
};

let anotherPerson = { name: "Priya" };

// call — runs immediately, arguments one by one
person.sayHello.call(anotherPerson, "Hello", "!");
// Hello, I am Priya!

// apply — runs immediately, arguments as array
person.sayHello.apply(anotherPerson, ["Hey", "."]);
// Hey, I am Priya.

// bind — returns new function, call it later
let boundFn = person.sayHello.bind(anotherPerson, "Hi", "...");
boundFn();
// Hi, I am Priya...

Why This Actually Matters

At first glance, call(), apply(), and bind() might feel like edge case tools. But they show up regularly in real JavaScript development. Borrowing methods between objects, setting the correct context for event handlers, working with callbacks, all of these situations involve controlling what this points to.

Understanding this and having these three tools in our toolkit means we are no longer guessing why a function is returning undefined for a property that clearly exists. We know exactly what this is, and we know how to change it when we need to.

let student1 = "Gurjeet";
let student2 = "Priya";
let student3 = "Rahul";
let student4 = "Sneha";
let student5 = "Arjun";

That works for five students. But what about fifty? Or five hundred? We cannot create a separate variable for every single value. That is where arrays come in.

An array is a way to store multiple values in a single variable, in a specific order. Instead of five separate variables, we get one clean list.

let students = ["Gurjeet", "Priya", "Rahul", "Sneha", "Arjun"];

One variable, five values, all organised in order. That is the core idea behind arrays.

How to Create an Array

Creating an array in JavaScript is straightforward. We use square brackets and separate each value with a comma.

let fruits = ["apple", "banana", "mango"];

let marks = [85, 92, 76, 88];

let mixed = ["Gurjeet", 22, true]; // arrays can hold different data types too

An array can hold strings, numbers, booleans, or even a mix of all of them. Each value inside an array is called an element.

Accessing Elements Using Index

Every element in an array has a position, and that position is called an index. The important thing to know here is that arrays in JavaScript are zero-indexed. That means the counting starts from 0, not 1.

let fruits = ["apple", "banana", "mango"];

//               0         1        2

So if we want to access the first element, we use index 0. The second element is at index 1, and so on.

let fruits = ["apple", "banana", "mango"];

console.log(fruits[0]); // apple
console.log(fruits[1]); // banana
console.log(fruits[2]); // mango

This trips up almost every beginner at least once. We naturally think of the first item as number 1, but in JavaScript it is always number 0. The sooner that becomes second nature, the better.

What happens if we try to access an index that does not exist?

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

JavaScript does not throw an error. It simply returns undefined because there is nothing at that position.

Updating Elements

Accessing an element and updating it follow the same logic. We use the index to target the position and assign a new value.

let fruits = ["apple", "banana", "mango"];

fruits[1] = "grapes"; // replacing "banana" with "grapes"

console.log(fruits); // ["apple", "grapes", "mango"]

We targeted index 1, which was "banana", and replaced it with "grapes". The rest of the array stays exactly as it was.

The length Property

Every array has a built-in property called length that tells us how many elements are in it.

let fruits = ["apple", "banana", "mango"];

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

This is more useful than it sounds. We use length constantly when looping through arrays, checking if an array is empty, or finding the last element.

Speaking of the last element, here is a neat trick. Since the last index is always one less than the total length, we can always access it like this:

let fruits = ["apple", "banana", "mango"];

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

This works no matter how many elements are in the array. Whether there are 3 items or 300, fruits.length - 1 will always point to the last one.

Looping Over an Array

Most of the time, we do not just want to access one element. We want to go through the entire array and do something with each item. That is where loops come in.

The most basic way is a for loop:

let fruits = ["apple", "banana", "mango"];

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

// Output:
// apple
// banana
// mango

Let's break down what is happening here. We start i at 0 because that is the first index. We keep going as long as i is less than fruits.length, which is 3. Each time the loop runs, we access fruits[i] and print it, then increase i by 1.

So the loop runs three times, once for index 0, once for index 1, and once for index 2, printing each fruit along the way.

A cleaner and more modern way to loop over an array is for...of:

let fruits = ["apple", "banana", "mango"];

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

// Output:
// apple
// banana
// mango

The for...of loop handles all the index tracking behind the scenes. We just get each element directly, one at a time. When we do not need the index number and just want to work with the values, for...of is the cleaner choice.

That is exactly what this post is about. Let's clear it up once and for all.

What is a Function and Why Do We Need It?

Before we get into the two types, let's make sure we are on the same page about what a function actually is.

A function is a reusable block of code that does a specific job. Instead of writing the same logic five times in different places, we write it once inside a function and call it whenever we need it.

Think of it like a recipe. We write the recipe once. Every time we want to make that dish, we just follow the same recipe. We do not rewrite it from scratch each time.

function greet(name) {
  console.log("Hello, " + name);
}

greet("Gurjeet"); // Hello, Gurjeet
greet("Priya");   // Hello, Priya

Same function, called twice, different results each time. That is the whole point.

Function Declaration

A function declaration is the most straightforward way to define a function. We use the function keyword, give it a name, and write the body.

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

console.log(multiply(3, 4)); // 12

That is it. This is called a function declaration because we are declaring a function with a name right from the start.

Function Expression

A function expression is when we create a function and assign it to a variable. The function itself has no name of its own. It lives inside the variable.

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

console.log(multiply(3, 4)); // 12

The result is exactly the same. The difference is just in how we wrote it. Here the function is treated as a value, just like a number or a string, and stored inside a variable called multiply.

Let's put both side by side:

// Function Declaration
function add(a, b) {
  return a + b;
}

// Function Expression
const add = function(a, b) {
  return a + b;
};

Both do the same job. The syntax is just different.

The Key Difference: Hoisting

This is where things get interesting, and also where the real practical difference between the two lies.

JavaScript does something called hoisting before it runs our code. In simple terms, it reads through the entire file first and moves certain things to the top in memory before executing anything.

Function declarations get hoisted. This means we can actually call a function declaration before we have even written it in our code, and it will work fine.

console.log(greet("Gurjeet")); // Hello, Gurjeet

function greet(name) {
  return "Hello, " + name;
}

JavaScript already knew about greet before reaching that line because the declaration got hoisted to the top.

Function expressions do not get hoisted the same way. If we try to call a function expression before we define it, we get an error.

console.log(greet("Gurjeet")); // Error: Cannot access 'greet' before initialization

const greet = function(name) {
  return "Hello, " + name;
};

The variable greet exists in memory, but the function has not been assigned to it yet at that point. So JavaScript does not know what we are trying to call.

For now, the simple takeaway is this: with function declarations, the order does not matter as much. With function expressions, we must define them before we use them.

When to Use Which One

Both are valid and both have their place. Here is a practical way to think about it.

Function declarations work well for the main, named functions in our program. Things like calculateTotal, getUserData, or sendEmail. Functions that are central to what our code does and might be called from multiple places.

function calculateTotal(price, tax) {
  return price + (price * tax);
}

Function expressions are great when we want to assign a function to a variable, pass it to another function, or define it as part of an object. They treat the function as a value, which makes them very flexible.

const calculateTotal = function(price, tax) {
  return price + (price * tax);
};

In modern JavaScript, function expressions are often written as arrow functions, which we covered in the last post:

const calculateTotal = (price, tax) => price + (price * tax);

Same idea, shorter syntax.

The Normal Function

Before we get into arrow functions, let's look at how we write a regular function so we have something to compare against.

function greet(name) {
  return "Hello, " + name;
}

console.log(greet("Gurjeet")); // Hello, Gurjeet

This works perfectly. But arrow functions let us write the same thing with much less code.

Basic Arrow Function Syntax

Here is the same greet function written as an arrow function:

const greet = (name) => {
  return "Hello, " + name;
};

console.log(greet("Gurjeet")); // Hello, Gurjeet

The function keyword is gone. Instead, we have the parameters in parentheses, followed by => which is the arrow, and then the function body inside curly braces. That => is why these are called arrow functions.

Let's put both side by side so the difference is easy to see:

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

// Arrow function
const add = (a, b) => {
  return a + b;
};

Same result, just written differently. The arrow function version is shorter and in modern JavaScript codebases, this is the style we will see most often.

Arrow Function with One Parameter

When our arrow function has only one parameter, we can remove the parentheses around it. This makes it even shorter.

// With parentheses — works fine
const double = (num) => {
  return num * 2;
};

// Without parentheses — also fine when there's only one parameter
const double = num => {
  return num * 2;
};

console.log(double(5)); // 10

Both versions work. It is just a matter of preference, though most developers skip the parentheses when there is only one parameter.

Arrow Function with Multiple Parameters

When there are two or more parameters, the parentheses are required.

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

console.log(multiply(4, 3)); // 12

No shortcut here. Multiple parameters always need the parentheses.

Implicit Return

This is where arrow functions get really interesting. When our function body has just a single return statement, we can remove the curly braces and the return keyword entirely. JavaScript will return the value automatically. This is called an implicit return.

// With explicit return
const square = (num) => {
  return num * num;
};

// With implicit return — same result, much shorter
const square = num => num * num;

console.log(square(4)); // 16

The moment we remove the curly braces, JavaScript assumes we want to return whatever is on that line. No need to type return at all.

Here is another example to make it clear:

const greet = name => "Hello, " + name;

console.log(greet("Gurjeet")); // Hello, Gurjeet

One line. Clean and readable. This is the style we will see constantly in real JavaScript projects.

Normal Function vs Arrow Function

Here is a side by side comparison showing how the same function evolves from a normal function all the way to a clean arrow function with implicit return:

// Step 1: Normal function
function square(num) {
  return num * num;
}

// Step 2: Arrow function with explicit return
const square = (num) => {
  return num * num;
};

// Step 3: Arrow function with implicit return
const square = num => num * num;

console.log(square(6)); // 36

All three do exactly the same thing. As we get more comfortable with JavaScript, we will naturally move towards the shorter versions.

Arrow Functions Inside map()

One place where arrow functions really shine is inside array methods like map() and filter(). Remember from the last post how we wrote map() with a regular function?

// With normal function
let numbers = [1, 2, 3, 4, 5];

let doubled = numbers.map(function(num) {
  return num * 2;
});

With an arrow function, the same thing becomes:

// With arrow function
let numbers = [1, 2, 3, 4, 5];

let doubled = numbers.map(num => num * 2);

console.log(doubled); // [2, 4, 6, 8, 10]

One line. Same result. This is why arrow functions are so popular in modern JavaScript, they pair beautifully with array methods and make our code much easier to read.

Let's go through the ones we will use most often.

push() and pop()

These two methods work on the end of an array.

push() adds one or more items to the end of an array.

let fruits = ["apple", "banana"];

fruits.push("mango");

console.log(fruits); // ["apple", "banana", "mango"]

pop() removes the last item from an array and returns it.

let fruits = ["apple", "banana", "mango"];

let removed = fruits.pop();

console.log(removed); // "mango"
console.log(fruits);  // ["apple", "banana"]

Think of it like a stack of plates. We add a plate on top with push() and take the top plate off with pop().

shift() and unshift()

These two do the same thing as push() and pop(), but they work on the beginning of the array instead of the end.

unshift() adds one or more items to the front of an array.

let fruits = ["banana", "mango"];

fruits.unshift("apple");

console.log(fruits); // ["apple", "banana", "mango"]

shift() removes the first item from an array and returns it.

let fruits = ["apple", "banana", "mango"];

let first = fruits.shift();

console.log(first);  // "apple"
console.log(fruits); // ["banana", "mango"]

A simple way to remember this: push and pop touch the end. unshift and shift touch the beginning.

forEach()

forEach() goes through every item in an array and runs a function on each one. It is the cleaner alternative to writing a traditional for loop when we just want to do something with each item.

With a regular for loop, it looks like this:

let numbers = [1, 2, 3, 4, 5];

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

With forEach(), the same thing looks like this:

let numbers = [1, 2, 3, 4, 5];

numbers.forEach(function(num) {
  console.log(num);
});

// Output: 1, 2, 3, 4, 5

Both do the same job. forEach() is just easier to read and write once we get comfortable with it.

map()

map() is one of the most useful array methods we will come across. It goes through every item in an array, does something to each one, and returns a brand new array with the updated values. The original array stays untouched.

let numbers = [1, 2, 3, 4, 5];

let doubled = numbers.map(function(num) {
  return num * 2;
});

console.log(doubled);  // [2, 4, 6, 8, 10]
console.log(numbers);  // [1, 2, 3, 4, 5] — original unchanged

Think of it like a machine on a production line. Items go in one side, get transformed, and come out the other side as something new. The raw materials do not disappear, we just get a new output.

The key difference between forEach() and map() is this: forEach() just loops and does something. map() loops, transforms, and gives us back a new array.

filter()

filter() goes through an array and returns a new array containing only the items that pass a condition we define. Everything that does not pass the condition gets left out.

let numbers = [3, 7, 12, 5, 18, 2];

let greaterThanTen = numbers.filter(function(num) {
  return num > 10;
});

console.log(greaterThanTen); // [12, 18]

The original array stays as it is. We just get a new filtered version back.

A real world way to picture it: imagine we have a list of job applicants and we only want to keep those with more than 2 years of experience. We run the list through a filter, and get back only the ones that qualify.

let applicants = [
  { name: "Arjun", experience: 1 },
  { name: "Priya", experience: 3 },
  { name: "Rahul", experience: 5 },
  { name: "Sneha", experience: 2 },
];

let qualified = applicants.filter(function(person) {
  return person.experience > 2;
});

console.log(qualified);
// [{ name: "Priya", experience: 3 }, { name: "Rahul", experience: 5 }]

reduce()

reduce() is a bit different from the others. Instead of returning a new array, it reduces the entire array down to a single value. The most common use case is calculating a total.

let numbers = [1, 2, 3, 4, 5];

let total = numbers.reduce(function(accumulator, currentValue) {
  return accumulator + currentValue;
}, 0);

console.log(total); // 15

Here is what is happening step by step. We start with 0 as the initial value, which is the accumulator. Then for each item in the array, we add the current item to the accumulator and carry the result forward. By the end, the accumulator holds the final total.

For now, just focus on the pattern: reduce() takes all the items in an array and combines them into one single result. We will use it most often for summing up numbers.

Operators are symbols that let us perform operations on values and variables. That is really all they are. Let's go through each type one by one.

Arithmetic Operators

These are the ones we are most familiar with. They do basic math.

let a = 10;
let b = 3;

console.log(a + b); // 13 — addition
console.log(a - b); // 7  — subtraction
console.log(a * b); // 30 — multiplication
console.log(a / b); // 3.33 — division
console.log(a % b); // 1  — remainder (modulus)

The % operator is the one that confuses beginners the most. It does not give us the result of division. It gives us the remainder. So 10 % 3 is 1 because 3 goes into 10 three times, and 1 is left over. This operator is surprisingly useful once we start writing real programs.

Assignment Operators

We have already been using the most basic assignment operator without thinking about it. The = sign does not mean "is equal to" in JavaScript. It means "assign this value to this variable."

let score = 0; // assign 0 to score

But there are shorter ways to update a variable's value:

let score = 10;

score += 5;  // same as: score = score + 5 → 15
score -= 3;  // same as: score = score - 3 → 12
score *= 2;  // same as: score = score * 2 → 24
score /= 4;  // same as: score = score / 4 → 6

These are just shortcuts. Instead of writing score = score + 5, we write score += 5. Both do the exact same thing. Once we get used to them, they feel very natural.

Comparison Operators

Comparison operators compare two values and always return either true or false. We use them constantly when writing conditions.

let age = 20;

console.log(age > 18);  // true
console.log(age < 18);  // false
console.log(age >= 20); // true
console.log(age <= 19); // false

Now the two that every beginner needs to understand properly: == and ===.

console.log(5 == "5");  // true
console.log(5 === "5"); // false

Both are checking for equality, but they do it differently.

== checks only the value. It does not care about the type, so it converts "5" (a string) to 5 (a number) behind the scenes before comparing. This is called type coercion, and it can lead to unexpected results.

=== checks both the value and the type. The number 5 and the string "5" are not the same type, so it returns false.

As a rule, always use === in our code. It is stricter and much more predictable.

console.log(5 != "5");  // false — loose inequality
console.log(5 !== "5"); // true  — strict inequality

Same idea applies for not-equal. Prefer !== over != for the same reasons.

Logical Operators

Logical operators let us combine multiple conditions together. There are three of them.

&& means AND. Both conditions must be true for the result to be true.

let age = 22;
let hasID = true;

console.log(age >= 18 && hasID); // true
// both conditions are true, so the result is true

|| means OR. At least one condition needs to be true.

let isWeekend = false;
let isHoliday = true;

console.log(isWeekend || isHoliday); // true
// one of them is true, so the result is true

! means NOT. It flips the value. true becomes false and false becomes true.

let isLoggedIn = false;

console.log(!isLoggedIn); // true
// we flipped false to true

We will use logical operators constantly once we start writing conditions and making decisions in our programs.

Our code works the same way. Control flow is just the order in which our program makes decisions and executes code. And the tools JavaScript gives us for that are if, else, and switch.

The if Statement

The if statement is the simplest form of decision making in JavaScript. It says: if this condition is true, run this block of code.

let marks = 75;

if (marks >= 50) {
  console.log("Passed!");
}
// Output: Passed!

JavaScript checks the condition inside the parentheses. If it evaluates to true, the code inside the curly braces runs. If it is false, JavaScript skips that block entirely and moves on.

The if-else Statement

What if we want something to happen when the condition is false as well? That is where else comes in.

let marks = 35;

if (marks >= 50) {
  console.log("Passed!");
} else {
  console.log("Failed. Try again.");
}
// Output: Failed. Try again.

Think of it like this. We are at a gate. If we have a ticket, we get in. If we do not have a ticket, we are turned away. One condition, two possible outcomes.

The else if Ladder

Sometimes two options are not enough. What if we want to check multiple conditions one after another? We use else if to build a ladder.

let marks = 72;

if (marks >= 90) {
  console.log("Grade: A");
} else if (marks >= 75) {
  console.log("Grade: B");
} else if (marks >= 60) {
  console.log("Grade: C");
} else {
  console.log("Grade: F");
}
// Output: Grade: C

JavaScript goes through each condition from top to bottom. The moment it finds one that is true, it runs that block and skips everything else. If none of the conditions match, the final else acts as the fallback.

The switch Statement

Now imagine we have one variable and we want to check it against many specific values. We could write a long else ifladder, but there is a cleaner way for situations like this.

let day = 3;

switch (day) {
  case 1:
    console.log("Monday");
    break;
  case 2:
    console.log("Tuesday");
    break;
  case 3:
    console.log("Wednesday");
    break;
  case 4:
    console.log("Thursday");
    break;
  default:
    console.log("Another day");
}
// Output: Wednesday

The switch statement takes a value and compares it against each case. When it finds a match, it runs that block of code.

Now notice the break keyword after each case. That is important. Without break, JavaScript does not stop after finding a match. It keeps running every case below it until it hits the end of the switch block. That behaviour is called fall-through and it causes bugs if we are not careful.

The default at the bottom is like the else in an if-else chain. It runs when none of the cases match.

When to Use switch vs if-else

Both do the job of decision making, but they suit different situations.

if-else is more flexible. We can check ranges, compare two different variables, or write any kind of condition inside it. When the logic is complex or the conditions are not simple equality checks, if-else is the right pick.

let age = 20;
let hasID = true;

if (age >= 18 && hasID) {
  console.log("Entry allowed");
} else {
  console.log("Entry not allowed");
}

switch works best when we are comparing one variable against a list of fixed, specific values. It reads more cleanly in those situations and is easier to scan through.

let plan = "pro";

switch (plan) {
  case "free":
    console.log("You have 5GB storage");
    break;
  case "basic":
    console.log("You have 20GB storage");
    break;
  case "pro":
    console.log("You have 100GB storage");
    break;
  default:
    console.log("Unknown plan");
}
// Output: You have 100GB storage

A simple way to decide: if the condition is about checking a range or combining multiple variables, go with if-else. If we are checking one variable against a bunch of specific values, switch keeps things neat.

That's exactly what variables do in JavaScript. They store information so our program can remember and use it later.

What is a Variable, and Why Do We Need It?

Think of a variable like a labelled box. We write a name on the outside of the box, and put a value inside it. Whenever we need that value, we just refer to the box by its name.

Without variables, a program would have no memory at all. We couldn't save a user's name, track a score in a game, or remember whether someone is logged in. Variables are what make code actually useful.

let playerName = "Gurjeet";
// The box called "playerName" now holds "Gurjeet"

console.log(playerName); // Output: Gurjeet

How to Declare Variables: var, let, and const

JavaScript gives us three keywords to create a variable. Think of them as three different types of boxes. Each one has slightly different rules.

var — the old way

var was the original way to declare variables in JavaScript. It still works, but it has some quirky behaviour that can lead to confusing bugs in bigger codebases. Most modern JavaScript code avoids it.

var city = "Amritsar";
city = "Delhi"; // works fine, value gets updated

let — for values that change

let is what we reach for when the value might need to change later. A score that updates as the game goes on, or a user's current status, that kind of thing.

let score = 0;
score = 10; // updated after the player earns points

const — for values that stay fixed

const is short for constant. Once we assign a value to it, we cannot replace it. The app's name, a base URL, a tax rate, anything that is not supposed to change during the program.

const appName = "MyApp";
appName = "OtherApp"; // Error! Cannot reassign a const

A good rule to follow: default to const. If we know the value will need to change at some point, switch to let. And for now, just leave var alone.

Primitive Data Types

Every value we store in a variable has a type. JavaScript has five basic types that we will work with constantly, and they are called primitive data types.

String is for text. Any time we are dealing with words, names, or sentences, we wrap the value in quotes and it becomes a string.

let name = "Gurjeet"; // String

Number covers any numeric value, whether it is a whole number or a decimal.

let age = 22;      // whole number
let price = 3.99;  // decimal

Boolean can only ever be true or false. Think of it as a yes/no switch.

let isStudent = true;
let hasSubscription = false;

Null means the box is intentionally empty. We are the ones who put nothing there on purpose.

let phoneNumber = null; // we know it's empty

Undefined means the box exists but nobody told it what to hold yet.

let address; // no value assigned, so it's undefined

The difference between null and undefined trips almost everyone up at first. Here is the simplest way to think about it: nullmeans "I know this is empty." undefined means "nobody even got around to filling this in yet." Small difference, but it matters once we start debugging real code.

let name = "Gurjeet";  // String
let age = 22;          // Number
let isStudent = true;  // Boolean
let phone = null;      // Null, intentionally empty
let address;           // Undefined, not assigned yet

var vs let vs const

The biggest practical difference comes down to two things: can the value be changed, and where in the code can the variable be accessed.

var can be reassigned and even re-declared, which sounds flexible but is actually what causes the bugs. let can be reassigned but not re-declared. const cannot be reassigned or re-declared at all.

The other difference is scope, which we are about to get into.

What is Scope?

Scope answers one question: where in our code can a particular variable be accessed?

Here is a simple way to picture it. Think of our house. Whatever is inside our bedroom, like a personal diary, stays in our bedroom. Someone in the kitchen cannot just reach in and grab it. But something in the living room, like the television, is accessible to everyone in the house.

Variables work the same way. A variable declared inside a block of code, anything wrapped in { }, can only be accessed within that block. That is called block scope, and it is the rule that both let and const follow.

let outsideVar = "I am outside";

{
  let insideVar = "I am inside the block";
  console.log(outsideVar); // works fine
  console.log(insideVar);  // works fine
}

console.log(outsideVar); // works fine
console.log(insideVar);  // Error, insideVar doesn't exist out here

This is exactly why var causes confusion. It does not respect block scope the same way. It leaks out of blocks, which means it can be accessed from places we never intended. That is a bug waiting to happen.

our code needs to talk to a server.

A browser does this all the time without us noticing. But as developers, we also need a direct way to send messages to servers and see their responses clearly. This is where cURL comes in.

In this blog, we will understand cURL from first principles. We will not rush into complex flags or advanced usage. We will first build the mental model, then slowly connect the dots.

What Is a Server (and Why We Need to Talk to It)

Before understanding cURL, we need to understand what a server is.

A server is just another computer connected to the internet. Its job is to receive requests and send responses. When we open a website, submit a form, or load data in an app, we are talking to a server.

The server may send:

• A webpage (HTML)

• Data (JSON)

• Images

• Or just a simple message like “OK” or “Error”

As developers, we constantly need to:

• Check what a server is returning

• Test APIs

• Debug errors

• Verify data

For this, relying only on the browser is not enough.

What Is cURL (in Very Simple Terms)

cURL is a tool that lets us send messages to a server from the terminal.

That’s it.

It does not have buttons.

It does not have a UI.

It does not hide anything.

It shows us:

• What request we send

• What response we get back

Think of cURL as a direct phone call to a server, instead of using a fancy app.

Why Programmers Need cURL

Browsers do many things automatically:

• They add headers

• They follow redirects

• They cache responses

• They hide raw data

This is good for users, but not always good for learning or debugging.

With cURL, we:

• Talk directly to the server

• See raw responses

• Test APIs without writing code

• Understand how HTTP really works

This makes cURL extremely important for backend developers, frontend developers, and even DevOps engineers.

Making Our First Request Using cURL

The simplest thing we can do with cURL is fetch a webpage.

When we run a basic cURL command, we are doing the same thing a browser does at a very basic level:

• Send a request

• Receive a response

• Print it on the screen

There is no magic here. cURL sends a request to the server, and the server sends something back.

Seeing this response directly helps us understand what is really happening behind the scenes.

Understanding Request and Response

Every communication with a server follows the same idea:

1. A request is sent

2. A response is returned

A request usually contains:

• Where we want to go (URL)

• What we want to do (method like GET or POST)

A response usually contains:

• A status (success or error)

• Data (HTML, JSON, text, etc.)

cURL lets us see this response clearly, without browser interference. This is one of its biggest learning advantages.

Introducing GET and POST (Only the Basics)

To keep things simple, we only focus on two methods.

GET means:

• “We want to read data”

• No changes on the server

POST means:

• “We want to send data”

• Something may be created or updated on the server

Most APIs in the beginning can be understood using just these two methods. There is no need to overload ourselves early.

Using cURL to Talk to APIs

An API is just a server endpoint that returns data instead of a full webpage.

When we use cURL with APIs, we:

• Send a request

• Get back structured data (often JSON)

• Check if the server behaves correctly

This is extremely useful when:

• Frontend is not ready

• Backend is under development

• We want to test quickly without writing code

cURL becomes a bridge between our terminal and the backend logic.

Common Mistakes Beginners Make with cURL

One common mistake is trying to learn all flags at once. cURL has many options, but beginners don’t need most of them early.

Another mistake is copying commands without understanding what they do. This creates confusion instead of clarity.

Some also expect cURL to behave like a browser. But cURL is not a browser, it is a network tool.

The goal in the beginning is not mastery. The goal is confidence.

Browser Request vs cURL Request (Conceptually)

A browser:

• Sends many automatic headers

• Loads CSS, JS, images

• Executes JavaScript

cURL:

• Sends exactly what we tell it

• Shows raw responses

• Does one job at a time

Both talk to servers, but cURL gives us transparency.

Where cURL Fits in Backend Development

In backend development, cURL is used to:

• Test APIs

• Debug production issues

• Verify server responses

• Learn HTTP deeply

It often becomes the first tool we reach for when something breaks.

cURL is not about commands.

It is about understanding communication between our system and a server.

Once we understand this flow, everything else, APIs, frameworks, tools starts making more sense.

We don’t rush.

We build clarity first.

Depth comes later.

But this data does not magically travel in a safe and correct way. There must be rules that decide how data is sent, received, ordered, and verified.

This is where TCP comes in.

In this article, we will slowly understand what TCP is, why it exists, what problems it solves, and how the famous 3 way handshake works. We will keep everything simple and focus on ideas instead of technical overload.

Before understanding TCP, we need to imagine what happens without it.

Suppose we send a long message from one computer to another over the internet. The message is broken into small pieces and travels through different paths. Some pieces may arrive late, some may arrive early, and some may not arrive at all.

Without rules:

• Data can arrive in the wrong order

• Some parts of data can be lost

• The receiver may not know whether the data is complete

• The sender may not know if the data was received

This would make websites unreliable. A page may load half content, images may break, or data may become corrupted.

So clearly, we need a system that controls data transfer properly.

What is TCP and why it is needed

TCP stands for Transmission Control Protocol.

TCP is a communication protocol that ensures reliable data transfer between two computers on a network. It does not send data blindly. Instead, it first creates a connection, then sends data carefully, and finally closes the connection properly.

We use TCP because:

• We want data to arrive correctly

• We want data in the correct order

• We want to know if something goes wrong

• We want both sides to agree before talking

Most important internet services like HTTP, HTTPS, email, and file transfer rely on TCP.

Problems TCP is designed to solve

TCP was designed to handle real world network problems.

First, TCP handles packet loss. If some data is lost during transfer, TCP detects it and sends the data again.

Second, TCP handles out of order delivery. Data packets may arrive in the wrong order, but TCP rearranges them correctly before giving them to the application.

Third, TCP handles duplication. If the same packet arrives twice, TCP can detect and ignore the duplicate.

Fourth, TCP handles flow control, which means it does not overwhelm the receiver with too much data at once.

Without TCP, reliable communication on the internet would not be possible.

What is the TCP 3 Way Handshake

Before sending actual data, TCP first creates a connection between the client and the server.

This connection setup process is called the 3 way handshake.

The purpose of the handshake is simple:

• Both sides confirm they are ready to communicate

• Both sides agree on starting sequence numbers

• A reliable connection is established

This happens in three steps, which is why it is called a 3 way handshake.

Understanding the handshake using a simple conversation

We can think of the handshake like a phone call.

First, one person says, “Hello, can we talk?”

Second, the other person replies, “Yes, I can hear you.”

Third, the first person says, “Great, let’s talk.”

Only after this confirmation does the real conversation begin.

TCP works in a very similar way.

Step by step working of SYN, SYN-ACK, and ACK

In the first step, the client sends a SYN message to the server.

SYN means “synchronize”. This message says:

“We want to start a connection and here is my starting number.”

In the second step, the server replies with SYN-ACK.

This means:

“I received your request, I am ready, and here is my starting number.”

In the third step, the client sends an ACK message.

This message confirms:

“I received your response and the connection is now established.”

After this third step, both sides fully trust that the connection exists.

How data transfer works in TCP

Once the connection is established, real data transfer begins.

TCP does not send data as one big chunk. It breaks data into smaller pieces called segments. Each segment has a sequence number, which helps track the order.

When the receiver gets data, it sends back an acknowledgment (ACK). This acknowledgment tells the sender which data has been received successfully.

If the sender does not receive an acknowledgment within a certain time, it assumes the data was lost and sends it again.

This constant back and forth ensures safe delivery.

Sequence numbers and acknowledgements (high level idea)

Sequence numbers help TCP keep data in order.

Each piece of data has a number attached to it. The receiver uses these numbers to arrange data correctly, even if packets arrive out of order.

Acknowledgements tell the sender, “We have received data up to this point.”

This allows the sender to know exactly what was delivered and what needs retransmission.

We do not need to understand the math behind it at the beginning. The idea is enough.

How TCP handles packet loss and retransmission

Packet loss is normal on the internet. Networks are not perfect.

TCP constantly monitors acknowledgements. If an acknowledgment is missing, TCP assumes packet loss.

When this happens:

• TCP resends the missing data

• The receiver ignores duplicates

• Data is reconstructed correctly

This happens automatically without the application knowing anything about it.

That is why TCP is called reliable.

How TCP ensures reliability, order, and correctness

TCP ensures reliability by using acknowledgements and retransmissions.

TCP ensures order by using sequence numbers.

TCP ensures correctness by verifying that data is complete and properly received before passing it to applications.

Because of this, applications like browsers and servers can focus on logic instead of worrying about broken data.

How a TCP connection is closed

Just like a connection must be created properly, it must also be closed properly.

TCP uses FIN and ACK messages to close a connection.

One side sends a FIN message saying, “I am done sending data.”

The other side acknowledges it.

Then the second side sends its own FIN.

Finally, the first side acknowledges that too.

This ensures both sides finish communication cleanly without data loss.

TCP connection lifecycle

A TCP connection goes through three main phases.

First, connection establishment using the 3 way handshake.

Second, data transfer using sequence numbers and acknowledgements.

Third, connection termination using FIN and ACK messages.

This full lifecycle makes TCP predictable and safe.

For this communication to work properly, all computers must agree on rules. These rules define how data is sent, how it is received, and what happens if something goes wrong.

These rules are called protocols.

Among many protocols, two very important ones work at the transport level of the internet:

• TCP

• UDP

And at a higher level, we often hear about:

• HTTP

To really understand the internet, we must understand how these fit together.

What Are TCP and UDP (High Level)

TCP and UDP are transport protocols. Their main job is to move data from one computer to another reliably or quickly, depending on the need.

They do not care what the data means.

They only care how data is delivered.

Think of them as delivery methods, not message content.

TCP: Safe and Reliable Data Delivery

TCP stands for Transmission Control Protocol.

TCP is used when data must arrive correctly and completely.

Before sending data, TCP first creates a connection between the sender and the receiver. Both sides agree to talk, just like starting a phone call.

While sending data, TCP:

• Sends data in small pieces

• Keeps track of every piece

• Checks if data is received

• Resends data if something is lost

• Delivers data in the correct order

Because of all these checks, TCP is slower, but it is very reliable.

A simple analogy is a courier service:

• Every package is tracked

• Missing packages are resent

• Order is preserved

• Delivery confirmation exists

UDP: Fast but Risky Data Delivery

UDP stands for User Datagram Protocol.

UDP does not create a connection before sending data. It simply sends data and moves on.

UDP does not:

• Check if data is received

• Resend lost data

• Guarantee order

Because of this, UDP is very fast, but not reliable.

A simple analogy is a live announcement:

• Message is broadcast

• If someone misses it, it is gone

• No retries

• Speed matters more than accuracy

UDP is used when speed is more important than perfection.

Key Differences Between TCP and UDP

TCP and UDP solve the same problem in different ways.

TCP focuses on:

• Accuracy

• Reliability

• Order

• Safety

UDP focuses on:

• Speed

• Low delay

• Real time delivery

TCP waits and verifies.

UDP sends and forgets.

Neither is better overall.

Each exists for a different purpose.

When We Use TCP

We use TCP when losing data is not acceptable.

Examples include:

• Loading a website

• Sending emails

• Downloading files

• Online payments

• APIs and backend communication

In these cases, even one missing piece of data can break the whole system. Speed is important, but correctness is more important.

That is why TCP is the default choice for most web related tasks.

When We Use UDP

We use UDP when real time speed matters more than perfect delivery.

Examples include:

• Video calls

• Live streaming

• Online gaming

• Voice calls

In these cases, it is better to lose a small amount of data than to wait. A delayed video frame is worse than a dropped one.

UDP keeps things fast and smooth, even if some data is lost.

Real World Examples: TCP vs UDP

To make this clearer, let us compare common real world usage.

Websites:

• Use TCP

• Because HTML, CSS, and JS must load correctly

Emails:

• Use TCP

• Because missing text is not acceptable

Video calls:

• Use UDP

• Because delay feels worse than data loss

Online games:

• Use UDP

• Because real time position updates matter

File downloads:

• Use TCP

• Because corrupted files are useless

What Is HTTP and Where It Fits

HTTP stands for HyperText Transfer Protocol.

HTTP is not a transport protocol.

It does not move data on the network by itself.

HTTP is an application level protocol.

Its job is to define:

• How requests are made

• How responses are structured

• How browsers and servers talk in a meaningful way

HTTP defines things like:

• GET and POST

• Headers

• Status codes

• Request and response format

But HTTP does not care how data travels physically.

It relies on lower level protocols to do that job.

Relationship Between TCP and HTTP

HTTP runs on top of TCP.

This means:

• TCP handles reliable data delivery

• HTTP handles request response logic

When we open a website:

1. A TCP connection is created

2. HTTP request is sent over TCP

3. Server responds using HTTP

4. TCP ensures data arrives correctly

HTTP depends on TCP’s reliability.

Without TCP, HTTP would not work properly.

Why HTTP Does Not Replace TCP

This is a very common beginner confusion.

HTTP and TCP solve different problems.

TCP answers:

• How does data safely travel between computers?

HTTP answers:

• What does this data mean?

• Is this a request or a response?

• What type of content is it?

HTTP cannot replace TCP because HTTP assumes that data delivery is already reliable.

That reliability comes from TCP.

Is HTTP the Same as TCP?

No, they are not the same.

A simple way to remember:

• TCP is the road

• HTTP is the traffic rules and signs

Without roads, rules are useless.

Without rules, roads are chaotic.

Both are required, but they exist at different layers.

Layering: The Big Picture

A simplified view of how things work:

• Application Layer → HTTP

• Transport Layer → TCP or UDP

• Network Layer → IP

Each layer has a clear responsibility.

This separation makes the internet flexible, scalable, and reliable.

Final Summary

• The internet needs rules to send data

• TCP and UDP are transport level rules

• TCP is safe and reliable

• UDP is fast but risky

• HTTP is an application level protocol

• HTTP runs on top of TCP

• HTTP does not replace TCP

• TCP and HTTP are not the same

Understanding this foundation makes everything else in web development easier to learn.

This is where DNS comes in.

DNS is one of those systems every web developer uses every day, often without realising it. To truly understand how the web works, we must understand DNS, not just definitions, but how it behaves in the real world. In this article, we will break DNS down step by step and use the dig command to build a clear mental model of how name resolution actually happens.

What is DNS and why name resolution exists

Computers do not understand domain names. They communicate using IP addresses, which are numeric values like 142.250.190.14. Humans, however, cannot easily remember numbers, especially at the scale of the internet.

DNS (Domain Name System) exists to solve this exact problem.

We can think of DNS as the internet’s phonebook. Instead of memorising IP addresses, we remember names like google.com. DNS acts as the translation system that maps these names to their corresponding IP addresses.

Without DNS, the web would still work, but it would be unusable for humans. Every website visit would require remembering and typing raw IP addresses. DNS makes the web usable, scalable, and human friendly.

What is the dig command and when it is used

dig stands for Domain Information Groper. It is a command line tool used to query DNS servers directly and inspect DNS records.

Browsers perform DNS lookups automatically, but they hide the details from us. dig removes that abstraction. It allows us to ask very specific DNS questions and see exactly which server responds and what information is returned.

We typically use dig when:

• Debugging DNS issues

• Understanding how DNS resolution flows

• Verifying DNS records like NS, A, MX, TXT

• Learning how DNS works internally

In short, dig is not just a tool, it is a lens into the DNS system.

Understanding dig . NS and root name servers

Let’s start at the very top of DNS.

When we run:

dig . NS

We are asking:

“Who is responsible for the root of the DNS system?”

The dot (.) represents the DNS root zone. Root name servers do not know IP addresses for domains like google.com. Instead, they know where to find information about top level domains such as .com, .org, .net, and country codes like .in.

Root servers are the first step in DNS resolution. They act like a directory that says,

“I don’t know the final answer, but I know who might.”

There are total 13 Root servers in the world, but total 1600+ implementations, means there are 1600+ copies present in the world.

This is an important concept: DNS works by referral, not by guessing.

Understanding dig com NS and TLD name servers

Next, we move one level down the hierarchy.

When we run:

dig com NS

We are asking:

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

These servers are called TLD (Top Level Domain) name servers.

TLD servers do not know the IP address of google.com. Instead, they know which authoritative name servers are responsible for domains under .com.

So again, we see the same pattern:

• Root → points to TLD

• TLD → points to authoritative servers

DNS is intentionally layered to remain scalable across billions of domains.

This output shows the result of running dig com NS, which asks DNS who is responsible for the .com top level domain. The important part is the ANSWER SECTION. It lists multiple NS (Name Server) records like a.gtld-servers.net, b.gtld-servers.net, and so on. These are the official TLD name servers for .com, and they are managed by the .com registry. The number 172800 is the TTL (time to live), which means resolvers can cache this information for about 2 days. This output does not give IP addresses for websites like google.com; instead, it tells DNS resolvers where to go next to find which authoritative name servers handle a specific .com domain.

Understanding dig google.com NS and authoritative name servers

When we run:

dig google.com NS

We are asking:

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

Authoritative name servers are the source of truth for a domain. They are configured by the domain owner (or their DNS provider). These servers contain the actual DNS records A, AAAA, MX, TXT, and more.

Once a resolver reaches the authoritative name server, it can finally ask:

“What is the IP address for google.com?”

And this server gives the final answer.

This output shows the result of running dig google.com NS, which asks DNS which name servers are authoritative for the google.com domain. In the ANSWER SECTION, we see four NS records: ns1.google.com, ns2.google.com, ns3.google.com, and ns4.google.com. These are Google’s authoritative name servers, meaning they are the final source of truth for all DNS records of google.com. The TTL value (270971) tells resolvers how long this information can be cached. The ADDITIONAL SECTION includes the actual IP addresses (both IPv4 A and IPv6 AAAA) of these name servers, so resolvers can contact them directly without doing another lookup. At this stage of DNS resolution, the system now knows exactly where to ask for the final IP address of google.com.

Understanding dig google.com and the full DNS resolution flow

Now let’s connect everything.

When we run:

dig google.com

dig performs the full lookup and shows us the final DNS response. But behind the scenes, the resolution followed a clear path:

1. Ask root name servers where .com lives

2. Ask .com TLD servers where google.com lives

3. Ask Google’s authoritative servers for the IP address

4. Receive the final answer

This entire process usually happens in milliseconds.

In real life, browsers don’t talk directly to root or TLD servers. They use recursive resolvers (usually provided by ISPs or public services like Google DNS). These resolvers perform all the steps on our behalf and cache results to make future lookups faster.

This output shows the final step of DNS resolution. The command dig google.com asks for the A record of google.com, which means we are now asking for the actual IP address to connect to. In the ANSWER SECTION, DNS returns 172.217.27.174, which is one of Google’s server IPs. The TTL value (107) is very small, showing that Google keeps this record short lived so traffic can be routed dynamically. At this point, DNS resolution is complete, the browser now has a concrete IP address and can open a network connection to Google’s servers.

What NS records represent and why they matter

NS (Name Server) records define who controls a domain’s DNS.

They are critical because:

• They define authority

• They enable delegation

• They allow DNS to scale globally

Without NS records, DNS would have no way to know where responsibility for a domain begins and ends.

Whenever we change DNS providers, what we are really doing is changing NS records.

How recursive resolvers use this information behind the scenes

Recursive resolvers are like professional DNS investigators.

They:

• Query root servers

• Follow referrals to TLD servers

• Reach authoritative servers

• Cache responses using TTL values

This caching is why DNS lookups are fast most of the time and slow only on first access.

Resolvers hide complexity, but dig exposes it, making DNS understandable instead of mysterious.

Before a browser can load any website, it must answer one basic question:

“Where does this website live on the internet?”

Browsers do not understand website names. They understand numbers. The system that helps convert human friendly names into machine friendly numbers is called DNS.

In this article, we will understand DNS from the ground up, using simple ideas and real life examples, without going deep into technical jargon.

What DNS Is (in very simple terms)

DNS stands for Domain Name System.

The easiest way to understand DNS is to think of it as the phonebook of the internet.

In real life, we save contact names like “Mom” or “Office” in our phone. Behind those names are actual phone numbers. We never dial the numbers directly because names are easier to remember.

The internet works in a similar way.

• Websites have names like example.com

• Computers communicate using IP addresses like 93.184.216.34

DNS is the system that connects these two.

So when we enter a website name, DNS tells the browser:

“This name belongs to this IP address.”

Only after that can the browser talk to the correct server.

Why DNS Records Are Needed

DNS is not just one big list. It is a collection of records, and each record solves a specific problem.

Websites today do more than just show pages. They handle emails, subdomains, security checks, and verifications. One single mapping is not enough for all of this.

DNS records exist so that:

• browsers know where to load the website from

• email systems know where to deliver emails

• services can verify domain ownership

• traffic can be managed cleanly and separately

Each DNS record answers one specific question about a domain.

What an NS Record Is (Who Is Responsible for a Domain)

NS stands for Name Server.

An NS record tells the internet:

“These servers are responsible for answering DNS questions for this domain.”

This is about authority, not IP addresses.

When DNS lookup starts, the system does not immediately ask for an IP address. First, it asks:

“Who should I talk to about this domain?”

NS records provide that answer.

They act like a signboard saying:

“For anything related to this domain, ask these name servers.”

Without NS records, a domain has no official place to store its DNS information**.**

What an A Record Is (Domain → IPv4 Address)

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

This is the most basic and important DNS record for a website.

When we open a website in a browser, eventually DNS needs to answer:

“Which IP address should we connect to?”

That answer usually comes from an A record.

For example:

• example.com → 93.184.216.34

This is how browsers find the actual server machine that hosts the website.

What an AAAA Record Is (Domain → IPv6 Address)

An AAAA record does the same job as an A record, but for IPv6 addresses instead of IPv4.

IPv6 exists because the internet ran out of IPv4 addresses.

So:

• A record → IPv4

• AAAA record → IPv6

Modern systems can use either. If both exist, the browser usually prefers IPv6.

Conceptually, both records solve the same problem:

turning a name into a reachable server address.

What a CNAME Record Is (One Name Pointing to Another Name)

CNAME stands for Canonical Name.

A CNAME record does not point to an IP address.

Instead, it points to another domain name.

This is useful when:

• multiple names should lead to the same place

• the actual server IP might change later

For example:

• www.example.com → example.com

Here, www.example.com does not have its own IP. It simply says:

“Go ask example.com for the real address.”

CNAME helps avoid duplication and keeps DNS easier to manage.

What an MX Record Is (How Emails Find the Mail Server)

MX stands for Mail Exchange.

MX records are used only for email, not websites.

When someone sends an email to hello@example.com, the sending mail server asks:

“Where should I deliver emails for this domain?”

The answer comes from MX records.

MX records point to mail servers, not web servers.

This is why:

• a website can be hosted on one service

• email can be handled by another service

This separation is intentional and very important.

What a TXT Record Is (Extra Information and Verification)

TXT records store plain text information about a domain.

They are commonly used for:

• domain ownership verification

• email security (SPF, DKIM, DMARC)

• service integrations

TXT records usually do not affect website loading directly.

Instead, they help other systems trust the domain.

Think of TXT records as notes attached to a domain, readable by machines.

How All DNS Records Work Together for One Website

A real website does not rely on just one DNS record.

For a single domain:

• NS records define who controls DNS

• A / AAAA records define where the website lives

• CNAME records manage alternate names

• MX records handle email delivery

• TXT records provide verification and security info

Each record has a clear role.

Together, they allow a domain to function fully on the internet.

DNS works well because responsibilities are separated, not mixed.

A Record vs CNAME

An A record points directly to an IP address.

A CNAME points to another domain name.

If we need a final destination → A / AAAA

If we need an alias → CNAME

NS vs MX

NS records decide who answers DNS questions.

MX records decide where emails are delivered.

They solve completely different problems.

At a very high level, this is what happens:

1. Browser gets a domain name

2. DNS finds the correct name servers (NS)

3. Name servers provide the needed records

4. Browser gets an IP address (A / AAAA)

5. Browser connects to the server

6. Website loads

All of this happens in milliseconds.

For many beginners, terms like modem, router, switch, firewall, and load balancer feel confusing because they are often explained separately, without showing how they connect in the real world.

In this article, we will understand what each device does, why it exists, and how all of them work together to deliver the internet to our laptop, phone, or backend server.

The goal is not memorization. The goal is to build a clear mental model.

How Internet Enters a Home or Office

The internet does not directly enter our laptop or mobile phone. It first reaches our building through cables owned by an Internet Service Provider (ISP). From there, it passes through a chain of devices, and each device has a single responsibility.

At a high level, the flow looks like this

Internet → Modem → Router → Switch → Devices

In production systems and data centers, this chain becomes longer and more advanced, but the idea remains the same.

What Is a Modem and Why It Exists

A modem is the device that connects our private network to the internet provided by the ISP.

The internet signal coming from the ISP is not directly usable by our computers. It may come through fiber, cable, or phone lines, and it uses formats that our local network cannot understand. The modem’s job is to translate this signal into a digital form that our router and devices can work with.

The word modem comes from Modulator–Demodulator.

In simple terms, the modem speaks the language of the ISP on one side and the language of our local network on the other side.

A modem does not manage devices, does not provide Wi-Fi, and does not control traffic. Its responsibility is very narrow: bring the internet inside.

A good analogy is a translator at an airport. The translator does not decide where we go. It only makes communication possible.

What Is a Router and How It Directs Traffic

Once the internet enters through the modem, it reaches the router.

The router is the decision maker of the network. Its main job is to decide where a packet should go next.

Inside a home or office, multiple devices want internet access at the same time. The router assigns private IP addresses, manages traffic, and ensures that responses coming from the internet reach the correct device.

This is also where NAT (Network Address Translation) usually happens. Many devices share a single public IP address, and the router keeps track of which request belongs to which device.

A router is like a traffic police officer at a busy junction.

Cars (data packets) arrive from different roads and are directed toward the correct destination without colliding.

Without a router, multiple devices cannot safely share one internet connection.

Hub vs Switch: How Local Networks Actually Work

Inside a local network, devices need to talk to each other. This is where hubs and switches come into the picture.

A hub is a very simple and outdated device. When it receives data, it broadcasts that data to all connected devices, even if only one device needs it. This causes unnecessary traffic and security issues.

A switch, on the other hand, is intelligent. It learns which device is connected to which port using MAC addresses. When data arrives, the switch sends it only to the intended device.

This makes switches faster, more secure, and scalable.

Think of a hub like someone shouting a message in a crowded room, while a switch is like sending a private message to one person.

In modern networks, switches have completely replaced hubs.

What Is a Firewall and Why Security Lives Here

A firewall is a security gate between networks.

Its job is to allow or block traffic based on defined rules. These rules may depend on IP addresses, ports, protocols, or even application level data.

Firewalls exist because not all traffic from the internet should be trusted. Without a firewall, every open service would be exposed directly to attackers.

In home networks, firewalls are often built into routers. In enterprises and cloud environments, firewalls are dedicated systems with advanced inspection capabilities.

A firewall is like a security guard at a building entrance.

Everyone is checked, and only allowed people can enter.

For backend systems, firewalls are critical because databases, internal services, and admin panels should never be publicly accessible.

What Is a Load Balancer and Why Scalable Systems Need It

A load balancer sits in front of multiple servers and distributes incoming traffic among them.

When a web application becomes popular, one server is not enough. Multiple backend servers are deployed, and the load balancer ensures that traffic is shared evenly so no single server becomes overloaded.

Load balancers also help with:

• High availability

• Fault tolerance

• Zero downtime deployments

If one server fails, the load balancer stops sending traffic to it.

A load balancer works like a toll booth system on a highway, directing cars to different lanes so traffic keeps moving smoothly.

In modern systems, load balancers are everywhere, cloud platforms, microservices, and container orchestration.

How All These Devices Work Together in Real Life

Let’s connect everything into one real world flow.

When we open a website:

1. The request leaves our device and goes to the router

2. The router forwards it to the modem

3. The modem sends it to the ISP and the internet

4. On the server side, traffic passes through a firewall

5. A load balancer distributes the request to one backend server

6. The response follows the same path back

Each device does one job, and together they form a reliable system.

This is where CSS selectors come in.

Selectors are not about design.

Selectors are about choice.

Before CSS can style anything, it must first decide what to style. That decision is made using selectors.

Why CSS Selectors Are Needed

HTML creates structure.

CSS adds appearance.

But a real webpage contains many elements: headings, paragraphs, buttons, links, and sections. If CSS applied styles blindly, everything would look the same.

Selectors solve this problem by acting as filters.

They help us say:

• style all elements of this type

• style only these specific elements

• style one unique element

Without selectors, CSS would not be able to target elements correctly.

Selectors as Ways to Choose Elements

A good way to think about selectors is like addressing people.

If we shout, “Everyone come here,” we get everyone.

If we say, “All students come here,” we get a group.

If we say, “Rahul from class 10,” we get one person.

CSS selectors work the same way.

They tell the browser who should receive the styling.

Element Selector (Selecting by Tag Name)

The element selector targets elements using their HTML tag name.

Consider this HTML:

<h1>Welcome</h1>
<p>This is the first paragraph</p>
<p>This is the second paragraph</p>

If we write this CSS:

p {
  color: blue;
}

CSS selects all <p> elements and applies the color blue to them.

This selector is useful when we want:

• consistent base styling

• all elements of the same type to look similar

However, element selectors are very broad.

If later we want one paragraph to look different, this selector becomes limiting.

That is why element selectors are best used for general rules, not detailed design.

Class Selector (Selecting a Group with Meaning)

A class selector allows us to select elements based on purpose, not just tag name.

Now consider this HTML:

<p class="highlight">Important note</p>
<p>Normal paragraph</p>

And this CSS:

.highlight {
  background-color: yellow;
}

Here, CSS selects only the element with the class highlight.

The important idea is this:

A class does not describe what the element is.

It describes why the element exists.

Multiple elements can share the same class:

<p class="highlight">Warning message</p>
<div class="highlight">System alert</div>

This makes class selectors reusable and flexible.

That is why classes are the most commonly used selectors in real projects.

ID Selector (Selecting One Unique Element)

An ID selector is used to target one specific element.

Example HTML:

<h1 id="main-heading">My Website</h1>

CSS:

#main-heading {
  font-size: 32px;
}

The ID selector starts with # and must be unique.

Only one element in the entire page can have that ID.

Because IDs are unique, they are very strong selectors.

But this strength can become a problem if we overuse them.

That is why IDs are best used for:

unique layout anchors

• main containers

• elements that appear only once

For styling repeated elements, classes are always better.

Group Selectors (Applying the Same Style Together)

Sometimes, different elements need the same styling.

Instead of repeating CSS, we can group selectors.

Example:

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

Here, CSS applies the same font to all three heading types.

Group selectors help us:

• avoid duplicate code

• keep CSS clean

• maintain consistency

They do not change how selection works, they simply allow us to apply one rule to multiple selectors.

Descendant Selectors (Selecting Based on Structure)

HTML elements are usually nested inside each other.

Consider this HTML:

<div class="card">
  <p>This is inside a card</p>
</div>

<p>This is outside the card</p>

If we write:

.card p {
  color: green;
}

CSS selects only the paragraph inside .card, not the one outside.

This selector depends on structure, not just class or tag.

Descendant selectors help us style elements differently based on where they live in the document. This becomes extremely important in real layouts where components contain other elements.

Basic Selector Priority (Very High Level)

Sometimes, multiple selectors target the same element.

Example:

p {
  color: blue;
}

.text {
  color: red;
}

HTML:

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

Even though both rules apply, the text becomes red.

At a very basic level, we can remember:

Element < Class < ID

• element selectors are weakest

• class selectors are stronger

• ID selectors are strongest

This simple idea helps us understand why some styles override others.

Before and After Styling (Conceptual Example)

Before CSS, HTML looks plain:

<h1>Title</h1>
<p>Description text</p>

After adding selectors and styles:

h1 {
  color: black;
}

p {
  color: gray;
}

.highlight {
  color: red;
}

Now the page has structure and meaning.

The difference happens not because of fancy CSS, but because selectors correctly identify what should change.

This experience is common. Almost everyone who learns HTML goes through this phase. The problem is not that HTML is difficult. The problem is that writing repetitive structure by hand is inefficient.

This is where Emmet becomes useful.

Emmet is a tool that helps us write HTML faster by allowing us to describe structure in a short form and letting the editor generate the full code for us.

What Is Emmet (in very simple terms)

Emmet is a shortcut language for writing HTML.

Instead of typing full HTML elements manually, we write short expressions that represent the structure we want. The code editor then converts those expressions into complete HTML code.

Emmet does not introduce a new language for the browser. The browser never sees Emmet. Emmet only exists inside the code editor to help developers write HTML more efficiently.

Emmet does not change how HTML works.

It only helps you type less and think more about structure.

Why Emmet Is Useful for HTML Beginners

When we are beginners, most of our energy goes into remembering syntax and avoiding small mistakes. We often forget closing tags, misplace elements, or lose track of nesting. This makes HTML feel harder than it actually is.

Emmet helps reduce these problems. By generating correct HTML structure automatically, Emmet removes many common beginner errors. This allows us to focus more on understanding how HTML elements relate to each other instead of worrying about typing everything perfectly.

Another important benefit is confidence. When writing HTML becomes faster and cleaner, learning feels smoother and more enjoyable. This encourages consistent practice, which is essential when learning web development.

How Emmet Works Inside Code Editors

Emmet works as a feature inside modern code editors. It is not a separate program that we run manually. Most editors, such as VS Code, already include Emmet by default.

When we type an Emmet abbreviation, the editor recognizes it as a special pattern. When we press a trigger key (usually the Tab key), the editor expands that abbreviation into full HTML.

Internally, the editor uses Emmet rules to understand what elements, nesting, attributes, and repetitions are being described. The final result is plain HTML that behaves exactly the same as if we had written it by hand.

Basic Emmet Syntax and Abbreviations

Emmet is based on a small set of symbols that describe structure.

These symbols are not random. They are chosen to represent relationships between elements. For example, some symbols indicate parent child relationships, while others indicate sibling elements or repetition.

The important idea is that Emmet allows us to describe how elements are arranged, not just which tags are used. Once this idea is clear, Emmet becomes easy to read and write.

For example:

• Tag names represent elements

• > means “inside”

• + means “next to”

• * means “repeat”

These symbols are enough for most HTML writing.

Creating HTML Elements Using Emmet

The most basic use of Emmet is creating individual HTML elements.

Instead of typing an opening tag and a closing tag manually, we write the tag name once and let Emmet generate the full element. This may seem like a small improvement, but it saves time and avoids mistakes, especially when writing many elements.

This approach also encourages consistency. Every generated element follows proper HTML syntax, which keeps the code clean.

If you type:

div

and press Tab, Emmet expands it to:

<div></div>

If you type:

p

you get:

<p></p>

This already saves time and prevents mistakes.

Adding Classes, IDs, and Attributes

In real world HTML, elements almost always have classes, IDs, or attributes. Writing these repeatedly can become tedious.

Emmet allows us to attach classes and IDs directly to the element definition. This keeps related information together and makes the structure easier to read at a glance.

Attributes can also be added using a clear and readable format. This makes Emmet especially useful when Emmet is used alongside CSS and JavaScript, where classes and IDs are frequently needed.

Emmet makes classes and IDs very easy.

Instead of writing:

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

You write:

div.container

For IDs:

div#main

This expands into proper HTML with class or id.

You can also add attributes like this:

input[type=text]

Emmet understands that you want an input element with attributes.

This keeps your focus on what the element is, not how to write it.

Creating Nested Elements

HTML is mostly about nesting. Without Emmet, nesting feels slow and error prone. With Emmet, nesting is natural. Suppose we want this structure in our page:

• A wrapper div

• Inside it, another div

• Inside that, a main section

• Inside main, a paragraph

Using Emmet, we can write:

div>div>main>p

This single line describes the entire hierarchy.

Reading it from left to right, we are describing levels:

• A div

• inside another div

• inside main

• inside p

Emmet expands it into a properly nested structure.

This helps beginners understand parent and child relationships in HTML.

Repeating Elements Using Multiplication

Many HTML structures repeat the same element.

Lists are the best example.

Instead of writing <li> five times manually, you can write:

li*5

Emmet understands that you want five list items.

This is extremely useful for menus, cards, tables, and layouts.

You save time and reduce typing fatigue.

Generating Full HTML Boilerplate with Emmet

One of the most popular Emmet shortcuts is generating the HTML boilerplate.

If you type:

! or html:5 and then press Enter

Emmet generates this complete HTML structure:

• <!DOCTYPE html>

• <html>

• <head>

• <meta charset>

• <body>

This is not magic.

It is just Emmet giving you a correct starting structure instantly.

This ensures beginners always start with valid HTML.

Most people think a browser is just an app that opens websites. But in reality it is very complex, it is like a separate operating system, it is very different what we think. When we type a URL, press Enter and a page appears, it seems like magically the website landing page appears but behind the scenes, there are a lot of things going on in a specific order.
In this blog we will understand the complete behind the scene process, it is very important because every web developer works with the browser, whether they write HTML, CSS or JS.

Now let’s answer one simple question:

What happens after when we type a URL and press Enter?

A Browser Is Not One Thing

A browser is not a single program doing everything.

It is a collection of components, each with a clear job.

You can think of it like a small factory:

• One part talks to the internet

• One part reads HTML

• One part understands CSS

• One part draws pixels on your screen

All of them work together to show a webpage.

At a very high level, a browser has:

• A user interface (address bar, tabs, buttons) - Handles visible elements like the address bar, tabs, back/forward buttons, bookmarks, and menus. It provides the interactive shell for user input and navigation, it is directly connected with browser’s backend.

• A Browser Engine (Gecko - Used by Firefox , Blink - Used by Google Chrome, Webkit - Used by Apple) - Acts as a coordinator or bridge between the user interface and other core components, such as the rendering and user interface and javascript engine.

• A networking layer (to fetch files) - Manages HTTP requests to fetch resources like HTML, CSS, images, and scripts from servers.

• A rendering engine (to turn code into visuals) - Parses HTML/CSS into the DOM and CSSOM, builds the render tree, performs layout (calculating positions), and paints pixels to the screen.

• A JavaScript engine (to run JS) - Compiles and executes JavaScript code, enabling dynamic interactions by manipulating the DOM. Examples: V8 (Chrome), SpiderMonkey (Firefox).

• Internal data structures (DOM, CSSOM) - Core models like the DOM (Document Object Model) for HTML structure and CSSOM (CSS Object Model) for styles, used by rendering and JS engines for processing.

Each part has one responsibility.

The User Interface: Where Everything Starts

The user interface is the visible part of the browser.

This includes:

• Address bar

• Back and forward buttons

• Tabs

• Reload button

When you type a URL and press Enter, the UI does not load the website itself. User interface is usually connected with backend, that give functionality to the buttons.

It simply passes the URL to the browser’s internal systems and says: Go get whatever lives at this address.

Browser Engine vs Rendering Engine (simple distinction)

The browser engine acts like a coordinator or manager. It sits between the user interface and the rest of the browser. When we type a URL, click refresh, open a new tab, or press the back button, the browser engine decides what should happen next.
It tells the networking part to fetch data, tells the rendering engine to update the page, and keeps everything moving in the correct order. It does not draw anything on the screen by itself. Its main job is coordination and control.

• The boss / coordinator

• Controls the whole page loading process

• Connects UI ↔ rendering ↔ JavaScript

• Decides when things happen

Overall, keep one thing in mind that browser engine is like a manger, who coordinated between different process.

The rendering engine, on the other hand, focuses only on turning code into visuals. It takes HTML and CSS, builds internal structures, calculates layout, paints pixels, and prepares the page for display. Whenever you see text, colors, boxes, or images on a webpage, that work is done by the rendering engine.

• The worker

• Reads HTML + CSS

• Calculates layout

• Draws pixels on the screen

Overall, thing render engine is like a painter, who paints the whole page UI.

Networking: How a Browser Fetches HTML, CSS, and JavaScript

When we press Enter after typing a URL, the browser first needs to find where the website lives. Computers do not understand website names, so the browser must convert the domain name into an IP address. This is done using DNS.

The browser first checks its cache to see if it already knows the IP address. If not, it asks a DNS resolver. The resolver then follows a fixed path: it asks the root DNS server, then the TLD server (like .com or .app), and finally the authoritative DNS server. The authoritative DNS returns the correct IP address, which is sent back to the browser and saved in cache.

Once the browser has the IP address, it creates a connection with the server using TCP. If the site uses HTTPS, a secure connection is also established. After the connection is ready, the browser sends a request asking for the webpage.

The server responds with the HTML file. While reading the HTML, the browser finds links to CSS, JavaScript, images, and fonts, and sends more requests to fetch them. When all required files arrive, networking is done and the browser moves on to parsing and rendering the page.

HTML Parsing: Turning Text into Structure

HTML arrives as plain text.

The browser cannot use text directly to draw a page.

So it parses the HTML.

Parsing simply means: Reading something step by step and understanding its meaning.

While reading HTML, the browser builds a structure called the DOM (Document Object Model).

You can imagine the DOM as a tree:

• <html> is the root

• <body> is a branch

• Headings, paragraphs, links are smaller branches

This DOM represents what elements exist on the page, not how they look.

CSS Parsing: Understanding Styles

CSS is also plain text when downloaded.

The browser parses CSS separately and builds another structure called the CSSOM.

The CSSOM answers questions like:

• What color is this text?

• How wide is this box?

• Where should this element be positioned?

So now the browser has:

• DOM → what exists

• CSSOM → how it should look

DOM + CSSOM: Creating the Render Tree

The browser now combines DOM and CSSOM.

The result is the Render Tree.

The Render Tree:

• Includes only visible elements

• Contains layout and style information

• Is ready to be drawn on screen

Hidden elements like display: none are excluded here**.**

Layout, Painting, and Display

Once the Render Tree is ready, the browser moves through three final steps:

Layout (Reflow)

The browser calculates:

• Exact position of each element

• Exact size of each element

Painting

The browser fills pixels:

• Colors

• Text

• Images

• Borders

Display (Compositing)

Everything is combined and sent to your screen.

At this point, you finally see the webpage.

A Very Simple Parsing Example

Parsing simply means breaking something into parts and understanding its structure.

Take this expression: 1 + 2 * 3.

At first glance, it looks like a single line of text. But to evaluate it correctly, we cannot read it from left to right blindly.

A parser first looks at the expression and understands the rules. It knows that multiplication has higher priority than addition. So instead of adding first, it groups 2 * 3 together.

The parser then converts this expression into a tree. At the top is the + operator. On one side is 1. On the other side is the *operator, which has 2 and 3 as its children.

This tree structure clearly shows what should happen first and what should happen next. The computer can now easily evaluate the expression by following the tree.

Browsers do the same thing with HTML and CSS. They take plain text, parse it, and turn it into tree structures like the DOM and CSSOM so the page can be understood and rendered correctly.

Just remember the flow:

1. URL entered

2. Files fetched

3. HTML → DOM

4. CSS → CSSOM

5. DOM + CSSOM → Render Tree

6. Layout → Paint → Display

What HTML is and why we use it

The question is why HTML exist and why we use it. Before HTML exist, documents on the computer were just plain text files, that files has no built in structure and no standardised way to connect documents together across different devices. Sharing documents globally was difficult.

In 1989, Tim Berners Lee was working at CERN. He proposed a system to share information using connected documents. This idea later became the World Wide Web (WWW).

The World Wide Web was built using three main parts:

• HTML - To describe documents

• HTTP - To transfer documents

• URLs - To locate documents

HTML was not created alone. It was created as one part of the web system. Its role was clear, describe the structure and meaning of documents so that they could be shared and read anywhere.

HTML was designed mainly for documents, not apps. That is why it focuses on text, headings, paragraphs, and links.

So basically, HTML(HyperText Markup Language) is not a programming language. It is a declarative markup language that describes Structure + Meaning of the document so that machine (browser) render it.
HTML is like, it describes things,

• This is header <h1>Header</h1>

• This is paragraph <p>Paragraph</p>

• This is image <img>

• This part is navigation <nav>Nav Bar</nav>

• This part is main content <main>Main Content</main>

HTML as structure of Web

Think of HTML as the structure that holds the web together. A webpage without CSS and JavaScript still works. You can still read the content. That content exists because of HTML.
But without HTML, there is nothing to show at all. That is why HTML is always present, even in modern frameworks. React, Vue, and others still produce HTML in the end, because browsers understand HTML, not frameworks.
HTML only describes meaning

• CSS controls how things look

• JavaScript controls how things behave

• HTML stays focused on structure.

What an HTML tag is

An HTML tag is a marker used to describe content. A tag tells the browser where something starts or ends.
Example:

<p>

This tag tells the browser that a paragraph starts here.

Tags are not content. Users never see them. They exist only for browsers and machines to understand the structure of a document.

There are three main kinds of tags:

• opening tags

• closing tags

• self closing (void) tags

Each type helps define how content is structured.

Opening tag, Closing tag and Content

Consider this example:

<p>This is a paragraph</p>

This line has three parts:

• <p> tells where the paragraph starts

• This is a paragraph is the actual content

• </p> tells where the paragraph ends

Closing tags are important because HTML is based on structure. If we do not add closing tag then browser will not know like after how much text this paragraph should be ended. To start using other tag we have to end previous one. The browser needs to know where one element ends and another begins.

What an HTML element means

An HTML element is the complete unit formed by tags and content. It combines both opening tag + content + closing tag (if required).

An element includes:

• opening tag

• content

• closing tag (if required)

So this:

<p>This is a paragraph</p>

is one element.

A tag is only a part of an element.

Browsers convert HTML into a structure in memory called the DOM (Document Object Model). JavaScript works with this DOM, not directly with the HTML text.

That is why JavaScript selects elements, not tags.

Self Closing (Void) Elements

Some elements do not wrap content. These are called void elements. These elements do not have any kind of closing tag, they work without closing tags,

Examples include:

• <img>

• <br>

• <input>

These elements represent single things, such as an image or an input field. Because there is nothing inside them, they do not need closing tags.

Block Level and Inline Elements

HTML elements are divided into block level and inline elements to describe structure.

Block level elements are used to build the main layout of a page. They usually start on a new line and group content together. They contains full width of the screen

Examples:

• <div>

• <p>

• <h1>

• <section>

Inline elements are used inside text. They do not break the line and are meant to describe small parts of content. They contain only that much space that is needed.

Examples:

• <span>

• <a>

• <strong>

A simple idea is:

• block elements are containers

• inline elements live inside containers

Why Semantic HTML Exists

As the web grew, developers needed a clearer way to describe meaning. This is like telling browser that this part include this type of content and this part includes that types of content. Semantic tags give meaning to the structure of the website, this is helpful for screen readers that work behind the scene in the browser. Screen readers helps visual impaired people to understand the content of the website.

Tags like:

• <header>

• <nav>

• <main>

• <footer>

tell what a section is meant for.

These tags help:

• search engines understand content

• screen readers work better

• developers read code more easily

Semantic HTML keeps documents clear and meaningful, just like HTML was originally designed to be.

Commonly Used HTML Tags

HTML has many tags, but they all exist for a reason.

Some tags are used to structure text, such as headings and paragraphs. Some are used for grouping content, like <div> and <span>. Others are used for links, images, and forms.

For example:

• headings show importance and order

• paragraphs group sentences

• links connect pages

• images display media

• form tags collect user input

Some frequently used HTML tags are:

• <html> - Root of the document

• <head> - Metadata

• <title> - Page title

• <body> - Visible content

• <h1> to <h6> - Headings

• <p> - Paragraph

• <a> - Link

• <img> - Image

• <div> - Container

• <span> - Inline container

• <br> - Line break

• <hr> - Horizontal line