Here's what that looks like in practice:

// Storing a function in a variable 
const greet = function(name) {
  console.log("Hello, " + name);
};

// Passing that variable to another function
function run(fn) {
  fn("Aditya"); // calls whatever was passed in
}

run(greet); // prints: Hello, Aditya

greet is just a value here. We handed it to run, and run called it. That's the whole mechanic. A callback is just a function passed to another function so that other function can call it later.

The word "callback" sounds formal, but the idea is simple: you're giving someone your phone number and saying "call me back when you're done." The function you pass is that phone number.

Passing Functions as Arguments

You've probably used callbacks already without noticing. addEventListener, setTimeout, Array.forEach, all of these take a function as an argument. That function is the callback.

// setTimeout takes a callback: runs it after 2 seconds
setTimeout(function() {
  console.log("Two seconds later");
}, 2000);

// forEach takes a callback: runs it once per item
["Manas", "Saumya", "Priya"].forEach(function(name) {
  console.log(name);
});

// addEventListener takes a callback: runs it on click
button.addEventListener("click", function() {
  console.log("Clicked");
});

Notice the pattern. You pass a function, something else holds onto it, and calls it at the right moment. You are not in charge of when it runs. That's kind of the point.

Why Async Even Needs Callbacks

JavaScript runs one thing at a time. There is no threading, no parallel execution of your code. One call stack, one line at a time. So when you need to wait for something, a network request, a file read, a timer, you have a problem: if you wait, everything else stops.

Think about a restaurant. The chef doesn't stand at the kitchen pass staring at your food until you come collect it. They put it on the counter, ring a bell, and move on to the next order. You come when you're ready. The kitchen keeps running.

Callbacks are that bell. You hand the runtime a function and say: when the thing is done, run this. Meanwhile, the rest of your code keeps going.

// SYNCHRONOUS: second log waits for the whole loop
console.log("start");
for (let i = 0; i < 1000000000; i++) {} // browser hangs here
console.log("end");

// ASYNC WITH CALLBACK: second log runs immediately
console.log("start");
setTimeout(function() {
  console.log("I ran later"); // runs after 2s, non-blocking
}, 2000);
console.log("end"); // this prints before the callback

Running that second block, you'll see "start", then "end", then two seconds later "I ran later". The callback didn't block anything.

Common Places Callbacks Show Up

Callbacks are everywhere. Once you start seeing the pattern, you can't unsee it. Here are the places you'll hit them most as a beginner.

// array methods: forEach, filter, map
const scores = [42, 88, 61, 95, 37];

// forEach: run callback for each item
scores.forEach(function(score) {
  console.log(score);
});

// filter: keep items where callback returns true
const passing = scores.filter(function(score) {
  return score >= 60;
}); // [88, 61, 95]

// map: transform each item, return new array
const grades = scores.map(function(score) {
  return score >= 60 ? "Pass" : "Fail";
}); // ["Fail", "Pass", "Pass", "Pass", "Fail"]

// Event Listeners
const btn = document.getElementById("submit");

// callback runs every time the button is clicked
btn.addEventListener("click", function(event) {
  event.preventDefault();
  console.log("Form submitted");
});

// fetch API
// fetch uses .then()  which takes a callback
fetch("/api/users/1")
  .then(function(response) {
    return response.json(); // callback 1: parse response
  })
  .then(function(data) {
    console.log(data.name); // callback 2: use the data
  });

Arrow functions are common shorthand for callbacks: scores.filter(s => s >= 60) does the same thing as the function version above. Same idea, fewer keystrokes.

Writing Your Own Function That Takes a Callback

It helps to write one yourself, even if it's small. Once you've built a function that accepts and calls a callback, the whole model locks in.

// greetUser takes a name and a callback
function greetUser(name, callback) {
  console.log("Fetching user data...");
  callback(name); // call whatever was passed in
}

// Two different behaviours, same greetUser function
greetUser("Saumya", function(name) {
  console.log("Hello, " + name + "!"); // "Hello, Saumya!"
});

greetUser("Manas", function(name) {
  console.log("Welcome back, " + name); // "Welcome back, Manas"
});

greetUser doesn't care what the callback does. It just calls it with the name. The caller decides the behaviour. That flexibility is exactly why callbacks are so useful — you write the structure once, plug in different logic as needed.

A real-world version of this is Array.sort. The sort algorithm is built into JavaScript, but you pass a callback that defines how to compare two items. You bring the comparison logic; sort brings the algorithm.

// sort with custom comparator callback
const users = [
  { name: "Manas",  age: 28 },
  { name: "Saumya", age: 24 },
  { name: "Priya",  age: 31 },
];

// sort needs to know HOW to compare — you provide that
users.sort(function(a, b) {
  return a.age - b.age; // youngest first
});

The Nesting Problem

Here's where callbacks get genuinely painful. Suppose you need to do three async things in sequence: fetch a user, then fetch their orders, then fetch the details of the first order. Each step depends on the previous one. With callbacks, you end up putting them inside each other.

getUser(1, function(user) {

  getOrders(user.id, function(orders) {

    getOrderDetails(orders[0].id, function(details) {

      console.log(details); // finally, the thing we wanted

    });
  });
});

Three levels. Now add error handling at each step. Add a fourth request. The indentation becomes a visual pyramid, and the logic is buried inside it. This has a name: callback hell.

The nesting itself is not wrong, it works. The problem is readability. Errors are hard to catch at the right level. Adding a step means nesting deeper. Debugging means tracing through a maze of closing braces. It gets old fast.

Callback hell is why Promises and async/await exist. They solve the same coordination problem with much flatter code. That's the next part of this series.

What Callbacks Actually Give You

REFERENCES:

• MDN Web Docs : Callback function

• JavaScript.info : Introduction: callbJavaScript.info : Introduction: callbacks

• JavaScript Asynchronous Programming and Callbacks

• Callback Hell

Here is the short version: new runs a function in a special mode where that function builds and returns an object. The function is called a constructor. The object it builds is called an instance. That is the whole idea. The rest is just details about how it works.

A constructor is not a special kind of function. It is a regular function that you call with new. The convention is to capitalize the first letter so people know it is meant to be called that way, but JavaScript does not enforce this.

A Constructor Function

Before classes came along in ES6, this is how you made objects that shared a structure. You wrote a plain function, used this inside it, and called it with new. It still works exactly the same way today.

// Capital P signals: call this with new
function Person(name, age) {
  this.name = name;
  this.age  = age;
}

const priya = new Person("Priya", 28);
const rohan = new Person("Rohan", 34);

console.log(priya.name); // "Priya"
console.log(rohan.age);  // 34

Each call to new Person() produces a separate object. Priya's name and Rohan's name live on different objects. Changing one does not touch the other. That sounds obvious, but it is worth saying because it is the point.

What new Does

When JavaScript sees new Person("Priya", 28), it does four things in order. You never see any of this happen, but it all runs before your function body even starts.

A blank object is created

JavaScript makes a fresh, empty object. Nothing in it yet. This is what will eventually come back from the call.

**
The prototype is linked**
That blank object gets its internal [[Prototype]] set to Person.prototype. This is how instances share methods without each one getting its own copy. More on this in a moment.

The function runs with this = that object

The constructor body runs, and every time you write this.something, you are writing onto that blank object from step 1.

The object is returned

Unless your constructor explicitly returns a different object, JavaScript returns the one it built in step 1. This is automatic. You do not write return this.

Where Methods Go: The Prototype

Here is something that trips people up early on. If you put a method inside the constructor body using this.greet = function() {...}, every single instance gets its own copy of that function. One hundred Person objects means one hundred separate greet functions sitting in memory, all doing the same thing.

The fix is to put shared methods on Person.prototype instead. Every instance automatically has access to it through the prototype chain, but only one copy exists.

// method in wrong places
function Person(name) {
  this.name = name;

  // Bad: every new Person() gets its own copy of this function
  this.greet = function() {
    console.log("Hi, I'm " + this.name);
  };
}

// method on the prototype
function Person(name) {
  this.name = name; // own property — each instance needs its own
}

// Defined once, shared by every Person instance
Person.prototype.greet = function() {
  console.log("Hi, I'm " + this.name);
};

const priya = new Person("Priya");
const rohan = new Person("Rohan");

priya.greet(); // "Hi, I'm Priya"
rohan.greet(); // "Hi, I'm Rohan"

// Same function object, just this changes per call
console.log(priya.greet === rohan.greet); // true

Own properties live on the instance. Methods that do not need unique per-instance data belong on the prototype. That line is where most of the judgment calls happen.

How Prototype Lookup Works

When you write priya.greet(), JavaScript looks for greet on priya itself first. It is not there. So it follows the internal [[Prototype]] link up to Person.prototype and looks there. It finds it. Done.

If it were not there either, it would keep climbing: Object.prototype is next. If it is not there, you get undefined. This chain of lookups is called the prototype chain, and it is the mechanism behind every method you call on any object in JavaScript.

The practical upshot: methods on the prototype behave exactly like methods on the instance from the caller's perspective. You write priya.greet() either way. The lookup is invisible. You only notice it when you start asking questions like "where does .toString() come from on every object ever."

Forgetting new: What Goes Wrong

Call a constructor without new and JavaScript just runs it as a regular function. No blank object gets created. this inside it is not a fresh instance, it is either the global object (in non-strict mode) or undefined (in strict mode). In non-strict mode you get no error. You just silently write properties onto window and wonder why nothing is working.

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

const oops = Person("Priya"); // no new

console.log(oops);        // undefined: function returned nothing
console.log(window.name);  // "Priya": oops, now it's global

In strict mode this at least throws a TypeError immediately, which is easier to catch. If you are writing constructor functions today, putting "use strict" at the top of your file is a reasonable safety net.

ES6 classes solve this permanently. A class constructor throws a TypeError if you call it without new, no matter what. That is one of the reasons classes exist.

Classes Do The Same Thing, With Better Guardrails

ES6 classes are not a different object model. They are a cleaner syntax over the same constructor function and prototype setup. If you understand constructors and prototypes, you already understand what classes compile down to.

//  constructor function
function Person(name, age) {
  this.name = name;
  this.age  = age;
}
Person.prototype.greet = function() {
  console.log("Hi, I'm " + this.name);
};

// class 
class Person {
  constructor(name, age) {
    this.name = name;
    this.age  = age;
  }
  greet() {
    console.log("Hi, I'm " + this.name);
  }
}

// Both produce instances with the same shape
const p = new Person("Priya", 28);
p.greet(); // "Hi, I'm Priya"

With the class syntax, greet is automatically placed on Person.prototype. You do not write that out manually. The engine handles it. The result is identical to the constructor function version, but there is less surface area for mistakes.

Constructor vs Instance

Properties and methods can live in three places: on the instance, on the prototype, or on the constructor function itself. Each one is used differently.

function Person(name) {
  this.name = name; // instance property: unique per object
}

Person.prototype.greet = function() { // prototype method: shared
  console.log(this.name);
};

Person.count = 0; // static: lives on the constructor, not instances

const p = new Person("Priya");
p.greet();               // works. found on prototype
console.log(p.count);    // undefined. instances don't see static props
console.log(Person.count); // 0. access it through the constructor

If you want to test what you just read, try this: write a Counter constructor that stores a count on this, then add increment and reset methods on the prototype. Make two counters and verify they count independently. Then check that both counters share the same increment function reference.

That small exercise covers everything in this post. Own properties, shared methods, separate instances. Once that clicks, classes will feel like a notation change rather than a concept change, because you will already know what the class body is doing behind the scenes.

REFERENCES:

• MDN Web Docs : new operator

• MDN Web Docs : Object prototypes

That's the whole thing. It's not a new data structure. It's not magic. It's a shorter way to pull values out of objects and arrays and assign them to variables in one shot.

It showed up in ES6 (2015) and now it's everywhere. You'll see it in React, Node, API responses, config files. Once you understand it, you'll spot it in every codebase you read.

Destructuring doesn't change the original object or array. It just copies values out into new variables. The source stays exactly as it was.

Objects First

Say you have a user object. The old way was to read each property individually. Three properties meant three lines. Twenty properties meant twenty lines, all with user. repeated like a broken record

// accessing objects
const user = {
  name: "User1",
  age: 28,
  city: "Delhi"
};

const name = user.name;
const age  = user.age;
const city = user.city;

// destructuring
const user = {
  name: "User1",
  age: 28,
  city: "Delhi"
};

const { name, age, city } = user;
// same result, one line

The curly braces on the left tell JavaScript: look inside user and find properties with these names. Create variables with those names. Done. The variable names match the property names exactly, so nothing is ambiguous.

You can pull out as many or as few properties as you need. You don't have to grab all of them. If user has ten properties and you only need name and email, just write those two.

// partial destructuring
const user = {
  name: "User1",
  age: 28,
  city: "Delhi",
  email: "user1@example.com",
  role: "admin"
};

// Only pull what you need, everything else stays in user
const { name, email } = user;
console.log(name);   // "User1"
console.log(email);  // "user1@example.com"

Destructuring Arrays

Arrays work the same way. Instead of curly braces you use square brackets, and instead of matching by name you match by position. First variable gets index 0, second gets index 1, and so on.

// before
const colors = ["red", "green", "blue"];

const first  = colors[0];
const second = colors[1];
const third  = colors[2];

// after
const colors = ["red", "green", "blue"];

const [first, second, third] = colors;

// first = "red", second = "green"

You name the variables yourself here, since arrays have no property names. Whatever you write inside the brackets becomes the variable name for that slot.

You can skip positions too. Leave a blank comma where you want to skip an index.

// skip positions
const scores = [88, 72, 95, 60];

// only grab first and third
const [first, , third] = scores;

console.log(first);  // 88
console.log(third);  // 95

Default Values

Sometimes a property doesn't exist in the object, or an array slot is empty. Without a default value, you get undefined. With one, you get a sensible fallback.

// default values in object destructuring
const settings = {
  theme: "dark"
  // no `fontSize` key in this object
};

const { theme, fontSize = 16 } = settings;

console.log(theme);     // "dark"   = came from the object
console.log(fontSize);  // 16      = used the default, key was missing

The default only kicks in when the value is undefined. If the object has the key and it's set to null or 0 or even an empty string, the default is ignored and you get whatever's actually there.

// defaults in array destructuring
const rgb = [255, 128];  // only two values, third is missing

const [r, g, b = 0] = rgb;

console.log(r);  // 255
console.log(g);  // 128
console.log(b);  // 0  = default used since index 2 didn't exist

Defaults make your code defensive without adding if statements. If an API sometimes returns an object without certain fields, destructuring with defaults handles the missing data in one line instead of three.

Renaming While Destructuring

Sometimes the property name in the object clashes with a variable you already have, or it's just not a clear name for what you're doing. You can rename it right in the destructure using a colon.

const response = {
  n: "User1",   // short API field name, not readable
  a: 28
};

// n becomes name, a becomes age 
const { n: name, a: age } = response;

console.log(name);  // "User1"
console.log(age);   // 28
// `n` and `a` no longer exist as variables, they became `name` and `age` 

You can also combine renaming with defaults in one go.

const config = { w: 800 };

const { w: width = 1024, h: height = 768 } = config;

console.log(width); // 800 = came from w 
console.log(height); // 768 = h missing, used default

Where You'll Actually Use This

The places destructuring shows up the most aren't random assignments, they're function parameters and API responses. These are worth seeing on their own.

Function parameters. You can destructure right in the parameter list. The function still receives one object, but you name the fields you care about up front. The function body never repeats the parameter name.

// Without parameter destructuring
function greet(user) {
  return `Hi ${user.name},
you're ${user.age}.`;
}

// With parameter destructuring
function greet({ name, age }) {
  return `Hi ${name},
you're ${age}.`;
}
// greet({ name: "User1", age: 28 }) = "Hi User1, you're 28."

API responses. You fetch data from a server. The response has a data field with a user inside. You need name and email. You can reach all the way in with one line.

// nested destructuring
const apiResponse = {
  status: 200,
  data: {
    user: {
      name: "User2",
      email: "user2@example.com"
    }
  }
};

// Reach three levels deep in one assignment
const { data: { user: { name, email } } } = apiResponse;

console.log(name);   // "User2"
console.log(email);  // "user2@example.com"

Deep nesting like this is fine when you know the structure. If any level might be missing (like data being null), combine it with optional chaining or check before destructuring. Nested destructuring on undefined throws an error.

What You Actually Get Out Of This

REFERENCES:

• MDN Web Docs : Destructuring assignment

Most of the time, that's fine. Adding numbers, updating a variable, looping through a list: these things happen in microseconds. Nothing needs to wait for anything.

// Each line runs and finishes before the next one starts
console.log("Step 1: make tea");
console.log("Step 2: add milk");
console.log("Step 3: drink it");

// Output, every time, in this exact order:
// Step 1: make tea
// Step 2: add milk
// Step 3: drink it

The problem shows up when one of those steps takes time. Fetching data from a server. Reading a file. Waiting on a timer. Suddenly "finish before moving on" becomes a real problem.

What Blocking Feels Like

JavaScript runs in one thread, like One lane on the highway. When something stops in that lane, everything behind it stops too. There's no overtaking.

Here's a fake slow operation that shows the problem clearly. The slowTask() function below ties up JavaScript for three full seconds. Nothing else happens during that time, no button clicks, no animations, no anything.

// blocking code 
function slowTask() {
  // Spin the CPU for 3 seconds. Nothing else runs during this.
  const end = Date.now() + 3000;
  while (Date.now() < end) {}
}

console.log("Starting...");
slowTask();                   // browser freezes for 3 seconds
console.log("Done.");         // only prints after the freeze

A real network request works the same way if you wait synchronously. The difference is a spin loop wastes CPU. A network call mostly just sits there doing nothing while your app freezes. Either way, your user is staring at a dead screen.

This is why browsers started giving JavaScript a way to say "go do this, and tell me when it's done, but don't stop everything while you wait." That's asynchronous code.

Asynchronous Means Not to Wait

When you make something asynchronous, you're telling JavaScript to kick it off and move on. The rest of your code keeps running. When the slow thing finishes, it comes back and delivers its result.

The classic real-world version: you order food at a restaurant. The waiter takes your order, goes to the kitchen, and comes back later. You don't sit frozen at the table until your food is cooked. You talk to your friends. You look at your phone. The kitchen is doing its thing in the background.

console.log("Placed the order");     // runs immediately

setTimeout(() => {
  console.log("Food is ready!");    // runs after 2 seconds
}, 2000);

console.log("Talking to friends");   // runs immediately, doesn't wait

// Output:
// Placed the order
// Talking to friends
// Food is ready!    ( arrives 2 seconds later )

"Talking to friends" printed before "Food is ready!" even though it's written after the setTimeout. That's asynchronous behavior. JavaScript didn't wait at the timer. It moved on, and the timer delivered its result later when it was done.

The Event Loop

There's a piece of JavaScript's internals called the event loop. It's not something you write. It just runs constantly in the background, checking one thing: "is the main thread free? Is there anything waiting to run?"

When you kick off a timer, an API call, or a file read, JavaScript hands it off to the browser (or Node.js) and moves on. When that thing finishes, the result gets placed in a queue. The event loop watches that queue. The moment the main thread goes idle, the event loop pulls the next item out of the queue and runs it.

This is how JavaScript stays responsive even though it only has one thread. It doesn't actually do two things simultaneously. It does things quickly enough, and defers slow things, that it feels simultaneous.

Three Ways to Write Async Code

JavaScript has gone through a few different syntaxes for dealing with async code. You'll see all three in real codebases, so it's worth knowing what each one looks like.

Callbacks were first. You pass a function to be called when something finishes. They work, but nesting them for multiple sequential steps becomes a mess fast.

// old way
fetchUser(1, function(user) {
  fetchPosts(user.id, function(posts) {
    fetchComments(posts[0].id, function(comments) {
      // three levels deep. now imagine five or six.
      console.log(comments);
    });
  });
});

This staircase pattern is called callback hell. It's what production code actually looked like before Promises.

Promises cleaned this up. A promise is an object that represents a value that isn't ready yet. You chain .then() calls instead of nesting functions.

// Promise
fetchUser(1)
  .then(user    => fetchPosts(user.id))
  .then(posts   => fetchComments(posts[0].id))
  .then(comments => console.log(comments))
  .catch(err     => console.error(err));  // one place to handle errors

async/await is the current standard. It's built on Promises, but it lets you write async code so it reads like synchronous code. The await keyword pauses the current function (not the whole thread) until the promise resolves.

// async-await
async function loadComments() {
  try {
    const user     = await fetchUser(1);
    const posts    = await fetchPosts(user.id);
    const comments = await fetchComments(posts[0].id);
    console.log(comments);
  } catch (err) {
    console.error(err);
  }
}

Same three network calls. Same asynchronous behavior. Reads almost like synchronous code.

Callback and Promises

• Callbacks looks simple at first, but gets into callback hell

• Promises has flat chains, and cleaner error handling

• Still reads like async code, harder to follow when promise chaining gets involved

async / await

• Syntactic sugar of Promises

• Reads top-to-bottom, like synchronous code

• try/catch handles errors the normal way

Fetching a User Profile

Here's what the async pattern looks like when something actually goes wrong. User1 loads the page. The app fetches their profile from an API. While that's happening, the rest of the UI stays live. When the data comes back, the card renders. If the server returns an error, the UI handles it cleanly.

// users.js
export async function fetchUserProfile(userId) { 
const res = await fetch(`/api/users/${userId}`); 
if (!res.ok) throw new Error(Status ${res.status}); 
return res.json(); 
}

// profile.js
import { fetchUserProfile } from '../api/users.js';

async function renderProfile(userId) {
  const card = document.getElementById("profile");
  card.innerHTML = "Loading...";   

  try {
    const user = await fetchUserProfile(userId);
    card.innerHTML = `
      <h2>${user.name}</h2>
      <p>${user.email}</p>
    `;
  } catch (err) {
    card.innerHTML = "Could not load profile.";
    console.error(err);
  }
}

renderProfile(42);

The "Loading..." line on line four is the important part. It runs synchronously, before the await. The user sees something immediately. The network call happens in the background.

What You Actually Get From Async Code

REFERENCES:

• MDN Web Docs : Introducing asynchronous JavaScript

• MDN Web Docs : async function

Most beginners use these without thinking about what's happening underneath. That works fine until you're in an interview and someone asks you to implement .includes() yourself. Or until you hit a weird edge case and don't understand why the built-in method behaved the way it did.

Strings in JavaScript are immutable. No string method changes the original. Every method returns a new value. If you don't capture that return value, it's gone.

How Built-In Methods Actually Work

JavaScript loops through characters, checks conditions, and builds a result. .includes() is a loop that returns true the moment it finds a match. .toUpperCase() walks every character and shifts it to uppercase using Unicode. .trim() scans from both ends and stops when it hits a non-space character.

When you understand that, weird behavior starts making sense. Why does .indexOf() return -1 when it finds nothing? Because it's returning the position of the match, and there's no position that means "not found" other than an impossible one. Why does .slice(-3) count from the end? Because the method is designed to accept negative indices as an offset from the string's length.

This matters because it changes how you read code. When you see .slice(6) you know it starts a loop at index 6. When you see .replace(/\s+/g, " ") you know it runs through the string once replacing every cluster of whitespace. They're loops with return values.

The Methods You'll Actually Use

There are 30-something string methods in JavaScript. Most of them you'll call once in your life. A handful you'll use every day. Here are the ones that matter.

Slicing and Searching

const s = "hello world";

// slice(start, end): end is exclusive. negative counts from the back.
s.slice(0, 5)     // "hello"
s.slice(6)        // "world"
s.slice(-5)       // "world" — 5 from the end

// indexOf: returns position or -1. case sensitive.
s.indexOf("world")  // 6
s.indexOf("xyz")    // -1

// includes: just want true/false? use this instead of indexOf.
s.includes("world") // true

// startsWith / endsWith
s.startsWith("hello") // true
s.endsWith("world")   // true

Transforming

const s = "  Hello World  ";

// Case
s.toUpperCase()  // "  HELLO WORLD  "
s.toLowerCase()  // "  hello world  "

// Trim whitespace: trim() does both ends, trimStart/trimEnd do one side
s.trim()         // "Hello World"
s.trimStart()    // "Hello World  "

// Replace: replace() only hits the first match. replaceAll() gets every one.
"aabbcc".replace("b", "x")    // "axbcc" — only first b
"aabbcc".replaceAll("b", "x") // "aaxxcc" — both

// Split and join: two sides of the same coin
"a,b,c".split(",")         // ["a","b","c"]
["a","b","c"].join("-")     // "a-b-c"

// Padding: useful for formatting numbers and IDs
"7".padStart(3, "0")  // "007"
"7".padEnd(3, ".")    // "7.."

// Repeat
"na".repeat(4)  // "nananana"

One thing that trips beginners: .replace() only replaces the first match. If you want all of them, use .replaceAll() or pass a regex with the g flag: .replace(/b/g, "x").

Polyfills: When The String Methods are Missing

A polyfill is just a manual implementation of a built-in method. You write it so an environment that doesn't have it can still run code that uses it. Older browsers are the typical reason, but polyfills show up in interviews for a different reason: if you can write one, you actually understand what the method does.

Let's see the example for trim polyfill:

function myTrim(str) {
  let start = 0;
  let end   = str.length - 1;

  // walk inward from both sides until we hit a non-space
  while (start <= end && str[start] === " ") start++;
  while (end   >= start && str[end]   === " ") end--;

  return str.slice(start, end + 1);
}

myTrim("  hello  ")  // "hello"
myTrim("   ")         // ""

Here is the implementation of includes through polyfill:

// .includes(searchStr, fromIndex)
function myIncludes(str, search, from = 0) {
  // normalize negative fromIndex
  const start = from < 0
    ? Math.max(0, str.length + from)
    : from;

  for (let i = start; i <= str.length - search.length; i++) {
    if (str.slice(i, i + search.length) === search) {
      return true;
    }
  }
  return false;
}

myIncludes("hello world", "world")  // true
myIncludes("hello world", "xyz")    // false

The Hiccup in Interview

Interviews like string problems because they test whether you can think character-by-character. You can't memorize your way through these. You need to actually understand how strings are structured.

Here are four problems that come up repeatedly. Each one builds on a concept from the methods above

Reverse a String

// split into chars, reverse the array, join back.
function reverseString(str) {
  return str.split("").reverse().join("");
}

// without array methods 
function reverseManual(str) {
  let result = "";
  for (let i = str.length - 1; i >= 0; i--) {
    result += str[i];
  }
  return result;
}

reverseString("hello")  // "olleh"

String is a Palindrome

// A string that reads the same forward and backward.
function isPalindrome(str) {
  const cleaned = str.toLowerCase().replace(/[^a-z0-9]/g, "");
  return cleaned === cleaned.split("").reverse().join("");
}

isPalindrome("racecar")          // true
isPalindrome("A man a plan a canal Panama") // true (after cleanup)
isPalindrome("hello")             // false

Count Occurrences of a Character

function countChar(str, char) {
  let count = 0;
  for (const c of str) {
    if (c === char) count++;
  }
  return count;
}

// One-liner using split
const countChar2 = (str, char) => str.split(char).length - 1;

countChar("hello", "l")   // 2

Capitalize First Letter of Each Word

function titleCase(str) {
  return str
    .split(" ")
    .map(word => word[0].toUpperCase() + word.slice(1).toLowerCase())
    .join(" ");
}

titleCase("the quick brown fox")  // "The Quick Brown Fox"

Why Built-In Behavior Matters

JavaScript's string methods are not always consistent in how they handle edge cases. Knowing what to expect saves you a debugging session at the wrong moment.

The Gotchas

• "".split("x") returns [""], not []

• .indexOf() is case-sensitive. "Hello".indexOf("h") is -1

• .slice(2, 0) returns "" . End before start is empty

• .replace() only replaces the first match without /g

• typeof "hello" is "string", not "object"

The Knowledge for the Long Run

• Template literals avoid a lot of .replace() calls

• .at(-1) gets the last character without .length - 1

• Chaining works: .trim().toLowerCase().split(",")

• .split("") breaks a string into individual characters

• Strings are iterable: for (const c of str) works

// split on empty string : array of individual chars
"abc".split("")    // ["a","b","c"]
"".split("")       // []  | empty string, empty array
"".split("x")      // [""]  | one empty string element. catches people out.

// indexOf vs includes
"hello".indexOf("H")   // -1 | case sensitive
"hello".includes("H")  // false | also case sensitive

// slice with inverted indices
"hello".slice(3, 1)   // "" | start after end. empty
"hello".slice(-2)     // "lo" | last 2 chars

What You Actually Get From Understanding This

REFERENCES:

• MDN Web Docs : String

• JavaScript.info : Strings

But line count is not actually the problem. The problem is that all that code shares one global scope. Aditya declares var user for his login flow. Saumya also declares var user for the profile component. JavaScript doesn't throw an error. It just replaces one with the other, silently, based on load order. Aditya's login function now reads Manas' cart user. No warning. You find out at 2am when something explodes in production.

This isn't a bug in anyone's code. It's what happens when three people share a single room with no walls. Any variable can reach any other variable. You lose track fast.

// Aditya's auth section 
var user = "Aditya";

// Saumya's profile section overwrites Aditya's user, no error 
var user = "Saumya";

// Manas' cart section overwrites Saumya's. login() now gets this. 
var user = "Manas"; function addToCart() { /* ... */ }

// Good luck figuring out which user you're reading on line 847.

What is a Module ?

A module is just a file that owns its own scope. Whatever you write in it stays in it. Other files cannot read your variables, call your functions, or accidentally overwrite anything inside unless you specifically open a door with export. And if another file wants something, it has to ask with import.

That's the whole model. JavaScript has had this built in since 2015. No extra tools. Two keywords. Each file becomes its own room with a lock on the door.

You end up with small files that each own their own piece of logic, and connect to each other through the specific things they choose to share. When something breaks, you know exactly whose room to check.

Exporting: What You Choose to Share

By default, nothing leaves a module file. You have to opt things out with export. There are two ways to do it and they work differently: named exports and default exports.

Named exports let you export multiple things from one file. You put export in front of each one, and they each keep their name. Default exports are for when the file is really just one thing, you get one per file, and whoever imports it can name it whatever they want locally.

// Each one is named and exported separately
export function add(a, b)      { return a + b; }
export function multiply(a, b) { return a * b; }
export const PI = 3.14159;

// This file's whole job is logging. One thing, one export.
export default function log(msg) {
  const ts = new Date().toLocaleTimeString();
  console.log(`[\({ts}] \){msg}`);
}

Importing: Asking For What You Need

Imports go at the top of the file, always. JavaScript reads them all first before executing anything, it builds a map of what depends on what before running a single line of your logic.

Named imports use curly braces and the exact name. Default imports don't need curly braces, and you can name them whatever makes sense locally. You can also rename a named import with as if it clashes with something.

// Named import, must match the exported name exactly
import { add, multiply, PI } from './utils/math.js';

// Default import, call it whatever you like locally
import log from './utils/logger.js';

// Rename a named import to avoid a local conflict
import { add as addNums } from './utils/math.js';

log(`2 + 3 = ${add(2, 3)}`);   // [10:32:01] 2 + 3 = 5

Named vs Default

Named and default exports look similar but they behave differently on the import side. Named imports need curly braces and the exact name. Default imports take no curly braces and you pick the local name yourself. Mixing them up is the most common beginner mistake and the error message is not always obvious.

The rule most teams use: if a file exports multiple things, use named. If a file is about one single thing a React component, a class, a config factory use default. That split tends to make codebases easier to read at a glance.

If bundle size matters to your project, prefer named exports for utility code. Bundlers like Vite and Rollup can drop named exports nobody imports, they can't do that with defaults, since the whole default is treated as one unit.

How Files Connect to Each Other

Once you split code into modules, a structure forms on its own. Utility files get imported by feature files. Feature files get imported by the entry point. Nothing in a utility knows anything about the feature files using it. Nothing in the entry point knows how the features are implemented internally.

When a bug shows up, you trace the arrow. Something wrong in the cart? Start at cart.js. It imports from api.js and utils/format.js, so the bug is in one of those three places, not scattered across 3,000 lines of a single file.

Isolation is Key

Here's a user card feature spread across four files. Read it and notice what each file does not know. utils/format.js has no idea there's a user object involved, it just handles strings. api/users.js knows nothing about how the card looks. main.js has two lines and still renders everything correctly.

// utils/format.js
// only job is formatting
export function formatName(user) {
  return `\({user.firstName} \){user.lastName}`;
}
export function formatDate(str) {
  return new Date(str).toLocaleDateString('en-IN');
}

// api/users.js
// only fetch a user
export async function fetchUser(id) {
  const res = await fetch(`/api/users/${id}`);
  if (!res.ok) throw new Error("User not found");
  return res.json();
}

// components/userCard.js
import { fetchUser } from '../api/users.js';
import { formatName, formatDate } from '../utils/format.js';

// just builds a card
export default async function renderUserCard(userId) {
  const user = await fetchUser(userId);
  return `
    <div class="card">
      <h2>${formatName(user)}</h2>
      <p>Joined: ${formatDate(user.createdAt)}</p>
    </div>`;
}

// main.js
import renderUserCard from './components/userCard.js';

// responsible to render things correctly
document.getElementById("app").innerHTML = await renderUserCard(42);

If the API changes how it returns user data, you update api/users.js. If the date format needs to change, you update utils/format.js. Neither change touches the other files. That's the payoff.

The Objective of This Approach

const page1 = [1, 2, 3];
const page2 = [4, 5, 6];

const combined = [page1, page2];
console.log(combined);
// → [[1, 2, 3], [4, 5, 6]]  | not what you wanted

// You wanted [1, 2, 3, 4, 5, 6]
// What you got is an array of arrays

That outer wrapper is the problem. You don't want to loop over two arrays, you want one flat list. That's flattening. You're collapsing the layers down into a single level so you can actually work with the data.

This happens more than you'd think. APIs send paginated responses. A .map() that returns an array per item gives you nested output. Form inputs grouped by section produce grouped values. The data structure that made sense to build becomes inconvenient the moment you need to use it.

What Nested Actually Looks Like

Before getting into solutions, it's worth seeing exactly what we're dealing with. An array can nest multiple levels deep, each layer adds another set of brackets around the values inside.

The number of layers is called depth. Depth 1 means one array wrapped inside another. Depth 2 means arrays inside arrays inside the outer array. When you flatten, you're deciding how many of those layers to remove.

Just Use .flat()

ES2019 added Array.prototype.flat() and honestly it just works. Pass a depth number, or pass Infinity to collapse every layer no matter how deep. Most of the time this is all you need.

const nested = [1, [2, 3], [4, [5, 6]]];

nested.flat();
// [1, 2, 3, 4, [5, 6]]   default depth is 1

nested.flat(2);
// [1, 2, 3, 4, 5, 6]     removes two levels

nested.flat(Infinity);
// [1, 2, 3, 4, 5, 6]     flattens everything

There's also .flatMap(), which runs a map and flattens one level in one pass. It's faster than calling .map() then .flat(1) separately, and you'll use it whenever your mapping function returns an array per element.

const sentences = ["hello world", "foo bar"];

// .map() gives you nested arrays
sentences.map(s => s.split(" "));
// [["hello","world"], ["foo","bar"]]

// .flatMap() flattens that one level automatically
sentences.flatMap(s => s.split(" "));
// ["hello", "world", "foo", "bar"]

One thing to watch: .flat() skips empty slots in arrays , things like [1, , 3]. That's usually what you want, but if you're working with sparse arrays intentionally, keep it in mind.

Before .flat() Came to Existence

This might be a favourite topic of few interviewers out there, to flatten the array without the inbuilt method. The classic approach uses reduce with recursion. For each element, check if it's an array. If it is, flatten it recursively and concat the result. If it isn't, add it directly.

function flatten(arr) {
  return arr.reduce((acc, val) => 
    Array.isArray(val) ? acc.concat(flatten(val)) : acc.concat(val), 
  []);
}

flatten([1, [2, [3, [4, [5]]]]]);
// [1, 2, 3, 4, 5]   
// works at any depth

This handles any depth without you specifying it. The recursion bottoms out naturally when there are no more arrays to unwrap.

For the depth-controlled version, that's a small addition:

const flattenByDepth = (arr, depth = 1) => 
  depth > 0 ? arr.reduce((acc, val) => 
    acc.concat(Array.isArray(val) ? flattenByDepth(val, depth - 1) : val), 
  []) : arr.slice();

flattenDepth([1, [2, [3, [4]]]], 2);
// [1, 2, 3, [4]]  
// stopped at depth 2

Nested arrays happen. APIs return batches, maps produce nested output, data gets grouped before it gets used. Flattening is just the act of removing those layers. .flat(Infinity) handles it in one call. The recursive reduce version is what interviewers want you to derive. And once you've written flatten a few times, the same mental model carries over to nested objects, tree traversal, and anything else where data lives at multiple depths.

The depth question is the one to keep in mind. Most bugs with flattening come from not removing enough layers, or accidentally removing too many. Know what's in your data before you pick your depth.

REFERENCES:

• Array : flat()

• Array.prototype.flatMap()

var name = "Priya";
var score = 42;

var msg = "Hello, " + name + "! Your score is " + score + ".";

// Hello, Priya! Your score is 42.
// Six pieces. Four operators. Two sets of quotes you can barely track.

It works. Nobody's disputing that. But read it again. Your eyes have to jump between strings and variables and operators to figure out what the final output looks like. Now imagine doing that with a URL, a multi-line HTML snippet, or anything where the variable is buried in the middle of actual sentence structure. The longer the string, the worse it gets.

Template literals fix this. They've been in JavaScript since 2015. If you're not using them, you're doing more work than you need to.

The Syntax, Plainly

Two changes. You swap regular quotes for backticks. And anywhere you'd previously close the string, concatenate, and reopen it, you write ${ } instead.

const name = "Priya";
const score = 42;

const msg = `Hello, \({name}! Your score is \){score}.`;

// Hello, Priya! Your score is 42.
// Same output. You can actually read what it says.

The backtick key is in the top-left of most keyboards, above Tab. That's the only new character involved. Everything inside ${ } is treated as JavaScript, so the value gets evaluated and dropped into the string wherever you put it.

The Actual Difference

The clearest way to see the improvement is to put both approaches next to each other doing the same job. Not a toy example. Something you'd actually write.

// String Concatenation
const user = "Riya";
const item = "headphones";
const price = 1299;
const currency = "INR";

const receipt = "Hi " + user + ", you bought " + item +
  " for " + currency + " " + price + "!";
// count the quotes. count the + signs. now imagine finding the bug.

// Template Literal
const user = "Riya";
const item = "headphones";
const price = 1299;
const currency = "INR";

const receipt = `Hi \({user}, you bought \){item} for \({currency} \){price}!`;
// read like a sentence. edit like a sentence. done.

Expressions, Not Just Variables

The ${ } slot takes any valid JavaScript expression. Not just variable names. A variable is just the simplest case. You can put math, function calls, ternaries, method calls, comparisons, if JavaScript can evaluate it to a value, it goes in there.

const a = 4; const b = 7;

// Math directly in the string 
const sum = \({a} + \){b} = ${a + b}; // "4 + 7 = 11"

// Function call 
const shout = Hello, ${"priya".toUpperCase()}!; // "Hello, PRIYA!"

// Ternary: conditional logic inside the string 
const stock = 0; const label = Item is ${stock > 0 ? "available" : "out of stock"}.; // "Item is out of stock."

Multi-Line Strings

This is where the old way falls apart completely. Building a multi-line string with concatenation means either pasting everything on one long line or escaping newlines with \n. Neither approach matches what the output actually looks like.

// String
const html = "<div class='card'>\n" +
  "  <h2>" + name + "</h2>\n" +
  "  <p>" + bio + "</p>\n" +
  "</div>";

// Template Literals
const name = "Riya";
const bio = "Frontend developer. Loves TypeScript.";

const html = `
  <div class="card">
    <h2>${name}</h2>
    <p>${bio}</p>
  </div>
`;

// the indentation in the code matches the indentation in the output.
// what you see is what you get.

The line breaks are real. The whitespace is real. You press Enter inside the backticks and it's in the string. No \n. No squinting at escape characters.

This matters most when building HTML fragments, SQL queries, email bodies, or any block of text that has real structure. You can format the string the way the output should look, and the two stay in sync.

Where You'll Actually Use This

Template literals show up in the same places strings show up. But there are a few spots where they make an especially big difference.

REFERENCES:

• Template literals : MDN Web Docs

• ECMAScript 2015 Specification Template Literals

That is this doing something you did not expect, because nobody explained the one idea that makes all of its behavior obvious. This post is built around that idea. Everything else follows from it.

What this Represents

this is the object that called the function. Not where the function was written, not where it lives in the file. Who called it, right now, at this moment.

Think of a customer service line. When someone calls in, the rep picks up and sees the caller's name on screen. That display changes every time a different person rings. The phone line is the function. The name on the display is this.

Here is the simplest version of that in code:

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

const user  = { name: "Rohan", greet };
const admin = { name: "Priya", greet };

user.greet();   // user called it: this = user
admin.greet();  // admin called it: this = admin

// OUTPUT:
// Hello, I am Rohan
// Hello, I am Priya

One function, written once. The dot before the method call is your clue every time: whatever is on the left of that dot when the function runs is this. Keep that in mind as you read the rest of this post.

this In The Global Context

Before any functions or objects, there is already a this. At the very top of a script, outside everything else, it points to the global object. In a browser that is window.

// Browser
console.log(this);            // Window {…}
console.log(this === window); // true

In Node.js the story is slightly different. At the top of a CommonJS file, this is the module's exports object, not Node's global. It looks like an empty object by default because nothing has been exported yet.

// Node.JS
console.log(this);                   // {}
console.log(this === global);         // false
console.log(this === module.exports); // true

You will almost never use the global this on purpose. What matters here is knowing it exists so you are not confused when it shows up unexpectedly in the console or in an error message.

this Inside Objects

When a function is called as a method of an object, this is that object. This is the case that feels the most natural and the one that matches what beginners usually expect. The object called the method, so the object is this.

const player = {
  name:  "Rohan",
  score: 1400,
  showScore() {
    console.log(this.name + " has " + this.score + " points");
  }
};

player.showScore();  // player is on the left: this = player

// OUTPUT:
// Rohan has 1400 points

Swap the caller, swap this. The same function attached to two different objects gives two different results:

const playerOne = { name: "Rohan", score: 1400 };
const playerTwo = { name: "Divya", score: 2100 };

function showScore() {
  console.log(this.name + " has " + this.score + " points");
}

playerOne.show = showScore;
playerTwo.show = showScore;

playerOne.show();  // this = playerOne
playerTwo.show();  // this = playerTwo

// OUTPUT:
// Rohan has 1400 points
// Divya has 2100 points

The Lost this

When you copy a method into a variable and call it, this is gone.

const player = {
  name: "Rohan",
  greet() {
    console.log("Hi, I am " + this.name);
  }
};

player.greet();          // `this` doesn't get lost

const fn = player.greet;  // just the function, no object
fn();                     // `this` gets lost

// OUTPUT:
// Hi, I am Rohan
// Hi, I am undefined

Passing a method as a callback is the same problem. setTimeout(player.greet, 1000) hands over the function with no object. When it runs a second later, this is not player. This shows up constantly in real code.

this Inside Regular Functions

When a plain function is called with nothing on the left of the dot, this defaults to the global object. In strict mode it becomes undefined instead, which is actually safer because it fails loudly.

// Non-strict. this defaults to Window
function whoAmI() {
  console.log(this);
}

whoAmI(); // Window {…} in the browser

// Strict mode. this becomes undefined
"use strict";

function whoAmIStrict() {
  console.log(this);
}

whoAmIStrict(); // undefined

ES modules are strict by default. If your files use import and export, strict mode is already on. Most modern JavaScript projects run in modules, so you already have this without thinking about it.

Nested Functions Lose this

A regular function written inside a method does not inherit the method's this. It resets. The inner function is called as a plain function, so it gets the global default. Proximity in code has no effect; only the call site matters.

const game = {
  title: "Space Run",
  start() {
    console.log(this.title); // "Space Run". this = game

    function inner() {
      console.log(this.title); // undefined. this reset to Window
    }

    inner(); // called alone. no object on the left
  }
};

game.start();

// OUTPUT:
// Space Run
// undefined

The fix for this is arrow functions, which do not reset this.

How the Calling Context Changes this

Because this is set at call time, you can control it. JavaScript gives you three methods for this: call, apply, and bind.

call() and apply()

Both invoke the function immediately and let you specify the object to use as this. The difference is just how you pass other arguments. call takes them one by one. apply takes an array.

function introduce(city, sport) {
  console.log(this.name + " is from " + city + " and plays " + sport);
}

const maya = { name: "Maya" };
const leo  = { name: "Leo"  };

introduce.call(maya,  "Mumbai",  "cricket");     // args one by one
introduce.call(leo,   "Lisbon",  "football");
introduce.apply(maya, ["Mumbai", "cricket"]);   // args as array

// OUTPUT
// Maya is from Mumbai and plays cricket
// Leo is from Lisbon and plays football
// Maya is from Mumbai and plays cricket

bind()

bind does not call the function. It returns a new copy with this permanently locked. That copy can be stored, passed around, and called later. It will always have the same this. This is the direct fix for the lost-this trap.

const player = {
  name: "Rohan",
  greet() {
    console.log("Hi, I am " + this.name);
  }
};

// Without bind, this is lost when passed as a callback
setTimeout(player.greet, 0);

// With bind, this is locked to player permanently
setTimeout(player.greet.bind(player), 0);

// OUTPUT:
// Hi, I am undefined
// Hi, I am Rohan

Arrow Functions and this

Arrow functions do not have their own this. They look at the code around them at the time they were written and borrow whatever this was in that scope. That value never changes, regardless of how the arrow function gets called later.

This is exactly what fixes the nested function problem:

const game = {
  title: "Space Run",
  start() {
    // Regular function: this resets to Window inside here
    function inner() {
      console.log("regular: " + this.title);
    }

    // Arrow: borrows this from start(), which is game
    const innerArrow = () => {
      console.log("arrow: " + this.title);
    };

    inner();       
    innerArrow();  
  }
};

game.start();

// OUTPUT:
// regular: undefined
// arrow: Space Run

Where Arrow Functions Go Wrong

Arrow functions work great inside methods. Used as a method directly on an object, they break. The surrounding scope at write time is the global scope, so that is what gets borrowed.

// Arrow as method: breaks
const player = {
  name: "Rohan",
  greetArrow: () => {
    // borrows global scope
    console.log(this.name);
  }
};

player.greetArrow();
// undefined

// Regular as method: works
const player = {
  name: "Rohan",
  greetRegular() {
    // set at call time = player
    console.log(this.name);
  }
};

player.greetRegular();
// Rohan

The practical rule: write methods on objects and classes with regular function syntax. Write callbacks inside those methods with arrow functions. That combination gives you the right this in both places without needing to think too hard about it.

All the Contexts at Once

Every case in this post comes from the same question: who is calling the function right now? Here is how each calling pattern maps to a result, and how to recognise which one you are looking at:

When you are unsure which case applies, ask the same question every time: what is on the left of the dot when this function is called? If there is an object, that is this. If there is nothing, you are in the plain function case. If you used call, apply, or bind, you set it yourself. Arrow functions are the only exception, they ignore the call site entirely and use whatever was in scope when they were written.

Most of the bugs you will encounter are just the extracted-method case. A function that worked on an object, passed somewhere as a callback, lost its caller. bind fixes it. Arrow callbacks inside methods fix it too. Once you see what is happening, the fix is never complicated.

REFERENCES:

• MDN: this

• JavaScript.info: Object methods and this

• MDN: Function.prototype.bind()

• MDN: Arrow function expression

Then your program grows. Say you are building something for college or work, and you need to track a group of candidates. You write something like this:

let student1Name  = "Chintu";
let student1Age   = 19;
let student1Grade = "A";

let student2Name  = "Pintu";
let student2Age   = 21;
let student2Grade = "B";

let student3Name  = "Mintu";
let student3Age   = 20;
let student3Grade = "A";


// Enter 50 more candidates

This works till the list starts to increase, and writing console.log for every candidate becomes a painful process. Adding new information becomes draining, and your code becomes more prone to typos. This is not something that is only related to new programmers. The code you are writing is functioning, but it does not scale. It is also fragile in ways that are not visible until something goes wrong.

There are a few principles that good programmers use to avoid situations like this, and they each have a name:

Object-Oriented Programming brings these principles together. You define the candidates using a template to define all their properties. This helps to create as many students as needed, tracking all the changes made. This template is known as a class.

What Does "Object-Oriented" Actually Mean?

Object-Oriented Programming is a style of writing code where you group related data and behaviour together into something called an object. A collection of properties is combined under one variable name, carrying methods along with it.

Consider a hospital that manages patients. The information of a patient, such as their name, age, and diagnosis are not kept in separate rooms. A single patient record is kept in one place. A doctor looks at the record, updates it, and reads from it. The data and the actions on that data live together. That is exactly what OOP is trying to replicate in code.

Real Life Analogy: Phone

Apple did not just create a single iPhone 17; they created a model defining the iPhone 15 as a device with an exact display size, camera, battery, call feature, and a camera. This specification is not an actual phone; rather, it is a description of what the phone will be.
Using this single specification, the factory produces millions of actual iPhones. The iPhone 17 owned by you and your friend are completely different physical objects. You may have an iPhone 17 that has 128GB of memory, and your friend may own an iPhone 17 your friend has 256GB of memory. You have two different iPhones. However, your iPhone and your friend's iPhone are both produced using the same model definition. Consequently, the way your iPhone and your friend's iPhone function is the same.
In JavaScript, the class corresponds to the model definition of the phone. The individual phones manufactured from that class model definition correspond to the objects. You only define the class once, and you create objects that correspond to that class as needed. Each object is unique, but all objects will share the same structure and behaviour as per the definition of the class.

Writing A Class

The earlier problem can be solved by using a class describing the properties, which allows you to generate many users or objects from one.
SYNTAX:

class ClassName {
  // code goes here
}

This is how class is declared, where class is a keyword followed by the name of the class that starts with a capital letter, which creates a visual difference between a regular variable and a class.

The Constructor

Whenever a new class is created, JavaScript invokes a method called the constructor. Let's consider an example of a student filling out an enrollment form that would collect information and store it in an object.

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

// Creating student objects from the class
const ram = new Student("Ram", 19, "A");
const shayam = new Student("Shyam", 21, "B");

console.log(ram.name);  // "Ram"
console.log(shayam.age);   // 21

When you write new Student("Ram", 19, "A"), JavaScript creates a new empty object and then runs a constructor to store the value. Inside the constructor, this refers to a brand new object. Hence, this.name = name indicates to take whatever is passed in as name and attach it to this new object as a property.

Adding Behaviour With Methods

Properties store data about an object, whereas methods define what an object can do. A Student object might hold a name and age, but it can also introduce itself, display its grade, or check whether it passed a course.
Methods are just functions, but they live inside the class and have access to the object's own data via this.

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

  // Method: introduce the student
  introduce() {
    return `Hi, my name is \({this.name} and I am \){this.age} years old.`;
  }

  // Method: show grade with a status
  getStatus() {
    if (this.grade === "A" || this.grade === "B") {
      return `\({this.name} is passing with a \){this.grade}.`;
    }
    return `${this.name} needs extra support.`;
  }
}

const karan = new Student("Karan", 18, "A");
const arjun = new Student("Arjun", 20, "C");

console.log(karan.introduce());
console.log(karan.getStatus());
console.log(arjun.introduce());
console.log(arjun.getStatus());

Notice that karan.introduce() and arjun.introduce() are both calling the same method, but each one knows its own name and age because this points to the right object each time.

Encapsulation

Encapsulation means the object's data and the code that operates on that data should be kept inside one block, and should not be accessed from outside to mess with internal values.

Here is a concrete example. Imagine a student's grade gets set to something nonsensical, like "Z" , because some part of your code sets it directly without any checks. Encapsulation is about protecting against that.

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

  // Instead of changing grade directly, use a method
  updateGrade(newGrade) {
    const validGrades = ["A", "B", "C", "D", "F"];

    if (validGrades.includes(newGrade)) {
      this.grade = newGrade;
      console.log(`\({this.name}'s grade updated to \){newGrade}.`);
    } else {
      console.log(`"${newGrade}" is not a valid grade.`);
    }
  }

  introduce() {
    return `Hi, I'm \({this.name}, currently at grade \){this.grade}.`;
  }
}

const rahul = new Student("Rahul", 18, "B");

rahul.updateGrade("A");    //Rahul's grade updated to A.
// This will be rejected
rahul.updateGrade("Z");  // "Z" is not a valid grade.

console.log(rahul.introduce()); // Hi, I'm Rahul, currently at grade A.

Object-Oriented Programming is not about memorising syntax. It's about bringing the disconnected variables and functions under one object. The way class works as a blueprint, a constructor sets up the object, and methods provide behaviour.

REFERENCES:

• MDN : Classes

• javaScript.info: Classes

• MDN : this

• javaScript.info: OOP Fundamentals

What is this ?

this keyword provides a way to know who called them, and the method and values they contain. When a function is called, this to point to the object that made the call.
Example:

this in Regular Functions

When you write a plain function and call it on its own, without any object in front of it, this gets set to the global object (global in Node, window in browser). In strict mode, it becomes undefined.

function whoAmI() {
  console.log(this);
}

whoAmI(); // window (browser), global (Node) or undefined (strict mode)

The function is called without any object in front, so this points to the global object and nothing meaningful.

this Inside Objects

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

const user = {
  name: "User",
  greet: function() {
    console.log("Hi, I'm " + this.name);
  }
};

user.greet(); // "Hi, I'm User"

Because user.greet() is called with user as the owner, this points to user, and this.name resolves to "User". Change the caller, and this changes with it.

Why It Breaks When You Copy A Method

Then a method is copied outside the object, stored in a variable, and it is called. this loses the context.

const user = {
  name: "User",
  greet: function() {
    console.log("Hi, I'm " + this.name);
  }
};

const detached = user.greet;
detached(); // "Hi, I'm undefined"

You copied the function reference, but this did not come along. When detached() runs, there is no object in front of it, so this is either global or undefined, and this.name comes back as undefined. The same problem happens when you pass an object method into setTimeout or an event listener.

This problem is solved by call(), apply(), and bind().

call(): Borrow a Function

call() invokes a function immediately and allows setting the context for that invocation by adding another argument.

// SYNTAX
call(thisArg)
call(thisArg, arg1, arg2,...,argN)

// Example
const user = {
  name: "User",
  greet: function() {
    console.log("Hi, I'm " + this.name);
  }
};

const anotherUser = { name: "Tom" };

// detached() broke because this was lost.
// call() fixes it by telling greet exactly what this should be.
user.greet.call(anotherUser);
// "Hi, I'm Tom"

// You can call it for any object you want
user.greet.call({ name: "Bob" });
// "Hi, I'm Bob"

Taking the same user object from above, we can borrow its greet method and run it for a completely different object.

apply(): call() With Array Arguments

apply() performs exactly like call(), the only difference is that we can pass multiple arguments in the form of an array instead of passing them one by one. The array gets unpacked into the function's parameter.
Take a function that greets a user with a custom message and a language tag. You want to run the same function for two different users, and the arguments you want to pass are already sitting in an array:

// SYNTAX
apply(thisArg)
apply(thisArg, argsArray)

// example
function greet(message, language) {
  console.log(message + ", " + this.name + " [" + language + "]");
}

const user1 = { name: "user1" };
const user2 = { name: "user2" };

const args = ["Hello", "EN"];

// call: you pass the args one by one
greet.call(user1, "Hello", "EN");  // "Hello, user1 [EN]"

// apply: you pass the args as an array, same result
greet.apply(user1, args);           // "Hello, user1 [EN]"
greet.apply(user2, args);           // "Hello, user2 [EN]"

The args is an array which could have been received from API response, form input, or another function output.

bind(): Lock The Context For Later

Unlike call() and apply(), bind() does not run the function at all. It creates and returns a brand new function with this permanently locked in, along with the arguments you passed, and this function can be called when needed.

bind() can be understood using:

const user = {
  name: "User",
  greet: function() {
    console.log("Hi, I'm " + this.name);
  }
};

// The bug: this is lost when greet is detached
const detached = user.greet;
detached(); // "Hi, I'm undefined"

// The fix: bind locks this to user permanently
const fixed = user.greet.bind(user);
fixed(); // "Hi, I'm User"

// Same fix for setTimeout — passes the function, not the result
setTimeout(user.greet, 1000);             // "Hi, I'm undefined"
setTimeout(user.greet.bind(user), 1000); // "Hi, I'm User"

Do not use setTimeout(user.greet(), 1000) with the parentheses included. That calls greet immediately and hands its return value, which is undefined, to setTimeout instead of scheduling the function itself. When passing functions as callbacks, leave the parentheses off, or use bind().

Another example is:

function log(...args) {
  console.log(this, ...args);
}

const boundLog  = log.bind("this value", 1, 2);
const boundLog2 = boundLog.bind("new this value", 3, 4);

boundLog2(5, 6);
// "this value", 1, 2, 3, 4, 5, 6

Let's understand it step by step:

Step 1: the first bind() - log.bind("this value", 1, 2) creates boundLog. It locks this to "this value" and fills the first two arguments as 1 and 2. Those arguments will always be passed first, no matter how boundLog is called later.

Step 2: trying to re-bind - boundLog.bind("new this value", 3, 4) tries to create a new function with a different this. Once this is locked by bind(), it cannot be changed, and the "new this value" gets ignored, because the bind() created a wrapper for boundLog, and when you try to create a new wrapper which try to provide new this gets ignored. Although, the value 3 and 4 gets added to the argument list.

Step 3: calling boundLog2(5, 6) - When boundLog2(5, 6) runs, the arguments arrive in the order they were locked in across all the bind calls, followed by whatever you pass at call time. That is why the output is "this value", 1, 2, 3, 4, 5, 6.

This behaviour is known as partial application.

call() vs apply() vs bind()

Logically, this should depend on where the function is written. Instead, it depends on who calls the function at the moment it runs. This information helps to understand the behaviour of this in a better way.

Functionally, both call() and apply() are ways to execute a function using a given this, and the only difference is whether the arguments are provided individually or all as an array. Each method behaves differently from the other; bind() is a completely different concept since it returns a new function with a predefined context to call whenever you desire. This makes bind() the best option for use with callbacks or any other code that is related to the event.

REFERENCES:

• MDN: The this keyword

• MDN: Function.prototype.call()

• MDN: Function.prototype.apply()

• MDN: Function.prototype.bind()

• javascript.info: Decorators and Forwarding

• javascript.info: Function Binding

const add = (a, b) => a + b;

This looks weird and alien at first, but once you understand this, it becomes a default for you to use in code.

What Are Arrow Functions?

Arrow functions are just a shorter way to write functions. That is the whole story. They behave similarly to regular functions in most cases; their syntax requires less typing and looks natural.

This is how a Function looks:

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

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

The same function can be written using arrow functions:

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

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

They produce the same output; the difference lies in the structure of the functions. The function keyword is dropped, and an arrow => is added between the parameter and the body.

Basic Syntax Breakdown

Arrow Function with Single Parameter

When arrow functions take a single parameter, the parentheses can be dropped.

// With parentheses, always valid
const shout = (word) => {
  return word.toUpperCase();
};

// Without parentheses, also valid with a single parameter
const shout = word => {
  return word.toUpperCase();
};

console.log(shout("hello")); // "HELLO"

Arrow Function with Multiple Parameters

When you have two or more parameters, the parentheses are not optional. They are required.

// Two parameters
const add = (a, b) => {
  return a + b;
};

console.log(add(3, 5));  // 8

// Three parameters
const fullName = (first, middle, last) => {
  return first + " " + middle + " " + last;
};

console.log(fullName("Amar", "Akbar", "Anthony")); // "Amar Akbar Anthony"

When there are no parameters, parentheses are still needed:

const greetWorld = () => {
  return "Hello, World!";
};

console.log(greetWorld()); // "Hello, World!"

Implicit Return vs Explicit Return

An explicit return means you write the return keyword yourself, inside curly braces.

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

An implicit return means the curly braces and the return keywords are dropped, and the arrow function will automatically return whatever expression follows the arrow:

const square = (n) => n * n; // implicit return

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

Here are some examples of the usage of these return types:

// Implicit

// Multiply two numbers
const multiply = (a, b) => a * b;
console.log(multiply(6, 7));  // 42

// Check if a number is even
const isEven = (n) => n % 2 === 0;
console.log(isEven(4));  // true
console.log(isEven(7));  // false

// Build a greeting string
const greet = (name) => `Hey, ${name}`;
console.log(greet("User"));  // "Hey, User"

// explicit

// Multi line body needs curly braces and explicit return
const describe = (n) => {
  const type = n % 2 === 0 ? "even" : "odd";
  return `\({n} is \){type}`;
};

console.log(describe(7));   // "7 is odd"
console.log(describe(12));  // "12 is even"

If curly braces are used, but the return keyword is not used, then the function would return undefined

const broken = (n) => { n * 2 }; // no return
console.log(broken(5)); // undefined

Arrow Functions vs Normal Functions

Hoisting of Arrow Function

Normal function declarations get hoisted to the top of their scope, which means you can call them before you define them in the file and it still works. Arrow functions stored in variables do not behave that way:

 // Normal function: this works 
console.log(sayHi()); // "Hi" -- called before definition

function sayHi() {
  return "Hi";
}

// Arrow function: this throws a ReferenceError
console.log(greet()); // ReferenceError: Cannot access before initialization

const greet = () => "Hi";

Arrow Function Importance

The arrow functions finds its real importance in array methods. Array Methods take a function as an argument, and make the code readable when used with arrow functions.

For example, there is an array of product prices and 10% discount is applied to it:

const prices = [29.99, 49.99, 9.99, 89.99];

// Using a normal function inside map
const discounted = prices.map(function(price) {
  return price * 0.9;
});

// Using arrow function
const discounted = prices.map((price) => price * 0.9);

console.log(discounted);
// [26.991, 44.991, 8.991, 80.991]

The arrow function makes things fit in a single line.

REFERENCES:

• MDN: Arrow function expressions

• javascript.info: Arrow functions, the basics

What is a Function?

Functions can be compared to a recipe card in a kitchen. It doesn't do anything unless someone picks it up, follows the instructions on the card, and creates the actual dish. In writing code, you are writing the recipe card by writing a function. Calling a function is the same as cooking from a recipe.Let's understand this through a simple example to greet user whenever a user enters a website:

// Doing this manually for every user is painful
console.log("Hello, User1");
console.log("Hello, User2");
console.log("Hello, User3");

This will be a painful process when the number of user keeps on increasing. Hence, we use functions:

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

greet("User1");
greet("User2");
greet("User3");

// Output
// Hello User1
// Hello User2
// Hello User3

The parameter gets filled with the argument whenever the function is called.

Functions can also give back a value using the return keyword which can be stored and used it elsewhere:

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

const total = add(5, 3);
console.log(total); // 8

When the return is encountered, the execution stops and send the value. If a value is returned, the line of code written after the return statement will not be executed.

Function Declaration Syntax

The function declaration starts with a keyword function, followed by a function name, along with parameters enclosed in parentheses if the function returns.

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

console.log(multiply(4, 6));   // 24
console.log(multiply(10, 3));  // 30

The function multiply is the block of code that can be called repeatedly and each function call is independent.

Another practical example can be:

function addTax(price, taxRate) {
  const tax = price * (taxRate / 100);
  return price + tax;
}

console.log(addTax(100, 18));   // price: 100, tax: 18%
console.log(addTax(250, 8));    // price: 250, tax: 8%
Function Expression Syntax

Function Expression Syntax

Function Expression is another way to create functions where a function is assigned to a variable. There is no function name as the variable name suffices.

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

console.log(multiply(4, 6));   // 24
console.log(multiply(10, 3));  // 30

The output is identical which means both fucntion works the same. The difference lies in how JavaScript handles the function.

Declaration vs Expression

Hoisting

When you execute a code, JavaScript doesn't run it line by line on the first read. Instead it scans the entire code on the first read to find all function declaration and variables and register them. This is called hoisting, where the declarations are placed at the top of the scope before the code runs. This means you can call a function declaration even if the call appears above the function definition in your file:

// Calling the function BEFORE it is defined in the file
console.log(square(5));  // This works fine

function square(n) {
  return n * n;    // 25
}

Function expression on the other hand, does not get hoisted. The variable is hoisted instead, but not the function. When the JavaScript runs the code line by line, and finally encounters the function to assign to that hoisted variable, the variable remains undefined or throws an error if declared with const or let.

// Calling before the expression is defined
console.log(square(5));  // ReferenceError: Cannot access 'square' before initialization

const square = function(n) {
  return n * n;
};

JavaScript know that square exist, but the function is not yet assigned to it. The variable lives in the temporal dead zone until the function is assigned to it in the case of const and let.

When to Use Each One

Both function definition works, the use case depends on the readability and intent.

Use Function declaration when: a named reuable utility is required that will not be reassigned which should be available across the file.

// A reusable utility - declaration makes sense here
function formatCurrency(amount) {
  return "$" + amount.toFixed(2);
}

console.log(formatCurrency(9.5));   // $9.50
console.log(formatCurrency(100));   // $100.00

Use a function expression when: a function is passed to another function, assign different fucntions in different conditions, or treating the fucntion as data. Callbacks, event handlers, and configuration options are all common situations where expressions feel natural.

const numbers = [3, 1, 8, 2, 5];

// Passing a function expression directly as an argument
const sorted = numbers.sort(function(a, b) {
  return a - b;
});

console.log(sorted);    // [1, 2, 3, 5, 8]

Another case:

const isLoggedIn = true;

const getWelcome = isLoggedIn
  ? function() { return "Welcome back!"; }
  : function() { return "Please log in."; };

console.log(getWelcome()); // Welcome back!

Function Scope

Function is JavaScript creates private space for variables declared with const or let inside the functions. Code outside the function will not be able to access the variable declared inside the function. This is known as local scope.

function makeGreeting() {
  // local variable
  const message = "Hello from inside!";  // Hello from inside!
  console.log(message);
}

makeGreeting();
// trying to access from outside
console.log(message);  // ReferenceError: message is not defined

The function did not encounter an error, but the moment an attempt was made to access the variable from outside of the function, the variable does not exist in the outer space.

Although, a function can access variables that are declared outside. They are known as global variables. The function looks for the variable outside if it cannot find variable in the outer scope.

const siteName = "MyShop";  // defined in outer scope

function showBanner() {
  // siteName is not declared here, so JS looks outward
  console.log("Welcome to " + siteName);
}

showBanner();  // Welcome to MyShop

The visual model is:

This scoping behaviour makes the function stay independent. Two functions can use variables with the same name inside its own scope without throwing an error.

Almost all of the JavaScript code that you will create will have functions at its core. In addition to knowing what a function is, how to create one using the two primary syntaxes, how to distinguish between a function declaration and function expression based on hoisting, and the scope, return values, default parameters, and passing functions as parameters.

To summarize the above: function declarations get hoisted while function expressions do not. Functions create their unique scope. Use return to get back a value whenever you need to return a value from a function, and since functions in JavaScript are also values, you can pass them around as if they were any other data type; this is what provides so much power and flexibility to JavaScript as a programming language.

REFERENCES:

• MDN: function declaration

• MDN: function expression

• MDN: Hoisting

• JavaScript.info: Function basics

• JavaScript.info: Function expressions

Node.js is, in reality, a collection of different software components where V8 and libuv are primary to operations:

• V8 Engine: This is the core engine that parses and executes your JavaScript, transforming it into machine code that the processor can understand.

• libuv: This C++ library is responsible for handling the file system, networking, timers, and the event loop, enabling Node to perform asynchronous, non-blocking tasks.

V8: The JavaScript Engine

The JavaScript engine was built by Google for Chrome. It is responsible for the execution of JavaScript code and executes it as fast as possible. When Ryan Dahl created Node.js, it was embedded with V8 to make JavaScript run outside the browser.
The journey of the code in a V8 engine would roughly look like this:

The Parser

The first job of V8 is to parse the code, that is, it would read through the code and build an Abstract Syntax Tree (AST). AST is a structured representation of the code. Consider a line of code: const x = 5 + 3 where it forms a tree of nodes of variable declaration, containing a binary expression, containing two number literals.

Parser's job is to throw SyntaxError even before the code is run. It looks for basic mistakes in your line of code.

const x = ;        // expected expected;
function ()  {}    // identifier expected
const return = 5;  // 'return' is not allowed as a variable declaration name.

How to see AST on your machine

You can see AST through Esprima, which you can install via npm install esprima

// create a js file ast.js
const esprima = require("esprima");

const code = `const x = 5 + 3`;

const ast = esprima.parseScript(code);

console.log(JSON.stringify(ast, null, 2));

// run node ast.js

// AST tree
{
  "type": "Program",
  "body": [
    {
      "type": "VariableDeclaration",
      "declarations": [
        {
          "type": "VariableDeclarator",
          "id": {
            "type": "Identifier",
            "name": "x"
          },
          "init": {
            "type": "BinaryExpression",
            "operator": "+",
            "left": {
              "type": "Literal",
              "value": 5,
              "raw": "5"
            },
            "right": {
              "type": "Literal",
              "value": 3,
              "raw": "3"
            }
          }
        }
      ],
      "kind": "const"
    }
  ],
  "sourceType": "script"
}

Ignition: The Interpreter

V8 hands over the AST to a component called Ignition, which compiles the AST into bytecode. Bytecode is not machine code, but it is instructions that the CPU understands and is executed by Ignition.

To see how it works:

Either create a JS file with code const x = 5 + 3 and run a command node --print-bytecode test.js in your terminal, or directly run node --print-bytecode --print-bytecode-filter="" --eval "const x = 5 + 3" .
You will notice an overwhelming response in your terminal, but in simple terms, what it does is:

// this may vary depending on V8 engine
LdaSmi [5]        // Load Small Integer 5 into the accumulator
Star r0           // Store accumulator into register r0

LdaSmi [3]        // Load Small Integer 3 into the accumulator
Star r1           // Store accumulator into register r1

Ldar r0           // Load r0 back into the accumulator
Add r1            // Add r1 to the accumulator  (5 + 3 = 8)

Star r2           // Store result (8) into register r2, this is x

The pipeline looks like:

TurboFan: The Optimising Compiler

V8 is pretty efficient in running the code. Ignition watches for the part of the code that executes often. A function, when called multiple times in a loop, is called hot code, which is sent to the second compiler called TurboFan. Its role is to analyse bytecode and compile it down to an optimised machine code. Now the functions that are frequently being called upon will be processed faster.

A simple function which V8 will optimise:

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

// Call it many times. V8 notices this is "hot"
let total = 0;
for (let i = 0; i < 1_000_000; i++) {
  total = add(total, i); // Always numbers
}
console.log(total); 

V8 also handles memory management through a process called garbage collection. When you create objects and variables, V8 allocates memory for them. When the code stops looking for the variables, V8 frees the memory space allocated to them. This is a periodic operation that might affect performance in heavy applications.

libuv: The Asynchronous Bridge

V8 can execute JavaScript code, but is unable to communicate with a file system, make network requests, or set timers without halting the ongoing process. For asynchronous operations, a communication channel needs to be established with the operating system, where a request can take an unpredictable amount of time. But the process cannot stay in an idle state.

The solution to this problem was libuv. It is a C library designed for Node.js that can handle the I/O operations without blocking the rest of your program.

The Thread Pool

It is common knowledge that Node.js is single-threaded, but libuv maintains worker threads in the background. By default, it provides us with four threads, which can be later configured using an environment variable: UV_THREADPOOL_SIZE .

// Run Node with 8 libuv threads instead of the default 4
UV_THREADPOOL_SIZE=8 node server.js

When fs.readFile() is called, JavaScript registers the callback, and the task of reading the file is handed over to the background threads. The thread is responsible for the blocking work, and when the task is completed, the result is put in the queue. The event loop will then pick it up and call the callback. This is how JavaScript became non-blocking.

const fs = require('fs');

console.log('1. Script starts');

// This goes to libuv's thread pool. It does NOT block here.
fs.readFile('./data.txt', 'utf8', (err, data) => {
  console.log('3. File read finished (came back from libuv)');
});

// This runs IMMEDIATELY after registering the file read
console.log('2. Still on the main thread - not blocked');

// output
// 1. Script starts 2. Still on the main thread - not blocked 3. File read finished (came back from libuv)

In the above code, line 2 prints before line 3, even though line 3 is written above it in the callback. The file reading was happening in the background the entire time line 2 was executing. This ordering is the direct result of how libuv works.

The Event Loop

The event loop is the bridge between V8 and libuv. As the name says, it is a loop that runs continuously to check for a pending task, and if there are any, it completes them.

Every iteration of the loop is called a tick. In every tick, the event loop follows an order of operations. libuv's role is to implement and drive the loop and call V8 whenever there is JavaScript code to execute.

The phase that is mostly put to use is the Poll Phase, where the Node waits for its I/O events. If there is nothing ready, it can block here momentarily, waiting for the OS to signal that a file read is completing, or a network packet is arriving. When work arrives from libuv's thread pool, it lands here.

The Full Picture: V8 + libuv

Your JavaScript code sits at the top. The Node.js APIs like fs or http are the interface Node exposes to you. Below that, V8 handles all the JavaScript execution while libuv handles the asynchronous operations involving the OS. Everything eventually reaches the OS at the bottom.

Let us trace exactly what happens when you run this familiar piece of code, step by step.

const fs = require('fs');

fs.readFile('file.json', 'utf8', function(err, data) {
  if (err) throw err;
  const users = JSON.parse(data);
  console.log(`Found ${users.length} users`);
});

console.log('Server is ready to accept requests');

The order of operations:

1. V8 parses and starts executing your script

2. fs.readFile is called, and Node.js hands this to libuv

3. libuv assigns the file read to one of its 4 background threads

4. V8 continues executing. console.log('Server is ready...') runs immediately

5. The background thread finishes reading file.json from disk

6. libuv puts your callback into the poll queue

7. The event loop picks it up in the poll phase

8. V8 executes your callback with the file contents

Notice that in step 4, the main thread did not halt its operation, waiting for the OS to finish reading the JSON file, showing that the task of waiting is handled by libuv.

Timers and setImmediate

Timers are also handled by libuv. Whenever a setTimeout function is called, libuv registers it. When the timer runs out, it places the callback in the queue, and this queue will be checked by the event loop on every tick to run the callbacks that are ready to be served.

setImmediate is a function specific to Node that schedules a callback for the Check Phase. The check phase comes after the Poll phase, which makes the setImmediate run after the I/O operations in the current tick, but before the timers in the next iteration.

Let's understand the execution order through:

console.log('A - synchronous, runs first');

setTimeout(() => {
  console.log('D - setTimeout fires in Timers phase');
}, 0);

setImmediate(() => {
  console.log('E - setImmediate fires in Check phase');
});

Promise.resolve().then(() => {
  console.log('C - Promise microtask runs before next phase');
});

console.log('B - still synchronous');

// output
// A - synchronous, runs first
// B - still synchronous
// C - Promise microtask runs before next phase
// D - setTimeout fires in Timers phase
// E - setImmediate fires in Check phase

C (Promise) runs before D and E (setTimeout and setImmediate), even though it comes after them. This is because Promise use microtask queue, which the event loop prioritizes to clean after every phase. Microtasks always get priority over regular callbacks.

V8 and libuv Task on Different Operations

Node.js is a combination of two software: V8 and libuv that work together through the event loop. V8 executes the JavaScript code on the main thread, whereas libuv is responsible for the asynchronous task, helping the Node to stay non-blocking.

The event loop is like a conductor, which, on every tick, works through its phases to run the callback ready to be served through V8. It is to be noted that the main thread should not be blocked with heavy synchronous tasks so that the system is able to handle all operations efficiently. Understanding the architecture helps to understand the sequence of operations and ways to handle heavy tasks.

REFERENCES:

• Node.js Docs: The Event Loop

• libuv.org : Official documentation

• V8 Developer Docs

• Philip Roberts: "What the heck is the event loop anyway?" (JSConf EU)

• Node.js Worker Threads

const username = "anon.codes";
const followers = 1240;
const bio = "building stuff on the internet";
const isPrivate = false;

This works for one person. But, what if you have 100 users? That would make 400 variables only for these four field. It would become a nightmare if you want to add profilePicture for the user, that add 100 variables. You could then try array:

const user = ["anon.codes", 1240, "building stuff on the internet", false];

But array are ordered list. To get the follower count, you have to remember it was stored at index 1. If you are building this with a teammate and they rearrange the order, every single read breaks silently. user[1] suddenly returns the bio instead of followers, and the app just shows the wrong thing with no error. That is the kind of bug that takes hours to find.

The real problem with both approaches is the same: the data has no labels. You know what the values mean, but the code does not. This is exactly the problem JavaScript objects were built to solve.

The JavaScript Objects

An object is a collection of key-value pairs. It allows us to bundle related data and behavior into a single, labeled entity. It is like a library, where every book is labeled with its genre, author, and title. You find them by their name.

Every piece of information has a label or key and the actual data or value. Here is the same user profile from before, written as an object:

const userProfile = {
  username: "anon.codes",   // key: username, value: "anon.codes"
  followers: 1240,          // key: followers, value: 1240
  bio: "building stuff on the internet",
  isPrivate: false,

  // Objects can even hold functions, called methods
  follow: function() {
    this.followers++;
    console.log("New follower added");
  }
};

This improves readability because we now access data like userProfile.username instead of indexing like user[1]. The relationship between the data is also maintained.
That last part, the follow function inside the object, is called a method. It is a function that belongs to the object. We will not go deep on methods in this post, but it is good to know they exist: objects can hold both data and behavior in the same place.

Everything is an Object or behaves like one.

Arrays vs Objects

Since we started with arrays as a comparison, it helps to see them side by side properly. They are not interchangeable. Each has a job.

Arrays are used to store data of same kind, like a list of usernames, notifications, etc. Objects are used to store different, multiple data for single entity, like a user's username, email, followers and following count, bio, profile picture, etc. In real apps: these two are combined in the form of array of user object, where each item is object of one user.

Creating an Object

An object is created using curly braces with key-value pair inside it known as object literal.

// Syntax
// Constructor
const o1 = new Object();

// Declaring it directly, commonly used
// example
const userProfile = {
  username: "anon.codes",
  followers: 1240,
  bio: "building stuff on the internet",
  isPrivate: false
};

The key comes first, then a colon, followed by the value. Each pair is separated by a comma. The keys do not need quotes around them as long as they follow standard variable naming rules (no spaces, no hyphens). The values can be any data type: strings, numbers, booleans, arrays, or even other objects.

Accessing Properties

There are two ways to read data from an object.

1. Dot Notation

const userProfile = {
  username: "anon.codes",
  followers: 1240,
  isPrivate: false
};

console.log(userProfile.username);   // "anon.codes"
console.log(userProfile.followers);  // 1240
console.log(userProfile.isPrivate);  // false

1. Bracket Notation: Bracket notation lets you pass the key as a string. It looks more like an array, but you are using a name instead of a number. The main reason to use it over dot notation is when your key is stored in a variable rather than written directly.

const userProfile = {
  username: "anon.codes",
  followers: 1240
};

// Works exactly like dot notation
console.log(userProfile["username"]);   // "anon.codes"

// The real use case: the key is in a variable
const field = "followers";
console.log(userProfile[field]);         // 1240

To gain a better understanding, let's consider an example where you are building a settings page where a user can edit his information. The field being editing gets stored in another variable like selectedVariable. To access the value, userProfile[selectedField] is needed. The dot notation will not work as userProfile.selectedField would look for selectedField as key, and would not find anything.

const userProfile = { username: "anon.codes", bio: "building stuff on the internet" };
const selectedField = "bio";

console.log(userProfile[selectedField]);   // "building stuff on the internet"
console.log(userProfile.selectedField);    // undefined 

Updating Object Properties

Updating a property is the same syntax as reading it, but with an assignment on the right.

const userProfile = {
  username: "anon.codes",
  followers: 1240,
  bio: "building stuff on the internet"
};

// User gained a new follower
userProfile.followers = 1241;

// User updated their bio
userProfile.bio = "Learn in public. building things.";

console.log(userProfile.followers);  // 1241
console.log(userProfile.bio);        // "Learn in public. building things."

Objects are mutable. When you update a property, you are changing the original object in memory. This is different from how strings behave, where every change gives you a new string and the original is untouched. With objects, the change happens in place.

Adding Properties

It is not necessary to define all the properties while creating the object. Objects let you add new fields after creation. If you assign value to a key that does not exist yet, then JavaScript adds it for you.

const userProfile = {
  username: "anon.codes",
  followers: 1240
};

// User added a profile picture and a location
userProfile.profilePicture = "avatar.jpg";
userProfile.location = "Lolpur";

console.log(userProfile);
// { username: "anon.codes", followers: 1240, profilePicture: "avatar.jpg", location: "Lolpur" }

Deleting Properties

Objects allows deletion of properties that are not needed. Use delete keyword to delete a property.

const userProfile = {
  username: "anon.codes",
  followers: 1240,
  tempToken: "abc123xyz"  // session token, not for display
};

// Remove the token before sending the profile to the frontend
delete userProfile.tempToken;

console.log(userProfile);
// { username: "anon.codes", followers: 1240 }

console.log(userProfile.tempToken);  // undefined

Checking If a Property Exist

If there is a need to check is a property exist or not, in operator is used. It returns boolean.

const userProfile = {
  username: "anon.codes",
  followers: 1240,
  bio: "building stuff on the internet"
};

console.log("bio" in userProfile);          // true
console.log("profilePicture" in userProfile); // false

// hasOwnProperty() is an older but equivalent approach
console.log(userProfile.hasOwnProperty("followers"));  // true
console.log(userProfile.hasOwnProperty("location"));   // false

Nested Object

When the value of a property is another object, then it is known as Nested Object.

const userProfile = {
  username: "anon.codes",
  followers: 1240,
  settings: {
    darkMode: true,
    language: "en",
    notifications: false
  }
};

// Access the top-level property
console.log(userProfile.username);                  // "anon.codes"

// Access the nested object's properties by chaining dots
console.log(userProfile.settings.darkMode);         // true
console.log(userProfile.settings.language);         // "en"

// Update a nested property the same way
userProfile.settings.notifications = true;
console.log(userProfile.settings.notifications);    // true

Looping Through Object Keys

To look throught the object, use for...in loop:

const userProfile = {
  username: "anon.codes",
  followers: 1240,
  isPrivate: false
};

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

//output
// username: anon.codes
// followers: 1240
// isPrivate: false

Inside the loop, key is a string holding the current property name. To get the value, you use bracket notation: userProfile[key]. You cannot use dot notation here because key is a variable, not the literal name of a property.

Methods to access object keys and values

There are three methods that can be used to access key, and values, and they return an array.

const userProfile = {
  username: "anon.codes",
  followers: 1240,
  isPrivate: false
};

// Get all the keys
console.log(Object.keys(userProfile));
// ["username", "followers", "isPrivate"]

// Get all the values
console.log(Object.values(userProfile));
// ["anon.codes", 1240, false]

// Get both, as [key, value] pairs
console.log(Object.entries(userProfile));
// [["username", "anon.codes"], ["followers", 1240], ["isPrivate", false]]

We started with four loose variables for a single user, saw why that falls apart at scale, and saw why an array is not the right tool for the job either. Objects solve both problems where data stays together, every field has a name, and you can read or update anything without knowing positions.

Objects become reality when you see API response, or someone else's code, and realize you can read it.

References:

• MDN: Working with Objects

• JavaScript.info: Objects

• MDN: for...in statement

• MDN: Object.keys()

But if you have ever stopped to wonder why console, setTimeout, and process are just... there, ready to use before your code does anything, the answer is global. It is the object Node.js quietly builds before your code even starts running, and it holds everything the runtime gives you for free.

Then in 2020, JavaScript introduced globalThis, which sounds like a small thing but solved a problem that had been quietly annoying developers for years.

What is Node.js, Actually?

JavaScript was built for browsers. Chrome, Firefox, Safari, all of them come with a JavaScript engine and a set of built-in tools like document, window, and fetch that let your code interact with a webpage.

Node.js had a different idea. It took V8, the same engine Chrome uses to run JavaScript, and stripped out everything browser-specific. The result was a JavaScript runtime that could run anywhere: on a server, on your machine, inside a build tool, wherever.

The language is the same. The environment is different. And just like browsers have an object that holds everything your code needs without importing it, Node.js has its own version of that.

In the browser, that object is window.

In Node.js, it is global.

global: The Object That Holds Everything

When Node.js starts up, it creates the global object and populates it with every built-in tool your code might need. When you type console.log(), Node.js is actually looking up global.console.log() behind the scenes.

// What you write:
console.log("I am global");
setTimeout(() => {}, 1000);

// What Node.js actually does:
global.console.log("I am global");
global.setTimeout(() => {}, 1000);

Node.js lets you skip the global. prefix, so it feels like these things exist on their own. But they are just properties on that one shared object.

console.log(global.console === console);       // true
console.log(global.setTimeout === setTimeout); // true

Here is a look at what lives on global by default:

Why this at the Top Level is Not global

Here is something that catches a lot of people off guard. If you open a Node.js file and log this at the top level, you do not get global.

console.log(this);           // {}
console.log(this === global); // false

The reason is that Node.js does not actually run your file directly. Before execution, it wraps your entire file in a function:

// Node.js silently does this before running your code:
(function(exports, require, module, __filename, __dirname) {

  // everything you write ends up in here

});

So your code is never truly at the top level. It is inside a function, and inside that function, this points to module.exports, not global. module.exports starts as an empty object, which is why you see {}.

console.log(this);                   // {}
console.log(this === global);        // false
console.log(this === module.exports); // true

If you call a regular function (not a method, not in strict mode), this inside it does resolve to global:

function test() {
  console.log(this === global); // true
}

test();

Here is the full picture:

The Problem globalThis Was Built to Solve

For a long time, Node.js developers used global and browser developers used window. That was fine until someone needed to write code that ran in both.

Say you build a utility library for formatting dates or handling errors and publish it on npm. Browser apps use it. Node.js apps use it. The moment you try to reference the global object directly, you are stuck:

// Crashes in Node.js
console.log(window.Math);
// ReferenceError: window is not defined

// Crashes in a browser
console.log(global.Math);
// ReferenceError: global is not defined

Neither name works in both places. So developers wrote workarounds like this:

const globalObject =
  typeof window !== "undefined" ? window :
  typeof global !== "undefined" ? global :
  typeof self   !== "undefined" ? self   :
  null;

It worked, but it was fragile and ugly. Every shared library had its own version of this block.

ES2020 replaced all of that with one thing.

globalThis: One Name That Works Everywhere

globalThis is a standard, universal way to access the global object regardless of where the code is running.

// In Node.js:
console.log(globalThis === global); // true

// In a browser:
console.log(globalThis === window); // true

// In a Web Worker:
console.log(globalThis === self);   // true

That messy workaround from above becomes:

const globalObject = globalThis;

globalThis did not replace global in Node.js. global is still valid and still works. The difference is portability:

If you are writing code that will only ever run in Node.js, global is fine. If there is any chance your code ends up in a browser or gets shared as a library, use globalThis.

// Both work in Node.js and point to the same object
console.log(global === globalThis);              // true
console.log(global.Math.PI);                     // 3.141592653589793
console.log(globalThis.Math.PI);                 // 3.141592653589793
console.log(globalThis.setTimeout === setTimeout); // true

Do Not Put Your Own Variables on global

Node.js will let you attach your own values to global. It will not throw an error. But it is a pattern that tends to create problems you only discover months later.

Here is a common beginner mistake. You have a username that needs to be accessible across multiple files, and attaching it to global seems like a clean shortcut:

// app.js
global.username = "User";
console.log("App started");

// greet.js
function greet() {
  console.log("Hello, " + username); // no import, just works
}

greet(); // "Hello, User"

This works right up until you have ten files, three months of code, and a bug where the username is printing wrong. You open greet.js looking for where username comes from, and there is nothing. No import. No declaration. You now have to trace through every file in the project to find where it was set.

Global variables have no trail. They appear from nowhere and make debugging slow and painful, especially when someone new joins the project.

The fix is straightforward:

// user.js
const username = "User";
module.exports = username;

// greet.js
const username = require("./user");

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

greet(); // "Hello, User"

Now anyone reading greet.js knows immediately where username comes from. No searching required. As the codebase grows, that clarity pays off every single time.

Conclusion

JavaScript was built for the browser, and Node.js pulled it out of that environment entirely. With that move came the need for a global object of its own, and that is global. Every built-in you use in Node.js without importing, console, setTimeout, process, Buffer, lives there.

The this behavior at the top level of a file is a side effect of how Node.js wraps your code in a function before running it. Once you know that, the {} output makes sense.

globalThis came along in ES2020 to give developers one consistent name for the global object across every JavaScript environment. In Node.js specifically, global and globalThis point to the same place. Which one you use depends on whether your code is staying in Node.js or needs to travel.

Either way, now you know where console.log actually comes from.

References

• Node.js: Global Objects

• MDN: globalThis

• javascript.info: Global Object