DEV Community: koushikmaya

Building a Notification System with JavaScript EventEmitter and a Queue

koushikmaya — Sun, 30 Aug 2026 07:49:20 +0000

If you are learning JavaScript, you have probably come across things
like events, callbacks, arrays, and DOM manipulation separately.

I recently worked through a small notification system that brought all
of these concepts together. At first, the code looked a little
complicated, especially the EventEmitter part. But once I broke it
down, the whole idea became much easier to understand.

This blog explains the same system in a beginner-friendly way.

What are we trying to build?

Imagine a social media application.

Three things happen:

Alex follows you
Sam likes your post
John comments on your post

We want to show notifications like:

Alex followed you
Sam liked your post
John commented on your post

The important part is that these notifications should appear one after
another, not all at once.

That gives us two main problems to solve:

How do we know when an event happens?
How do we display notifications in the correct order?

The solution is:

EventEmitter + Notification Queue

1. Understanding Events

An event is simply something that happens.

For example:

Someone followed me
Someone liked my post
Someone commented on my post

We can give these events names:

"new-follower"
"like"
"comment"

Instead of directly connecting every part of our application together,
we can say:

"When this event happens, run this function."

This is where an EventEmitter becomes useful.

2. Creating the EventEmitter

Here is the basic structure:

class EventEmitter {
    constructor() {
        this.events = {};
    }
}

A class is basically a blueprint.

When we write:

const notificationEmitter = new EventEmitter();

we create an actual EventEmitter object.

The constructor runs automatically and creates:

this.events = {};

At this point, events is just an empty object:

{}

We will use it to store our event listeners.

3. What is `this`?

If this is your first time working with classes, this can be
confusing.

When we create:

const notificationEmitter = new EventEmitter();

this refers to the object being created.

So:

this.events = {};

is essentially giving our new object an events property.

Conceptually:

notificationEmitter.events = {};

So our object starts like this:

notificationEmitter
        |
        └── events
              |
              └── {}

4. Listening to an Event with `on()`

Now we need a way to listen for events.

That's what the on() method does:

on(eventName, callback) {
    if (!this.events[eventName]) {
        this.events[eventName] = [];
    }

    this.events[eventName].push(callback);
}

For example:

emitter.on("like", handleLike);

This means:

"When the like event happens, remember handleLike."

Here:

"like"

is the event name.

And:

handleLike

is the callback.

5. What is a Callback?

A callback is simply a function that we give to another function so it
can be called later.

For example:

function handleLike() {
    console.log("Someone liked the post");
}

emitter.on("like", handleLike);

We don't write:

emitter.on("like", handleLike());

because that would execute the function immediately.

Instead:

emitter.on("like", handleLike);

means:

"Here is the function. Run it when the like event occurs."

6. Why do we use an Array?

Inside on() we have:

if (!this.events[eventName]) {
    this.events[eventName] = [];
}

Suppose we listen for "like" for the first time.

Initially:

this.events = {};

There is no "like" property.

So we create:

this.events["like"] = [];

Now we can add callbacks:

this.events["like"].push(callback);

Eventually, the object could look like:

{
    like: [functionA, functionB],
    comment: [functionC],
    "new-follower": [functionD]
}

The array is useful because multiple functions can listen to the same
event.

7. Stopping a Listener with `off()`

Sometimes we don't want a function to listen anymore.

That's what off() does:

off(eventName, callback) {
    if (!this.events[eventName]) {
        return;
    }

    this.events[eventName] =
        this.events[eventName].filter(
            (listener) => listener !== callback
        );
}

Suppose we have:

emitter.on("like", handleLike);

Later, we can remove it:

emitter.off("like", handleLike);

The filter() method creates a new array that keeps every listener
except the one we want to remove.

For example:

Before:

[functionA, functionB, functionC]

Remove functionB

After:

[functionA, functionC]

So the easy way to remember it is:

on  → start listening
off → stop listening

8. Triggering an Event with `emit()`

Now comes the most important part.

emit(eventName, data) {
    if (!this.events[eventName]) {
        return;
    }

    this.events[eventName].forEach((callback) => {
        callback(data);
    });
}

emit() means:

"This event happened."

For example:

emitter.emit("like");

means:

"A like happened!"

We can also send information with the event:

emitter.emit("like", {
    name: "Sam"
});

Now the callback receives:

{
    name: "Sam"
}

as its data.

9. How `emit()` Finds the Right Function

Suppose we registered:

emitter.on("like", (data) => {
    console.log(`${data.name} liked your post`);
});

Then we trigger:

emitter.emit("like", {
    name: "Sam"
});

The EventEmitter looks inside:

this.events["like"]

and finds the callback.

Then:

forEach()

goes through the listeners.

Finally:

callback(data);

runs the callback and passes the data to it.

The result is:

Sam liked your post

10. Connecting the EventEmitter to Notifications

Now we can connect the EventEmitter to our notification system.

For a new follower:

notificationEmitter.on(
    "new-follower",
    (data) => {
        addNotification(
            `${data.name} followed you`
        );
    }
);

For a like:

notificationEmitter.on(
    "like",
    (data) => {
        addNotification(
            `${data.name} liked your post`
        );
    }
);

For a comment:

notificationEmitter.on(
    "comment",
    (data) => {
        addNotification(
            `${data.name} commented on your post`
        );
    }
);

Now the EventEmitter doesn't need to know how notifications are
displayed.

It simply triggers the appropriate callback.

The callback creates the notification message.

11. The Notification Queue

Now we have another problem.

What happens if three notifications arrive at almost the same time?

We don't want:

Alex followed you
Sam liked your post
John commented

to all fight for the same space on the screen.

Instead, we use a queue:

const notificationQueue = [];

A queue works like a line.

The first notification that enters should be the first one displayed.

This is called:

FIFO --- First In, First Out

For example:

Alex
Sam
John

Alex goes first, then Sam, then John.

12. Adding Notifications to the Queue

Our function is:

function addNotification(message) {
    notificationQueue.push(message);

    showNextNotification();
}

The first line:

notificationQueue.push(message);

adds the notification to the end of the queue.

For example:

[]

Then:

["Alex followed you"]

Then:

[
    "Alex followed you",
    "Sam liked your post"
]

And finally:

[
    "Alex followed you",
    "Sam liked your post",
    "John commented"
]

So:

push()

means:

Add something to the end.

13. Taking the First Notification

When it's time to display a notification, we use:

const message = notificationQueue.shift();

shift() removes the first item.

For example:

[
    "Alex followed you",
    "Sam liked your post",
    "John commented"
]

After shift():

message = "Alex followed you"

And the queue becomes:

[
    "Sam liked your post",
    "John commented"
]

This is what gives us FIFO behavior.

Remember:

push()  → add to the end
shift() → remove from the beginning

14. Making Sure Only One Notification Shows

We use a simple flag:

let isShowingNotification = false;

This tells us whether a notification is currently visible.

When nothing is showing:

false

When a notification is on screen:

true

This prevents multiple notifications from appearing at the same time.

15. The Important `if` Statement

Inside showNextNotification() we have:

if (
    isShowingNotification ||
    notificationQueue.length === 0
) {
    return;
}

This basically asks two questions:

Is a notification already showing?
Is the queue empty?

If either answer is yes, we stop.

The || means OR.

So in plain English:

"If something is already showing OR there is nothing waiting in the
queue, don't do anything."

This small check is what keeps the queue under control.

16. Creating the Notification in the DOM

Once we're ready to display a notification:

const notification = document.createElement("div");

This creates a new <div> using JavaScript.

Then:

notification.className = "notification-toast";

gives it a CSS class.

And:

notification.textContent = message;

puts the notification message inside it.

Finally:

container.appendChild(notification);

adds it to the webpage.

If the HTML contains:

<div id="notification-container"></div>

we can end up with:

<div id="notification-container">
    <div class="notification-toast">
        Sam liked your post
    </div>
</div>

17. Removing the Notification

We don't want the notification to stay forever.

So we use:

setTimeout(() => {
    notification.remove();

    isShowingNotification = false;

    showNextNotification();
}, 3000);

The 3000 means 3000 milliseconds, or 3 seconds.

So the process is:

Show notification
      ↓
Wait 3 seconds
      ↓
Remove notification
      ↓
Set isShowingNotification to false
      ↓
Show the next notification

This is what makes the notifications appear one after another.

18. Putting Everything Together

Now the complete flow makes much more sense.

Suppose we run:

notificationEmitter.emit(
    "new-follower",
    {
        name: "Alex Developer"
    }
);

The flow is:

emit()
  ↓
Find "new-follower" listener
  ↓
Run callback
  ↓
Create "Alex Developer followed you"
  ↓
addNotification()
  ↓
push() into queue
  ↓
showNextNotification()
  ↓
Display notification

Then:

notificationEmitter.emit(
    "like",
    {
        name: "Sam"
    }
);

creates:

Sam liked your post

If Alex's notification is still visible, Sam's notification waits in the
queue.

Then the comment event creates:

John commented on your post

That also waits.

The final queue might look like:

[
    "Sam liked your post",
    "John commented on your post"
]

Once Alex's notification disappears, Sam appears.

Then John appears.

19. The Full Mental Model

The easiest way I found to understand the project is to think of it as
two systems working together.

EventEmitter

Something happens
       ↓
emit()
       ↓
Find listeners
       ↓
Run callback

Notification Queue

Callback creates message
       ↓
push()
       ↓
Wait in queue
       ↓
shift()
       ↓
Display notification
       ↓
Wait 3 seconds
       ↓
Remove notification
       ↓
Show next one

Together:

User action
    ↓
Event
    ↓
emit()
    ↓
EventEmitter
    ↓
callback
    ↓
addNotification()
    ↓
Queue
    ↓
showNextNotification()
    ↓
DOM
    ↓
3 seconds
    ↓
Remove
    ↓
Next notification

20. What I Learned from This

The biggest lesson for me was that the code looks much more complicated
when everything is viewed at once.

Breaking it into smaller ideas makes it easier:

class creates the EventEmitter blueprint.
on() stores listeners.
off() removes listeners.
emit() triggers listeners.
callback is the function that runs when an event occurs.
push() adds a notification to the queue.
shift() takes the oldest notification out.
setTimeout() controls how long the notification stays visible.
DOM methods create and remove the notification on the page.

Once these pieces are understood individually, the whole notification
system becomes much easier to follow.

Final Takeaway

You don't need to memorize the entire code.

If you're learning this from scratch, focus on these five ideas first:

on()       → listen
emit()     → trigger
callback   → respond
push()     → add to queue
shift()    → take from queue

That's the foundation of this notification system.

And honestly, that's one of the useful things about building small
JavaScript projects: concepts that seem abstract in isolation start
making sense when you see them working together.

# Week 4 - Task 1: Understanding JavaScript Core Concepts

koushikmaya — Sun, 23 Aug 2026 21:39:00 +0000

JavaScript Prototypes, Inheritance, Classes, and Encapsulation

When I first started learning JavaScript objects, prototype, Object.create(), class, inheritance, getters, setters, and private fields felt like completely different topics.

After working through them, I started seeing that most of them are connected through one main idea:

JavaScript objects use prototypes underneath.

This is my beginner-friendly understanding of the topic, with the examples I used while learning.

What I am learning

In this note, I am connecting:

Prototype and prototype chain
Object.create()
Constructor functions
Constructor function + prototype
Inheritance
class and why it works with prototypes
extends and super
Static members
Getters and setters
Encapsulation with closures
Private fields using #
How all these concepts fit together

1. First: What is a Prototype?

A prototype is another object that JavaScript can look at when it cannot find a property or method directly on the current object.

A simple example:

const animal = {
    eat() {
        console.log("Eating");
    }
};

const dog = Object.create(animal);

dog.bark = function () {
    console.log("Barking");
};

dog.bark();
dog.eat();

Output:

Barking
Eating

The important thing is that eat() is not actually inside dog.

JavaScript finds it through dog's prototype.

dog
 ↓
animal
 ↓
Object.prototype
 ↓
null

So I can think of a prototype as:

"If you don't have something, JavaScript can look here next."

2. Prototype Chain

The prototype chain is simply the path JavaScript follows when looking for a property or method.

For example:

const person = {
    name: "Koushik"
};

console.log(person.toString());

I never created toString() inside person.

So how does it work?

JavaScript searches:

person
 ↓
Object.prototype
 ↓
null

toString() is found on Object.prototype.

Property lookup in simple steps

When I write:

object.someProperty

JavaScript roughly does this:

Look inside object.
If it finds the property, use it.
If not, look at the object's prototype.
Keep moving up the prototype chain.
If it reaches null, the property was not found.

For example:

const animal = {
    eat() {
        console.log("Eating");
    }
};

const dog = Object.create(animal);

dog.eat();

The search is:

dog
 ↓
animal          ← eat() found here
 ↓
Object.prototype
 ↓
null

3. `prototype` vs `proto`

These names confused me at first, so I keep this distinction clear.

`prototype`

prototype is commonly seen with constructor functions and classes.

Example:

function Person(name) {
    this.name = name;
}

Person.prototype.sayHello = function () {
    console.log(`Hello ${this.name}`);
};

const person = new Person("Koushik");

person.sayHello();

The object created by new Person() can find sayHello() through:

Person.prototype

The chain is:

person
 ↓
Person.prototype
 ↓
Object.prototype
 ↓
null

`proto`

__proto__ gives access to an object's actual prototype.

console.log(person.__proto__ === Person.prototype);

Output:

true

For modern code, I should prefer:

Object.getPrototypeOf(person);

instead of directly using __proto__.

4. `Object.create()`

Object.create() creates a new object and lets me choose its prototype.

Syntax:

Object.create(prototype);

Example:

const animal = {
    eat() {
        console.log("Eating");
    }
};

const dog = Object.create(animal);

dog.bark = function () {
    console.log("Barking");
};

dog.eat();
dog.bark();

The relationship is:

dog
 ↓
animal

This is the simplest form of object-to-object inheritance.

My simple way of remembering it

const child = Object.create(parent);

means:

"Create a new object whose prototype is parent."

5. `Object.create()` Inheritance

This is the first inheritance pattern I learned.

const obj = {
    name: "Koushik",
    age: 25,

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

const obj2 = Object.create(obj);

obj2.getage = function () {
    console.log(`My age is ${this.age}`);
};

obj2.getinfo();
obj2.getage();

Here:

obj2
 ↓
obj

obj2 can use getinfo() because JavaScript finds it in obj.

So this is:

Object-to-object inheritance.

This is simple and useful when I already have an object that I want another object to be based on.

6. Constructor Functions

Before understanding inheritance with constructor functions, I first need to understand what a constructor function does.

Example:

function Bike(company, colour, cc) {
    this.company = company;
    this.colour = colour;
    this.cc = cc;
}

I can think of this as a blueprint.

Then:

const bike1 = new Bike("Yamaha", "Blue", 1000);

creates an object.

Conceptually:

bike1
├── company → "Yamaha"
├── colour  → "Blue"
└── cc      → 1000

The new keyword is important because it creates a new object and connects that object to Bike.prototype.

7. Constructor Function + Prototype

Now I can add methods to the prototype.

My example:

function Bike(company, colour, cc) {
    this.company = company;
    this.colour = colour;
    this.cc = cc;
}

Bike.prototype.fun = function () {
    console.log(
        "Hi, is this " +
        this.company + " " +
        this.colour +
        " colour bike. This looks good. Is this " +
        this.cc + "?"
    );
};

const bike1 = new Bike("Yamaha", "Blue", 1000);

bike1.fun();

The important thing is that fun() is on:

Bike.prototype

not copied directly into every object.

The chain is:

bike1
 ↓
Bike.prototype
 ↓
Object.prototype
 ↓
null

When I call:

bike1.fun();

JavaScript looks for fun().

It checks:

bike1                 → not found
Bike.prototype        → found

So the method runs.

8. Important: Constructor + Prototype Is Not Automatically Inheritance

This was an important distinction for me.

If I write:

function Bike(company, colour, cc) {
    this.company = company;
    this.colour = colour;
    this.cc = cc;
}

Bike.prototype.fun = function () {
    console.log("Bike method");
};

const bike1 = new Bike("Yamaha", "Blue", 1000);

I have:

A constructor function
A prototype
An instance

But I do not yet have a parent-child inheritance relationship.

The chain is only:

bike1
 ↓
Bike.prototype
 ↓
Object.prototype
 ↓
null

Actual constructor-function inheritance needs a second constructor.

9. Constructor Function + Prototype Inheritance

Now I can make:

Bike
 ↓
SuperBike

Here is my example:

function Bike(company, colour, cc) {
    this.company = company;
    this.colour = colour;
    this.cc = cc;
}

Bike.prototype.fun = function () {
    console.log(
        "Hi, is this " +
        this.company + " " +
        this.colour +
        " colour bike. This looks good. Is this " +
        this.cc + "?"
    );
};


function SuperBike(company, colour, cc, topspeed) {

    Bike.call(this, company, colour, cc);

    this.topspeed = topspeed;
}


// Actual prototype inheritance
SuperBike.prototype = Object.create(Bike.prototype);


// SuperBike's own method
SuperBike.prototype.showSpeed = function () {
    console.log(
        this.company +
        " has a top speed of " +
        this.topspeed +
        " km/h"
    );
};


const bike1 = new SuperBike(
    "Yamaha",
    "Blue",
    1000,
    300
);

bike1.fun();
bike1.showSpeed();

Where does inheritance actually happen?

This line:

SuperBike.prototype = Object.create(Bike.prototype);

is the important inheritance line.

It creates:

bike1
 ↓
SuperBike.prototype
 ↓
Bike.prototype
 ↓
Object.prototype
 ↓
null

So:

bike1.fun();

works because JavaScript eventually finds fun() in Bike.prototype.

10. Why `Bike.call()`?

This line:

Bike.call(this, company, colour, cc);

handles the parent's properties.

The parent constructor has:

function Bike(company, colour, cc) {
    this.company = company;
    this.colour = colour;
    this.cc = cc;
}

When Bike.call(this, ...) runs inside SuperBike, this refers to the new SuperBike object.

So it effectively sets:

this.company = company;
this.colour = colour;
this.cc = cc;

Then SuperBike adds:

this.topspeed = topspeed;

So I remember the pattern like this:

Bike.call(...)
      ↓
Get parent's properties

Object.create(Bike.prototype)
      ↓
Get parent's prototype methods

11. `Object.create()` vs Constructor Inheritance

This was one of the things I wanted to understand clearly.

`Object.create()`

const child = Object.create(parent);

This is:

"Make this object inherit from that object."

Simple object-to-object inheritance.

Constructor + prototype

function Parent() {}

Parent.prototype.method = function () {};

const child = new Parent();

This is mainly:

"Create many instances from a constructor and share methods through the prototype."

It is not automatically parent-child inheritance.

Actual constructor inheritance

Child.prototype = Object.create(Parent.prototype);

Now I have:

Child
 ↓
Parent

So I do not need to think of Object.create() and constructor inheritance as unrelated topics.

Object.create() is actually part of the old-style inheritance pattern.

12. Classes

Modern JavaScript gives us class.

Example:

class Bike {
    constructor(company, colour, cc) {
        this.company = company;
        this.colour = colour;
        this.cc = cc;
    }

    fun() {
        console.log(
            `This is a ${this.colour} ${this.company} bike`
        );
    }
}

const bike1 = new Bike("Yamaha", "Blue", 1000);

bike1.fun();

This looks very different from:

function Bike(company, colour, cc) {
    this.company = company;
    this.colour = colour;
    this.cc = cc;
}

Bike.prototype.fun = function () {
    // ...
};

But the important thing is:

Classes still use prototypes underneath.

The class method is placed on:

Bike.prototype

rather than copied separately into every instance.

So:

class syntax
     ↓
prototype system underneath

This is why classes are often described as syntactic sugar over the prototype-based system.

13. Class Inheritance with `extends`

With classes, inheritance becomes much cleaner.

class Bike {
    constructor(company, colour) {
        this.company = company;
        this.colour = colour;
    }

    ride() {
        console.log(`${this.company} is riding`);
    }
}

class SuperBike extends Bike {
    showSpeed() {
        console.log("Top speed is 300 km/h");
    }
}

const bike = new SuperBike("Yamaha", "Blue");

bike.ride();
bike.showSpeed();

The inheritance chain is approximately:

bike
 ↓
SuperBike.prototype
 ↓
Bike.prototype
 ↓
Object.prototype
 ↓
null

So bike.ride() works even though ride() is defined in Bike.

14. `super`

super is used when I want to work with the parent class.

Example:

class Bike {
    constructor(company, colour) {
        this.company = company;
        this.colour = colour;
    }
}

class SuperBike extends Bike {
    constructor(company, colour, speed) {
        super(company, colour);
        this.speed = speed;
    }
}

This:

super(company, colour);

calls the parent constructor.

It is similar in purpose to:

Bike.call(this, company, colour);

in constructor-function inheritance.

One important rule:

In a derived class constructor, super() must be called before using this.

15. Static Members

A normal method belongs to an instance:

class Bike {
    show() {
        console.log("Bike");
    }
}

const bike = new Bike();

bike.show();

A static method belongs to the class itself:

class Bike {
    static info() {
        console.log("Bike information");
    }
}

Bike.info();

I should not do:

const bike = new Bike();

bike.info(); // ❌

because info() is static.

Static property

class Bike {
    static wheels = 2;
}

console.log(Bike.wheels);

The important difference is:

Normal method
     ↓
instance

Static method
     ↓
class itself

16. Static with Constructor Functions

I can also create a static-like member with a constructor function.

function Bike(company) {
    this.company = company;
}

Bike.info = function () {
    console.log("Bike information");
};

Bike.info();

Here info is attached directly to Bike.

I don't use:

const bike = new Bike("Yamaha");

bike.info(); // ❌

The main idea is:

Bike.info()
    ↓
belongs to Bike itself

bike.info()
    ↓
looks for an instance method

For modern JavaScript, I will usually see the static keyword with classes.

17. Getters

A getter lets me read a method like a property.

Without a getter:

class User {
    constructor(firstName, lastName) {
        this.firstName = firstName;
        this.lastName = lastName;
    }

    getFullName() {
        return `${this.firstName} ${this.lastName}`;
    }
}

const user = new User("Koushik", "Maya");

console.log(user.getFullName());

I have to use:

user.getFullName();

With a getter:

class User {
    constructor(firstName, lastName) {
        this.firstName = firstName;
        this.lastName = lastName;
    }

    get fullName() {
        return `${this.firstName} ${this.lastName}`;
    }
}

const user = new User("Koushik", "Maya");

console.log(user.fullName);

Now I use:

user.fullName

not:

user.fullName()

The simple meaning is:

get → when I READ the property, run this code

18. Getters and Setters — My Age Example

This is the example that helped me understand getters and setters.

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

    get age() {
        return this._age;
    }

    set age(newAge) {
        if (newAge < 0) {
            console.log("Age cannot be negative");
            return;
        }

        this._age = newAge;
    }
}

const p1 = new Person("Koushik", 25);

console.log(p1.age);

p1.age = 26;

console.log(p1.age);

Output:

25
26

What is happening?

When I write:

console.log(p1.age);

I am reading age.

So the getter runs:

get age() {
    return this._age;
}

It returns:

Then when I write:

p1.age = 26;

I am setting/changing age.

So the setter runs:

set age(newAge) {

Here:

newAge = 26

The condition:

if (newAge < 0)

is false.

So:

this._age = newAge;

changes the stored value to:

_age = 26

When I read it again:

console.log(p1.age);

the getter returns 26.

19. Why `_age`?

I use:

this._age

as the internal storage.

The _ is only a convention. It does not make the property private.

So this is still possible:

console.log(p1._age);

The idea is:

_age
 ↓
internal storage

age
 ↓
getter/setter interface

This also prevents a common problem.

If I wrote:

set age(newAge) {
    this.age = newAge;
}

the setter would call itself again and again.

So instead I store the actual value in:

this._age

20. Setter = Validation and Controlled Changes

A setter becomes especially useful when I need to control what values are allowed.

For example:

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

    get balance() {
        return this._balance;
    }

    set balance(amount) {
        if (amount < 0) {
            console.log("Balance cannot be negative");
            return;
        }

        this._balance = amount;
    }
}

Now:

account.balance = 5000;

is allowed.

But:

account.balance = -5000;

is rejected.

So:

Getter
  ↓
Controls reading

Setter
  ↓
Controls changing

21. Encapsulation

Encapsulation means keeping internal implementation details controlled instead of exposing everything directly.

For example, this is very open:

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

Someone can do:

account.balance = 999999;

There is no validation.

JavaScript gives me different ways to keep internal state controlled.

The two important approaches here are:

Closures
Private class fields using #

22. Encapsulation with Closures

A closure allows a function to remember variables from its outer scope.

Example:

function BankAccount(initialBalance) {

    let balance = initialBalance;

    return {
        deposit(amount) {
            if (amount <= 0) {
                throw new Error("Invalid amount");
            }

            balance += amount;
        },

        withdraw(amount) {
            if (amount > balance) {
                throw new Error("Insufficient balance");
            }

            balance -= amount;
        },

        getBalance() {
            return balance;
        }
    };
}

Create an account:

const account = BankAccount(1000);

Use it:

account.deposit(500);

console.log(account.getBalance());

Output:

But:

console.log(account.balance);

returns:

undefined

Why?

Because balance is not a property of account.

It is a variable inside the BankAccount() function.

The returned functions remember it.

Conceptually:

BankAccount()
     │
     ├── balance = 1000   ← hidden
     │
     ├── deposit()
     ├── withdraw()
     └── getBalance()
              │
              └── can access balance

This is closure-based encapsulation.

23. Private Fields with `#`

Modern JavaScript gives us actual private class fields.

class BankAccount {
    #balance;

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

    deposit(amount) {
        this.#balance += amount;
    }

    getBalance() {
        return this.#balance;
    }
}

Use it:

const account = new BankAccount(1000);

account.deposit(500);

console.log(account.getBalance());

Output:

But this is not allowed:

console.log(account.#balance);

#balance is actually private to the class.

24. `_field` vs `#field`

This distinction is very important.

this._balance

means:

"I intend this to be an internal property."

But JavaScript does not enforce that.

Someone can still do:

account._balance;

Whereas:

this.#balance

is a real private field.

So:

_balance
   ↓
Convention only

#balance
   ↓
Actual JavaScript private field

25. Private Methods

Methods can also be private.

class BankAccount {
    #balance = 1000;

    #validateAmount(amount) {
        return amount > 0;
    }

    deposit(amount) {
        if (!this.#validateAmount(amount)) {
            throw new Error("Invalid amount");
        }

        this.#balance += amount;
    }
}

This method:

#validateAmount()

can only be used inside the class.

Outside code cannot call:

account.#validateAmount(100);

26. Closures vs Private Fields

Both can hide internal state.

Closure

function Counter() {
    let count = 0;

    return {
        increment() {
            count++;
        },

        getCount() {
            return count;
        }
    };
}

Here count is hidden inside the function scope.

Private field

class Counter {
    #count = 0;

    increment() {
        this.#count++;
    }

    getCount() {
        return this.#count;
    }
}

Here #count is private because JavaScript enforces the private-field rule.

My simple distinction:

Closure
   ↓
private variable in lexical scope

#field
   ↓
JavaScript-enforced private class field

27. One Complete Example

Now I can combine the concepts:

Class
Inheritance
static
Getter
Setter
Private field

class Person {

    static species = "Human";

    #age;

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

    get age() {
        return this.#age;
    }

    set age(value) {
        if (value < 0) {
            throw new Error("Age cannot be negative");
        }

        this.#age = value;
    }

    introduce() {
        console.log(
            `My name is ${this.name} and I am ${this.#age} years old.`
        );
    }
}


class Student extends Person {

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

    study() {
        console.log(
            `${this.name} is studying ${this.course}`
        );
    }
}


const student = new Student(
    "Koushik",
    22,
    "JavaScript"
);

student.introduce();
student.study();

console.log(student.age);

student.age = 23;

console.log(student.age);

console.log(Person.species);

Output:

My name is Koushik and I am 22 years old.
Koushik is studying JavaScript
22
23
Human

28. Understanding the Prototype Chain in This Example

When I write:

const student = new Student(
    "Koushik",
    22,
    "JavaScript"
);

the object is connected to prototypes roughly like this:

student
 ↓
Student.prototype
 ↓
Person.prototype
 ↓
Object.prototype
 ↓
null

If I call:

student.study();

JavaScript finds study() on:

Student.prototype

If I call:

student.introduce();

JavaScript searches:

student
 ↓
Student.prototype
 ↓
Person.prototype       ← introduce() found

This is what is happening underneath class inheritance.

29. Where Does `#age` Fit?

The private field is used inside the getter and setter.

Getter:

get age() {
    return this.#age;
}

So:

console.log(student.age);

flows like:

student.age
    ↓
get age()
    ↓
this.#age
    ↓
private value

When I write:

student.age = 23;

the setter runs:

student.age = 23
    ↓
set age(value)
    ↓
validate value
    ↓
this.#age = 23

So the getter/setter gives me controlled access to the private field.

30. Prototype Methods vs Instance Properties

This is another important distinction.

Consider:

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

    greet() {
        console.log(`Hello ${this.name}`);
    }
}

Each object has its own:

name

But greet() is shared through:

User.prototype

Conceptually:

user1 ─────┐
           │
user2 ─────┼──→ User.prototype → greet()
           │
user3 ─────┘

This is one reason prototypes are important.

The method does not need to be separately recreated on every instance.

31. My Final Mental Model

This is how I now connect the topics:

                    JavaScript Objects
                           │
                           ▼
                    Prototype System
                           │
              ┌────────────┴────────────┐
              ▼                         ▼
       Prototype Chain            Object.create()
              │
              ▼
           Classes
              │
        ┌─────┴─────┐
        ▼           ▼
     extends      static
        │
        ▼
      super

For controlling internal state:

                Encapsulation
                     │
             ┌───────┴────────┐
             ▼                ▼
         Closures          #private
             │                │
             └───────┬────────┘
                     ▼
              Controlled Data
                     │
              ┌──────┴──────┐
              ▼             ▼
           getter         setter

32. The Main Things I Need to Remember

Prototype

An object can look at another object for properties/methods.

Prototype chain

JavaScript searches from the object upward until it finds the property.

`Object.create()`

const child = Object.create(parent);

Creates an object whose prototype is parent.

Constructor function

function Bike(...) {}

Acts like a blueprint for creating objects with new.

Constructor + prototype

Bike.prototype.method = function () {};

Stores a shared method on the prototype.

Constructor inheritance

Child.prototype = Object.create(Parent.prototype);

Creates the parent-child prototype relationship.

`class`

class Bike {}

Provides cleaner syntax while still using prototypes underneath.

`extends`

class SuperBike extends Bike {}

Creates class inheritance.

`super`

super(...);

Accesses the parent constructor or parent method.

`static`

static info() {}

Belongs to the class itself, not its instances.

Getter

get age() {}

Runs when I read:

person.age

Setter

set age(value) {}

Runs when I write:

person.age = value;

`_field`

_age

Convention only. Not truly private.

`#field`

#age

Actual JavaScript private field.

Closure

A function can remember variables from its outer scope.

Conclusion

The biggest thing I learned is that these features are not random, separate JavaScript concepts.

The prototype system is the foundation.

Object
  ↓
Prototype
  ↓
Prototype Chain
  ↓
Inheritance
  ↓
Classes

And for controlling internal state:

Encapsulation
    ├── Closures
    └── Private fields (#field)

Getters and setters can then provide a controlled way to access that state:

getter → read
setter → change

The most important idea for me is:

JavaScript classes do not replace prototypes. Classes provide cleaner syntax for working with JavaScript's prototype-based object system.

And the privacy rule I want to remember is:

_field is a convention, while #field provides actual private class fields.

If I understand the prototype chain first, the rest of JavaScript's object-oriented features become much easier to understand.

# Week 3 - Task 2: Understanding JavaScript Core Concepts

koushikmaya — Fri, 21 Aug 2026 20:37:04 +0000

JavaScript Event Loop Explained: Call Stack, Web APIs, Queues, Promises and setTimeout

If you've ever looked at JavaScript code like this:

console.log("Start");

setTimeout(() => {
  console.log("Timeout");
}, 0);

Promise.resolve().then(() => {
  console.log("Promise");
});

console.log("End");

and wondered:

"Why does Promise run before setTimeout, even though the timer is 0ms?"

You're not alone.

To understand this, we need to understand a few important JavaScript concepts:

Call Stack
Web APIs / Node.js APIs
Callback Queue
Macrotasks
Microtask Queue
Event Loop
Promises
setTimeout()

Once these pieces fit together, asynchronous JavaScript becomes much easier to reason about.

1. Is JavaScript really single-threaded?

JavaScript code is executed by an execution environment that processes one piece of JavaScript at a time on a given thread.

That means JavaScript doesn't normally execute two JavaScript functions simultaneously on the same execution thread.

So if we write:

console.log("A");
console.log("B");
console.log("C");

the execution happens in order:

A
B
C

This is possible because JavaScript uses a Call Stack to keep track of what is currently executing.

But then we have a problem.

What happens when JavaScript needs to wait for:

a timer?
a network request?
a file operation?
a user click?
some other asynchronous operation?

JavaScript shouldn't freeze the entire application while waiting.

This is where the runtime environment and event loop come in.

2. The Call Stack

The Call Stack is a data structure used to keep track of JavaScript execution contexts.

It follows the LIFO principle:

Last In, First Out.

Consider:

function first() {
  console.log("First");
}

function second() {
  console.log("Second");
}

first();
second();

When first() is called, it is placed on the stack.

Call Stack

┌─────────────┐
│   first()   │
└─────────────┘

Inside first(), console.log() is executed.

Once first() finishes, it is removed from the stack.

Then second() is executed.

first()
  ↓
console.log()
  ↓
first() finishes
  ↓
second()
  ↓
console.log()
  ↓
second() finishes

The Call Stack is therefore responsible for what JavaScript is executing right now.

Simple definition

The Call Stack is a LIFO structure that keeps track of currently executing JavaScript functions.

3. What happens with asynchronous code?

Now consider:

console.log("Start");

setTimeout(() => {
  console.log("Hello");
}, 1000);

console.log("End");

A common beginner assumption is:

Start
wait 1 second
Hello
End

But that's not what happens.

The output is:

Start
End
Hello

Why?

Because JavaScript doesn't keep the setTimeout() callback on the Call Stack for one second.

Instead, the timer is handled by the surrounding runtime environment.

In a browser, this involves Web APIs.

In Node.js, the runtime provides its own APIs and event-loop mechanisms for timers, I/O, and other asynchronous work.

4. Web APIs

When JavaScript runs inside a browser, the browser provides APIs that JavaScript can use.

These include things such as:

setTimeout()
setInterval()
fetch()
DOM events
XMLHttpRequest

These capabilities are provided by the browser environment rather than being implemented as ordinary JavaScript functions inside your program.

For example:

setTimeout(() => {
  console.log("Hello");
}, 1000);

Conceptually:

JavaScript
    │
    │ setTimeout()
    ▼
Browser runtime
    │
    │ waits for timer
    ▼
Callback becomes eligible

Meanwhile, JavaScript can continue executing:

console.log("This runs immediately");

That's one of the reasons asynchronous programming is so important in JavaScript.

5. Node.js APIs

When JavaScript runs in Node.js, there is no browser providing Web APIs.

Instead, Node.js provides runtime APIs and an event-loop implementation for things such as:

timers
file system operations
networking
other I/O operations

For example:

const fs = require("fs");

fs.readFile("data.txt", "utf8", (err, data) => {
  console.log(data);
});

console.log("Reading file...");

The file operation can be handled by the Node.js runtime while JavaScript continues executing other code.

So a useful mental model is:

Browser JavaScript
        ↓
Browser APIs

Node.js JavaScript
        ↓
Node.js APIs / runtime

The exact internals differ between browsers and Node.js, so it's better not to think of the browser and Node.js event loops as identical implementations.

6. Callback Queue

When an asynchronous operation finishes, the callback needs somewhere to wait until JavaScript can execute it.

This is where task queues come into the picture.

For example:

setTimeout(() => {
  console.log("Timer finished");
}, 0);

Once the timer is eligible, its callback can be queued as a task.

A simplified mental model looks like:

Timer
  │
  ▼
Task Queue
  │
  ▼
Event Loop
  │
  ▼
Call Stack

You may hear this queue called the Callback Queue, Task Queue, or Macrotask Queue.

Strictly speaking, the modern web platform uses the terminology tasks and microtasks rather than treating everything as one generic "callback queue."

7. What is a Macrotask?

The term macrotask is commonly used by developers when discussing tasks such as timer callbacks.

For example:

setTimeout(() => {
  console.log("Hello");
}, 0);

The callback is scheduled as a task.

Other examples can include callbacks associated with:

setTimeout()
setInterval()
user events
some I/O operations

The exact task scheduling behavior depends on the runtime and API involved.

A simplified model is:

Macrotask / Task Queue

┌──────────────────────┐
│ setTimeout callback  │
├──────────────────────┤
│ event callback       │
├──────────────────────┤
│ another task         │
└──────────────────────┘

8. What is a Microtask?

Now we get to the interesting part.

A microtask is a type of asynchronous work that is processed at specific points in the event loop, before the runtime proceeds to the next task.

Promises use the microtask queue for their reaction callbacks.

For example:

Promise.resolve().then(() => {
  console.log("Promise");
});

The function passed to .then() does not execute immediately.

Instead, it is scheduled as a microtask.

Other ways to create microtasks include:

queueMicrotask(() => {
  console.log("Microtask");
});

The simplified picture is:

Microtask Queue

┌─────────────────────┐
│ Promise.then()      │
├─────────────────────┤
│ Promise.catch()     │
├─────────────────────┤
│ queueMicrotask()    │
└─────────────────────┘

9. Why do Promises run before setTimeout?

This is the question that usually makes the event loop finally "click."

Consider:

console.log("Start");

setTimeout(() => {
  console.log("setTimeout");
}, 0);

Promise.resolve().then(() => {
  console.log("Promise");
});

console.log("End");

The output is:

Start
End
Promise
setTimeout

Let's understand why.

Step 1: Synchronous code

First:

console.log("Start");

prints:

Start

Then:

setTimeout(..., 0);

schedules a timer callback.

Promise.resolve().then(...);

schedules the Promise reaction as a microtask.

Finally:

console.log("End");

prints:

End

So the synchronous output is:

Start
End

10. What is waiting in the queues?

After the synchronous code finishes, conceptually we have:

Microtask Queue

Promise

and:

Task / Macrotask Queue

setTimeout

The runtime processes the microtask queue before moving on to the next task.

Therefore:

Promise

runs first.

Then:

setTimeout

runs.

Final output:

Start
End
Promise
setTimeout

MDN describes Promise callbacks as microtasks and setTimeout() callbacks as tasks, with microtasks processed before the next task.

11. `setTimeout(..., 0)` does NOT mean "run immediately"

This is an important misconception.

When you write:

setTimeout(() => {
  console.log("Hello");
}, 0);

0 does not mean:

Execute this function right now.

It means the timer is configured with a zero-millisecond delay, after which the callback becomes eligible to be scheduled.

The callback still has to wait for the current JavaScript execution to finish and for the event loop to reach that task.

For example:

console.log("A");

setTimeout(() => {
  console.log("B");
}, 0);

console.log("C");

Output:

A
C
B

The timer doesn't interrupt the currently running JavaScript.

12. Promises don't execute immediately either

There's another important misconception.

Some developers see:

Promise.resolve().then(() => {
  console.log("Promise");
});

and think the callback runs immediately because the Promise is already resolved.

It doesn't.

Consider:

Promise.resolve().then(() => {
  console.log("Promise");
});

console.log("Normal");

Output:

Normal
Promise

The .then() callback is scheduled as a microtask.

MDN explicitly notes that Promise .then() callbacks are not called synchronously, even when the Promise is already resolved.

13. The Event Loop

The Event Loop is the mechanism that coordinates JavaScript execution with queued tasks and microtasks.

A simplified model is:

              ┌───────────────┐
              │  Call Stack   │
              └───────┬───────┘
                      │
                      ▼
              Stack becomes empty
                      │
                      ▼
             ┌─────────────────┐
             │ Microtask Queue │
             └────────┬────────┘
                      │
                Drain microtasks
                      │
                      ▼
             ┌─────────────────┐
             │   Task Queue    │
             └────────┬────────┘
                      │
                 Run a task
                      │
                      ▼
             Drain microtasks
                      │
                      ▼
                 Next task

The important idea is:

The runtime doesn't simply alternate between "stack" and "queue." After a task finishes, pending microtasks are processed before the next task is taken.

MDN describes the event loop as processing a task and then pending microtasks, with newly queued microtasks also being processed before moving on.

14. A More Interesting Example

Let's make things slightly harder:

console.log("1");

setTimeout(() => {
  console.log("2");
}, 0);

Promise.resolve().then(() => {
  console.log("3");
});

Promise.resolve().then(() => {
  console.log("4");
});

console.log("5");

What will be printed?

First, synchronous code:

1
5

Then microtasks:

3
4

Then the timer:

So the final output is:

The key is not to memorize the output.

Instead, identify where each callback goes.

console.log("1")
        ↓
Synchronous

setTimeout(...)
        ↓
Task

Promise.then(...)
        ↓
Microtask

Promise.then(...)
        ↓
Microtask

console.log("5")
        ↓
Synchronous

15. Microtasks Can Create More Microtasks

This is where the event loop gets even more interesting.

Consider:

setTimeout(() => {
  console.log("A");
}, 0);

Promise.resolve().then(() => {
  console.log("B");

  Promise.resolve().then(() => {
    console.log("C");
  });
});

Output:

B
C
A

Why?

Initially:

Microtask Queue:
B

Task Queue:
A

The microtask B runs:

While running B, another Promise callback is created:

Microtask Queue:
C

The runtime continues processing microtasks until the microtask queue is empty.

So:

runs before the timer.

Finally:

runs.

MDN notes that newly added microtasks are processed before the next task, which is also why continuously creating microtasks can potentially prevent the runtime from reaching later tasks.

16. A Macrotask Can Create a Microtask

Now reverse the situation:

setTimeout(() => {
  console.log("A");

  Promise.resolve().then(() => {
    console.log("B");
  });
}, 0);

setTimeout(() => {
  console.log("C");
}, 0);

Output:

A
B
C

Why isn't it:

A
C
B

When the first timer runs:

it creates a Promise microtask.

That microtask is processed before the runtime proceeds to the next task:

A
B
C

This is one of the most useful patterns to understand when debugging asynchronous JavaScript.

17. A Complete Example

Consider this:

console.log("A");

setTimeout(() => {
  console.log("B");

  Promise.resolve().then(() => {
    console.log("C");
  });
}, 0);

Promise.resolve().then(() => {
  console.log("D");

  setTimeout(() => {
    console.log("E");
  }, 0);
});

console.log("F");

Let's trace it.

First: synchronous code

A
F

Then: microtask

During D, another timer is scheduled:

Next: first timer

During B, another Promise microtask is created.

So:

runs before the next timer.

Finally:

The output is:

A
F
D
B
C
E

18. The Mental Model I Use

When I see asynchronous JavaScript, I don't try to guess the output immediately.

I ask three questions:

Question 1: Is this synchronous?

If yes, it runs on the Call Stack immediately.

Question 2: If it's asynchronous, which queue does it use?

For example:

Promise.then()
        ↓
Microtask

setTimeout()
        ↓
Task / Macrotask

Question 3: Are there microtasks waiting?

After a task completes, microtasks are processed before the next task.

This makes complicated examples much easier to solve.

19. Quick Comparison

Feature	Call Stack	Microtask Queue	Task / Macrotask Queue
Purpose	Execute current JS	Schedule microtasks	Schedule tasks
Examples	Function calls	Promise callbacks	`setTimeout()`
Executes	Immediately while active	After current task/stack	During a later event-loop iteration
Priority	Current execution	Before next task	After microtasks
Can contain Promise callbacks?	No	Yes	No
Can contain timer callbacks?	No	No	Yes

20. The Most Important Ordering Rule

If you remember only one thing from this article, remember this:

Synchronous JavaScript
        ↓
Microtasks
        ↓
Next Task
        ↓
Microtasks
        ↓
Next Task

Or, more practically:

Promise.then()
        ↓
before
        ↓
setTimeout()

when both are scheduled during the same synchronous turn.

This is why:

setTimeout(() => {
  console.log("Timeout");
}, 0);

Promise.resolve().then(() => {
  console.log("Promise");
});

produces:

Promise
Timeout

21. Common Mistakes

Mistake 1: "0ms means immediate"

setTimeout(fn, 0);

❌ Not immediate.

It schedules a task that can run after the timer becomes eligible and the event loop gets to it.

Mistake 2: "Promises are synchronous"

Promise.resolve().then(fn);

❌ The .then() callback is asynchronous.

It is scheduled as a microtask.

Mistake 3: "The event loop executes everything at once"

❌ JavaScript execution on a given thread proceeds one job/task at a time.

The event loop coordinates when queued work gets a chance to execute.

Mistake 4: "Every asynchronous callback goes into the same queue"

❌ Not quite.

The runtime distinguishes between tasks and microtasks, and their scheduling rules differ.

Promises use microtasks, while timer callbacks such as setTimeout() are tasks.

22. Final Cheat Sheet

CALL STACK
→ Where current JavaScript executes.

WEB APIs
→ Browser-provided asynchronous capabilities.

NODE.JS APIs
→ Runtime APIs for Node.js timers, I/O, networking, etc.

CALLBACK
→ A function that can be invoked later.

TASK / MACROTASK
→ A scheduled unit of work such as a timer callback.

MICROTASK
→ High-priority queued work processed before the next task.

MICROTASK QUEUE
→ Where Promise reaction callbacks are scheduled.

EVENT LOOP
→ Coordinates execution of tasks and microtasks.

PROMISE
→ Represents the eventual completion or failure of an asynchronous operation.

setTimeout()
→ Schedules a timer callback as a task.

PROMISE.then()
→ Schedules a reaction callback as a microtask.

And the core ordering:

┌─────────────────────┐
│ Synchronous Code    │
└──────────┬──────────┘
           ↓
┌─────────────────────┐
│ Microtask Queue     │
│ Promise.then()      │
│ Promise.catch()     │
│ queueMicrotask()    │
└──────────┬──────────┘
           ↓
┌─────────────────────┐
│ Task Queue          │
│ setTimeout()        │
│ events / other tasks│
└──────────┬──────────┘
           ↓
     Microtasks again
           ↓
       Next task

Once you understand Call Stack → Runtime APIs → Task Queue → Microtask Queue → Event Loop, you can predict most common JavaScript asynchronous output questions without memorizing them.

References

# Week 3 - Task 1: Understanding JavaScript Core Concepts

koushikmaya — Wed, 12 Aug 2026 02:09:08 +0000

Week 3 - Task 1: JavaScript Core Concepts

JavaScript has many concepts that look simple at first but become very important when writing real applications. While learning JavaScript, I came across concepts like var, let, const, hoisting, lexical scope, execution context, call stack, closures, and this.

In this blog, I’m sharing my understanding of these concepts with simple examples.

1. Variables: `var`, `let`, and `const`

Variables are used to store data in JavaScript.

var name = "Koushik";
let age = 20;
const city = "Hyderabad";

Although all three can be used to declare variables, they behave differently.

`var`

var is the older way of declaring variables in JavaScript.

var age = 20;

age = 21;

console.log(age); // 21

var is function-scoped.

if (true) {
    var x = 10;
}

console.log(x); // 10

The variable is accessible outside the if block.

`let`

let is block-scoped.

if (true) {
    let x = 10;
}

console.log(x); // ReferenceError

A variable declared with let can be reassigned.

let age = 20;

age = 21;

console.log(age); // 21

But it cannot be redeclared in the same scope.

let age = 20;
let age = 21; // SyntaxError

`const`

const is also block-scoped.

const age = 20;

It cannot be reassigned.

const age = 20;

age = 21; // TypeError

However, const does not make an object completely immutable.

const user = {
    name: "Koushik"
};

user.name = "Rahul";

console.log(user.name); // Rahul

The object can still be modified. The variable itself cannot be reassigned to another object.

Quick Comparison

Feature	`var`	`let`	`const`
Scope	Function	Block	Block
Reassignment	Yes	Yes	No
Redeclaration	Yes	No	No
Hoisted	Yes	Yes	Yes
Temporal Dead Zone	No	Yes	Yes

For modern JavaScript, let and const are generally preferred over var.

2. Hoisting

Hoisting is the behavior where JavaScript processes declarations before executing the code in that scope.

For example:

console.log(x);

var x = 10;

The output is:

undefined

This can be understood roughly as:

var x;

console.log(x);

x = 10;

The declaration is available before the assignment happens.

`let` and `const`

Now consider:

console.log(x);

let x = 10;

This gives:

ReferenceError

let and const are also hoisted, but they cannot be accessed before their declaration is evaluated.

This period is called the Temporal Dead Zone (TDZ).

// TDZ starts

let x = 10;

// TDZ ends

Trying to access x before its declaration causes a ReferenceError.

Function Hoisting

Function declarations are also hoisted.

sayHello();

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

Output:

Hello

However, function expressions assigned to let or const cannot be called before their declaration.

sayHello();

const sayHello = function () {
    console.log("Hello");
};

This results in a ReferenceError.

3. Lexical Scope

Lexical scope means that the scope of a variable is determined by where the code is written.

Consider:

let name = "Koushik";

function outer() {
    let age = 20;

    function inner() {
        console.log(name);
        console.log(age);
    }

    inner();
}

outer();

The inner() function can access variables from its own scope and from the outer scopes.

The scope chain looks like:

inner()
   ↓
outer()
   ↓
global scope

This is called the scope chain.

JavaScript uses lexical scoping, which is also one of the main reasons closures work.

4. Execution Context

An execution context is the environment in which JavaScript code is executed.

There are mainly two execution contexts that are important to understand:

Global Execution Context
Function Execution Context

When JavaScript starts running a program, it creates the Global Execution Context.

For example:

let name = "Koushik";

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

greet();

First, JavaScript creates the global execution context.

When greet() is called, JavaScript creates another execution context for that function.

Global Execution Context
          |
          ↓
       greet()
          |
          ↓
Function Execution Context

Creation and Execution

Execution can be simplified into two phases:

Creation phase
Execution phase

During the creation phase, JavaScript prepares the environment for variables, functions, scope information, and this.

During the execution phase, JavaScript executes the code.

5. Call Stack

The call stack keeps track of which functions are currently being executed.

Consider:

function one() {
    console.log("One");
}

function two() {
    one();
    console.log("Two");
}

two();

When two() is called, it is pushed onto the call stack.

Then two() calls one(), so one() is pushed on top.

| one()     |
| two()     |
| global    |
------------

one() finishes first, so it is removed.

| two()     |
| global    |
------------

Then two() finishes.

The call stack follows LIFO:

Last In, First Out

This is why the most recently called function finishes first.

6. Closures

Closures are one of the most interesting concepts in JavaScript.

A closure happens when a function remembers variables from its outer lexical scope even after the outer function has finished executing.

Example:

function outer() {
    let count = 0;

    function inner() {
        count++;
        console.log(count);
    }

    return inner;
}

const counter = outer();

counter(); // 1
counter(); // 2
counter(); // 3

At first, outer() finishes execution.

Normally, we might expect count to disappear.

But inner() still needs access to count.

Because inner() was created inside outer(), it remembers the environment where it was created.

outer()
   |
   | count = 0
   |
   └── inner()
          |
          └── remembers count

This is a closure.

Why Are Closures Useful?

Closures are commonly used for:

Maintaining state
Data privacy
Counters
Function factories
Callbacks
Event handlers

For example:

function createCounter() {
    let count = 0;

    return function () {
        count++;
        return count;
    };
}

const counter = createCounter();

console.log(counter()); // 1
console.log(counter()); // 2
console.log(counter()); // 3

The count variable is private to the closure.

7. Understanding `this`

The this keyword is another important JavaScript concept.

A common beginner mistake is thinking:

"this always refers to the object where the function was created."

For normal functions, this is not necessarily true.

The value of this depends mainly on how the function is called.

Some important cases are:

Implicit binding
Explicit binding
new binding
Arrow functions

8. Implicit Binding

When a function is called as a method of an object, this refers to that object.

const user = {
    name: "Koushik",

    greet() {
        console.log(this.name);
    }
};

user.greet();

Output:

Koushik

Here:

this === user

because the function was called as:

user.greet();

The object before the dot determines the this value in this case.

9. Explicit Binding

JavaScript provides three methods that can be used to control this:

call()
apply()
bind()

`call()`

function greet() {
    console.log(this.name);
}

const user = {
    name: "Koushik"
};

greet.call(user);

Output:

Koushik

call() immediately invokes the function with the specified this.

`apply()`

apply() works similarly to call(), but arguments are passed as an array.

function introduce(age, city) {
    console.log(this.name, age, city);
}

const user = {
    name: "Koushik"
};

introduce.apply(user, [20, "Hyderabad"]);

`bind()`

bind() creates a new function with this permanently bound to the provided object.

function greet() {
    console.log(this.name);
}

const user = {
    name: "Koushik"
};

const newGreet = greet.bind(user);

newGreet();

Output:

Koushik

The simple difference is:

call()  → calls the function immediately
apply() → calls the function immediately
bind()  → returns a new function

10. `new` Binding

The new keyword creates a new object and makes that object the this value inside the constructor function.

function User(name) {
    this.name = name;
}

const user1 = new User("Koushik");

console.log(user1.name);

Output:

Koushik

Conceptually, this happens:

new User("Koushik")
        |
        ↓
Create a new object
        |
        ↓
this points to that object
        |
        ↓
this.name = "Koushik"
        |
        ↓
Object is returned

So user1 becomes an instance of User.

11. Arrow Functions and `this`

Arrow functions behave differently from normal functions.

An arrow function does not have its own this.

Instead, it inherits this from its surrounding lexical scope.

For example:

const user = {
    name: "Koushik",

    greet() {
        setTimeout(() => {
            console.log(this.name);
        }, 1000);
    }
};

user.greet();

The arrow function gets this from greet().

greet()
   |
   | this → user
   |
   └── arrow function
          |
          └── inherits this → user

Therefore, the output is:

Koushik

This is one reason arrow functions are very useful for callbacks.

However, arrow functions should not be used when you specifically need a function to have its own dynamic this.

12. Putting the Concepts Together

Let's look at an example that combines lexical scope, execution context, closures, and the call stack.

var name = "Global";

function outer() {
    let name = "Outer";

    function inner() {
        console.log(name);
    }

    return inner;
}

const fn = outer();

fn();

When the program starts, JavaScript creates the global execution context.

Then:

const fn = outer();

calls outer().

A new function execution context is created.

Inside outer():

let name = "Outer";

Then inner() is created.

outer() returns inner.

const fn = outer();

Now fn refers to inner.

When we call:

fn();

inner() can still access:

name = "Outer"

even though outer() has already finished.

That's because of the closure.

The output is:

Outer

Final Mental Model

These concepts are connected.

JavaScript starts
       |
       ↓
Global Execution Context
       |
       ↓
Code starts executing
       |
       ↓
Function is called
       |
       ↓
New Execution Context
       |
       ↓
Function pushed onto Call Stack
       |
       ↓
Variables resolved using Lexical Scope
       |
       ↓
Nested functions can create Closures
       |
       ↓
Function finishes
       |
       ↓
Execution Context removed from Call Stack
       |
       ↓
Closure can keep required variables accessible

For this, remember:

How was the function called?
          |
    ┌─────┼─────────┬────────┐
    ↓     ↓         ↓        ↓
 obj.fn  call/apply  new     arrow
    ↓     ↓         ↓        ↓
implicit explicit   new    lexical
binding  binding    this     this

Key Takeaways

var is function-scoped, while let and const are block-scoped.
Hoisting happens when JavaScript sets up a scope before executing it.
let and const have a Temporal Dead Zone.
Lexical scope is determined by where the code is written.
Execution contexts provide the environment for code execution.
The call stack manages function execution using LIFO.
Closures allow functions to remember variables from their outer scope.
this depends on how a normal function is called.
call(), apply(), and bind() provide explicit control over this.
new creates a new object and binds this to it.
Arrow functions don't have their own this; they inherit it from the surrounding scope.

These concepts helped me understand that JavaScript is not just about writing statements one after another. There is a whole execution process happening behind the scenes, and understanding that process makes it much easier to reason about JavaScript code and debug unexpected behavior.
Also if anyone wants my handwritten notes on this core topic you can comment on this blog. Thank You!

Also added my Handwritten notes at the end .please do check it out.

koushikmaya — Mon, 10 Aug 2026 09:52:42 +0000

koushikmaya

Aug 10

Understanding the Browser Rendering Pipeline: DOM, CSSOM, Layout, Paint, Compositing & Layout Thrashing

#webdev #css #performance #frontend

7 min read

Understanding the Browser Rendering Pipeline: DOM, CSSOM, Layout, Paint, Compositing & Layout Thrashing

koushikmaya — Mon, 10 Aug 2026 09:39:27 +0000

Understanding the Browser Rendering Pipeline: From DOM to Pixels 🚀

A beginner-friendly look at DOM, CSSOM, Render Tree, Layout, Paint, Compositing, Critical Rendering Path, and Layout Thrashing.

Introduction

While working on my Week 2 frontend tasks in my training, I wanted to understand what actually happens inside the browser when we load a webpage.
I had heard terms like DOM, CSSOM, reflow, repaint, and compositing, but I didn't fully understand how they were connected.
So I decided to learn the browser rendering pipeline and use Chrome DevTools Performance to see some of these concepts in practice.

This post covers what I learned and the small experiment I performed on layout thrashing.

📌 What I Learned

In this learning session, I covered:

DOM Construction

CSSOM Construction

Render Tree

Style Calculation

Layout / Reflow

Paint / Repaint

Compositing

Critical Rendering Path

Layout Thrashing

Batching DOM Reads and Writes

- Chrome DevTools Performance

🔄 Browser Rendering Pipeline

At a high level, the browser goes through something like this:

HTML
  ↓
DOM
  ↓
CSS
  ↓
CSSOM
  ↓
Style Calculation
  ↓
Render Tree
  ↓
Layout
  ↓
Paint
  ↓
Compositing
  ↓
Screen

Let's understand each stage.

1️⃣ DOM Construction

DOM stands for Document Object Model.
When the browser receives HTML, it parses it and creates a tree-like structure.
For example:

<body>
    <h1>Hello</h1>
    <p>Welcome</p>
</body>

The browser creates something conceptually like:

Document
└── html
    └── body
        ├── h1
        └── p

This is the DOM tree.

Simple way to remember

DOM = What elements exist?

2️⃣ CSSOM Construction

CSSOM stands for CSS Object Model.
The browser also parses CSS and creates a representation of the CSS rules.
For example:

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

The CSSOM helps the browser understand how the elements should be styled.

Simple way to remember

DOM   → What exists?
CSSOM → How should it look?

3️⃣ Style Calculation

Now the browser needs to figure out which styles actually apply to each element.
It considers things such as:

CSS selectors
Cascade
Specificity
Inheritance
Browser default styles
Media queries
CSS variables For example:

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

4️⃣ Render Tree

The browser combines the DOM and CSSOM to determine what actually needs to be rendered.

DOM + CSSOM
     ↓
Style Calculation
     ↓
Render Tree

The Render Tree isn't exactly the same as the DOM.
For example:

.hidden {
    display: none;
}

The element still exists in the DOM, but it doesn't participate in the normal rendered layout.

Simple way to remember

Render Tree = What actually participates in rendering?

5️⃣ Layout / Reflow

Once the browser knows what needs to be rendered, it needs to calculate the size and position of the elements.
This is the Layout stage.
It calculates things like:

Width

Height

Position

Margin

Padding

Text positioning For example:

.card {
    width: 300px;
    height: 200px;
}

The browser needs to calculate where the card is and how much space it occupies.

Simple way to remember

Layout = Where is everything and how big is it?

Layout is also commonly referred to as reflow.

6️⃣ Paint / Repaint

After calculating the layout, the browser needs to draw the page.
This is the Paint stage.
Paint deals with things such as:

Text

Backgrounds

Borders

Images

Shadows

Gradients For example:

.card {
    background: white;
    border: 1px solid #ddd;
    box-shadow: 0 4px 10px gray;
}

These visual details need to be painted.

Simple way to remember

Paint = Draw what the user should see.

If something visual changes, the browser may need to paint that area again. This is commonly called a repaint.

7️⃣ Compositing

After painting, the browser may have different painted surfaces or layers that need to be combined.
That's where Compositing comes in.

Layer 1
   +
Layer 2
   +
Layer 3
   ↓
Compositing
   ↓
Screen

Properties such as:

transform
opacity

can often be handled efficiently by the compositor.
This is one reason these properties are commonly used for animations.
For example:

.box {
    transform: translateX(100px);
}

8️⃣ Critical Rendering Path

Now we can put everything together.
The simplified Critical Rendering Path looks like this:

HTML
  ↓
DOM

CSS
  ↓
CSSOM

DOM + CSSOM
  ↓
Style Calculation
  ↓
Render Tree
  ↓
Layout
  ↓
Paint
  ↓
Compositing
  ↓
Screen

JavaScript can modify the DOM or CSS, which may cause parts of this process to run again.

This is where frontend performance becomes important.

🧪 Practical Experiment With Chrome DevTools

Learning the theory was useful, but I wanted to actually see what was happening.
So I used my Week 2 responsive landing page and opened:

Chrome DevTools
→ Performance

I recorded the page load and inspected the Main thread.
I found rendering-related activities such as:

Recalculate Style
Layout
Paint
Composite / Commit

This helped me connect the theory with what the browser was actually doing.
Instead of just reading:

"The browser performs layout and paint."

I could actually see rendering activity in DevTools.

🔥 Layout Thrashing Experiment

The most interesting part of the experiment was layout thrashing.
I created a simple page with multiple boxes and used JavaScript to change their height and immediately read their height.

for (const box of boxes) {
    box.style.height = "100px";
    console.log(box.offsetHeight);
}

Here:

box.style.height = "100px";

is a write because I'm changing the style.
And:

box.offsetHeight

is a layout read because I'm asking the browser for the current height.
So the pattern becomes:

WRITE
  ↓
READ
  ↓
WRITE
  ↓
READ

When layout has been invalidated, reading layout information such as offsetHeight can require the browser to synchronously update layout.

Doing this repeatedly can lead to layout thrashing.

🤔 Why Is `offsetHeight` Important?

Some properties require the browser to provide up-to-date layout information.
Examples include:

element.offsetWidth
element.offsetHeight
element.clientWidth
element.clientHeight
element.getBoundingClientRect()

If we've just changed something that affects layout and then immediately request one of these values, the browser may need to perform layout work before returning the result.

❌ The Problem: Layout Thrashing

The problematic pattern is:

for (const box of boxes) {
    box.style.height = "100px";
    console.log(box.offsetHeight);
}

Conceptually:

WRITE → READ
WRITE → READ
WRITE → READ

This can cause unnecessary synchronous layout work

✅ Fixing Layout Thrashing

The basic solution is to separate reads and writes.
Instead of:

WRITE → READ
WRITE → READ
WRITE → READ

we can do:

READ
READ
READ
  ↓
WRITE
WRITE
WRITE

The optimized version:

// READ
for (const box of boxes) {
    console.log(box.offsetHeight);
}
// WRITE
for (const box of boxes) {
    box.style.height = "100px";
}

This gives the browser a better opportunity to batch the rendering work.

📊 Before vs After

❌ Before

for (const box of boxes) {
    box.style.height = "100px";
    console.log(box.offsetHeight);
}

Pattern:

WRITE → READ
WRITE → READ
WRITE → READ

✅ After

for (const box of boxes) {
    console.log(box.offsetHeight);
}
for (const box of boxes) {
   box.style.height = "100px";
}

Pattern:

READ
READ
READ
   ↓
WRITE
WRITE
WRITE

🔍 What I Observed in DevTools

I recorded both versions using the Performance panel.
I was able to inspect:

JavaScript execution
Recalculate Style
Layout activity
Paint
Compositing / Commit One thing I learned during the experiment is that Chrome is heavily optimized, so we shouldn't expect to see one separate Layout event for every single operation. The important part was understanding why alternating layout writes and reads can cause synchronous rendering work. --- # 💡 Key Takeaways | Concept | What I learned | | --- | --- | | DOM | Represents the structure of the HTML document. | | CSSOM | Represents the CSS rules. | | Render Tree | Determines what participates in rendering. | | Layout | Calculates the size and position of elements. | | Paint | Draws the visual appearance. | | Compositing | Combines painted surfaces/layers into the final frame. | | Layout Thrashing | Can happen when layout-affecting writes and layout reads are repeatedly mixed. | | Performance Optimization | Batch DOM/layout reads and writes when possible. | | DevTools | Performance tools are useful for understanding what the browser is actually doing instead of simply guessing. | --- # 🎯 What I Learned From This Before doing this experiment, I mostly thought about HTML, CSS, and JavaScript as separate parts of frontend development. Now I have a better understanding of how they connect:

HTML
 ↓
DOM
 ↓
CSSOM
 ↓
Render Tree
 ↓
Layout
 ↓
Paint
 ↓
Compositing
 ↓
Screen

I also learned that the way JavaScript interacts with the DOM can affect browser rendering performance.

The layout-thrashing experiment was especially useful because I could see how a simple operation like reading `offsetHeight` can become important when it is repeatedly mixed with style changes.

🏁 Conclusion

This was one of those topics that made much more sense after actually experimenting with it.
Instead of only reading about reflow, repaint, and compositing, I used Chrome DevTools to observe the browser's rendering work.
The biggest lesson I took from this experiment is:

Don't just learn how the browser works. Use DevTools to see it working.

This experiment gave me a better understanding of what happens behind the scenes when the browser turns our HTML, CSS, and JavaScript into pixels.

🛠️ Practical Work

As part of my Week 2 learning, I worked on:

✅ Responsive landing page

✅ Chrome DevTools Performance analysis

✅ Layout, Paint and Compositing investigation

✅ Layout thrashing experiment

✅ Batched DOM reads and writes

✅ Before/after performance comparison ## Tools Used

HTML

CSS

JavaScript

Chrome DevTools

- VS Code

📚 Final Note

I'm still learning frontend performance, but this experiment helped me understand that writing frontend code isn't only about making the page look correct — it's also about understanding how the browser processes that code.

📝 My Handwritten Notes

I also made handwritten notes while learning these concepts. They helped me understand the browser rendering pipeline and remember the key points.
Here are my notes:
Handwritten notes - Browser Rendering Pipeline

CSS Architecture

koushikmaya — Mon, 10 Aug 2026 06:21:17 +0000

Responsive CSS: From Mobile-First Design to Modern Styling

Responsive design is about creating websites that work well across mobile, tablet, and desktop screens. In this post, I learned some important techniques for building responsive and maintainable CSS.

1. Mobile-First Media Queries

Mobile-first means writing the base CSS for smaller screens first and then enhancing the layout for larger screens.

/* Mobile */
.card {
    width: 100%;
}

/* Tablet */
@media (min-width: 768px) {
    .card {
        width: 70%;
    }
}

/* Desktop */
@media (min-width: 1024px) {
    .card {
        width: 50%;
    }
}

The main idea is:

Mobile → Tablet → Desktop

min-width is commonly used for mobile-first development because styles are progressively added as the screen gets larger.

`min-width` vs `max-width`

min-width: applies styles when the screen is at least the specified width.
max-width: applies styles when the screen is at most the specified width.

For example:

@media (max-width: 768px) {
    h1 {
        font-size: 20px;
    }
}

One important lesson I learned: CSS media queries belong inside `<style>` or a CSS file, not inside `<script>`.

2. Fluid Typography

Fixed font sizes don't always work well across different screen sizes. Fluid typography allows text to adapt to the viewport.

`rem`

rem is relative to the root font size.

h1 {
    font-size: 2rem;
}

If the root size is 16px, 2rem is 32px.

`vw`

vw is relative to the viewport width.

h1 {
    font-size: 5vw;
}

However, using only vw can make text too small or too large.

`clamp()`

clamp() provides a minimum, flexible value, and maximum:

h1 {
    font-size: clamp(1.5rem, 4vw, 3rem);
}

This allows the font size to grow smoothly while keeping it within limits.

3. Responsive Images

Images can consume a lot of bandwidth, so responsive images help browsers choose an appropriate image for the device.

`srcset`

<img
    src="small.jpg"
    srcset="
        small.jpg 400w,
        medium.jpg 800w,
        large.jpg 1200w"
    sizes="100vw"
    alt="Mountain">

srcset provides multiple image sizes, allowing the browser to choose an appropriate resource.

`<picture>`

picture is useful when different images should be displayed at different screen sizes.

<picture>
    <source
        media="(min-width: 1000px)"
        srcset="desktop.jpg">
    <source
        media="(min-width: 600px)"
        srcset="tablet.jpg">
    <img src="mobile.jpg" alt="Nature">
</picture>

4. BEM Naming Convention

BEM stands for:
Block → Element → Modifier
It helps keep CSS class names organized and reduces naming conflicts.

<div class="card card--dark">
    <img class="card__image">
    <h2 class="card__title">
        Product
    </h2>
    <p class="card__text">
        Description
    </p>
</div>

The structure is:

Block
.card
Element
.card__title
Modifier
.card--dark

BEM makes larger CSS projects easier to understand and maintain.

5. Utility-First Styling

Utility-first CSS uses small, reusable classes to build a component.
A popular example is Tailwind CSS:

<button class="bg-blue-500 text-white p-4 rounded">
    Submit
</button>

Each utility generally performs a specific styling job.

Advantages

Fast development
Reusable utility classes
Consistent styling
Less custom CSS ### Disadvantage HTML can become crowded with many classes. --- ## 6. Component-Scoped Styling CSS Modules are an example of component-scoped styling.

/* Button.module.css */
.button {
    background: blue;
    color: white;
    padding: 10px;
}

Then in a component:

import styles from "./Button.module.css";
function Button() {
    return (
        <button className={styles.button}>
            Submit
        </button>
    );
}

The styles are scoped to the component, which helps prevent global CSS conflicts.

Utility-First vs CSS Modules

Feature	Utility-First	CSS Modules
Styling	Utility classes	Component CSS
HTML	More classes	Cleaner
Scope	Utilities	Component-scoped
Development	Very fast	Structured
Best for	Rapid UI development	Component-based applications

Neither approach is universally better. The choice depends on the project's requirements, team preferences, and architecture.

Key Takeaways

From this topic, I learned:

Start responsive designs with a mobile-first approach.
Use min-width to progressively enhance layouts.
Use rem, vw, and especially clamp() for flexible typography.
Use srcset for different image sizes.
Use <picture> when different image sources are needed.
Use BEM to create structured and predictable CSS class names.
Utility-first CSS focuses on composing designs from small utility classes.
CSS Modules provide component-scoped styling.
Media queries are CSS, so they belong in <style> or .css files, not <script>. Responsive CSS is not just about making a website "fit" on different screens. It's about building layouts that adapt, remain accessible, perform well, and are easy to maintain.

DEV Community: koushikmaya

Building a Notification System with JavaScript EventEmitter and a Queue

What are we trying to build?

1. Understanding Events

2. Creating the EventEmitter

3. What is this?

4. Listening to an Event with on()

5. What is a Callback?

6. Why do we use an Array?

7. Stopping a Listener with off()

8. Triggering an Event with emit()

9. How emit() Finds the Right Function

10. Connecting the EventEmitter to Notifications

11. The Notification Queue

12. Adding Notifications to the Queue

13. Taking the First Notification

14. Making Sure Only One Notification Shows

15. The Important if Statement

16. Creating the Notification in the DOM

17. Removing the Notification

18. Putting Everything Together

19. The Full Mental Model

EventEmitter

Notification Queue

20. What I Learned from This

Final Takeaway

# Week 4 - Task 1: Understanding JavaScript Core Concepts

JavaScript Prototypes, Inheritance, Classes, and Encapsulation

What I am learning

1. First: What is a Prototype?

2. Prototype Chain

Property lookup in simple steps

3. prototype vs __proto__

prototype

__proto__

4. Object.create()

My simple way of remembering it

5. Object.create() Inheritance

6. Constructor Functions

7. Constructor Function + Prototype

8. Important: Constructor + Prototype Is Not Automatically Inheritance

9. Constructor Function + Prototype Inheritance

Where does inheritance actually happen?

10. Why Bike.call()?

11. Object.create() vs Constructor Inheritance

Object.create()

Constructor + prototype

Actual constructor inheritance

12. Classes

13. Class Inheritance with extends

14. super

15. Static Members

Static property

16. Static with Constructor Functions

17. Getters

18. Getters and Setters — My Age Example

What is happening?

19. Why _age?

20. Setter = Validation and Controlled Changes

21. Encapsulation

22. Encapsulation with Closures

23. Private Fields with #

24. _field vs #field

25. Private Methods

26. Closures vs Private Fields

Closure

Private field

27. One Complete Example

28. Understanding the Prototype Chain in This Example

29. Where Does #age Fit?

30. Prototype Methods vs Instance Properties

31. My Final Mental Model

32. The Main Things I Need to Remember

Prototype

Prototype chain

Object.create()

Constructor function

Constructor + prototype

Constructor inheritance

class

3. What is `this`?

4. Listening to an Event with `on()`

7. Stopping a Listener with `off()`

8. Triggering an Event with `emit()`

9. How `emit()` Finds the Right Function

15. The Important `if` Statement

3. `prototype` vs `proto`

`prototype`

`proto`

4. `Object.create()`

5. `Object.create()` Inheritance

10. Why `Bike.call()`?

11. `Object.create()` vs Constructor Inheritance

`Object.create()`

13. Class Inheritance with `extends`

14. `super`

19. Why `_age`?

23. Private Fields with `#`

24. `_field` vs `#field`

29. Where Does `#age` Fit?

`Object.create()`

`class`

`extends`

`super`

`static`

`_field`

`#field`

11. `setTimeout(..., 0)` does NOT mean "run immediately"

1. Variables: `var`, `let`, and `const`

`var`

`let`

`const`

`let` and `const`

7. Understanding `this`

`call()`

`apply()`

`bind()`

10. `new` Binding