DEV Community: SAURAV KUMAR

Understanding Recursion in JavaScript — Explained in Simple Words

SAURAV KUMAR — Tue, 21 Apr 2026 15:40:29 +0000

If you are learning DSA, recursion can feel scary at first.

When I started learning it, I also felt like:

“Why is a function calling itself?”
“How do I know when it will stop?”
“Why does this look so confusing?”

But the truth is:

Recursion is not hard because of the logic.

It feels hard because we try to understand everything at once.

So in this post, let’s not do that.

Let’s understand recursion in very simple words, step by step, using JavaScript.

What is recursion?

Recursion means:

a function calls itself

That’s the full idea.

A function does some work, and then calls itself again for a smaller problem.

First, let’s remember what a function is

A function is just a block of code that does some work.

Example:

function sayHi() {
  console.log("Hi");
}

sayHi();

Output:

Hi;

Simple.

Now let’s see recursion.

A function calling itself

function hello() {
  console.log("Hello");
  hello();
}

Now think:

What will happen here?

it prints Hello
then calls itself again
then prints Hello
then calls itself again
again and again

This never stops.

That is the problem.

This is called infinite recursion.

So what do we need?

We need a way to stop the function.

That stopping condition is called the base case.

In simple words:

base case means stop here

Without a base case, recursion keeps running forever.

First simple example: print N to 1

function printNToOne(n) {
  if (n === 0) return;

  console.log(n);
  printNToOne(n - 1);
}

printNToOne(5);

Output:

5;
4;
3;
2;
1;

Now let’s understand it slowly.

Step-by-step dry run

We call:

printNToOne(5);

Step 1

n = 5

Is n === 0?

No.

So print 5.

Then call:

printNToOne(4);

Step 2

n = 4

Is n === 0?

No.

So print 4.

Then call:

printNToOne(3);

Then same thing happens for:

Finally:

printNToOne(0);

Now n === 0 is true.

So function stops.

Done.

Two things every recursive function needs

This is the most important part.

Every recursion problem needs these 2 things:

1. Base case

Where should it stop?

Example:

if (n === 0) return;

2. Smaller problem

How will it move toward the base case?

Example:

printNToOne(n - 1);

So recursion is usually:

stop at some point
do some work
call itself with a smaller value

One very common mistake

Look at this:

function test(n) {
  if (n === 0) return;

  console.log(n);
  test(n + 1);
}

This is wrong.

Why?

Because the base case says stop at 0.

But the recursive call is doing n + 1.

So if n = 5:

5 becomes 6
6 becomes 7
7 becomes 8

It is moving away from 0.

So just having a base case is not enough.

You must also move toward the base case.

Easy rule to remember

Whenever you write recursion, ask:

Where will it stop?
Is every call getting closer to that stop?

If the second answer is no, the recursion is wrong.

Now let’s print 1 to N

This is where many beginners get confused.

function printOneToN(n) {
  if (n === 0) return;

  printOneToN(n - 1);
  console.log(n);
}

printOneToN(5);

Output:

1;
2;
3;
4;
5;

Now the question is:

Why is this printing from 1 to 5?

The simple reason

Because the console.log(n) is written after the recursive call.

That changes the order.

Let’s see:

printOneToN(3);

The function goes like this:

printOneToN(3)
printOneToN(2)
printOneToN(1)
printOneToN(0)

At 0, it stops.

Now while coming back:

print 1
print 2
print 3

That is why output becomes:

1;
2;
3;

One small but important idea

If you print before the recursive call:

console.log(n);
printNToOne(n - 1);

you get:

5 4 3 2 1

If you print after the recursive call:

printOneToN(n - 1);
console.log(n);

you get:

1 2 3 4 5

So the position of console.log() matters a lot.

What is happening inside memory?

You will hear this word a lot:

call stack

Do not make it complicated.

Just imagine a stack of plates.

a new plate goes on top
the top plate comes out first

Same idea here.

When a function calls itself, JavaScript keeps each call in memory.

Example:

function printOneToN(n) {
  if (n === 0) return;

  printOneToN(n - 1);
  console.log(n);
}

If we call:

printOneToN(3);

Then calls are stored like this:

printOneToN(3)
printOneToN(2)
printOneToN(1)
printOneToN(0)

Then 0 stops.

Now the stack starts coming back:

return to 1 → print 1
return to 2 → print 2
return to 3 → print 3

That is why recursion sometimes prints while coming back.

Head recursion and tail recursion

These names sound big.

But the idea is small.

It only depends on where the work happens.

Head recursion

In head recursion:

recursive call happens first
work happens later

Example:

function headRecursion(n) {
  if (n === 0) return;

  headRecursion(n - 1);
  console.log(n);
}

headRecursion(5);

Output:

1;
2;
3;
4;
5;

Why?

Because function first goes deep.

Then it prints while coming back.

Tail recursion

In tail recursion:

work happens first
recursive call happens after that

Example:

function tailRecursion(n) {
  if (n === 0) return;

  console.log(n);
  tailRecursion(n - 1);
}

tailRecursion(5);

Output:

5;
4;
3;
2;
1;

Why?

Because it prints first, then goes deeper.

Easiest way to remember

Head recursion

function demo(n) {
  if (n === 0) return;
  demo(n - 1);
  console.log(n);
}

Work happens later.

Tail recursion

function demo(n) {
  if (n === 0) return;
  console.log(n);
  demo(n - 1);
}

Work happens first.

That’s it.

Parameterized recursion

Sometimes beginners write recursion using outside variables.

Example:

let count = 1;

function printOneToN(n) {
  if (count > n) return;

  console.log(count);
  count++;
  printOneToN(n);
}

This works.

But it depends on an outside variable.

A cleaner way is to pass everything in parameters.

That is called parameterized recursion.

Example:

function printOneToN(i, n) {
  if (i > n) return;

  console.log(i);
  printOneToN(i + 1, n);
}

printOneToN(1, 5);

Output:

1;
2;
3;
4;
5;

Why is this better?

no outside variable
cleaner code
easier to understand
easier to control

In simple words:

parameterized recursion means passing the changing values inside the function parameters

Example: print X, N times

function printXNTimes(x, n) {
  if (n === 0) return;

  console.log(x);
  printXNTimes(x, n - 1);
}

printXNTimes(4, 5);

Output:

4;
4;
4;
4;
4;

Very simple:

print x
reduce n
stop when n becomes 0

Recursion that returns values

Till now, we printed values.

Now let’s see recursion that returns values.

This is very common in DSA.

Example 1: Sum of first N numbers

We know:

sumOfN(5) = 1 + 2 + 3 + 4 + 5

So we can think like this:

sumOfN(5) = 5 + sumOfN(4)

That gives us:

function sumOfN(n) {
  if (n === 0) return 0;

  return n + sumOfN(n - 1);
}

console.log(sumOfN(5));

Output:

15;

Example 2: Factorial

We know:

5! = 5 * 4 * 3 * 2 * 1

So the recursive idea is:

factorial(5) = 5 * factorial(4)

Code:

function factorial(n) {
  if (n === 1) return 1;

  return n * factorial(n - 1);
}

console.log(factorial(5));

Output:

120;

Example 3: Power

Let’s say we want:

2^4 = 16

Then we can think:

power(a, b) = a * power(a, b - 1)

Base case:

power(a, 0) = 1

Code:

function power(a, b) {
  if (b === 0) return 1;

  return a * power(a, b - 1);
}

console.log(power(2, 4));

Output:

16;

Time complexity of simple recursion

Let’s take this function:

function printNToOne(n) {
  if (n === 0) return;
  console.log(n);
  printNToOne(n - 1);
}

If n = 5, it runs about 5 times.

If n = 100, it runs about 100 times.

So time complexity is:

O(n);

Because the function runs n times.

Space complexity of simple recursion

In recursion, memory is used in the call stack.

For this same function, calls stay in memory until the base case is reached.

So stack depth also becomes about n.

That means space complexity is:

O(n);

Simple way to remember:

time = how many times function runs
space = how many function calls are sitting in stack

How to solve recursion problems step by step

This is the most useful part.

Whenever you see a recursion question, ask these 3 things:

1. What is the base case?

Where should it stop?

2. What is the smaller problem?

How can I reduce the input?

3. What is the relation?

If the smaller answer is already known, how do I use it?

That’s the full thinking process.

My simple recursion template

Before writing code, think like this:

// 1. Base case:
// when should it stop?

// 2. Smaller problem:
// what smaller input should I send?

// 3. Relation:
// how do I use the smaller answer?

This one habit makes recursion much easier.

Common beginner mistakes

Here are some mistakes that happen a lot:

1. No base case

Then recursion never stops.

2. Wrong base case

Then it stops too early or too late.

3. Moving in the wrong direction

Like doing n + 1 when you should do n - 1.

4. Mixing printing and returning

Printing and returning are not the same thing.

5. Using outside variables when not needed

Sometimes parameters make recursion cleaner.

Final thoughts

If recursion feels confusing, that is normal.

It confuses many people in the beginning.

The good thing is this:

Once you understand these 2 ideas, recursion becomes much easier:

where to stop
how to make the problem smaller

That’s the heart of recursion.

You do not need to learn everything in one day.

Start with small problems:

print N to 1
print 1 to N
sum of first N
factorial
power

Practice these a few times.

After that, recursion will start feeling much more natural.

If you are also learning DSA right now, spend time on the basics first.

A strong base makes the harder problems much easier later.

Thanks for reading.

👋 About Me

Hi, I’m Saurav Kumar.

I enjoy learning, building, and writing about web development in simple words, especially topics that are useful for beginners and developers preparing for interviews.

Right now, I’m also focusing on improving my understanding of core concepts like JavaScript, OOP, system design, and software engineering fundamentals.

Let's connect!

🐙 GitHub: @saurav02022
💼 LinkedIn: Saurav Kumar

If you found this helpful, share it with a friend learning JavaScript — it might help them too.

Until next time, keep coding and keep learning 🚀

Software Design Principles in JavaScript: DRY, KISS, and YAGNI Explained Simply

SAURAV KUMAR — Sun, 19 Apr 2026 16:52:27 +0000

When we hear the term software design, it often sounds like something very advanced.

People start talking about architecture, scalability, patterns, maintainability, and a lot of other big words.

But in reality, good software design often starts with very small decisions.

Questions like:

Should I repeat this logic?
Am I making this solution more complex than needed?
Am I building something I do not even need right now?

These small decisions matter a lot.

As I’ve been spending more time revisiting core software engineering concepts, I realized that before going deep into system design, it helps to understand a few simple principles that shape good code from the beginning.

Three of the most important ones are:

DRY — Don’t Repeat Yourself
KISS — Keep It Simple, Stupid
YAGNI — You Aren’t Gonna Need It

These are not frameworks.

They are not strict rules either.

They are practical principles that help us write code that is easier to understand, maintain, and extend.

In this post, let’s understand these three principles in simple words with JavaScript examples.

Why these principles matter

When a project is small, even messy code can feel manageable.

But as the project grows, the same issues start showing up again and again:

the same logic appears in multiple places
simple features become harder to change
unnecessary abstractions make code harder to read
“future-ready” features increase complexity without solving a real problem

That is where design principles help.

They do not guarantee perfect code.

But they do help us avoid many common mistakes.

And that is a big part of writing maintainable software.

1. DRY: Don’t Repeat Yourself

What DRY means

DRY means that a piece of logic or knowledge should have one clear source of truth.

In simple words:

If the same logic is repeated in multiple places, it becomes harder to maintain.

Because later, when the logic changes, you may need to update it everywhere.

And if you miss even one place, bugs start appearing.

A simple example without DRY

const length1 = 10;
const width1 = 5;
const area1 = length1 * width1;
console.log("Area 1:", area1);

const length2 = 8;
const width2 = 4;
const area2 = length2 * width2;
console.log("Area 2:", area2);

This works.

But the area calculation logic is repeated.

Right now, it may not look like a big issue.

But if you later want to add validation, change the formula, or reuse the same logic in more places, this duplication becomes a maintenance problem.

A better DRY version

class AreaCalculator {
  static calculateArea(length, width) {
    return length * width;
  }
}

const area1 = AreaCalculator.calculateArea(10, 5);
const area2 = AreaCalculator.calculateArea(8, 4);

console.log("Area 1:", area1);
console.log("Area 2:", area2);

Now the logic lives in one place.

That means:

easier updates
less duplication
lower chance of inconsistency

This is the main benefit of DRY.

Where DRY helps in real projects

In real JavaScript applications, DRY often shows up in places like:

form validation
API handling
utility functions
repeated formatting logic
repeated UI behavior
business rules used in multiple places

For example, if multiple forms need the same email validation logic, it usually makes sense to extract that into a reusable function.

That way, if the validation rule changes later, you update it once.

When DRY is overused

This is where things get interesting.

Many developers learn DRY and then start extracting everything too early.

But just because two code blocks look similar does not always mean they should be merged.

For example:

function formatUserName(user) {
  return `${user.firstName} ${user.lastName}`;
}

function formatProductName(product) {
  return `${product.brand} ${product.title}`;
}

At first glance, both are “formatting names”.

But they serve different domains.

If we force them into one generic helper too early, we may make the code less clear.

So DRY is useful.

But premature abstraction is not.

A good rule is:

Avoid repeating true logic, but do not rush into creating shared abstractions too early.

2. KISS: Keep It Simple, Stupid

What KISS means

KISS means:

Use the simplest solution that clearly solves the problem.

In simple words:

Do not overcomplicate things.

Sometimes code becomes hard to read not because the problem is difficult, but because the solution is written in a more complicated way than necessary.

An unnecessarily complex example

Let’s say we want to check whether a number is even.

class NumberUtils {
  static isEven(number) {
    let isEven = false;

    if (number % 2 === 0) {
      isEven = true;
    } else {
      isEven = false;
    }

    return isEven;
  }
}

This code works.

But it is doing too much for a very small task.

It uses:

an extra variable
an unnecessary if...else
more lines than needed

That makes the code longer and slightly harder to read.

A simpler version

class NumberUtils {
  static isEven(number) {
    return number % 2 === 0;
  }
}

This is much better.

Why?

Because it is:

shorter
clearer
easier to understand at a glance

That is what KISS encourages.

KISS in everyday JavaScript code

KISS is very useful when writing:

conditionals
helper functions
component logic
state updates
APIs
class methods

For example, compare these two conditions:

if (!(user === null || user === undefined) && user.isActive === true) {
  console.log("User is active");
}

and

if (user && user.isActive) {
  console.log("User is active");
}

Both do the same job.

But the second version is cleaner and easier to read.

That is usually the better design choice.

Simple does not mean careless

This is important.

KISS does not mean:

avoid structure
ignore edge cases
skip validation
write everything in one function
never create abstractions

Simple code is not lazy code.

Simple code is code that solves the problem without unnecessary mental overhead.

That is a big difference.

3. YAGNI: You Aren’t Gonna Need It

What YAGNI means

YAGNI means:

Do not build something until it is actually needed.

In simple words:

Avoid adding features just because you think they may be useful in the future.

This happens a lot during development.

We start with one requirement, then our mind jumps ahead:

maybe later we will need categories
maybe later we will need filters
maybe later we will need version history
maybe later we will need sync support

So we start designing for all of that from day one.

But many of those features never arrive.

And even if they do, they may come in a completely different form.

That is why YAGNI matters.

A simple example

Suppose the current requirement is only this:

create a note
view notes

That’s it.

But instead of building just that, we create a bigger system with support for:

tags
archived notes
sharing
version tracking
cloud sync queues

Like this:

class NotesApp {
  constructor() {
    this.notes = [];
    this.tags = new Map();
    this.archivedNotes = [];
    this.sharedNotes = [];
    this.versionHistory = new Map();
    this.syncQueue = [];
  }

  addNote(note) {
    this.notes.push(note);
  }
}

Most of this complexity is unnecessary if the product only needs basic notes right now.

A better version

class NotesApp {
  constructor() {
    this.notes = [];
  }

  addNote(note) {
    this.notes.push(note);
  }

  getNotes() {
    return this.notes;
  }
}

This version is focused.

It solves the current problem.

And if new requirements come later, we can extend it then.

That is the spirit of YAGNI.

When YAGNI should not be applied blindly

Just like DRY and KISS, YAGNI is also not absolute.

Sometimes future requirements are not guesses.

Sometimes they are already confirmed.

For example, if your team knows that file attachments are definitely coming in the next sprint, it may be reasonable to prepare the design a little.

So YAGNI does not mean:

never think ahead

It means:

do not spend time building complexity for imaginary requirements

That is the important difference.

These principles are helpful, but not absolute

One of the most useful things to understand is this:

These principles can sometimes pull in different directions.

For example:

DRY says avoid duplication
KISS says keep things simple

But sometimes making code DRY too early creates an abstraction that actually makes the code harder to understand.

So what do we do?

We use these principles as guides, not as rigid laws.

The real goal is not to “apply a principle”.

The real goal is to write code that is:

clear
easy to change
easy to test
easier for other developers to understand

That is what good design is really about.

A simple way to remember all three

Here is the easiest way I remember them:

DRY → don’t repeat real logic
KISS → don’t make the solution harder than necessary
YAGNI → don’t build for requirements that do not exist yet

That is it.

Small principles.

But very powerful when used well.

Interview-friendly explanation

If someone asks this in an interview, you can answer like this:

DRY means avoiding duplication by keeping one source of truth for logic.
KISS means choosing the simplest solution that works clearly.
YAGNI means not implementing features until they are actually needed.

These principles help improve readability, maintainability, and reduce unnecessary complexity in software systems.

That answer is short, clean, and strong enough for many interview situations.

Common mistake developers make

A very common mistake is thinking that better design always means:

more abstraction
more layers
more generic code
more future planning

But that is not always true.

Sometimes better design means:

fewer moving parts
smaller functions
simpler conditions
less abstraction
fewer assumptions about the future

In many cases, simple and well-structured code is far better than clever code.

👋 About Me

Hi, I’m Saurav Kumar.

I enjoy learning, building, and writing about web development in simple words, especially topics that are useful for beginners and developers preparing for interviews.

Right now, I’m also focusing on improving my understanding of core concepts like JavaScript, OOP, system design, and software engineering fundamentals.

Let's connect!

🐙 GitHub: @saurav02022
💼 LinkedIn: Saurav Kumar

If you found this helpful, share it with a friend learning JavaScript — it might help them too.

Until next time, keep coding and keep learning 🚀

Inheritance in JavaScript — Explained in Simple Words

SAURAV KUMAR — Sun, 19 Apr 2026 16:04:59 +0000

If you are learning Object-Oriented Programming in JavaScript, one concept that starts appearing very often is:

Inheritance

At first, it can feel confusing.

Words like parent class, child class, extends, super(), and overriding can make the topic look bigger than it really is.

When I started learning it, I realized inheritance is not as hard as it sounds.

It is mainly about reusing code in a cleaner way.

In this post, let’s understand inheritance in JavaScript in very simple words.

🧠 What Is Inheritance?

Inheritance is an OOP concept where one class can use the properties and methods of another class.

In simple words:

Inheritance allows a child class to reuse code from a parent class.

So instead of writing the same methods again and again in different classes, we can write common code once in a parent class and let child classes use it.

That is the basic idea.

🤔 Why Do We Need Inheritance?

Let’s say we write code like this:

class Dog {
  eat() {
    console.log("This animal eats food");
  }

  sleep() {
    console.log("This animal sleeps");
  }

  bark() {
    console.log("Dog barks");
  }
}

class Cat {
  eat() {
    console.log("This animal eats food");
  }

  sleep() {
    console.log("This animal sleeps");
  }

  meow() {
    console.log("Cat meows");
  }
}

This works.

But there is one problem.

Both classes have the same methods:

eat()
sleep()

So we are repeating code.

That is not a good idea, especially when the project becomes bigger.

Instead, we can move the common methods into one parent class.

That is where inheritance becomes useful.

📦 Parent Class and Child Class

To understand inheritance, we first need to know these two terms.

Parent Class

A parent class is the class that contains common properties and methods.

It acts like a base.

Child Class

A child class is the class that inherits from the parent class.

It can use parent features and also add its own features.

In simple words:

parent class = common features
child class = common features + own features

⚙️ `extends` in JavaScript

In JavaScript, we use the extends keyword to create inheritance.

Example:

class Dog extends Animal {
}

This means:

Dog inherits from Animal.

So if Animal has some methods, Dog can use them too.

That is the first syntax rule to remember.

💻 A Very Simple Example

class Animal {
  eat() {
    console.log("Animal eats food");
  }
}

class Dog extends Animal {
}

const dog = new Dog();
dog.eat();

Output

Animal eats food

Why does this work?

Because Dog inherited the eat() method from Animal.

Even though Dog does not define eat() itself, it can still use it.

That is inheritance in the simplest way.

🐣 Child Class Can Also Add Its Own Methods

Inheritance does not mean the child class only depends on the parent.

The child class can also add its own methods.

class Bird {
  move() {
    console.log("Bird moves");
  }
}

class Parrot extends Bird {
  speak() {
    console.log("Parrot speaks");
  }
}

const parrot = new Parrot();

parrot.move();
parrot.speak();

Output

Bird moves
Parrot speaks

Here:

move() comes from the parent class
speak() belongs to the child class

So the child class gets:

inherited methods
its own methods

That is one of the most important ideas in inheritance.

🏗️ Constructor in Inheritance

Now let’s go one step deeper.

Sometimes classes do not only have methods.

They also store data.

For that, we use a constructor.

Example:

class Person {
  constructor(name) {
    this.name = name;
  }

  sayName() {
    console.log(`My name is ${this.name}`);
  }
}

If we do this:

const person = new Person("Saurav");
person.sayName();

Output

My name is Saurav

Now let’s connect this with inheritance.

🔑 What Is `super()` in JavaScript?

When a child class has its own constructor, and the parent class also has a constructor, we use super().

super() is used to call the parent constructor.

class Person {
  constructor(name) {
    this.name = name;
  }

  showName() {
    console.log(`Name is ${this.name}`);
  }
}

class Teacher extends Person {
  constructor(name, subject) {
    super(name);
    this.subject = subject;
  }

  showSubject() {
    console.log(`Subject is ${this.subject}`);
  }
}

const teacher = new Teacher("Saurav", "Math");

teacher.showName();
teacher.showSubject();

Output

Name is Saurav
Subject is Math

What is happening here?

Let’s understand it step by step:

Teacher inherits from Person
Person stores name
Teacher stores subject
super(name) sends the value to the parent constructor
So the object gets both name and subject

That is why super() is important.

⚠️ Important Rule About `super()`

Inside a child class constructor, we must call super() before using this.

Correct:

class Vehicle {
  constructor(brand) {
    this.brand = brand;
  }
}

class Car extends Vehicle {
  constructor(brand, model) {
    super(brand);
    this.model = model;
  }
}

If we try to use this before super(), JavaScript throws an error.

So this is an important rule to remember:

In a child constructor, call super() first.

🔄 Method Overriding

Sometimes the child class does not want to use the parent method exactly as it is.

It wants to provide its own version.

That is called method overriding.

class User {
  login() {
    console.log("User logged in");
  }
}

class Admin extends User {
  login() {
    console.log("Admin logged in");
  }
}

const admin = new Admin();
admin.login();

Output

Admin logged in

Here, both parent and child have a method called login().

When we call login() using the Admin object, JavaScript uses the child version.

In simple words:

Method overriding means the child class creates its own version of a parent method using the same method name.

⬆️ Calling Parent Method with `super`

Sometimes we do not want to completely replace the parent method.

We want to call the parent method first and then add more behavior.

For that, we use:

super.methodName()

Example:

class User {
  login() {
    console.log("User logged in");
  }
}

class Admin extends User {
  login() {
    super.login();
    console.log("Admin has special access");
  }
}

const admin = new Admin();
admin.login();

Output

User logged in
Admin has special access

So here:

super.login() calls the parent method
then the child adds extra behavior

This is useful when we want to extend parent behavior instead of fully replacing it.

🧱 Types of Inheritance

There are a few common types of inheritance you should know.

1. Single Inheritance

In single inheritance, one child class inherits from one parent class.

class Device {
  powerOn() {
    console.log("Device powers on");
  }
}

class Laptop extends Device {
  code() {
    console.log("Laptop is used for coding");
  }
}

Here, Laptop inherits from Device.

That is single inheritance.

2. Multilevel Inheritance

In multilevel inheritance, inheritance happens in a chain.

class LivingThing {
  grow() {
    console.log("Living thing grows");
  }
}

class Plant extends LivingThing {
  needWater() {
    console.log("Plant needs water");
  }
}

class Tree extends Plant {
  giveOxygen() {
    console.log("Tree gives oxygen");
  }
}

Here:

Plant inherits from LivingThing
Tree inherits from Plant

So inheritance is happening across multiple levels.

That is multilevel inheritance.

3. Hierarchical Inheritance

In hierarchical inheritance, multiple child classes inherit from the same parent class.

class Appliance {
  turnOn() {
    console.log("Appliance turns on");
  }
}

class Fan extends Appliance {
  spin() {
    console.log("Fan spins");
  }
}

class Light extends Appliance {
  glow() {
    console.log("Light glows");
  }
}

Here:

Fan and Light both inherit from Appliance

That is hierarchical inheritance.

🧑‍💼 Practical Example

Let’s understand inheritance with one practical example.

class Employee {
  constructor(name, id) {
    this.name = name;
    this.id = id;
  }

  displayDetails() {
    console.log(`Name : ${this.name}`);
    console.log(`Id : ${this.id}`);
  }
}

class Manager extends Employee {
  constructor(name, id, teamSize) {
    super(name, id);
    this.teamSize = teamSize;
  }

  displayDetails() {
    super.displayDetails();
    console.log(`Team Size : ${this.teamSize}`);
  }
}

class Engineer extends Employee {
  constructor(name, id, specialization) {
    super(name, id);
    this.specialization = specialization;
  }

  displayDetails() {
    super.displayDetails();
    console.log(`Specialization : ${this.specialization}`);
  }
}

const manager = new Manager("Jax", 101, 8);
manager.displayDetails();

const engineer = new Engineer("William", 202, "Backend Developer");
engineer.displayDetails();

This example shows many important things together:

common data inside Employee
extra data inside Manager and Engineer
constructor chaining using super()
method overriding using displayDetails()
calling parent method with super.displayDetails()

This is one of the best ways to understand inheritance in a practical way.

❌ Does JavaScript Support Multiple Inheritance?

This is an important point.

With JavaScript classes, multiple inheritance is not supported.

That means one class can extend only one class at a time.

So this is not valid:

class C extends A, B {
}

In JavaScript class syntax:

single inheritance → yes
multilevel inheritance → yes
hierarchical inheritance → yes
multiple inheritance → no

⚠️ Common Beginner Mistakes

Here are some common mistakes beginners make:

1. Forgetting `extends`

Without extends, inheritance does not happen.

2. Forgetting `super()` in child constructor

If the child class has its own constructor, it must call the parent constructor properly.

3. Using `this` before `super()`

This causes an error in JavaScript.

4. Thinking overriding means changing parent code

We do not directly change the parent class.

We create the same method name in the child class and provide a different implementation.

🧠 Key Takeaway

Inheritance in JavaScript is mainly about code reuse.

It allows one class to inherit properties and methods from another class.

In simple words:

parent class contains common features
child class reuses those features
child class can also add its own features
child class can override parent methods when needed

If you understand these clearly:

extends
super()
method overriding
inheritance types

then your inheritance foundation is strong.

✅ Final Thoughts

Inheritance can feel confusing at first.

But once you practice it with small examples, it starts making much more sense.

For me, the biggest shift was to stop thinking of inheritance as a big theory topic and start seeing it as a simple way to reuse common code.

If one class already has something useful, another class can inherit it instead of rewriting it.

That is the real value of inheritance.

If you are learning OOP in JavaScript right now, take it step by step.

Do not rush.

Start with small examples, understand extends, then super(), then overriding.

That makes the topic much easier.

👋 About Me

Hi, I’m Saurav Kumar.

I enjoy learning, building, and writing about web development in simple words, especially topics that are useful for beginners and developers preparing for interviews.

Right now, I’m also focusing on improving my understanding of core concepts like JavaScript, OOP, system design, and software engineering fundamentals.

Let's connect!

🐙 GitHub: @saurav02022
💼 LinkedIn: Saurav Kumar

If you found this helpful, share it with a friend learning JavaScript — it might help them too.

Until next time, keep coding and keep learning 🚀

Understanding Low-Level Design (LLD) in Simple Words — With an Online Shopping App Example

SAURAV KUMAR — Sat, 18 Apr 2026 15:03:35 +0000

When I first started learning Low-Level Design (LLD), it sounded like a very big and complicated topic.

I used to think it was only for very senior developers or for people working in Java.

But after spending some time on it, I realised the core idea is actually very simple.

LLD is just about planning the small details of how a feature or system will work before we jump into writing full code.

In this post, let’s understand Low-Level Design in very simple words using a relatable example:

an online shopping app like Flipkart.

We will not go too deep into advanced theory.

The goal is just to build a clear beginner-friendly understanding.

🧠 What Is Low-Level Design (LLD)?

Low-Level Design means thinking about the detailed structure of a system.

It focuses on questions like:

what small parts will exist inside the feature
what each part will do
how those parts will talk to each other
what data they will handle
what should happen step by step

In simple words:

LLD is the stage where your idea starts becoming close to real code.

🏠 A Very Simple Real-Life Analogy

Think of building a house.

High-Level Design (HLD)

This is like deciding:

where the bedroom will be
where the kitchen will be
where the bathroom will be

This is the big picture.

Low-Level Design (LLD)

This is like deciding:

where the switchboard will go
where the pipes will go
where the tap will be placed
what material will be used

So:

HLD = big picture
LLD = detailed picture

That is the main difference.

🆚 HLD vs LLD in Simple Words

Let’s say we are building an online shopping app.

HLD says:

We need:

login
home page
product page
cart
address
payment

This is the overall structure.

LLD says:

Okay, but now:

how will login work?
how will cart store products?
how will quantity increase?
how will address be saved?
what happens if payment fails?
which part should handle what?

This is Low-Level Design.

So if I say it in one line:

HLD tells us what main parts the system has.

LLD tells us how each part will actually work.

🛒 Let’s Understand LLD Using an Online Shopping App

Suppose a user opens an online shopping app.

The flow is something like this:

User logs in
User goes to home page
User selects a product
User adds product to cart
User changes quantity
User adds address
User makes payment
Order gets placed

At first, this looks like one simple flow.

But in LLD, we break this into smaller parts.

That is where things become clearer.

🔍 Step 1: Break the Big Feature Into Small Parts

Instead of saying:

“User buys a product”

LLD says:

Let’s break it into small jobs.

For this shopping app, some small parts can be:

Login handling
Product handling
Cart handling
Address handling
Payment handling
Order handling

Now the system already feels easier to understand.

👤 1) Login Part

When the user tries to log in, many small checks can happen.

For example:

check if email or phone is valid
check if password is correct
create user session after successful login
show error if login fails

So LLD asks:

who will validate login?
where will session be created?
what should happen if password is wrong?

Even one small feature like login has many details inside it.

That is LLD thinking.

📦 2) Product Part

Now user comes to the home page and sees products.

Each product may have data like:

product id
product name
price
stock
image
description

Now LLD asks:

where should product data come from?
how should one product be shown?
what happens if item is out of stock?
what should happen when user opens product details?

So again, we are moving from “show products” to “how exactly should this work?”

🛒 3) Cart Part

Now user clicks Add to Cart.

This sounds easy.

But inside it, many small decisions are there.

For example:

if product is already in cart, increase quantity
if product is not in cart, add it as a new item
check stock before increasing quantity
calculate total price
remove item if quantity becomes 0

This is a very good LLD example.

Because “cart” is not just one button.

It has real logic behind it.

➕ 4) Quantity Part

Suppose user clicks + to increase quantity.

Now LLD asks:

should quantity increase directly?
should stock be checked first?
what if only 2 items are left in stock?
what if user tries to add 10?

So behind one small + button, there is still some detailed thinking.

That is why LLD is important.

It helps us think before we write messy code.

📍 5) Address Part

Before payment, user adds delivery address.

Now again, it is not just “save address”.

There can be many checks:

name should not be empty
pin code should be valid
phone number should be valid
city and state should be selected properly

And then we also think:

should user save multiple addresses?
should there be one default address?
where should selected address be stored?

These are all LLD-type questions.

💳 6) Payment Part

Now user clicks on payment.

This also has many details:

which payment method is selected?
is payment successful?
what if payment fails?
what if money is deducted but order is not placed?
when should order status become confirmed?

This is where detailed design becomes very important.

Because payment mistakes can create real problems.

📄 7) Order Part

After successful payment, order should be created.

Now LLD asks:

when exactly should order be created?
what product details should be saved?
what address should be attached?
what payment status should be stored?
what order status should be shown?

Again, this is not just “place order”.

There is a lot happening inside.

🧩 So What Is LLD Really Doing Here?

In this whole shopping app example, LLD is helping us do one simple thing:

break one big user flow into small, clear, manageable parts.

Instead of writing everything in one big file or one huge function, we think in smaller responsibilities.

That makes the system:

easier to understand
easier to build
easier to debug
easier to extend later

⚙️ A Simple Beginner Way to Think About It

You can think of the shopping app like a team of workers.

one worker handles login
one worker handles products
one worker handles cart
one worker handles address
one worker handles payment
one worker handles orders

If one person does everything alone, confusion happens.

Same in code.

That is why we break the feature into small parts.

This is one of the most important ideas in Low-Level Design.

💻 A Small Code-Like Example

Let’s say we want to model a very small cart system.

Here is a simple example:

class CartItem {
  constructor(productId, name, price, quantity = 1) {
    this.productId = productId;
    this.name = name;
    this.price = price;
    this.quantity = quantity;
  }

  increaseQuantity() {
    this.quantity++;
  }

  getTotal() {
    return this.price * this.quantity;
  }
}

class Cart {
  constructor() {
    this.items = [];
  }

  addProduct(product) {
    const existingItem = this.items.find(
      (item) => item.productId === product.productId
    );

    if (existingItem) {
      existingItem.increaseQuantity();
    } else {
      this.items.push(new CartItem(product.productId, product.name, product.price));
    }
  }

  getCartTotal() {
    return this.items.reduce((total, item) => total + item.getTotal(), 0);
  }
}

What is happening here?

CartItem handles one item
Cart handles the full cart
addProduct() decides whether to add new item or increase quantity
getCartTotal() calculates total

This is a very small example, but it shows the idea well.

We are separating responsibilities clearly.

That is the heart of LLD.

📌 Why LLD Matters

Low-Level Design is useful because it helps us:

1. Avoid messy code

If we start coding without thinking, one file or one function can become too big.

2. Improve clarity

When each part has one clear job, the project becomes easier to understand.

3. Make features easier to extend

Later, if you want to add coupon logic, wishlist, or order tracking, a better design helps a lot.

4. Work better in teams

When the structure is clear, different developers can work on different parts more easily.

5. Build stronger interview thinking

Many companies ask LLD not because they only want syntax, but because they want to see how you think.

🎯 Important Point: LLD Is Not Just About Classes

This is something beginners should understand clearly.

LLD does not mean:

“Just create some classes.”

LLD is bigger than that.

It means:

thinking clearly
dividing work properly
deciding responsibilities
designing the flow before coding

Classes can be one part of it.

But the bigger idea is clean planning.

🚀 Final Thoughts

When I first started learning Low-Level Design, I thought it was something very advanced.

But after understanding it better, I realised the idea is actually simple:

take one big feature
break it into small parts
decide what each part should do
think about the step-by-step flow before coding

That is Low-Level Design.

If you are a beginner, do not worry about making it perfect from day one.

Just start with simple examples like:

login system
shopping cart
food delivery app
movie booking app

Once you practice breaking features into smaller responsibilities, LLD starts making much more sense.

And honestly, this is one of those topics that sounds scary at first, but becomes much easier when you connect it to real product flows.

🙋‍♂️ About Me

Hi, I’m Saurav Kumar.

I enjoy learning, building, and writing about web development in simple words—especially breaking down topics that are useful for beginners and developers preparing for interviews.

Right now, I’m focusing on deepening my understanding of core concepts like JavaScript, Object-Oriented Programming, system design, and software engineering fundamentals.

Let's connect!

🐙 GitHub: @saurav02022
💼 LinkedIn: Saurav Kumar

Encapsulation in JavaScript — Explained in Simple Words

SAURAV KUMAR — Fri, 17 Apr 2026 05:23:18 +0000

If you are learning Object-Oriented Programming (OOP) in JavaScript, one word that starts appearing very often is: Encapsulation

At first, it can sound like a big and confusing concept.

When I started learning it, I realized the idea is actually much simpler than the name.

Encapsulation is mainly about protecting data and controlling how that data is used.

In simple words, it helps us stop objects from being changed in the wrong way.

In this post, let’s understand encapsulation in JavaScript in the simplest way possible.

🧠 What Is Encapsulation?

Encapsulation means:

keeping data and methods together inside a class
hiding internal details from the outside world
allowing access through controlled methods

In simple words:

The object should control its own data.

For example, if we have a bank account, its balance should not be changed randomly from outside.

Doing this is risky:

account.balance = -5000;

Instead, we should allow safe actions like:

account.deposit(1000);
account.withdraw(500);

That is the core idea of encapsulation.

🔒 Why Do We Need Encapsulation?

Without encapsulation, any part of the program can directly change important values.

That can create invalid states and bugs.

For example:

a bank balance should not become negative randomly
marks should not go above 100
product price should not become negative
salary should not go below 0

Encapsulation helps us protect these values by making sure updates happen only in valid ways.

It also makes code cleaner and easier to maintain.

📦 Real-Life Analogy

Think of an ATM.

When you use an ATM, you do not open the machine and directly edit its internal data.

You only interact with the options it gives you:

check balance
deposit
withdraw

The internal working stays hidden.

You only use the allowed interface.

That is a simple real-world example of encapsulation.

⚙️ How Encapsulation Works in JavaScript

In JavaScript, one common way to achieve encapsulation is by using:

private fields
public methods

Private fields are written using #.

Example:

#balance

This means that field can only be accessed inside the class.

Code outside the class cannot use it directly.

🏦 BankAccount Example

Let’s understand this with a simple example.

class BankAccount {
  #accountHolderName;
  #balance;

  constructor(accountHolderName, balance) {
    this.#accountHolderName = accountHolderName;
    this.#balance = balance > 0 ? balance : 0;
  }

  getAccountHolderName() {
    return this.#accountHolderName;
  }

  getBalance() {
    return this.#balance;
  }

  deposit(amount) {
    if (amount <= 0) {
      console.log("Deposit amount must be positive.");
      return;
    }

    this.#balance += amount;
  }

  withdraw(amount) {
    if (amount <= 0) {
      console.log("Withdrawal amount must be positive.");
      return;
    }

    if (amount > this.#balance) {
      console.log("Insufficient funds.");
      return;
    }

    this.#balance -= amount;
  }
}

const account = new BankAccount("Saurav", 5000);

console.log(account.getBalance()); // 5000
account.deposit(1000);
console.log(account.getBalance()); // 6000
account.withdraw(2000);
console.log(account.getBalance()); // 4000

🔍 What Is Happening Here?

Let’s break it down.

1. `#accountHolderName` and `#balance` are private fields

#accountHolderName;
#balance;

These values are hidden from outside code.

That means this is not allowed:

account.#balance = 100000; // Error

Only the class itself can access and change #balance.

2. The constructor sets the initial values

constructor(accountHolderName, balance) {
  this.#accountHolderName = accountHolderName;
  this.#balance = balance > 0 ? balance : 0;
}

When the object is created, the constructor initializes the private data.

We also added a small validation so invalid starting balance becomes 0.

3. `getBalance()` gives controlled read access

getBalance() {
  return this.#balance;
}

If we want the balance, we ask the object for it.

We do not access it directly.

4. `deposit()` and `withdraw()` control updates

These methods decide how balance can change.

For example:

deposit must be positive
withdrawal must be positive
withdrawal cannot be more than current balance

This is where encapsulation becomes useful.

Instead of letting outside code change the balance however it wants, the object protects its own state.

❌ Without Encapsulation vs ✅ With Encapsulation

Without encapsulation

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

const account = new BankAccount("Saurav", 5000);
account.balance = -10000;

console.log(account.balance); // -10000

This is dangerous because anyone can change the balance directly.

With encapsulation

class BankAccount {
  #balance;

  constructor(balance) {
    this.#balance = balance;
  }

  getBalance() {
    return this.#balance;
  }

  withdraw(amount) {
    if (amount > 0 && amount <= this.#balance) {
      this.#balance -= amount;
    }
  }
}

Now the balance is protected.

That is much safer.

🧩 A Common Beginner Mistake

One very common mistake in JavaScript is confusing these two:

this.#balance
this.balance

They are not the same thing.

this.#balance → private field
this.balance → normal public property

If your class uses #balance, then inside the class you must always use this.#balance.

If you accidentally write this.balance, you are working with a different property.

That can create confusing bugs.

🎯 Getters and Setters

Encapsulation is often explained using getters and setters.

Here is a simple example:

class Student {
  #marks;

  constructor(marks) {
    this.#marks = marks >= 0 && marks <= 100 ? marks : 0;
  }

  getMarks() {
    return this.#marks;
  }

  setMarks(newMarks) {
    if (newMarks >= 0 && newMarks <= 100) {
      this.#marks = newMarks;
    } else {
      console.log("Invalid marks");
    }
  }
}

const s1 = new Student(80);

console.log(s1.getMarks()); // 80
s1.setMarks(95);
console.log(s1.getMarks()); // 95
s1.setMarks(150); // Invalid marks

Here:

#marks is private
getMarks() reads the value
setMarks() updates it with validation

This is a common encapsulation pattern.

🛠️ Business Methods Are Often Better Than Generic Setters

In real-world code, generic setters are not always the best choice.

For example, instead of writing this:

setBalance(amount)

it is often better to write:

deposit(amount)
withdraw(amount)
transfer(amount)

Why?

Because these methods reflect real actions.

They also make business rules clearer.

For a bank account, deposit() and withdraw() are more meaningful than a plain setBalance().

That is why encapsulation is not only about private variables.
It is also about controlled behavior.

✅ Benefits of Encapsulation

Here are some practical benefits:

1. Better data protection

Important values stay safe from direct misuse.

2. Better validation

You can stop invalid updates before they happen.

3. Cleaner code

The logic related to one object stays inside that object.

4. Easier maintenance

You can change internal implementation later without affecting outside code too much.

5. Better interview understanding

Encapsulation is one of the most important OOP concepts asked in interviews.

⚠️ Common Beginner Mistakes

1. Making everything public

If everything is public, outside code can change object state freely.

2. Using setters without validation

If setters accept invalid data, encapsulation becomes weak.

3. Thinking encapsulation only means private variables

Private fields are one part of it, but the bigger idea is controlled access.

4. Mixing `this.balance` and `this.#balance`

This is one of the easiest mistakes to make in JavaScript.

🎤 How to Explain Encapsulation in an Interview

If someone asks:

What is encapsulation?

You can say:

Encapsulation is the process of bundling data and methods together inside a class and restricting direct access to internal state. It helps protect data and allows controlled access through methods.

How do you achieve encapsulation in JavaScript?

You can say:

In JavaScript, encapsulation can be achieved using private fields like #balance and public methods like getters, setters, or business methods such as deposit() and withdraw().

Why is encapsulation useful?

You can say:

Encapsulation helps protect object data, prevents invalid state changes, and makes code cleaner and easier to maintain.

🚀 Final Thoughts

Encapsulation may sound like a difficult OOP term at first.

But the idea is actually simple.

It means:

keep data and methods together
hide internal details when needed
allow controlled access through methods

If you are learning OOP in JavaScript, start with small examples like:

student marks
product price
employee salary
bank account

Once these examples become clear, encapsulation starts feeling natural.

And after that, learning concepts like inheritance, polymorphism, and abstraction becomes much easier.

🙋‍♂️ About Me

Hi, I’m Saurav Kumar.

I enjoy learning, building, and writing about web development in simple words—especially breaking down topics that are useful for beginners and developers preparing for interviews.

Right now, I’m focusing on deepening my understanding of core concepts like JavaScript, Object-Oriented Programming, system design, and software engineering fundamentals.

Let's connect!

🐙 GitHub: @saurav02022
💼 LinkedIn: Saurav Kumar

Class vs Object in JavaScript — Explained in Simple Words

SAURAV KUMAR — Mon, 13 Apr 2026 16:31:55 +0000

In my previous post, I explained what OOP is in JavaScript in simple words.

But when we go a little deeper into OOP, a few terms start showing up again and again:

class
object
properties
methods

At first, these words sound easy.

But when I started learning them, the difference between them was not always very clear.

So in this post, let’s understand these basics properly in JavaScript — in the simplest way possible.

We will also look at how objects are created, what happens when they are no longer used, and a small memory-related idea that every beginner should know.

🧱 What Is a Class in JavaScript?

A class is a blueprint.

It tells us what kind of data an object should have and what kind of actions it should perform.

In simple words, a class is like a design.

It is not the actual object itself.

It is just the structure from which objects are created.

Let’s take a simple Employee example:

class Employee {
  constructor(name, salary) {
    this.name = name;
    this.salary = salary;
  }

  setName(name) {
    this.name = name;
  }

  setSalary(salary) {
    this.salary = salary;
  }

  getSalary() {
    return this.salary;
  }
}

Here:

Employee is the class
name and salary are properties
setName(), setSalary(), and getSalary() are methods

So this class defines what an employee object should contain and what it should be able to do.

📦 What Is an Object?

An object is an instance of a class.

If class is the blueprint, object is the real thing created from it.

For example:

const emp1 = new Employee("Raj", 10000);
const emp2 = new Employee("Rahul", 15000);

console.log(`${emp1.name}'s salary is ₹${emp1.getSalary()}`);
console.log(`${emp2.name}'s salary is ₹${emp2.getSalary()}`);

Here:

emp1 is one object
emp2 is another object

Both are created from the same class.

But both have their own separate data.

That means even if two objects come from the same class, they still behave like separate real entities.

That is one of the most important ideas in OOP.

🧠 Properties and Methods

When we create objects, they usually have two things:

1. Properties

Properties are the data of an object.

They describe the current state of that object.

In the Employee example:

name
salary

These are properties.

2. Methods

Methods are the actions an object can perform.

In the same example:

setName()
setSalary()
getSalary()

These are methods.

So in very simple words:

properties = data
methods = actions

That is the basic building block of OOP.

⚙️ How Objects Are Created

In JavaScript, we create objects from a class using the new keyword.

Example:

const emp1 = new Employee("Raj", 10000);

When this runs:

a new object is created
the constructor() runs
values are assigned to that object
emp1 starts referring to that object

Let’s see the full example again:

class Employee {
  constructor(name, salary) {
    this.name = name;
    this.salary = salary;
  }

  setName(name) {
    this.name = name;
  }

  setSalary(salary) {
    this.salary = salary;
  }

  getSalary() {
    return this.salary;
  }
}

const emp1 = new Employee("Raj", 10000);
const emp2 = new Employee("Rahul", 15000);

console.log(`${emp1.name}'s salary is ₹${emp1.getSalary()}`);
console.log(`${emp2.name}'s salary is ₹${emp2.getSalary()}`);

Output:

Raj's salary is ₹10000
Rahul's salary is ₹15000

Now let’s change one object:

emp1.setSalary(20000);

console.log(emp1.getSalary()); // 20000
console.log(emp2.getSalary()); // 15000

This shows that both objects have their own separate state.

Changing one object does not change the other.

🗑️ What Happens When an Object Is No Longer Used?

This part is important because different languages handle memory differently.

In JavaScript, we usually do not delete objects manually in normal code.

Instead, JavaScript uses garbage collection.

That means if an object is no longer reachable anywhere in the program, JavaScript can remove it from memory automatically.

Example:

let emp = new Employee("Raj", 10000);

emp = null;

After this, if nothing else is referring to that object, it becomes eligible for garbage collection.

So the simple idea is:

we create objects using new
JavaScript keeps them in memory while they are needed
when they are no longer reachable, JavaScript cleans them up automatically

For beginners, this understanding is enough.

🧮 One Simple Memory Idea Beginners Should Know

In JavaScript, object variables store references.

That means the variable points to the object instead of copying the whole object.

For example:

const emp1 = new Employee("Raj", 10000);
const emp2 = emp1;

emp2.setSalary(25000);

console.log(emp1.getSalary()); // 25000

You might expect only emp2 to change.

But both show the same updated value.

Why?

Because both emp1 and emp2 are referring to the same object.

This is a very important beginner concept in JavaScript.

So remember:

primitives like numbers and strings behave differently
objects are reference-based
unused objects are cleaned up automatically by the garbage collector

You do not need to go deep into engine internals right now.

Just understanding reference is already very helpful.

🚀 Why This Matters

Class and object are not just theory topics.

We use these ideas to model real things in software like:

users
employees
bank accounts
products
orders

Once you understand class, object, properties, methods, and references, it becomes much easier to understand bigger OOP concepts later like:

encapsulation
inheritance
polymorphism
abstraction

That is why these basics matter so much.

They are also common in interviews, especially when someone wants to check whether your OOP foundation is clear.

🎯 Quick Interview-Friendly Answer

If someone asks you:

What is a class in JavaScript?

You can say:

A class is a blueprint for creating objects. It defines what properties and methods those objects will have.

If they ask:

What is an object?

You can say:

An object is an instance created from a class. It contains its own data and can use the methods defined in that class.

If they ask:

What happens when an object is no longer used in JavaScript?

You can say:

JavaScript uses garbage collection, so objects that are no longer reachable can be cleaned up automatically from memory.

✅ Final Thoughts

If you are learning OOP in JavaScript, do not try to jump too quickly into advanced concepts.

First, make these basics strong:

Class = blueprint
Object = instance
Properties = data
Methods = actions
new = creates object
Unused objects = cleaned up automatically

Once these ideas become clear, OOP starts making much more sense.

And honestly, this is one of those topics that feels theoretical at first, but becomes very practical when you start building real projects.

🙋‍♂️ About Me

Hi, I’m Saurav Kumar.

I enjoy learning, building, and writing about web development in simple words—especially breaking down topics that are useful for beginners and developers preparing for interviews.

Right now, I’m focusing on deepening my understanding of core concepts like JavaScript, Object-Oriented Programming, system design, and software engineering fundamentals.

Let's connect!

🐙 GitHub: @saurav02022
💼 LinkedIn: Saurav Kumar

Object-Oriented Programming (OOP) in JavaScript — Explained in Simple Words

SAURAV KUMAR — Thu, 09 Apr 2026 06:59:45 +0000

What is OOP in JavaScript? Explained in Simple Words

If you are starting OOP, one thing can feel confusing at first:

People use words like class, object, methods, and attributes — but it’s not always clear what they actually mean in JavaScript.

When I started learning it, I realized OOP is not just about syntax.

It is more about how we organize code.

Instead of writing only step-by-step instructions, we try to model real-world things as objects that contain both data and behavior.

In this post, let’s understand Object-Oriented Programming (OOP) in JavaScript in very simple words.

🧠 What is OOP?

Object-Oriented Programming (OOP) is a programming style based on objects.

An object can contain:

data → like name, age, balance
behavior → like login, deposit, withdraw

In simple words, OOP helps us keep related data and functionality together.

For example, if we create a Bank Account in JavaScript, it can have:

account holder name
balance
account number
methods like deposit() and withdraw()

So instead of keeping everything separate, OOP lets us organize it in a cleaner way.

📦 Class and Object in JavaScript

OOP mainly revolves around two basic things:

Class

A class is a blueprint.

It defines what an object should have and what it should do.

Object

An object is a real instance created from that class.

Let’s see a simple JavaScript example:

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

  deposit(amount) {
    this.balance += amount;
    console.log(`₹${amount} deposited. New balance: ₹${this.balance}`);
  }

  withdraw(amount) {
    if (amount > this.balance) {
      console.log("Insufficient balance");
      return;
    }

    this.balance -= amount;
    console.log(`₹${amount} withdrawn. New balance: ₹${this.balance}`);
  }
}

const account1 = new BankAccount("Saurav", 5000, "ACC123");

account1.deposit(1000);
account1.withdraw(2000);

Here:

BankAccount is the class
account1 is the object
name, balance, and accountNumber are properties
deposit() and withdraw() are methods

That’s the core idea.

🔄 Procedural Programming vs OOP

Before OOP, many programs were written using procedural programming.

In procedural programming, we focus more on writing functions step by step.

In OOP, we focus more on entities and their behavior.

Let’s understand the difference in a simple way.

1. Approach

Procedural programming follows a sequence of steps.

OOP models the system using objects.

2. Data Handling

In procedural programming, data is often handled separately and can be modified more easily from different places.

In OOP, data is usually kept inside objects and accessed through methods.

This makes the code more organized and safer.

3. Code Reusability

In procedural programming, we can reuse functions.

But in OOP, reusability is stronger because we can extend existing code using concepts like inheritance.

That makes it easier to build bigger systems.

4. Scalability

Procedural code can become harder to manage as the project grows.

OOP is usually easier to scale because we can add new classes or extend old ones without changing everything.

5. Modularity

In procedural programming, code is divided into functions.

In OOP, code is divided into classes and objects, which makes large applications easier to manage.

6. Real-World Modeling

This is one of the biggest reasons OOP feels natural.

Real software often deals with things like:

users
accounts
products
orders
employees

OOP lets us represent these directly in code.

💻 Procedural vs OOP Example in JavaScript

Let’s take the same bank example.

Procedural style

let accountName = "Saurav";
let balance = 5000;

function deposit(amount) {
  balance += amount;
  console.log(`₹${amount} deposited. New balance: ₹${balance}`);
}

function withdraw(amount) {
  if (amount > balance) {
    console.log("Insufficient balance");
    return;
  }

  balance -= amount;
  console.log(`₹${amount} withdrawn. New balance: ₹${balance}`);
}

deposit(1000);
withdraw(2000);

This works.

But if we need multiple users, multiple accounts, and more features, this style becomes messy.

Now look at the OOP version.

OOP style

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

  deposit(amount) {
    this.balance += amount;
    console.log(`${this.name} deposited ₹${amount}. Balance: ₹${this.balance}`);
  }

  withdraw(amount) {
    if (amount > this.balance) {
      console.log(`${this.name} has insufficient balance`);
      return;
    }

    this.balance -= amount;
    console.log(`${this.name} withdrew ₹${amount}. Balance: ₹${this.balance}`);
  }
}

const user1 = new BankAccount("Saurav", 5000);
const user2 = new BankAccount("Rahul", 3000);

user1.deposit(1000);
user2.withdraw(500);

Now each account has its own data and behavior.

That is much cleaner and easier to manage.

🚀 Why OOP is Useful in Real Projects

There are a few big reasons why OOP is widely used.

1. Modularity

OOP helps break a big problem into smaller parts.

For example, in a banking app, we can create separate classes for:

Account
Customer
Transaction

This makes the code more structured.

2. Code Reusability

We can reuse and extend existing code instead of writing similar logic again and again.

Example:

class Vehicle {
  start() {
    console.log("Vehicle started");
  }
}

class Car extends Vehicle {}
class Bike extends Vehicle {}

const car = new Car();
car.start();

Here, Car and Bike can reuse behavior from Vehicle.

3. Scalability

As the application grows, OOP makes it easier to add new features.

Instead of changing unrelated code, we can create new classes or extend old ones.

4. Security

OOP also helps us control how data is accessed.

We should not let every part of the app directly modify important values.

Instead, we should use methods.

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

  deposit(amount) {
    if (amount <= 0) {
      console.log("Invalid amount");
      return;
    }
    this.balance += amount;
  }

  getBalance() {
    return this.balance;
  }
}

This approach makes the code more controlled and predictable.

🏦 Real-Life Analogy: Bank System

A bank is one of the easiest examples to understand OOP.

Here’s how:

Classes → Account, Customer, Transaction
Objects → Raj’s account, Saurav’s account, one specific transaction
Attributes → name, balance, account number
Methods → deposit, withdraw, transfer

This is why OOP is powerful.

It maps very naturally to real-world systems.

🎯 Why OOP is Better for Large Applications

For very small programs, procedural programming can still work fine.

But when an application becomes large, OOP gives better structure.

It helps with:

better organization
cleaner code
easier maintenance
easier scaling
more reusable logic

That’s why OOP is so common in real projects.

📝 A Simple Way to Think About OOP

If you are just starting, remember this:

Class = blueprint
Object = real thing created from blueprint
Properties = data
Methods = actions

That’s enough to build a strong base.

You do not need to make it complicated in the beginning.

🎤 How to Explain OOP in an Interview

If someone asks:

What is OOP?

You can say:

OOP is a programming paradigm where we model real-world entities as objects. These objects contain both data and behavior. In JavaScript, we usually create objects from classes, where the class acts like a blueprint.

If they ask:

Why is OOP useful?

You can say:

OOP helps with modularity, reusability, scalability, and better code organization. It is especially useful for building large and maintainable applications.

✅ Final Thoughts

OOP is not just a theory topic.

It is a practical way to write cleaner and more organized code.

In JavaScript, once you understand:

class
object
properties
methods

everything starts making more sense.

So if you’re learning OOP right now, don’t rush into advanced terms.

Start with small real-world examples like:

bank account
student
user
cart
product

That makes OOP much easier to understand.

If you're also learning JavaScript for interviews, this topic is worth understanding properly because it helps both in coding and in explaining design clearly.

🙋‍♂️ About Me

Hi, I’m Saurav Kumar.

I enjoy learning, building, and writing about web development in simple words, especially topics that are useful for beginners and developers preparing for interviews.

Right now, I’m also focusing on improving my understanding of core concepts like JavaScript, OOP, system design, and software engineering fundamentals.

You can connect with me here:

GitHub: github.com/saurav02022
LinkedIn: linkedin.com/in/saurav02022

🧠 How Do Closures Work in JavaScript?

SAURAV KUMAR — Wed, 05 Nov 2025 06:03:24 +0000

Explained in Simple Words (with Code Examples & Interview Tips)

When I first started learning JavaScript, the word closure sounded scary.

Later I realised closures are just functions that remember things — nothing magical, only useful.

This article explains closures in plain English, with small code examples and a short interview-friendly answer you can use. Let’s keep it simple and practical.

🧩 What Is a Closure?

A closure is when a function remembers and uses variables from its outer (parent) function — even after the outer function has finished running.

Think of it like a backpack 🎒: when a function is created, it carries its surrounding variables inside that backpack. Even if the parent function returns, the inner function still has access to those items in the backpack.

💡 Very Simple Example

function outerFunction() {
  let count = 0;

  function innerFunction() {
    count++;
    console.log("Count is:", count);
  }

  return innerFunction;
}

const counter = outerFunction();

counter(); // Count is: 1
counter(); // Count is: 2
counter(); // Count is: 3

Why this shows a closure:

innerFunction keeps access to count even after outerFunction has finished. That remembered access is a closure.

🧠 Step-by-step: What’s Happening?

Call outerFunction() → it creates a local variable count = 0.
Define innerFunction() inside outerFunction().
Return innerFunction from outerFunction.
Even though outerFunction finishes, innerFunction still remembers count.
Each call to counter() updates the same count stored in the closure.

🔐 Practical Use: Private Data (Counter Module)

Closures help you hide data (make it private) and expose only controlled methods.

function createCounter() {
  let count = 0; // private

  return {
    increment() {
      count++;
      console.log("Count:", count);
    },
    decrement() {
      count--;
      console.log("Count:", count);
    },
    getCount() {
      return count;
    }
  };
}

const counter = createCounter();
counter.increment(); // Count: 1
counter.increment(); // Count: 2
console.log(counter.getCount()); // 2
// direct access like counter.count → undefined

Benefit: count cannot be changed except via the provided methods. This pattern avoids global variables and accidental mutations.

⏰ Closures with Async Code

Closures work perfectly with timers, promises, and callbacks.

function greetUser(name) {
  setTimeout(function () {
    console.log("Hello, " + name);
  }, 1000);
}

greetUser("Saurav"); // After 1s: Hello, Saurav

Even after greetUser returns, the timeout callback remembers name because of the closure.

⚙️ Function Factories (Another Useful Pattern)

Closures can produce customised functions.

function multiplyBy(factor) {
  return function (number) {
    return number * factor;
  };
}

const double = multiplyBy(2);
const triple = multiplyBy(3);

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

Each returned function remembers its own factor. This is simple and powerful.

⚠️ Common Beginner Mistakes

Shared loop variable problem: Using var in loops with closures can be confusing. Prefer let or create new scopes.
Memory concerns: Closures keep references to outer variables; avoid holding large data unnecessarily.
Confusing scopes: Same variable names in inner and outer scopes shadow each other — be clear about where a variable is defined.

🚀 Where You See Closures in Real Code

React hooks (useState, useEffect) use closures under the hood.
Event handlers that access outer variables.
Module and factory patterns for encapsulation.
Currying and functional utilities.

🧠 Key Takeaway

A closure is simply an inner function that remembers variables from its outer scope.

Use closures to keep data private, remember state, and write modular code.

🎯 Bonus: How to Explain Closures in an Interview (with Example)

When an interviewer asks “What is a closure?” or “Explain closures in JavaScript”, keep your answer short and then show a tiny example.

Short answer (30–45 seconds)

A closure is when a function remembers the variables from its outer scope even after that outer function has finished executing. In other words, the inner function carries its lexical environment with it. Closures enable data privacy and stateful functions in JavaScript.

Follow-up: Quick example to show on the whiteboard or in code

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

const greetSaurav = makeGreeter("Saurav");
greetSaurav(); // Hello, Saurav

Explain while you show it:

makeGreeter creates a local name.
It returns greet, which uses name.
Even after makeGreeter returns, greet still remembers name — that’s a closure.

Common interview follow-ups & how to answer them

Q: Why is closure useful? A: For stateful functions and data privacy without globals. It helps implement modules, factories, and callbacks.
Q: Any pitfalls? A: If not careful, closures can unintentionally keep large objects alive, causing memory to be retained. Also, loop-variable capture mistakes can confuse results — use let to avoid it.
Q: Can you show a bug caused by closures? A: Yes — older code using var in loops with async callbacks captures the same variable. Show the fixed version using let or an IIFE.

Mini whiteboard challenge (simple coding task)

Task: Write a function makeCounter() that returns an object with increment and get methods. get returns the current count.

Solution to write quickly:

function makeCounter() {
  let count = 0;
  return {
    increment() { count++; },
    get() { return count; }
  };
}

const c = makeCounter();
c.increment();
console.log(c.get()); // 1

Why this is a good interview answer:

Short, correct, and shows you understand closures and data privacy.
You can extend it (add decrement, validation) if asked.

👋 About Me

Hi, I'm Saurav Kumar — a Software Engineer passionate about building modern web and mobile apps using JavaScript, TypeScript, React, Next.js, and React Native.

I’m exploring how AI tools can speed up development,

and I share beginner-friendly tutorials to help others grow faster.

🔗 Connect with me:

LinkedIn — I share short developer insights and learning tips

GitHub — Explore my open-source projects and experiments

If you found this helpful, share it with a friend learning JavaScript — it might help them too.

Until next time, keep coding and keep learning 🚀

Why Doesn’t My API Call Wait? — Understanding Promises & Async/Await in JavaScript

SAURAV KUMAR — Mon, 20 Oct 2025 05:16:48 +0000

Imagine you’re building a small weather app 🌤️.

You click a “Get Weather” button, and your JavaScript calls a weather API like this:

const data = fetch("https://api.weatherapi.com/data");
console.log(data);

You expect it to print the weather data.

Instead, it shows this 👇

Promise { <pending> }

No temperature. No city name. Just... pending.

You try adding more logs, maybe even a delay — but the result doesn’t change.

Why?

Because JavaScript is asynchronous — it doesn’t stop and wait for slow tasks (like APIs, timers, or file reads).

While your fetch request is still in progress, JS moves to the next line.

To handle this properly, JavaScript gives us Promises — a way to represent “something that will finish later.”

And once you understand Promises, you’ll learn Async/Await, which makes asynchronous code look clean and readable — like synchronous code.

🧠 What Is a Promise?

A Promise is just a JavaScript object that represents the eventual result of an asynchronous operation.

It can be in one of three states:

Pending → still waiting
Fulfilled → operation succeeded
Rejected → operation failed

Let’s see an example 👇

const weatherData = new Promise((resolve, reject) => {
  const success = true;
  if (success) {
    resolve("☀️ Weather data fetched successfully!");
  } else {
    reject("❌ Failed to fetch weather data!");
  }
});

weatherData
  .then((message) => console.log(message))
  .catch((error) => console.error(error));

Step-by-step:

We create a Promise that either resolves (success) or rejects (error).
.then() handles success.
.catch() handles failure.

This way, your app doesn’t freeze while waiting — it continues other work and handles the result later.

⚙️ The Problem with `.then()` Chains

As your app grows, chaining .then() becomes hard to read.

fetchUser()
  .then((user) => fetchWeather(user.city))
  .then((weather) => fetchForecast(weather.id))
  .catch((error) => console.error(error));

This can quickly look messy — especially with multiple dependencies.

That’s where Async/Await comes in.

✨ Async/Await — Making Async Code Look Simple

async/await is just a cleaner way to work with Promises.

It helps you write asynchronous code that looks synchronous.

async function getWeather() {
  try {
    const response = await fetch("https://api.chucknorris.io/jokes/random");
    const data = await response.json();
    console.log("☀️ Weather:", data.value);
  } catch (error) {
    console.error("❌ Error fetching data:", error);
  }
}

getWeather();

Step-by-step:

Add the async keyword before the function.
Use await to pause until the Promise resolves.
Wrap code in try...catch for error handling.

🌦️ Mini Project: Weather Fetch App

Let’s build a beginner-friendly Weather App that uses async/await and proper error handling.

<body>
  <h1>🌦️ Weather App</h1>
  <input type="text" id="city" placeholder="Enter city name" />
  <button id="btn">Get Weather</button>
  <p id="result">Enter a city and click the button 👆</p>

  <script>
    const cityInput = document.getElementById("city");
    const btn = document.getElementById("btn");
    const result = document.getElementById("result");

    async function getWeather() {
      const city = cityInput.value.trim();
      if (!city) {
        result.innerText = "⚠️ Please enter a city name!";
        return;
      }

      try {
        result.innerText = "⏳ Loading...";
        const res = await fetch(`https://api.weatherapi.com/v1/current.json?key=YOUR_API_KEY&q=${city}`);
        if (!res.ok) throw new Error("City not found or API issue.");
        const data = await res.json();
        result.innerText = `🌤️ ${data.location.name}: ${data.current.temp_c}°C`;
      } catch (err) {
        result.innerText = "❌ Could not fetch weather data.";
        console.error(err);
      }
    }

    btn.addEventListener("click", getWeather);
  </script>
</body>

✅ What’s happening:

When you click the button, it calls getWeather().
The function waits (await) for the API to respond.
If something fails (no internet or bad city name), it’s handled gracefully with catch.

⚠️ Common Mistakes Beginners Make

Forgetting to use await:

const data = fetch(url).json(); // ❌ Doesn't wait for the response

Mixing .then() and await:

const data = await fetch(url).then(res => res.json()); // ❌ Avoid mixing

No error handling: Always use try...catch to avoid unhandled rejections.
Using await outside an async function: Only works inside functions marked with async.

🧩 Real-World Example in React

Here’s how you’d use the same concept inside a React component 👇

import { useEffect, useState } from "react";

export default function WeatherApp() {
  const [weather, setWeather] = useState(null);
  const [error, setError] = useState(null);

  useEffect(() => {
    async function fetchWeather() {
      try {
        const res = await fetch("https://api.weatherapi.com/v1/current.json?key=API_KEY&q=Delhi");
        const data = await res.json();
        setWeather(data.current.temp_c);
      } catch (err) {
        setError("Failed to fetch weather.");
      }
    }

    fetchWeather();
  }, []);

  if (error) return <p>{error}</p>;
  if (!weather) return <p>Loading...</p>;
  return <p>🌤️ Current Temperature: {weather}°C</p>;
}

🎯 Bonus: How to Explain in an Interview

Q: What is a Promise?

A: A Promise represents a value that will be available in the future — success or failure.

Q: How is async/await different from Promises?

A: Async/Await is syntactic sugar over Promises — it makes async code cleaner and easier to read.

Q: How do you handle errors in async code?

A: Using try...catch blocks or the .catch() method.

Q: What happens if you forget await?

A: You get a Promise object instead of the resolved value.

🧠 Key Takeaways

✅ Promises represent future results of async operations.

✅ Async/Await makes Promises easier to use.

✅ Always handle errors using try...catch.

✅ Use async/await for cleaner, more readable code.

✅ Async doesn’t block — it helps your app stay responsive.

👋 About Me

Hi, I'm Saurav Kumar — a Software Engineer passionate about building modern web and mobile apps using JavaScript, TypeScript, React, Next.js, and React Native.

I’m exploring how AI tools can speed up development,

and I share beginner-friendly tutorials to help others grow faster.

🔗 Connect with me:

LinkedIn — I share short developer insights and learning tips

GitHub — Explore my open-source projects and experiments

If you found this helpful, share it with a friend learning JavaScript — it might help them too.

Until next time, keep coding and keep learning 🚀

var, let, and const in JavaScript — Differences Explained for Beginners

SAURAV KUMAR — Wed, 15 Oct 2025 18:02:09 +0000

If you are learning JavaScript, one of the first questions you will meet is: when should I use var, let, or const?

They all declare variables, but they behave differently — and those differences can cause bugs if you don’t know the rules.

In this post I’ll explain the differences in very simple words, show short code examples you can run, and give clear rules you can use right away. No heavy jargon — just practical advice for students and early React learners.

🔎 Why this matters

Choosing the right keyword makes your code safer and easier to reason about:

Avoid accidental bugs caused by redeclaration or wrong scope.
Make your intent clear to other developers (and future you).
Reduce runtime errors caused by Temporal Dead Zone (TDZ) or accidental globals.

Knowing a few small rules will help you write cleaner code from day one.

✋ Quick summary (the short rule)

const — use for values that should not be reassigned. Prefer by default.
let — use when you need to change the variable later. Block-scoped.
var — older behaviour, function-scoped, allows redeclaration. Avoid in modern code.

Now let’s see why, with simple examples.

🔬 1) Scope: where the variable lives

`var` — function scope (or global)

function testVar() {
  if (true) {
    var x = 10;
  }
  console.log(x); // 10 — visible outside the if-block
}
testVar();

var ignores block boundaries (like if, for) and belongs to the function scope.

`let` / `const` — block scope

function testLetConst() {
  if (true) {
    let a = 5;
    const b = 6;
  }
  console.log(a); // ReferenceError
  console.log(b); // ReferenceError
}
testLetConst();

let and const are limited to the block { ... } where they are declared.

Rule: prefer block-scoped let/const to avoid accidental leaks outside blocks.

🔁 2) Redeclaration: can you declare the same name twice?

var v = 1;
var v = 2; // allowed — overwrites v

let l = 1;
// let l = 2; // SyntaxError: Identifier 'l' has already been declared

const c = 1;
// const c = 2; // SyntaxError

var allows redeclaration (can cause accidental overwrites).
let and const do not allow redeclaration in the same scope.

Rule: avoid var redeclaration problems by using const / let.

🔄 3) Reassignment: can you change the value?

let x = 1;
x = 2; // OK

const y = 3;
y = 4; // TypeError: Assignment to constant variable.

let allows reassignment.
const does not allow reassigning the variable binding.

Important nuance: const protects the binding, not the value itself for objects.

const obj = { name: "saurav" };
obj.name = "saurav kumar"; // allowed — object content changed
obj = {}; // TypeError — cannot reassign the const binding

Rule: use const for variables that should not be reassigned; for objects you can still mutate properties if needed.

⏳ 4) Temporal Dead Zone (TDZ) — `let` / `const` safety

console.log(z); // ReferenceError
let z = 10;

let/const are hoisted but not initialized until their line runs — the period before initialization is the TDZ. Accessing them early throws an error. var is hoisted and initialized with undefined, so it gives undefined instead.

Rule: TDZ prevents accidental use before initialization — a safety feature.

🔍 5) Global object behavior

In browsers:

var a = 1;
console.log(window.a); // 1

let b = 2;
console.log(window.b); // undefined

Declaring with var at top-level creates a property on the global object (window in browsers). let and const do not. This helps avoid accidental global pollution.

Rule: avoid making globals — use modules and const/let.

✅ When to use what (practical guide)

Start with const: default to const for every variable. It communicates intent: this value should not be reassigned.
Use let when you need to update the variable (loops, counters, changing state).
Avoid var in modern JavaScript. Only use it if you must support very old code or environments.

Example — typical modern code style:

const maxUsers = 10;
let current = 0;

function addUser() {
  if (current < maxUsers) {
    current += 1;
  }
}

⚠️ Common beginner mistakes

Using var for everything → leads to accidental scope leaks and redeclaration bugs.
Expecting const objects to be immutable → const prevents reassigning the variable, but object properties can change.
Accessing let/const before declaration → TDZ errors — put declarations before use.
Relying on global var variables — hard to debug and easy to conflict.

🎯 Small project example (React friendly)

Imagine a small counter component in React:

import React, { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0); // use const for state variable reference
  const step = 1; // step does not change — const

  function increment() {
    setCount((c) => c + step); // we update state with setCount
  }

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={increment}>Add</button>
    </div>
  );
}

Notes:

const [count, setCount] is standard — the binding is constant, state changes through setCount.
Use let for temporary loop counters if needed.

🎯 Interview prep — short & sharp

30s answer:

var is function-scoped and allows redeclaration. let and const are block-scoped; let can be reassigned, const cannot. Prefer const by default and let where reassignment is required. Avoid var in new code.

Show quick examples (these are great on a whiteboard):

// var
var a = 1;
var a = 2; // allowed

// let
let b = 1;
// let b = 2; // not allowed

// const
const c = 1;
// c = 2; // TypeError

Common follow-ups & answers:

Q: Can you mutate a const object? A: Yes — the object contents can change, but you can't reassign the variable.
Q: Why prefer const by default? A: It makes intent clear and prevents accidental reassignments.

Mini whiteboard challenge: Convert a small var-based snippet into const/let style and explain scope differences.

🧠 Key takeaways

Prefer const for values that won't reassign.
Use let for variables that will change.
Avoid var — it has confusing scope and redeclaration rules.
Remember TDZ for let/const.
const prevents reassigning bindings, but object properties can still change.

👋 About Me

Hi, I'm Saurav Kumar — a Software Engineer passionate about building modern web and mobile apps using JavaScript, TypeScript, React, Next.js, and React Native.

I’m exploring how AI tools can speed up development,

and I share beginner-friendly tutorials to help others grow faster.

🔗 Connect with me:

LinkedIn — I share short developer insights and learning tips

GitHub — Explore my open-source projects and experiments

If you found this helpful, share it with a friend learning JavaScript — it might help them too.

Until next time, keep coding and keep learning 🚀

What is Hoisting in JavaScript? Explained for Beginners

SAURAV KUMAR — Tue, 14 Oct 2025 20:54:20 +0000

Imagine a teacher who quickly checks the attendance list before class starts. The teacher notes who is present, then the class begins. JavaScript does something similar: before it runs your code it makes a short pass to note declarations. This behaviour is called hoisting.

Hoisting explains many surprises beginners see — like why var sometimes gives undefined, or why calling a function works even if the function appears later in the file. In this post we will explain hoisting in simple words, show clear code examples, and give short tips you can use right away.

🔎 Why hoisting matters

When JavaScript runs a script it does two small steps for each scope (global or function):

Creation step — it looks for declarations and prepares memory.
Execution step — it runs the code line by line.

Hoisting happens because of that first step. If you know these two steps, many confusing behaviours become easy to understand.

✋ Easy intuition (no hard words)

During the creation step, var names are set up and given the value undefined.
let and const names are known but not ready to use until the code reaches them — this waiting period is called the Temporal Dead Zone (TDZ).
Function declarations are ready in creation step with their full body, so you can call them even before the line where they are written.

🧪 Short examples (see it clearly)

1) `var` example — gives `undefined`

console.log(a); // undefined
var a = 5;
console.log(a); // 5

What happened: JavaScript set up a at the start (with value undefined), then later the assignment a = 5 happened.

2) `let` / `const` — not ready before their line

console.log(b); // ReferenceError
let b = 10;

What happened: b is known to the engine, but it is not usable until the line let b = 10 runs. Accessing it early gives an error.

3) Function declaration — can be called early

greet(); // works: "Hello!"

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

What happened: The whole greet function is set up during the creation step, so it is ready to call even before the code reaches its line.

4) Function expression — not hoisted the same way

sayHi(); // TypeError: sayHi is not a function
var sayHi = function() {
  console.log("Hi");
};

What happened: sayHi was set up as undefined at creation. The function value is only assigned later. So calling it too early causes an error.

🔍 Simple step-by-step of what engine does

Creation step: JavaScript finds declarations.
- var → create name, set to undefined.
- let/const → reserve name, do not set a value yet (TDZ).
- Function declarations → create name and set function value.
Execution step: JavaScript runs the code line by line, doing assignments and calls.

This model is enough to reason about most hoisting cases.

⚠️ Common beginner mistakes (and quick fixes)

Thinking hoisting moves code. It does not rewrite your source — it just prepares memory first. Fix: Read code top to bottom, initialise variables where you use them.
Using var everywhere. var can cause undefined surprises. Fix: Use const by default, let when you must reassign.
Expecting function expressions to be callable early. Only function declarations are available before execution reaches them. Fix: Use function declarations when you need that behaviour, otherwise keep functions close to where they are used.

🚀 Practical rules you can start using

Prefer const for values that do not change, let for values you will change. Avoid var.
Initialise variables near where you use them — it is clearer for readers and for you.
If you need a helper that should be available anywhere in the scope, a function declaration is OK. Otherwise use function expressions for clearer order.

🎯 Bonus: How to explain hoisting in an interview (short and clear)

30-second answer:

Hoisting is the JS engine’s creation step that runs before code execution. var is hoisted and set to undefined. let and const are known but not usable until their line (TDZ). Function declarations are hoisted with their body.

Show quickly: paste this in the interview:

console.log(x); // undefined
var x = 1;

console.log(y); // ReferenceError
let y = 2;

foo(); // works
function foo() { console.log('hi') }

bar(); // TypeError
var bar = function() { console.log('ho') }

Common follow-ups: TDZ meaning, leading practice (const/let), and difference between function declarations and expressions.

🧠 Key takeaways

Hoisting = creation step + execution step.
var → hoisted and initialised as undefined.
let / const → hoisted but not initialised (TDZ) until the line runs.
Function declarations → hoisted with the function body.
Prefer const/let and keep declarations clear and close to use.

👋 About Me

Hi, I'm Saurav Kumar — a Software Engineer building web and mobile apps using JavaScript, TypeScript, React, Next.js, and React Native.
I explore using AI tools to speed up development and I share beginner-friendly tutorials and practical tips.

🔗 Connect with me:

GitHub

If this helped you, please share with a friend learning JavaScript.
Until next time, keep coding and keep learning 🚀

⏱️ Debounce vs Throttle — How to Choose & Build One Mini Project

SAURAV KUMAR — Mon, 13 Oct 2025 12:16:27 +0000

You know the problem: the search box fires too many requests, or scrolling and resize make the UI janky. Two tools fix this: debounce and throttle. The trick is not memorising code — it’s knowing when to use which.

This article gives you:

a short decision checklist to pick the right tool,
a single beginner-friendly mini-project that uses both (so you see the difference),
plain-JS + React code you can copy, and
a short interview prep section.

Let’s be practical and keep things small.

✅ Quick decision checklist — when to use which

Use this checklist first. If you can answer “yes” to a line, follow that rule.

Does the user expect the final value after they stop interacting? → debounce. (search box, autosave, type-to-filter where final query matters)
Do you need regular updates while the user is interacting, capped at a frequency? → throttle. (scroll position updates, resize/layout recalculation, performance telemetry)
Do you need the last event after a burst and regular updates during the burst? → consider throttle + trailing or a combined approach.
Are you protecting server/API costs (many users typing)? → debounce for inputs.
Is the event happening continuously (scroll/resize) and you want a steady stream of updates? → throttle.

Simple rule:

final-value ⇒ debounce
steady-rate ⇒ throttle

Recommended starting delays:

UI inputs (debounce): 250–500ms
scroll/resize (throttle): 100–300ms

🔁 Mini project: PhotoSearch (one app, both tools)

Build a small app with:

a search box that queries (debounced), and
an infinite scroll that loads more photos while the user scrolls (throttled).

This shows both problems in one place — and teaches decision-making by doing.

Plain JavaScript: core helpers

debounce.js

export function debounce(fn, delay = 300) {
  let timer;
  return function (...args) {
    clearTimeout(timer);
    timer = setTimeout(() => fn.apply(this, args), delay);
  };
}

throttle.js

export function throttle(fn, wait = 200) {
  let last = 0;
  return function (...args) {
    const now = Date.now();
    if (now - last >= wait) {
      last = now;
      fn.apply(this, args);
    }
  };
}

PhotoSearch: simple layout (HTML)

<!-- index.html -->
<input id="search" placeholder="Search photos..." />
<div id="gallery" class="gallery"></div>
<script type="module" src="app.js"></script>

styles.css can be a simple grid — use CSS grid with grid-template-columns: repeat(auto-fill, minmax(180px,1fr));.

PhotoSearch: app logic (plain JS)

// app.js
import { debounce } from './debounce.js';
import { throttle } from './throttle.js';

let page = 1;
let query = '';

async function fetchPhotos(q = '', pageNo = 1) {
  // replace with a real API or mock
  console.log('fetching', q, pageNo);
  // example: return fetch(`/api/photos?q=${q}&page=${pageNo}`)
}

const gallery = document.getElementById('gallery');
const input = document.getElementById('search');

const debouncedSearch = debounce((value) => {
  query = value;
  page = 1;
  fetchPhotos(query, page);
  gallery.innerHTML = ''; // reset gallery
}, 400);

input.addEventListener('input', (e) => debouncedSearch(e.target.value));

const handleScroll = throttle(() => {
  if (window.innerHeight + window.scrollY >= document.body.offsetHeight - 200) {
    page++;
    fetchPhotos(query, page);
  }
}, 250);

window.addEventListener('scroll', handleScroll);

// initial load
fetchPhotos();

Why this shows the difference:

Typing triggers many input events; debounce collapses them into one final fetch.
Scrolling fires many events; throttle ensures we load more photos at most once per interval.

⚛️ React: same idea but modular

useDebounce hook

// useDebounce.js
import { useEffect, useState } from 'react';

export default function useDebounce(value, delay = 300) {
  const [debounced, setDebounced] = useState(value);

  useEffect(() => {
    const t = setTimeout(() => setDebounced(value), delay);
    return () => clearTimeout(t);
  }, [value, delay]);

  return debounced;
}

useThrottleRef for scroll

// useThrottleRef.js
import { useEffect, useRef } from 'react';

export default function useThrottleRef(callback, wait = 200) {
  const lastRef = useRef(0);
  const cbRef = useRef(callback);
  cbRef.current = callback;

  useEffect(() => {
    function handler() {
      const now = Date.now();
      if (now - lastRef.current >= wait) {
        lastRef.current = now;
        cbRef.current();
      }
    }
    window.addEventListener('scroll', handler);
    return () => window.removeEventListener('scroll', handler);
  }, [wait]);
}

PhotoSearch component (sketch)

import React, { useState, useEffect } from 'react';
import useDebounce from './useDebounce';
import useThrottleRef from './useThrottleRef';

function PhotoSearch() {
  const [q, setQ] = useState('');
  const debouncedQ = useDebounce(q, 400);
  const [page, setPage] = useState(1);

  useEffect(() => {
    // call API with debouncedQ
    // reset page if debouncedQ changed
    setPage(1);
    // fetchPhotos(debouncedQ, 1)
  }, [debouncedQ]);

  useThrottleRef(() => {
    if (window.innerHeight + window.scrollY >= document.body.offsetHeight - 200) {
      setPage((p) => p + 1);
      // fetchPhotos(debouncedQ, page + 1)
    }
  }, 250);

  return (
    <>
      <input value={q} onChange={(e) => setQ(e.target.value)} placeholder="Search photos..." />
      <div className="gallery">{/* map photos */}</div>
    </>
  );
}

⚠️ Common beginner mistakes — focused checklist

Don’t debounce when you need immediate feedback (e.g., toggles).
Don’t throttle when you need the final value (e.g., final form submit) — or add a trailing call.
Don’t recreate handlers every render — use hooks or memoised helpers.
Always remove event listeners in cleanup (React useEffect return).
Test wait on real devices — 100ms ≠ 100ms on mobile.

🎯 Interview-friendly explanation (short & demo)

30s answer:

Debounce waits for a pause and runs the last event — good for inputs. Throttle runs at most once per interval — good for continuous events like scroll/resize.

Show: paste both helpers side-by-side and explain setTimeout/clearTimeout vs Date.now() timestamp checks.

Follow-ups to expect: leading vs trailing behavior, combining throttle+trailing, SSR concerns, handler identity in React.

Mini challenge: Implement throttle(fn, wait, { leading, trailing }) and explain the timeline.

🧠 Key takeaways (one-liner checklist)

final-value → debounce (search, autosave).
steady updates → throttle (scroll, resize, telemetry).
combined needs → consider throttle with trailing or a hybrid.
test wait on real devices (100–300ms typical).
in React, use hooks and useRef to keep handlers stable.

👋 About Me

Hi, I'm Saurav Kumar — a Software Engineer passionate about building modern web and mobile apps using JavaScript, TypeScript, React, Next.js, and React Native.

I’m exploring how AI tools can speed up development,

and I share beginner-friendly tutorials to help others grow faster.

🔗 Connect with me:

LinkedIn — I share short developer insights and learning tips

GitHub — Explore my open-source projects and experiments

If you found this helpful, share it with a friend learning JavaScript — it might help them too.

Until next time, keep coding and keep learning 🚀

DEV Community: SAURAV KUMAR

Understanding Recursion in JavaScript — Explained in Simple Words

What is recursion?

First, let’s remember what a function is

A function calling itself

So what do we need?

First simple example: print N to 1

Step-by-step dry run

Step 1

Step 2

Two things every recursive function needs

1. Base case

2. Smaller problem

One very common mistake

Easy rule to remember

Now let’s print 1 to N

The simple reason

One small but important idea

What is happening inside memory?

call stack

Head recursion and tail recursion

Head recursion

Tail recursion

Easiest way to remember

Head recursion

Tail recursion

Parameterized recursion

Example: print X, N times

Recursion that returns values

Example 1: Sum of first N numbers

Example 2: Factorial

Example 3: Power

Time complexity of simple recursion

Space complexity of simple recursion

How to solve recursion problems step by step

1. What is the base case?

2. What is the smaller problem?

3. What is the relation?

My simple recursion template

Common beginner mistakes

1. No base case

2. Wrong base case

3. Moving in the wrong direction

4. Mixing printing and returning

5. Using outside variables when not needed

Final thoughts

👋 About Me

Software Design Principles in JavaScript: DRY, KISS, and YAGNI Explained Simply

Why these principles matter

1. DRY: Don’t Repeat Yourself

What DRY means

A simple example without DRY

A better DRY version

Where DRY helps in real projects

When DRY is overused

2. KISS: Keep It Simple, Stupid

What KISS means

An unnecessarily complex example

A simpler version

KISS in everyday JavaScript code

Simple does not mean careless

3. YAGNI: You Aren’t Gonna Need It

What YAGNI means

A simple example

A better version

When YAGNI should not be applied blindly

These principles are helpful, but not absolute

A simple way to remember all three

Interview-friendly explanation

Common mistake developers make

👋 About Me

Inheritance in JavaScript — Explained in Simple Words

🧠 What Is Inheritance?

🤔 Why Do We Need Inheritance?

📦 Parent Class and Child Class

Parent Class

Child Class

⚙️ extends in JavaScript

💻 A Very Simple Example

Output

⚙️ `extends` in JavaScript

🔑 What Is `super()` in JavaScript?

⚠️ Important Rule About `super()`

⬆️ Calling Parent Method with `super`

1. Forgetting `extends`

2. Forgetting `super()` in child constructor

3. Using `this` before `super()`

1. `#accountHolderName` and `#balance` are private fields

3. `getBalance()` gives controlled read access

4. `deposit()` and `withdraw()` control updates