You already know JavaScript. You know it runs in the browser. The entire purpose was simple make web pages respond to user actions. But have you ever think why does it run in the browser at all?

Because something inside the browser is reading your JavaScript line by line and telling the computer what to do. That something is called a runtime engine. In Chrome, it's called V8. In Firefox, it's SpiderMonkey. Think of it as a translator JavaScript speaks, the engine listens, and the computer acts.

Now here's the problem. That translator only lived inside the browser. You couldn't take it outside. You couldn't run JavaScript on a server, talk to a database, read files on disk, or build an API. JavaScript was essentially trapped.

Ryan Dahl looked at this in 2009 and said what if we break it out? He took V8 out of Chrome and wrapped it with something extra. That wrapper became Node.js.

How Nodejs was build?

Ryan noticed that Google's V8 engine inside Chrome was fast, open-source, and not tied to the browser in any fundamental way. It was just a C++ library that could compile and execute JavaScript. So he pulled it out.

But V8 alone was only half the answer. He needed to give it hands. He wrapped V8 with a C library called libuv, which was built specifically to handle I/O operations file system calls, network connections, DNS lookups across different operating systems in a non-blocking way.

That combination is the entire foundation of Node.js.

V8

You don't need to understand V8 deeply to use Node.js. But a high-level picture helps.

V8 job is to take JavaScript code and turn it into something the CPU can actually. V8 reads your code, figures out what it's doing, and translates it into native machine code on the fly. This is called JIT(Just in time) compilation.

The result is that JavaScript runs fast compared to what anyone expected from a scripting language. V8 also handles memory management for you allocating it when you create objects, cleaning it up when you're done with them, through a process called garbage collection.

When Node.js runs your code, V8 is the one actually executing it. Node.js just sets the stage.

Event Drive Architecture

Let's use an analogy. Imagine a restaurant.

Traditional servers like PHP or Java with thread-per-request models work like a waiter who takes your order and then stands next to your table, doing absolutely nothing, until your food comes out of the kitchen. During that entire waiting time, that waiter is occupied. If 1,000 customers walk in, you need 1,000 waiters just standing around.

Node.js works like a smart waiter. They take your order, walk it to the kitchen, and immediately go take the next table's order. When the kitchen shouts "order up!", the waiter gets notified and delivers it. One waiter can handle 100 tables because they're never standing around waiting.

That's event-driven, non-blocking I/O. Instead of stopping everything while waiting for a database response or a file read, Node.js registers a callback and moves on. When the result is ready, it comes back via the event loop.

This is the reason Node.js can handle tens of thousands of concurrent connections on a single server process while traditional multi-threaded servers would be crushed under that load. Not because Node.js is faster at computation it's often not. But because it never idles.

Now here's how the Node.js runtime architecture actually fits together:

General use cases

• REST APIs and GraphQL Backends

• Streaming applications

• Serverless functions

• Internet of Things (IoT)

I hope you get to know something valuable from the article.

I’m currently deep-diving into the JavaScript, building projects and exploring the internals of the web. If you're on a similar journey or just love talking about JavaScript, let’s stay in touch!

• Connect on LinkedIn: Satpalsinh's Profile

• Follow my Blog: blogs.satpal.cloud

Keep coding and keep building.

A nested array (or a multi-dimensional array) is simply an array that contains other arrays as its elements.

Think of a standard array as a single-story egg carton. A nested array is more like a shipping crate filled with smaller boxes, some of which might contain even smaller boxes.

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

In the example above, 1 is at the top level, but 4 and 5 are buried three levels deep.

Why Bother Flattening?

Flattening is the process of reducing the dimensionality of an array. We do this because:

• Easier Iteration: It’s much simpler to run a single .map() or .forEach() on a flat list than to write recursive loops for every level.

• Data Consistency: Many UI components (like dropdowns or tables) expect a simple, linear array of items.

• Searchability: Finding a specific value is faster when you don't have to check every "sub-box."

Transformation

When we "flatten," we are essentially taking every element from the inner arrays and pushing them into a new, single-level array while maintaining their original order.

How to Flatten Arrays:

flat()

Introduced in ES2019, the .flat() method is the gold standard. By default, it flattens one level deep, but you can pass a depth or use Infinity to go all the way.

const multidimensional = [1, [2, [3, [4]]]];

console.log(multidimensional.flat()); // [1, 2, [3, [4]]]

console.log(multidimensional.flat(Infinity)); // [1, 2, 3, 4]

reduce() and concat()

Before .flat() existed, this was the go-to manual method. It helps you understand the logic of the transformation: "Take the accumulator, and merge it with the current item."

const nested = [1, [2, 3], [4]];
const flat = nested.reduce((acc, val) => acc.concat(val), []);

toString() and split()

If your array only contains numbers or strings, you can convert the whole thing to a string (which removes brackets) and then split it back.

Note: Use this with caution, as it turns everything into strings!

When you see a nested structure, just ask yourself about the depth.

• Is it always one level deep? Use [].concat(...arr).

• Is the depth unknown? Use .flat(Infinity).

• Are you on an older environment (like legacy IE)? You'll need a recursive polyfill.

Flattening isn't just about making arrays shorter; it’s about making your data usable.

Most of the time those assumptions hold. Then they don't and what happens next is entirely up to you.

JavaScript gives you a system for managing failures without letting them crash the whole program. Understanding it isn't just about catching errors. It's about writing code that fails gracefully code that tells you exactly what went wrong, cleans up after itself, and gives the user something useful instead of a blank screen or a frozen UI.

What errors actually are in JavaScript

When JavaScript encounters something it can't handle dividing by something illegal, calling a method on undefined, trying to parse malformed JSON it creates an Error object and throws it. This throw unwinds the call stack, skipping everything below it, until something catches it or it reaches the top level and crashes your program.

const user = null;
console.log(user.name); // TypeError: Cannot read properties of null

That TypeError is a real object. It has a message (what went wrong), a name (the type of error), and a stack (the trace of function calls that led here). JavaScript creates it, throws it, and your program stops unless something is listening for it.

JavaScript has several built-in error types:

• TypeError (wrong type)

• ReferenceError (variable doesn't exist)

• SyntaxError (invalid code)

• RangeError (value out of bounds).

They all inherit from the base Error class.

The try/catch block

try/catch lets you put risky code in a guarded zone. If anything throws inside try, execution jumps immediately to catch and you decide what to do with the error instead of letting it crash your program.

try {
  const data = JSON.parse("this is not valid json");
  console.log(data);
} catch (error) {
  console.error("Failed to parse:", error.message);
}

// Failed to parse: Unexpected token 'h', "this is n"... is not valid JSON

Without try/catch, that JSON.parse throws a SyntaxError and everything stops. With it, you catch the error, log it clearly, and your program keeps running.

The error object passed to catch is whatever was thrown. It has two properties you'll use constantly:

try {
  undeclaredVariable;
} catch (error) {
  console.log(error.name);    // "ReferenceError"
  console.log(error.message); // "undeclaredVariable is not defined"
}

The finally block

finally is a block that runs no matter what whether the try succeeded, whether the catch triggered, whether an error was re-thrown. It always runs.

function loadData() {
  showSpinner();

  try {
    const result = fetchSomething();
    display(result);
  } catch (error) {
    showErrorMessage(error.message);
  } finally {
    hideSpinner(); // always runs — success or failure
  }
}

hideSpinner() runs whether fetchSomething succeeded or crashed. Without finally, you'd have to call hideSpinner() in both the try and the catch, duplicating cleanup logic. finally exists precisely for this: teardown, cleanup, resource release anything that must happen regardless of outcome.

Here's the full execution order laid out clearly:

Throwing custom errors

JavaScript lets you throw anything but throwing a proper Error object (or a subclass of it) is best practice because it gives you a stack trace and a message.

function divide(a, b) {
  if (b === 0) {
    throw new Error("Cannot divide by zero");
  }
  return a / b;
}

try {
  const result = divide(10, 0);
} catch (error) {
  console.error(error.message); // "Cannot divide by zero"
}

You're not waiting for JavaScript to fail you're proactively saying "this situation is invalid" and throwing your own error. The caller's catch block handles it just like any built-in error.

For larger applications, creating custom error classes makes your error handling more precise you can catch specific error types and respond differently:

class ValidationError extends Error {
  constructor(message, field) {
    super(message);
    this.name = "ValidationError";
    this.field = field;
  }
}

class NetworkError extends Error {
  constructor(message, statusCode) {
    super(message);
    this.name = "NetworkError";
    this.statusCode = statusCode;
  }
}

function processForm(data) {
  if (!data.email.includes("@")) {
    throw new ValidationError("Invalid email address", "email");
  }
}

try {
  processForm({ email: "notanemail" });
} catch (error) {
  if (error instanceof ValidationError) {
    console.log(`Validation failed on field: ${error.field}`);
    highlightField(error.field);
  } else if (error instanceof NetworkError) {
    console.log(`Network failed with status: ${error.statusCode}`);
    showRetryButton();
  } else {
    console.error("Unexpected error:", error);
  }
}

instanceof lets you branch on error type different failures get different responses instead of one generic "something went wrong" message.

Error handling with async/await

try/catch works exactly the same way with async/await. Rejected promises become catchable errors:

async function loadUserData(id) {
  try {
    const response = await fetch(`/api/users/${id}`);

    if (!response.ok) {
      throw new NetworkError("Request failed", response.status);
    }

    const user = await response.json();
    return user;
  } catch (error) {
    if (error instanceof NetworkError) {
      console.error(`HTTP \({error.statusCode}: \){error.message}`);
    } else {
      console.error("Unexpected error:", error.message);
    }
    return null;
  } finally {
    hideLoadingIndicator();
  }
}

Same underlying problem. Completely different user experience. Error handling is how you translate a technical failure into a useful human message.

A pattern worth building into any serious application:

async function safeLoadDashboard() {
  try {
    const [user, stats, notifications] = await Promise.all([
      fetchUser(),
      fetchStats(),
      fetchNotifications()
    ]);

    renderDashboard(user, stats, notifications);
  } catch (error) {
    console.error("Dashboard load failed:", error);
    renderErrorState("Unable to load dashboard. Please refresh.");
  } finally {
    hideGlobalSpinner();
  }
}

If any of the three fetches fail, catch handles it.

getUser(userId)
  .then(user => {
    return getOrders(user.id);
  })
  .then(orders => {
    return getProduct(orders[0].productId);
  })
  .then(product => {
    console.log(product.name);
  })
  .catch(err => {
    console.error(err);
  });

It works. But it reads sideways. Each .then() is a new indentation, a new callback, a new mental context to hold. You can't easily share variables between steps without hoisting them outside the chain. Error handling applies to the whole chain but it's tacked on at the end, invisible until something breaks.

async/await was introduced in ES2017 to fix exactly this. Not by replacing promises by giving you a way to write promise-based code that looks and reads like regular synchronous code.

Syntactic sugar over promises

The first thing to understand is that async/await is not a new async system. It's a new syntax for working with promises. Under the hood, every async function returns a promise. Every await pauses execution and waits for a promise to resolve. No new engine magic just a cleaner way to write what you were already doing.

Think of it this way. Promises gave you a contract: "this will eventually have a value." async/await gives you a way to write code as if that value is already there, and JavaScript handles the waiting behind the scenes.

The async keyword

Putting async before a function declaration does one thing: it makes that function always return a promise. Even if you return a plain value, JavaScript automatically wraps it in a resolved promise.

async function greet() {
  return "Hello!";
}

greet().then(msg => console.log(msg)); // "Hello!"

You returned a string. But because the function is async, the caller receives a promise that resolves to that string. That's the contract.

You can use async with any function style:

// function declaration
async function fetchData() { ... }

// arrow function
const fetchData = async () => { ... }

// method in an object
const api = {
  async getUser() { ... }
};

The await keyword

await can only live inside an async function. It pauses that function's execution until the promise it's waiting on resolves then hands you the resolved value directly.

async function loadUser() {
  const user = await getUser(1); // pauses here until resolved
  console.log(user.name);        // then continues
}

Without await, getUser(1) returns a promise object not the user. With await, you get the user directly, as if the function was synchronous. The pause is real but it's non-blocking: while this function is waiting, JavaScript keeps running everything else.

Here's what that promise chain from earlier looks like rewritten with async/await:

async function loadProductFromUser(userId) {
  const user    = await getUser(userId);
  const orders  = await getOrders(user.id);
  const product = await getProduct(orders[0].productId);

  console.log(product.name);
}

Top to bottom. Left to right. Each line waits for the previous one before moving on. No callbacks. No indentation staircase. It reads like a recipe: get the user, get their orders, get the first product, show its name.

Here's the execution flow when you call an async function:

JavaScript is single-threaded. It runs one piece of code at a time, which means when you perform a slow operation, like fetching data from a server, reading a file, or waiting for a timer.

The entire thread can't afford to stop and wait. Instead, JavaScript uses an event-driven, asynchronous model: kick off the work, continue with other things, and handle the result when it's ready.

The earliest pattern for this was the callback you pass a function to another function, and that function calls yours back when the work completes. This works, but it breaks down fast. Imagine fetching a user, then fetching their posts, then fetching comments on each post. You end up nesting callbacks inside callbacks inside callbacks code that fans rightward across the screen, where error handling is duplicated at every level and the logical sequence of operations is buried in indentation. Developers called this callback hell.

Promises were introduced to solve this. A promise represents a value that isn't available yet, but will be in the future or won't arrive at all because something went wrong. Instead of passing callbacks into every function, you work with an object that carries the result of an asynchronous operation, with a clean, chainable API for handling success and failure.

Promise states

Every promise lives in exactly one of three states at any given moment:

Pending: The operation is in progress. No result yet. This is the starting state.

Fulfilled: The operation completed successfully. The promise now holds the resolved value.

Rejected: The operation failed. The promise now holds a reason, typically an Error object explaining what went wrong.

The key rule: once a promise transitions out of pending, it never changes again. A fulfilled promise stays fulfilled forever. A rejected promise stays rejected. This predictability is one of the things that makes promises much easier to reason about than raw callbacks.

Creating a promise

You create a promise by calling the Promise constructor and passing it an executor, a function that receives two callbacks: resolve and reject. You call one of them when the async work finishes.

const fetchUser = new Promise((resolve, reject) => {
  setTimeout(() => {
    const success = true; // pretend this comes from a network call

    if (success) {
      resolve({ id: 1, name: 'Priya' }); // fulfills the promise
    } else {
      reject(new Error('User not found')); // rejects the promise
    }
  }, 1000);
});

The executor runs immediately when new Promise(...) is called. The resolve and reject callbacks settle the promise and trigger any handlers that have been attached.

Handling success and failure

Once you have a promise, you react to its outcome using .then(), .catch(), and .finally():

fetchUser
  .then((user) => {
    console.log('Got user:', user.name); // runs if resolved
  })
  .catch((error) => {
    console.error('Failed:', error.message); // runs if rejected
  })
  .finally(() => {
    console.log('Done loading'); // always runs
  });

.then() receives the resolved value. .catch() receives the rejection reason. .finally() receives nothing.

It's purely for cleanup (hiding a loading spinner, closing a connection). A critical point: .finally() doesn't consume the promise value. Whatever the promise settled with flows through .finally() unchanged to any subsequent handler.

Callbacks vs promises

Let's look at a concrete comparison. Three sequential async operations: load a user, then load their orders, then calculate their total spend.

loadUser(userId, function(err, user) {
  if (err) return handleError(err);
  loadOrders(user.id, function(err, orders) {
    if (err) return handleError(err);
    calculateSpend(orders, function(err, total) {
      if (err) return handleError(err);
      console.log('Total spend:', total);
    });
  });
});

With promises:

loadUser(userId)
  .then((user) => loadOrders(user.id))
  .then((orders) => calculateSpend(orders))
  .then((total) => console.log('Total spend:', total))
  .catch(handleError);

The logic is identical. But the promise version reads like a linear sequence of steps because it is one. Error handling is consolidated in a single .catch() at the end rather than duplicated at every level.

Promise chaining

Promise chaining is possible because .then() always returns a new promise. Whatever value you return from inside a .then() callback becomes the resolved value of that new promise, which the next .then() in the chain receives.

fetchUser(1)
  .then((user) => {
    return fetchPostsByUser(user.id); // returns another promise
  })
  .then((posts) => {
    return posts.filter((p) => p.published); // returns a plain array
  })
  .then((publishedPosts) => {
    console.log(publishedPosts.length, 'published posts');
  })
  .catch((err) => {
    // any rejection in the chain above lands here
    console.error('Something went wrong:', err.message);
  });

The chain automatically unwraps promises: if you return a promise from inside .then(), the next .then() waits for that inner promise to settle before it fires. If you return a plain value, it's wrapped into a resolved promise automatically. This is the mechanism that makes chaining work seamlessly for both sync and async return values.

A note on async/await

Modern JavaScript introduced async/await as syntax sugar built directly on top of promises. An async function always returns a promise, and await pauses execution inside that function until a promise settles without blocking the thread. It makes promise-based code look synchronous:

async function loadDashboard(userId) {
  try {
    const user = await fetchUser(userId);
    const orders = await fetchOrders(user.id);
    const total = await calculateSpend(orders);
    console.log('Total spend:', total);
  } catch (err) {
    console.error('Failed:', err.message);
  }
}

This is the same sequence as the promise chain above, just written differently. Understanding promises deeply states, .then(), .catch(), chaining is essential before async/await makes sense, because under the hood, that's exactly what it's doing.

In JavaScript, strings come with a powerful set of built-in methods functions attached to every string value that let you search, transform, slice, and inspect text. When you call "hello".toUpperCase(), you're using a method that JavaScript's engine provides automatically. These aren't magic; they're functions defined on String.prototype, the shared blueprint that every string inherits from.

The key insight for interview preparation is this: knowing what a method does isn't enough. Interviewers want to know how it works and whether you could rebuild it from scratch. That's where polyfills come in.

Why developers write polyfills

A polyfill is a piece of code that implements a feature that the current runtime doesn't support or that you're implementing yourself to demonstrate understanding. When a new string method lands in the JavaScript specification, older browsers don't have it. Developers write polyfills to bridge that gap, attaching the implementation directly to String.prototype before the browser's built-in version would run.

But in interviews, polyfills serve a different purpose. They force you to reason about the logic behind familiar tools. Can you write trim() without calling trim()? Can you implement includes() using only index-based access? These questions reveal how deeply you understand strings as sequences of characters.

Here's how the string processing model works under the hood:

One important detail the diagram highlights: strings in JavaScript are immutable. No string method ever modifies the original string.

Implementing simple string utilities as polyfills

Before writing a polyfill, always check if the method already exists. This prevents overwriting the native implementation in environments that support it.

if (!String.prototype.customTrim) {
  String.prototype.customTrim = function () {
    // `this` refers to the string value the method is called on
    let start = 0;
    let end = this.length - 1;

    while (start <= end && this[start] === ' ') start++;
    while (end >= start && this[end] === ' ') end--;

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

The logic here is a two-pointer approach.

Advance from the left until you hit a non-space character, retreat from the right until you hit a non-space character, then slice out the middle. This is exactly the kind of thinking interviews test: can you express a simple operation in terms of indices and comparisons?

Here's how the polyfill checking behavior works visually:

Common interview string methods to implement

includes(searchStr)

The built-in method checks whether a substring exists anywhere in the string, returning true or false. The polyfill uses a sliding window: at every position, compare the next searchStr.length characters against the target.

String.prototype.myIncludes = function (searchStr) {
  const str = String(this);
  const search = String(searchStr);

  if (search.length === 0) return true;
  if (search.length > str.length) return false;

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

Note the edge cases: an empty search string always returns true (this matches the spec), and a search string longer than the source immediately returns false.

repeat(count)

This builds a new string by concatenating the original count times.

String.prototype.myRepeat = function (count) {
  const n = Math.floor(count);
  if (n < 0 || n === Infinity) throw new RangeError('Invalid count value');
  let result = '';
  for (let i = 0; i < n; i++) result += this;
  return result;
};

startsWith(prefix) and endsWith(suffix)

These are slice comparisons at fixed positions:

String.prototype.myStartsWith = function (prefix) {
  return this.slice(0, prefix.length) === prefix;
};

String.prototype.myEndsWith = function (suffix) {
  if (suffix.length === 0) return true;
  return this.slice(-suffix.length) === suffix;
};

padStart(targetLength, padStr) and padEnd()

Padding methods fill the string until it reaches a desired length:

String.prototype.myPadStart = function (targetLength, padStr = ' ') {
  const str = String(this);
  if (str.length >= targetLength) return str;
  const padNeeded = targetLength - str.length;
  let padding = '';
  while (padding.length < padNeeded) padding += padStr;
  return padding.slice(0, padNeeded) + str;
};

A Map is a collection of keyed data items, similar to an Object. However, the primary difference is that Map allows keys of any type functions, objects, or even primitives.

Map vs Object

What is a Set?

A Set is a collection of values where each value must be unique. Think of it as an Array with a built-in "no duplicates" policy.

The Power of Uniqueness

The most common use case for a Set is instantly cleaning an array. If you have a list of user IDs with duplicates, you can wipe them out in one line:

const uniqueIds = [...new Set([1, 2, 2, 3, 4, 4])]; // [1, 2, 3, 4]

Set vs. Array

• Search Speed: Checking if an item exists in an Array (arr.includes(x)) takes O(n) time. In a Set (set.has(x)), it is O(1). If you have 10,000 items, the Set is orders of magnitude faster.

• No Duplicates: Arrays allow you to push the same value a million times. Sets silently ignore duplicates, keeping your data clean automatically.

When to reach for Map and Set

Use a Map when:

• You need keys that aren't strings (e.g., associating metadata with a DOM element).

• You need to frequently add and remove key-value pairs (Maps are optimized for this).

• You need to iterate over data in the exact order it was added.

Use a Set when:

• You are dealing with a list where duplicates are logically impossible or unwanted (like a list of "Liked" posts).

• You need to perform high-speed "existence checks" (checking if a username is already taken in a local list).

One expands things out. The other collects things in.

By the end of this, you'll look at ... and immediately know which one it is and what it's doing. Let's go.

The Three Dots ...

Before we split them apart, let's establish what they share.

Both the spread operator and the rest operator are written as ... three dots, nothing more. JavaScript figures out which one you mean based entirely on where you use it.

Think of it like the word "run." The same word means completely different things in "I run every morning" and "a run of bad luck." Context does all the work. Same idea here.

Spread

Expanding Things Out. The spread operator takes something that's grouped together like an array or object and expands its contents out individually.

Imagine you have a box of apples. Spread tips the box over and lays every apple out on the table individually. The box is gone. Just apples.

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

console.log(fruits);    // ["apple", "mango", "banana"]  ← the box
console.log(...fruits); // apple mango banana             ← apples on table

That's it. ...fruits says don't give me the array, give me everything inside it.

Rest

Collecting Things In. The rest operator does the exact opposite. It takes a bunch of individual values and collects them into an array.

If spread tips the box over, rest is the box itself gathering loose items and packaging them together.

function collect(...items) {
  console.log(items); // ["apple", "mango", "banana"]
}

collect("apple", "mango", "banana");

You passed three separate strings. Rest collected them into one neat array called items.

Spread with Arrays

This is where spread gets genuinely useful. Here are the four things you'll do with it all the time.

Copying an array:

const original = [1, 2, 3];
const copy = [...original];

copy.push(4);

console.log(original); // [1, 2, 3] — untouched
console.log(copy);     // [1, 2, 3, 4]

Without spread, doing const copy = original just creates another pointer to the same array. Change one, change both. Spread makes a real independent copy.

Merging arrays:

const frontend = ["HTML", "CSS", "JavaScript"];
const backend  = ["Node.js", "Express", "MongoDB"];

const fullStack = [...frontend, ...backend];
// ["HTML", "CSS", "JavaScript", "Node.js", "Express", "MongoDB"]

Clean and readable. No loops. No .concat().

Adding items while spreading:

const skills = ["CSS", "JavaScript"];
const updatedSkills = ["HTML", ...skills, "React"];
// ["HTML", "CSS", "JavaScript", "React"]

You can place ... anywhere in the array literal. Items before, after, or both.

Passing array items as function arguments:

const nums = [4, 8, 2, 6];

console.log(Math.max(nums));    // NaN — Math.max wants numbers, not an array
console.log(Math.max(...nums)); // 8   — spread unpacks them perfectly

Math.max expects individual numbers like Math.max(4, 8, 2, 6). Spread converts your array into exactly that.

Spread with Objects

Spread works on objects too — and it's used constantly in modern JavaScript, especially in React.

Copying an object:

const user = { name: "Satpal", age: 25 };
const copy = { ...user };

copy.age = 30;

console.log(user.age); // 25 — original untouched
console.log(copy.age); // 30

Merging objects:

const defaults = { theme: "light", language: "en", fontSize: 14 };
const userPrefs = { theme: "dark", fontSize: 18 };

const settings = { ...defaults, ...userPrefs };
// { theme: "dark", language: "en", fontSize: 18 }

When keys clash, the last one wins. userPrefs.theme overwrote defaults.theme. This pattern — merge defaults, then override with user values is everywhere in real code.

Updating one field without mutating:

const user = { name: "Riya", age: 24, city: "Mumbai" };

const updated = { ...user, age: 25 };
// { name: "Riya", age: 25, city: "Mumbai" }

You spread all existing properties, then write the one you want to change. The original user object is never touched. This is the standard pattern in React state updates.

Rest

Collecting Function Arguments. Rest shines in functions. It lets you accept any number of arguments without knowing in advance how many there will be.

function sum(...numbers) {
  return numbers.reduce((total, n) => total + n, 0);
}

sum(1, 2);           // 3
sum(1, 2, 3, 4, 5);  // 15
sum(10, 20);         // 30

...numbers scoops up every argument passed in and packages them into an array. Then you can use all your normal array methods on them.

Mix regular parameters with rest:

function introduce(greeting, ...names) {
  names.forEach(name => {
    console.log(greeting + ", " + name + "!");
  });
}

introduce("Hello", "Priya", "Arjun", "Dev");
// Hello, Priya!
// Hello, Arjun!
// Hello, Dev!

greeting catches the first argument normally. ...names catches everything after it. The rest parameter must always come last nothing can follow it.

Difference:

What it does:

Quick Rule:

The Quick Reference

So you write this:

const user = {
  name: "Priya",
  email: "priya@example.com",
  age: 28,
  city: "Pune",
  plan: "premium"
};

console.log(user.name);
console.log(user.email);
console.log(user.age);
console.log(user.city);

It works. But user. appears everywhere.

Destructuring is JavaScript's way of saying: pull out what you need, give it a name, and work with it directly.

What destructuring means

Destructuring is a syntax for unpacking values from arrays or properties from objects into individual variables. In one line, you extract multiple values and name them. After that line, you work with plain variables no more reaching back into the original structure every time.

It doesn't modify the original object or array. It just creates new variables that hold copies of the values.

Destructuring objects

The syntax uses curly braces on the left side of an assignment. The variable names inside the braces must match the property names in the object.

const user = {
  name: "Priya",
  email: "priya@example.com",
  age: 28,
  city: "Pune"
};

const { name, email, age } = user;

console.log(name);  // "Priya"
console.log(email); // "priya@example.com"
console.log(age);   // 28

One line. Three variables. You've extracted exactly what you need and nothing more. After that line, you just use name, email, age clean, direct, no repeated user. prefix.

Here's what's actually happening each variable on the left matches a key in the object, and gets assigned that key's value:

Renaming while destructuring

What if a property name is too generic, or clashes with another variable in your scope? You can rename on the fly using a colon:

const { name: userName, city: userCity } = user;

console.log(userName); // "Priya"
console.log(userCity); // "Pune"

Read the colon as "rename to". The left side is the key to look for in the object. The right side is the variable name you want locally.

Destructuring arrays

Array destructuring uses square brackets instead of curly braces. Here, order matters variables are assigned based on their position in the array, not by name.

const scores = [95, 82, 77, 68, 55];

const [first, second, third] = scores;

console.log(first);  // 95
console.log(second); // 82
console.log(third);  // 77

The first variable gets index 0, the second gets index 1, and so on. The rest of the array is simply ignored.

Need to skip a position? Leave a hole with a comma:

const [top, , bronze] = scores;

console.log(top);    // 95
console.log(bronze); // 77

The empty slot between the two commas skips index 1 entirely. You're essentially saying: "I want position 0 and position 2, nothing else."

Here's the positional mapping laid out:

The swap trick

One of the most satisfying uses of array destructuring is swapping two variables without a temporary holder:

let a = 10;
let b = 20;

[a, b] = [b, a];

console.log(a); // 20
console.log(b); // 10

Before destructuring, swapping required three lines and a temp variable. Now it's one line and reads almost like plain English.

Default values

What happens when you destructure a property that doesn't exist? You get undefined. Default values let you specify a fallback instead.

In object destructuring:

const settings = { theme: "dark" };

const { theme, fontSize = 16, language = "en" } = settings;

console.log(theme);    // "dark"    — came from the object
console.log(fontSize); // 16        — default, not in object
console.log(language); // "en"      — default, not in object

The default only kicks in when the value is undefined. If the property exists but is set to null or 0 or "", the default is ignored — those are real values.

In array destructuring:

const colors = ["red"];

const [primary = "blue", secondary = "gray"] = colors;

console.log(primary);   // "red"  — came from array
console.log(secondary); // "gray" — default, array only had one item

This is especially useful when writing functions that accept optional configuration you give sensible defaults right at the destructuring line instead of writing a wall of if checks inside the function body.

Destructuring in function parameters

This is where destructuring really starts to clean up real code. Instead of receiving an object and then reaching into it, you destructure it directly in the parameter list:

function renderProfile(user) {
  return `\({user.name}, \){user.age} — ${user.city}`;
}

function renderProfile({ name, age, city }) {
  return `\({name}, \){age} — ${city}`;
}

renderProfile({ name: "Rohan", age: 24, city: "Delhi" });

The second version is self-documenting. Anyone reading the function signature immediately knows what properties it expects. You don't have to read the function body to understand what shape the argument needs to have.

Add defaults to parameter destructuring and you get optional configurations for free:

function createButton({ label, color = "blue", size = "md", disabled = false }) {
  return `<button class="\({color} \){size}" \({disabled ? "disabled" : ""}>\){label}</button>`;
}

createButton({ label: "Submit" });


createButton({ label: "Delete", color: "red", disabled: true });

Destructuring is JavaScript telling you: stop reaching into the same container over and over. Take what you need, name it, and work with it.

Arrays give you positional unpacking. Objects give you name-based unpacking. Both support default values, renaming, and nesting. And when you combine destructuring with function parameters, your code stops describing how it gets its data and starts describing what it does with it.

Every time you find yourself writing something.property three times in a row that's your cue to destructure.

const name = "Priya";
const age = 28;

const message = "Hello, my name is " + name + " and I am " + age + " years old.";

It works. You move on. Then the string gets longer. You add another variable. Then a condition. Then a line break. And suddenly you're staring at something that looks like this:

const html = "<div class='card'>" +
  "<h2>" + user.name + "</h2>" +
  "<p>Age: " + user.age + "</p>" +
  "<p>Role: " + user.role + "</p>" +
"</div>";

Count the quotes. Count the plus signs. Miss one closing quote and the whole thing breaks —and the error message won't even tell you where.

This is the problem template literals solve. Not just cosmetically. They fundamentally change how you think about building strings in JavaScript.

What template literals actually are

A template literal is a string wrapped in backticks instead of single or double quotes.

const simple = `Hello, world`;

That's it at the surface level. But backticks unlock three things that regular quotes simply can't do: embedding expressions directly into strings, writing multi-line strings without any tricks, and running logic inside a string all without a single + operator.

Backticks and ${}

The full syntax has two parts. The backtick wraps the whole string. The \({} is the slot where you embed anything a variable, a calculation, a function call, a ternary. Whatever JavaScript expression you put inside \){} gets evaluated and inserted into the string at that position.

const name = "Ankit";
const age = 22;

const message = `Hello, my name is \({name} and I am \){age} years old.`;

console.log(message);
// Hello, my name is Ankit and I am 22 years old.

No plus signs. No closing and reopening quotes. The string reads like a sentence because it is a sentence, with slots in it.

Old way vs new way: a direct comparison

Let's put them side by side so the difference is impossible to miss.

Old way:

const user = { name: "Rohan", city: "Mumbai" };

const greeting = "Welcome back, " + user.name + "! We see you're logging in from " + user.city + ".";

Template literal:

const greeting = `Welcome back, \({user.name}! We see you're logging in from \){user.city}.`;

Same output. But the second version reads like English. You don't have to mentally parse where the string ends and the variable begins they're woven together.

Embedding expressions, not just variables

Math directly in the string:

const price = 120;
const qty = 3;
const tax = 0.18;

const bill = `Subtotal: ₹\({price * qty}. With tax: ₹\){(price * qty * (1 + tax)).toFixed(2)}`;

console.log(bill);
// Subtotal: ₹360. With tax: ₹424.80

A ternary for conditional text:

const user = { name: "Sneha", isPremium: true };

const badge = `\({user.name} — \){user.isPremium ? "Premium member" : "Free tier"}`;

console.log(badge);
// Sneha — Premium member

A function call:

const formatDate = (d) => d.toLocaleDateString("en-IN");

const message = `Report generated on ${formatDate(new Date())}`;

console.log(message);
// Report generated on 25/03/2026

The string becomes a living thing. Instead of building the value outside and plugging it in as a variable, you can do the work right inside the string. For simple cases this is enormously readable.

Multi-line strings: no more \n

Before template literals, writing a multi-line string looked like one of two painful options:

// Option 1 — \n escape sequences
const poem = "Roses are red,\nViolets are blue,\nJavaScript is fun,\nAnd so are you.";

// Option 2 — concatenation across lines
const poem = "Roses are red,\n" +
             "Violets are blue,\n" +
             "JavaScript is fun,\n" +
             "And so are you.";

Both work. Neither looks like a poem. With template literals, you just press Enter:

const poem = `Roses are red,
Violets are blue,
JavaScript is fun,
And so are you.`;

console.log(poem);
// Roses are red,
// Violets are blue,
// JavaScript is fun,
// And so are you.

The line breaks in your source code become line breaks in the string. What you see is what you get.

javascript

const today = new Date();
const pattern = new RegExp("hello");

That new sitting there what is it actually doing?

Most tutorials hand-wave it as it creates an object. And technically that's true. But there's a four-step process happening every time you type new, and once you see it laid out clearly, a lot of things in JavaScript prototypes, instances, this, class syntax suddenly snap into place.

Let's build this understanding from the ground up.

const today = new Date();
const pattern = new RegExp("hello");

That new sitting there — what is it actually doing? Most tutorials hand-wave it as "it creates an object." And technically that's true. But there's a four-step process happening every time you type new, and once you see it laid out clearly, a lot of things in JavaScript — prototypes, instances, this, class syntax — suddenly snap into place.

Let's build this understanding from the ground up.

The problem new is solving

Before new makes sense, the problem it solves needs to make sense.

Say you're building a simple app and you need to represent multiple users. The naive approach is just making plain objects:

const user1 = { name: "Ankit", age: 22, role: "admin" };
const user2 = { name: "Priya", age: 28, role: "editor" };
const user3 = { name: "Rohan", age: 19, role: "viewer" };

This works. For three users. But what happens when you have 300? You're copying the same shape by hand every time, with no guarantee the structure stays consistent. Miss a property on user 147 and you've got a bug that's annoying to track down.

What you really want is a template something you call once and get back a properly-shaped object every time. That's exactly what a constructor function is.

Constructor functions: a template for objects

A constructor function is just a regular function that you intend to call with new. By convention, its name starts with a capital letter not a rule JavaScript enforces, but a strong signal to anyone reading your code.

function User(name, age, role) {
  this.name = name;
  this.age = age;
  this.role = role;
}

That this inside the function is the key. When you call it with new, this refers to the brand new object being created. Every property you attach to this ends up on that new object.

Now you can create as many users as you need:

const user1 = new User("Ankit", 22, "admin");
const user2 = new User("Priya", 28, "editor");
const user3 = new User("Rohan", 19, "viewer");

console.log(user1.name); // "Ankit"
console.log(user2.role); // "editor"

Each call to new User(...) produces a fresh, independent object. Change user1.name and user2.name doesn't budge. They share a shape but not their data.

The four things new does

This is the part most explanations skip. When you write new User("Ankit", 22, "admin"), JavaScript silently does four things in sequence. Understanding these four steps is the unlock for everything else.

Step 1

A blank object is created. JavaScript creates a fresh {}. Nothing on it yet. This is the object that will eventually be returned.

Step 2

The prototype is linked. That blank object gets its internal [[Prototype]] set to User.prototype. This is how the object inherits methods. More on this in a moment.

Step 3

The constructor runs with this pointing to the new object. User is called, and inside it, every this.something = ... line adds properties to that blank object. This is where your data lands.

Step 4

The new object is returned. If your constructor function doesn't explicitly return an object, JavaScript returns this automatically the fully populated object from step 3.

Here's how all four steps look if you imagine JavaScript doing it manually:

Prototype linking

Step 2 is the one that confuses people most, so let's give it the attention it deserves.

Every function in JavaScript automatically gets a prototype property it's an object that sits attached to the function. When you create an instance with new, that instance gets a hidden link back to the constructor's prototype. This link is what JavaScript follows when it can't find a property directly on the object.

Here's why this matters in practice. Instead of defining greet directly on every instance (which would create a new copy of the function for each object), you put it on the prototype once:

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

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

const user1 = new User("Ankit", 22);
const user2 = new User("Priya", 28);

user1.greet(); // "Hi, I'm Ankit"
user2.greet(); // "Hi, I'm Priya"

user1 and user2 don't have greet on them directly. But when JavaScript looks for greet on user1, it follows the hidden prototype link up to User.prototype and finds it there. One function, shared by every instance.

Here's the relationship laid out visually:

The instances own their own data. The shared behavior lives on the prototype above them. That's the whole model.

Instances

Every object created with new SomeFunction() is called an instance of that constructor. JavaScript gives you a way to verify this:

console.log(user1 instanceof User); // true
console.log(user2 instanceof User); // true

instanceof checks whether User.prototype is anywhere in the object's prototype chain. Since we linked it in step 2, the answer is always true for objects created with new User.

You can also check which constructor built an object:

console.log(user1.constructor === User); // true

This is useful when you're debugging and want to confirm an object came from the constructor you think it did.

What happens if you forget new

This is a classic beginner mistake and it fails in a confusing way:

const user = User("Ankit", 22, "admin"); // no new!

console.log(user);       // undefined
console.log(window.name); // "Ankit" — oops

Without new, the function runs as a regular function. There's no blank object created, nothing gets returned. Worse, this inside the function points to the global object so this.name = "Ankit" pollutes the global scope. This is exactly the kind of bug that takes twenty minutes to find.

The capital-letter naming convention exists precisely to signal: call this with new, not without it.

Classes

If you've used ES6 classes, here's something worth knowing: they are not a new object system. They're syntactic sugar over exactly what we just covered.

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

  greet() {
    console.log("Hi, I'm " + this.name);
  }
}

const user1 = new User("Ankit", 22, "admin");

Under the hood, this is identical to the constructor function + prototype version we wrote earlier. The constructor method is the function body. The greet method goes on User.prototype automatically. JavaScript is still running the same four-step process when you call new User(...).

The class syntax is cleaner to read and write especially when inheritance gets involved but it's not doing anything fundamentally different. Once you understand what new actually does, class syntax stops being magic and starts being shorthand.\

setTimeout(function() {
  console.log("hello");
}, 1000);

That function you passed inside setTimeout?

That's a callback. And once you truly understand what's happening there, a huge chunk of JavaScript events, fetch, promises, array methods, suddenly makes complete sense.

Let's start from the very beginning.

Functions Are Just Values

Before we even touch callbacks, you need to see something that surprises a lot of beginners.

In JavaScript, a function isn't special. It's just a value like a number, a string, or an object. That means you can store it in a variable, put it in an array, and yes, pass it as an argument to another function.

Watch:

// a number stored in a variable
const age = 25;

// a string stored in a variable
const name = "Satpal";

// a function stored in a variable — same idea
const greet = function() {
  console.log("Hello!");
};

greet is just a variable that holds a function. You can pass it around exactly like you'd pass age or name. This one idea is the entire foundation of callbacks.

So What Is a Callback Function?

A callback is simply a function that you pass into another function, so that other function can call it later.

That's it. Nothing magical. Just a function being passed as an argument.

function doSomething(callback) { 
    console.log("doing the task...");    
    callback(); // calling the function you passed in 
}

function finished() {
  console.log("task complete!");
}


doSomething(finished);

// Output:
// doing the task...
// task complete!

Notice: we wrote finished not finished(). When you write finished(), you're calling it right then. When you write finished, you're passing the function itself handing it over like a recipe card. The other function decides when to cook.

A Real-World Analogy

Think about ordering food at a restaurant.

You place your order and give the waiter your phone number. You don't stand at the counter waiting. You go sit down. When the food is ready, the kitchen calls you back.

Your phone number is the callback. You handed it over and said "call this when the thing is done."

JavaScript works exactly the same way. You hand a function over and say "run this when you're done."

Passing Functions as Arguments

Let's see this in non-async situations first, because callbacks are not just an async thing.

Example 1:

A simple custom function:

function greetUser(name, callback) {
  const message = "Hello, " + name + "!";
  callback(message); // passes the message to your callback
}

greetUser("Priya", function(msg) {
  console.log(msg); // Hello, Priya!
});

Example 2 — you already use callbacks with array methods:

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

// the function you pass to .filter() is a callback
const evens = numbers.filter(function(num) {
  return num % 2 === 0;
});

console.log(evens); // [2, 4]

Every time you use .map(), .filter(), .forEach(), .sort() — you are already writing callbacks. Every day. You just might not have called them that.

Why callbacks exist

Here's the real reason callbacks are everywhere. JavaScript runs in a single thread. That means it can only do one thing at a time. When it hits something slow — a network request, a file read, a timer it can't just freeze and wait. The whole page would lock up.

So instead, JavaScript says: "I'll start this task, then come back to the rest of the code. When the slow thing finishes, call this function."

console.log("1. Start");

setTimeout(function() {
  console.log("2. This runs after 2 seconds");
}, 2000);

console.log("3. This runs immediately");

// Output:
// 1. Start
// 3. This runs immediately
// 2. This runs after 2 seconds   ← came back later

JavaScript didn't pause at the setTimeout. It registered your callback, moved on, and came back when the timer expired. That's the whole idea.

Callbacks in common scenarios

You see this pattern everywhere once you know what to look for.

Reading a file (Node.js):

fs.readFile("data.txt", function(error, content) {
  if (error) {
    console.log("Something went wrong");
    return;
  }
  console.log(content);
});

Listening for a button click:

button.addEventListener("click", function() {
  console.log("button was clicked!");
});

Fetching data from an API (older style):

fetchUserData(userId, function(user) {
  console.log("Got user:", user.name);
});

In every case, the pattern is the same. You're handing off a function and saying: run this when you have the result.

Callback nesting

Now for the part nobody warns you about early enough.

Callbacks work great for one operation. But real applications chain operations. Get the user, then get their orders, then get each product in the order. Each step needs the result from the previous one. So you nest a callback inside a callback inside a callback.

getUser(userId, function(user) {
  getOrders(user.id, function(orders) {
    getProduct(orders[0].productId, function(product) {
      getReviews(product.id, function(reviews) {
        console.log(reviews); // finally got what we needed
      });
    });
  });
});

Every new requirement pushes the code one level deeper. This is what developers call callback hell

The problem isn't just visual. Code this deep is genuinely hard to maintain. Add error handling at each level and it gets worse. Move a step around and you're hunting through nested brackets. Debug it and you're tracing a path through a maze.

This is not a hypothetical problem it's what pushed the JavaScript community to invent Promises and then async/await. Those tools exist entirely to solve the mess callbacks create when chained.

But here's the important thing to remember: Promises and async/await don't eliminate callbacks. They're built on top of the same concept. Understanding callbacks is understanding the foundation of async JavaScript.

It looks simple. But it behaves differently depending on where you use it, how you call a function, and sometimes even whether you're in strict mode or not.

By the end of this, you'll stop guessing what this is. You'll know.

Thumb Rule

Before any examples, here's the single most important thing to understand about this:

this is not about where a function is defined. It's about who calls it.

Read that again. Burn it in.

Most this confusion comes from thinking that this is locked to the function at the time you write it. It isn't. this is decided at the moment the function is called based on what's to the left of the dot.

That's the whole secret. Everything else is just variations of that rule.

Visualizing Caller to Function Relationship

Think of every function call as a conversation. Someone calls the function. That someone is this.

Same function. Different caller. Different this. That's the whole game.

this in the Global Context

When you open a JavaScript file and write this outside of any function or object, it refers to the global object.

In a browser, that's window. In Node.js, that's global.

console.log(this); // window (in browser)

function showThis() {
  console.log(this); // also window — no caller, so global is assumed
}

showThis();

Think of the global object as the default owner of everything. When there's no specific caller, the global context steps in.

In strict mode, this changes:

"use strict";

function showThis() {
  console.log(this); // undefined — strict mode removes the global fallback
}

showThis();

This is a common gotcha. Strict mode is more honest it says there's no caller here, so this is nothing instead of quietly pointing to window.

this Inside Objects

This is where this starts feeling genuinely useful.

When a function lives inside an object and you call it through that object, this refers to the object itself.

const user = {
  name: "Satpal",
  greet: function() {
    console.log("Hello, " + this.name);
  }
};

user.greet(); // Hello, Satpal

user is to the left of the dot. So this inside greet is user. JavaScript looks left of the dot — that's what this gets set to.

Multiple methods sharing this:

const counter = {
  count: 0,
  increment: function() {
    this.count++;
  },
  reset: function() {
    this.count = 0;
  },
  show: function() {
    console.log("Count:", this.count);
  }
};

counter.increment();
counter.increment();
counter.show();  // Count: 2
counter.reset();
counter.show();  // Count: 0

Every method can talk to the same object's data through this. That's exactly what makes objects useful shared state with methods that can read and change it.

How Calling Context Changes this

Here's where most developers get burned. The same function can produce completely different this values depending on how it's called.

const user = {
  name: "Riya",
  greet: function() {
    console.log(this.name);
  }
};

user.greet();         // "Riya" — called on user, this = user

const fn = user.greet;
fn();                 // undefined — called alone, this = window

You didn't change the function. You just changed how you called it. The moment you detach a method from its object, it loses its this.

This catches people constantly especially when passing methods as callbacks:

const user = {
  name: "Arjun",
  greet: function() {
    console.log("Hello,", this.name);
  }
};

setTimeout(user.greet, 1000); // Hello, undefined 😬

user.greet got handed to setTimeout. When setTimeout calls it, there's no user. in front — so this is lost.

Here's the full picture of how context shifts across four common situations:

For global:

For Object:

Regular Function:

Arrow Function:

this Inside Regular Functions

A standalone function called without any object in front of it follows the global fallback rule.

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

showThis(); // window (browser) or undefined (strict mode)

No dot. No owner. Global takes over or undefined in strict mode.

Nested functions lose this too:

const user = {
  name: "Priya",
  greet: function() {
    console.log(this.name); // "Priya" — works fine

    function inner() {
      console.log(this.name); // undefined — inner lost the context
    }
    inner();
  }
};

user.greet();

inner() is called without a dot. Even though it's inside a method, it doesn't inherit this. Each function has its own this determined by how it's called not where it's written.

The Full Picture

Here's every context in one place:

"Programs must be written for people to read, and only incidentally for machines to execute."

--Harold Abelson

Don't worry. By the end of this, it'll feel obvious. Let's start from zero.

JavaScript Runs One Line at a Time

Before we talk about async, you need to understand how JavaScript normally works.

JavaScript is single-threaded. That's a fancy way of saying it can only do one thing at a time. It reads your code top to bottom, line by line, finishing each one before moving to the next.

That's synchronous code. And honestly, most of the time it's fine:

console.log("Step 1 — make coffee");
console.log("Step 2 — open laptop");
console.log("Step 3 — start coding");

No surprises. JavaScript read it top to bottom. Done.

Then what is the problem?

What If One Step Takes Forever?

Now imagine step 2 was "wait for the kettle to boil" and that took 4 minutes.

In synchronous world, JavaScript would just… stand there. Frozen. Doing nothing. Waiting. And everything after it your entire app would be on hold too.

That's called blocking code. And on the web, it's a disaster.

Think about what happens when a website fetches data from a server. That server might be in another country. It might take 2 seconds to respond. If JavaScript just sat there waiting synchronously, your entire page would freeze. No scrolling. No clicking. Nothing. Just a white screen staring back at the user.

That's why JavaScript needed a way to say: "go do that thing, and come back when you're done an I'll carry on in the meantime."

That's asynchronous code.

Js need someone who says:

Tu jaa bhai kaam kar le… main tab tak zindagi sambhaal leta hoon 😌

Let's understand what async really mean

Think of a busy coffee shop.

Synchronous would be the barista taking one order, making that drink completely, handing it over, then taking the next order. Everyone behind you waits in silence. The queue backs up. It's painful.

Asynchronous is how real coffee shops work. The barista takes your order, shouts it to the machine, then immediately takes the next person's order. When your drink is ready, they call your name. You collect it. Nobody was blocked waiting for you.

JavaScript works the same way when it's async. It starts a task, sets it aside, keeps going, and comes back when the result is ready.

Real Life Examples Where You Need Async

Here are situations where synchronous code would completely break your app:

• Fetching data from an API: When you call an external server, you have no idea how long it'll take. Could be 200ms, could be 3 seconds. You can't block everything waiting.

• Timers: setTimeout tells JavaScript "do this after 2 seconds." Synchronous JavaScript can't just pause for 2 seconds.

• Reading files: In Node.js, reading a file from disk takes time. You don't want your server frozen while it reads a config file.

• User interactions: You can't predict when a user clicks a button. The code waiting for that click can't block everything else.

Seeing the Difference in Code

Here's synchronous code fetching data the kind that would break everything:

// Imagine this magically waits for the server (it doesn't work like this) 
const data = fetchFromServer(); // ← everything freezes here 
console.log(data); // ← only runs after the wait console.log("This is stuck too");

Now here's the async version where JavaScript keeps moving:

fetch('https://api.example.com/data')
  .then(response => response.json())
  .then(data => console.log(data)); // ← runs when ready

console.log("This runs immediately, without waiting!"); // ← runs right now

Let's Breakdown above example

1. Fetching Starts

   

2. JS keep going

   

3. Data arrives

   

4. Output Order

   

The Three Eras of Async JavaScript

JavaScript didn't always handle async code cleanly. It evolved through three stages and understanding all three matters, because you'll see all of them in real codebases.

Era 1: Callbacks (The Old Way)

The original solution was simple: pass a function as an argument, and run it when the job's done.

setTimeout(function() {
  console.log("2 seconds later...");
}, 2000);

For simple cases, fine. But the moment you needed to chain several async steps together, things got ugly fast:

getUser(userId, function(user) {
  getOrders(user.id, function(orders) {
    getOrderDetails(orders[0].id, function(details) {
      sendEmail(details, function(response) {
        console.log("Done... finally");
        // welcome to Callback Hell
      });
    });
  });
});

This pyramid of doom is called Callback Hell. Each step depends on the previous one, and the nesting goes deeper and deeper. Debugging this is miserable. Handling errors in this is worse.

Era 2: Promises (The Better Way)

In 2015, JavaScript introduced Promises, objects that represent a value that will be available eventually.

A Promise has three states:

• Pending — still waiting

• Fulfilled — it worked, here's the result

• Rejected — something went wrong

fetch('https://api.example.com/user')
  .then(response => response.json())   // fulfilled → transform data
  .then(user => console.log(user))     // fulfilled → use it
  .catch(error => console.log(error)); // rejected  → handle error

Much cleaner. Flat chain instead of a pyramid. Errors handled in one place with .catch().

But chaining many .then() calls could still feel verbose. So JavaScript went one step further.

Era 3: Async/Await (The Modern Way)

async/await is just a cleaner way to write Promises. Under the hood it's still Promises — it just looks synchronous, which makes it dramatically easier to read and reason about.

async function getUser() {
  try {
    const response = await fetch('https://api.example.com/user');
    const user     = await response.json();
    console.log(user);
  } catch (error) {
    console.log("Something went wrong:", error);
  }
}

The await keyword tells JavaScript: "pause this function here and wait for the Promise to resolve — but don't block the rest of the app."

Notice how it reads almost like synchronous code. That's the whole point.

Key rules for async/await:

• await can only be used inside a function marked async

• An async function always returns a Promise, even if you don't write return Promise

• Errors are handled with normal try/catch — no more .catch() chains

The Stuff Most Devs Don't Know

You understand the basics now. Here's where it gets genuinely interesting.

The Asynchronous Task Queue

You've seen that JavaScript can come back to async code later. But where does that code go while it's waiting? And who decides when it runs?

That's the job of the task queue system and once you see it, async JavaScript will never feel mysterious again.

There are three players working together at all times.

The call stack is where your code actually executes. Every function call goes onto the stack. When it finishes, it pops off. JavaScript can only run one thing at a time here, it's strictly one in, one out.

The Web APIs (in the browser) are external helpers that live outside JavaScript. When you call setTimeout, fetch, or add an event listener, JavaScript hands that job off here and immediately moves on. The Web API does the waiting so JavaScript doesn't have to.

The task queue (also called the callback queue) is the waiting room. When a Web API finishes its job. The timer expired, the server responded, the user clicked, it puts the callback here. It doesn't jump straight into execution. It waits politely.

The event loop is the traffic officer. It runs in a constant loop asking one question: is the call stack empty? The moment it is, it takes the first item from the task queue and pushes it onto the stack.

That's the whole system. Simple in concept, powerful in effect.

Now let's watch it work step by step with real code. This is where it fully clicks.

Example Code

// the code we are tracing through
console.log("A")
setTimeout(() => console.log("B"), 0)
console.log("C")

Lets see how it's work BTS,

1. Start

   

2. A logs

   

3. setTimeout

   

4. C logs

   

5. Stack clears

   

6. B logs

   

7. Output

   

Now here's the part that trips up even experienced developers. There isn't just one queue. There are two and they have different priorities.

The microtask queue handles Promises and queueMicrotask. It has higher priority than the regular task queue. After every single task, the event loop drains the entire microtask queue before it picks up the next regular task. Even if a microtask adds another microtask, they all get processed before moving on.

The macrotask queue (the regular task queue) handles setTimeout, setInterval, and I/O callbacks. These wait until the microtask queue is completely empty.

This is the full picture of the async task queue system:

The call stack runs your code. The Web APIs do the waiting. Completed callbacks land in one of two queues

The microtask queue for Promises (high priority, drained completely after every task) or the macrotask queue for timers and I/O (lower priority, one per turn).

The event loop ties it all together, constantly watching the stack and feeding it the next piece of work in the right order.

That two-queue priority is why Promise always beats setTimeout, not because Promises are faster, but because they sit in a queue the event loop checks first. Once you see that, the output order of any async code becomes completely predictable.

"Programs must be written for people to read, and only incidentally for machines to execute."

-- Harold Abelson

Don't worry. By the end of this, it'll click.

Let's start from the very beginning.

Imagine a Classroom With No Desks

Picture a classroom where every student just throws their stuff on the floor. Books, bags, lunch boxes all mixed together in one giant pile. Now imagine trying to find your pencil in that mess.

That's literally what early JavaScript was like.

Every file you wrote dumped its variables into one shared space called the global scope. And here's where it got ugly — if two files used the same variable name, the second one would just wipe out the first. No warning. No error. Just silent, confusing chaos.

Say you had two files:

Example:

https://codepen.io/editor/Satpalsinh-Rana/pen/019cfcc2-89a6-780a-bc59-8ecb8f458177

If both are loaded on the same page, price is now 0. Your cart logic just got quietly destroyed by your checkout file. Fun times.

The Fix: Give Every File Its Own Room

This is exactly what modules do. A module is just a JavaScript file that keeps its variables to itself. Nothing leaks out accidentally. If you want another file to use something, you have to deliberately export it. And the other file has to deliberately import it.

It's like going from that messy floor to everyone having their own desk with a locked drawer. You only share what you choose to share.

Simple idea. Huge difference.

Two Ways JavaScript Does This

There are two main module systems you'll come across. Don't let that scare you — they do the same thing, just with slightly different styles.

CommonJS — The Old School Way

This one was invented for Node.js (JavaScript on the server). You'll see it a lot in older projects and tutorials.

It uses two things:

• module.exports — to send something out

• require() — to bring something in

Sending code out:

// greet.js
const sayHello = (name) => {
  console.log("Hello, " + name + "!");
};

module.exports = { sayHello };

Bringing it in:

const { sayHello } = require('./greet.js');
sayHello("Riya"); // Hello, Riya!

That's really it. You wrap your stuff in module.exports, and you grab it with require().

You might see people write exports.sayHello = ... as a shortcut. It mostly works, but the moment you do exports = { sayHello }, it breaks. Stick to module.exports when you're starting out. Way less confusing.

ES Modules — The Modern Way

In 2015, JavaScript introduced a cleaner, more modern system called ES Modules. This is what most tutorials and frameworks use today, and it's what you should focus on learning.

Instead of require and module.exports, you use import and export. Much more readable.

Named Exports sharing multiple things

// math.js
export const add = (a, b) => a + b;
export const PI = 3.14;

// main.js
import { add, PI } from './math.js';
console.log(add(2, PI)); // 5.14

Notice the curly braces {} in the import? That tells JavaScript exactly which piece you want.

Default Export — when a file has one main thing

// User.js
export default class User {
  constructor(name) {
    this.name = name;
  }
}

// main.js
import User from './User.js'; // No curly braces needed!
const me = new User("Arjun");

No curly braces here because there's only one default thing JavaScript already knows what you mean.

Seeing both together

If you've ever used React, you've already seen this in action:

import React, { useState, useEffect } from 'react';

• React → default export (no braces)

• useState, useEffect → named exports (inside braces)

Once you get that distinction, a lot of code starts making sense.

So What Should You Actually Use?

If you're just starting out go with ES Modules. It's cleaner to read, it's the modern standard, and every major framework (React, Vue, Svelte) uses it.

You'll run into CommonJS eventually, especially in older Node.js code. But now that you understand the why behind modules, picking up either syntax is just a matter of remembering a few keywords.

Okay, You've Got the Basics now Let's Go Deeper

So you understand what modules are and how import/export works. Great. But here's the thing CJS and ESM aren't just different syntaxes. Under the hood, they behave very differently. And those differences actually matter when you're building real apps.

Let's talk about the stuff most tutorials skip.

How They Actually Load Files

This is one of the biggest differences, and it affects performance.

CommonJS is synchronous. When Node.js hits a require(), it stops everything, reads the entire file, executes it, and then moves on. It's like stopping your car completely every time you need to check the map.

const data = require('./heavyFile.js'); // Everything pauses here
console.log("This runs AFTER the file loads");

This works fine on a server where files live on your hard drive and load in milliseconds. But it's a disaster for browsers, where files travel over a network and could take seconds.

ES Modules are asynchronous. The browser (or Node.js) can start fetching multiple modules at the same time without blocking everything else. Your app stays responsive while the files load in the background.

This is a big reason why ESM became the standard for the web.

Static vs Dynamic

This is where it gets really interesting, and most beginners never hear about it.

CommonJS is dynamic. The require() call can live anywhere in your code inside an if statement, inside a function, even based on user input:

// This is totally valid CJS
if (userRole === "admin") {
  const adminTools = require('./adminTools.js');
}

Sounds flexible, right? But here's the problem because the module path can be a variable, JavaScript has no idea what's being imported until the code actually runs. That means:

• Bundlers can't tree-shake (remove unused code)

• Security scanners can't see what's being loaded

• A bad actor could potentially manipulate what gets required

Imagine this nightmare scenario:

const userInput = getInputFromSomewhere();
const module = require(userInput); // What is this loading?

If that userInput somehow comes from an untrusted source, you've got a serious security hole.

ES Modules are static. Every import statement must sit at the top of the file with a fixed path no variables, no conditions, no surprises:

// This is NOT allowed in ESM
if (condition) {
  import something from './file.js'; // Syntax error
}

That might feel restrictive, but it's actually a feature. Because the structure is fixed and predictable, tools can analyze your entire dependency tree before running anything. Security scanners know exactly what your app loads. Bundlers can eliminate dead code with confidence. Everything is transparent.

Live Bindings vs Copied Values

This one is subtle but genuinely catches developers off guard.

CJS gives you a copy of the exported value at the time of import. If that value changes later in the original file, your copy doesn't update.

// counter.cjs
let count = 0;
module.exports = { count, increment: () => count++ };

// main.cjs
const { count, increment } = require('./counter.cjs');
increment();
console.log(count); // Still 0 — you got a copy, not the real thing

ESM gives you a live binding. A live connection to the actual variable in the original file. If it changes, you see the change.

// counter.js
export let count = 0;
export const increment = () => count++;

// main.js
import { count, increment } from './counter.js';
increment();
console.log(count); // 1 — it updated!

This matters a lot when you're working with shared state, counters, flags, or anything that changes over time.

A Quick Side-by-Side to Tie It All Together

"The secret to building large apps is never build large apps. Break your applications into small pieces. Then assemble those testable, bite-sized pieces into your big application." — Justin Meyer

The simplest way to think about this is: "Who is calling the function?"

It is a keyword that refers to the context (the object) that is currently executing the code. It acts like a pronoun in English instead of saying "Satpal is coding", you say "He is coding."

this inside Objects

When you use this inside a method of an object, it refers to the object itself.

const dev = {
  name: "Satpal",
  greet: function() {
    console.log(`Hi, I am ${this.name}`);
  }
};

dev.greet(); 

Here, this is dev because dev is the one calling greet().

this inside Normal Functions

In a regular function (not a method of an object), this defaults to the Global Object (window in browsers). If you use strict mode, it will be undefined.

Controlling this: Call, Apply, and Bind

Sometimes, you want to borrow a method from one object and use it with another. This is where call, apply, and bind come in.

call()

Calls a function immediately and allows you to pass in the this context explicitly, followed by arguments one by one.

function intro(city, tech) {
  console.log(`\({this.name} from \){city} loves ${tech}.`);
}

const user = { name: "Satpal" };
intro.call(user, "Ahmedabad", "Angular"); 
// Output: Satpal from Ahmedabad loves Angular.

apply()

Exactly like call(), but it takes arguments as an Array. Mnemonic: Apply = Array.

intro.apply(user, ["Ahmedabad", "NodeJS"]);

bind()

Instead of calling the function immediately, bind() returns a new function with the this context fixed. You can call it later.

const boundIntro = intro.bind(user, "Ahmedabad", "TypeScript");
boundIntro(); // Calls the function later

Example

const laptop = {
  brand: "MacBook",
  showInfo: function(ram, storage) {
    console.log(`\({this.brand} with \){ram}GB RAM and ${storage}GB SSD`);
  }
};

const desktop = { brand: "Custom PC" };

// 1. Borrowing with call()
laptop.showInfo.call(desktop, 32, 1024);

// 2. Borrowing with apply()
laptop.showInfo.apply(desktop, [16, 512]);

// 3. Storing with bind()
const showDesktop = laptop.showInfo.bind(desktop);
showDesktop(64, 2048);

Understanding this is what separates a beginner from an intermediate JavaScript developer. While this can seem "magical", it always follows the simple rule: look at what is to the left of the dot when the function is called.

Let's Connect! 🚀

I’m currently deep-diving into the JavaScript, building projects and exploring the internals of the web. If you're on a similar journey or just love talking about JavaScript, let’s stay in touch!

• Connect on LinkedIn: Satpalsinh's Profile

• Follow my Blog: blogs.satpal.cloud

Keep coding and keep building.

Why ?

Imagine you are a car manufacturer. You don’t just start building a car from scratch every time. Instead, you create a blueprint. This blueprint defines the features (color, engine) and actions (drive, brake).

• The Blueprint is the Class.

• The Physical Car on the road is the Object (or Instance).

What is a Class in JavaScript?

Introduced in ES6, a class is a template for creating objects. It encapsulates data (properties) and behavior (methods) into a single unit, promoting code reusability.

Let’s look at how to translate that blueprint into JavaScript code.

class Car {
  // The Constructor: The "Setup" function
  constructor(brand, model, color) {
    this.brand = brand;
    this.model = model;
    this.color = color;
  }

  // A Method: Defining behavior
  drive() {
    console.log(`The \({this.color} \){this.brand} is now driving!`);
  }
}

// Instantiating Objects (Creating cars from the blueprint)
const myCar = new Car("Tesla", "Model 3", "White");
const friendsCar = new Car("Tata", "Nexon", "Blue");

myCar.drive(); // Output: The White Tesla is now driving!

Breakdown

• The Constructor Method: This is a special method that runs automatically when you create a new object. It’s where you initialize the object's properties using the this keyword.

• Methods: These are functions defined inside the class that describe what the object can do.

• Encapsulation (The Basics): This is the practice of "bundling" the data and the methods that operate on that data within one unit (the class). It keeps the code organized and prevents outside code from accidentally messing with the internal logic.

Example - The Student Class

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

  // Method to display details
  displayDetails() {
    console.log(`Student: \({this.name}, Age: \){this.age}, Course: ${this.course}`);
  }
}

// Creating multiple student objects
const student1 = new Student("Satpal", 24, "Full Stack Development");
const student2 = new Student("Aman", 22, "Data Science");

student1.displayDetails();
student2.displayDetails();

The Four Pillars of OOP

Encapsulation (Data Hiding)

Encapsulation is about keeping the internal state of an object private and only exposing what is necessary through a public interface. In modern JavaScript (ES2022+), we use the # prefix for truly private fields.

class BankAccount {
  #balance = 0; // Private field

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

  getBalance() {
    return `Your balance is ₹${this.#balance}`;
  }
}

const myAcc = new BankAccount();
myAcc.deposit(500);
console.log(myAcc.#balance); // Error: Private field '#balance' must be declared in an enclosing class

Abstraction (Complexity Hiding)

Abstraction means showing only the essential features of an object and hiding the "how it works" logic. You may know how to use a fetch() call in your Angular app/ React App, but you don't need to know the low-level TCP/IP handshake logic happening in the background.

Inheritance (Hierarchy)

Inheritance allows one class to derive properties and methods from another. In JS, we use extends and super().

class User {
  constructor(username) {
    this.username = username;
  }
  logIn() { console.log(`${this.username} logged in.`); }
}

class Admin extends User {
  deleteUser(user) { console.log(`Admin deleted ${user}`); }
}

Polymorphism (Many Forms)

Polymorphism allows different classes to be treated as instances of the same parent class through the same interface, but each responds in its own way.

class Shape {
  draw() { console.log("Drawing a shape..."); }
}

class Circle extends Shape {
  draw() { console.log("Drawing a circle ⭕"); } // Overriding
}

Prototypal Inheritance:

Unlike Classical OOP (C++/Java), JavaScript uses Prototypal Inheritance. Every object in JS has a hidden property called [[Prototype]] (accessible via __proto__).

• When you call a method on an object, JS first looks at the object itself.

• If it doesn't find it, it looks at the object's Prototype.

• It keeps going up the "Prototype Chain" until it reaches null.

By using Classes and the Four Pillars (Encapsulation, Abstraction, Inheritance, and Polymorphism), you ensure that your code is:

1. Maintainable: Changes in one class don't break the whole app.

2. Scalable: Adding new features becomes a matter of extending existing logic.

3. Readable: Your code tells a story about real-world objects.

Let's Connect! 🚀

I’m currently deep-diving into the JavaScript, building projects and exploring the internals of the web. If you're on a similar journey or just love talking about JavaScript, let’s stay in touch!

• Connect on LinkedIn: Satpalsinh's Profile

• Follow my Blog: blogs.satpal.cloud

Keep coding and keep building.

What Are Objects and Why Do We Need Them?

Imagine you want to store information about a person. Using basic variables, your code would look like this:

let personName = "Alex";
let personAge = 25;
let personCity = "London";

This works, but it’s messy. These variables are floating around independently. If you add 10 more people, your code becomes a nightmare to manage.

Object

An Object solves this by grouping related data together into a single, organized structure. Think of an object like a real-world dictionary: you look up a word (the key) to find its definition (the value).

In JavaScript, objects are collections of these key-value pairs.

Array vs. Object: What’s the Difference?

You might be wondering, "Can't I just use an array?"

You can, but it’s not always the right tool for the job.

• Arrays are for ordered lists of data. You access items using their numbered index (array[0]). Use arrays when the order matters (e.g., a list of top 10 movies).

• Objects are for labeled data. You access items using their specific name (object.name). Use objects when you have a single entity with descriptive properties.

Create Object

Creating an object is incredibly straightforward. We use curly braces {} to define it, and inside, we separate our keys and values with a colon :.

const person = {
  name: "Alex",
  age: 25,
  city: "London"
};

console.log(person);

Access Data inside Object

Now that we have our object, how do we read the data inside it? You have two main tools in your belt: Dot Notation and Bracket Notation.

Dot Notation (The everyday choice):

This is the cleanest and most common way to grab a value.

console.log(person.name); // Output: "Alex"

Bracket Notation (The flexible choice):

You use brackets when your key has a space in it (which isn't recommended, but happens), or when you are using a variable to look up a key dynamically.

console.log(person["city"]); // Output: "London"

// Dynamic lookup example:
let query = "age";
console.log(person[query]); // Output: 25

Updating Object Properties

Objects are mutable, meaning you can change their data even after they are created (yes, even if you used const).

// Alex had a birthday
person.age = 26; 

// Alex moved to a new city
person["city"] = "Manchester";

console.log(person.age); // Output: 26

Adding and Deleting Properties

JavaScript objects are incredibly flexible. You can add new properties on the fly, or delete them if they are no longer needed.

Add

person.profession = "Software Developer";
console.log(person.profession); // Output: "Software Developer"

Delete

delete person.city;
console.log(person.city); // Output: undefined

Looping Through Object Keys

Sometimes you need to read every single piece of data inside an object, but you don't know the keys in advance. To do this, we use a special loop called the for...in loop.

const car = {
  brand: "Tesla",
  model: "Model 3",
  year: 2023
};

for (let key in car) {
  // We use bracket notation here because 'key' is a variable!
  console.log(`\({key}: \){car[key]}`); 
}

// Output:
// brand: Tesla
// model: Model 3
// year: 2023

Deep Dive in object

All ways to create object

The Object Literal (The Daily Driver)

As mentioned above, this is the standard, easiest way to create an object. You will use this 95% of the time.

const user = {
  name: "Alex",
  role: "Developer"
};

The new Object() Constructor

This uses JavaScript's built-in Object constructor. It does the exact same thing as the literal, but it's more verbose. It's rarely used in modern code.

const user = new Object();
user.name = "Alex";
user.role = "Developer";

Object.create() (For Prototypal Inheritance)

This is a powerful method. It creates a brand new object, but allows you to choose an existing object to act as its "prototype" (blueprint).

const vehiclePrototype = { wheels: 4 };
const car = Object.create(vehiclePrototype);

car.brand = "Tesla";
console.log(car.wheels); // Output: 4 (Inherited from the prototype!)

Constructor Functions (The Old-School Blueprint)

Before modern classes existed, developers used normal functions with the new keyword to create multiple instances of an object.

function User(name, role) {
  this.name = name;
  this.role = role;
}
const user1 = new User("Alex", "Developer");

ES6 Classes (The Modern Blueprint)

Introduced in 2015, this provides a cleaner, more readable syntax for creating object blueprints. Under the hood, it works exactly like the Constructor Function above.

class UserClass {
  constructor(name, role) {
    this.name = name;
    this.role = role;
  }
}
const user2 = new UserClass("Sam", "Designer");

Important methods on objects

JavaScript provides a static Object utility with several incredibly useful methods. If you are manipulating data, you will use these constantly.

const laptop = { brand: "Apple", model: "MacBook Pro", year: 2023 };

• Object.keys(obj): Returns an array of the object's keys.

  console.log(Object.keys(laptop)); // ["brand", "model", "year"]
  

• Object.values(obj): Returns an array of the object's values.

  console.log(Object.values(laptop)); // ["Apple", "MacBook Pro", 2023]
  

• Object.entries(obj): Returns an array of arrays, each containing a [key, value] pair. This is amazing for looping!

  console.log(Object.entries(laptop)); 
  // [["brand", "Apple"], ["model", "MacBook Pro"], ["year", 2023]]
  

• Object.freeze(obj): Completely locks an object. You cannot add, delete, or change any properties.

• Object.seal(obj): Partially locks an object. You cannot add or delete properties, but you can update existing ones.

Deep Copy vs Shallow Copy

This is a core concept that trips up almost every JavaScript developer at some point.

In JavaScript, primitive types (strings, numbers) are passed by value. But Objects are passed by reference. When you assign an object to a new variable, you aren't copying the data; you are just copying the memory address pointing to that data.

The Shallow Copy

A shallow copy creates a new object and copies the top-level properties over. However, if your object has a nested object inside it, that nested object still shares the same memory reference!

How to make a shallow copy: You can use the Spread Operator (...) or Object.assign().

const original = {
  name: "Alex",
  skills: { language: "JavaScript" } // This is a nested object
};

// Create a shallow copy using the spread operator
const shallowCopy = { ...original };

// Let's change the top-level property
shallowCopy.name = "Sam"; 
console.log(original.name); // "Alex" (Safe! Top-level is copied)

// BUT, let's change the nested property
shallowCopy.skills.language = "TypeScript";
console.log(original.skills.language); // "TypeScript" (Wait, the original changed too?!)

because it was a shallow copy, both objects are sharing the exact same skills object in memory.

The Deep Copy

A deep copy creates a completely independent clone. Every nested object is duplicated into a brand new memory space. Changing the clone will never affect the original.

How to make a deep clone:

1. The Modern Way: structuredClone()
This is a built-in feature in modern JavaScript (available in browsers and Node.js). It is currently the absolute best and cleanest way to deep clone an object.

JavaScript

const deepCopy = structuredClone(original);

deepCopy.skills.language = "Python";
console.log(original.skills.language); // "TypeScript" (The original is perfectly safe!)

2. The Old Hack: JSON.parse(JSON.stringify())
Before structuredClone() existed, developers used this trick. It converts the object into a text string, and then parses it back into a brand new object.

• Warning: This method breaks if your object contains Functions, Date objects, or undefined values, as JSON doesn't support them.

3. The Library Way: Lodash
If you are working in a massive enterprise codebase, you might see _.cloneDeep(obj) from the Lodash library being used to safely handle complex cloning.

Function Expression

It means to use function keyword and define a function inside an expression. In simple words, previously folk use to write and assign function to variable as below,

const ctc = function (base, variable) { return base +  variable; };

console.log(ctc(30000, 40000));

Arrow Functions

So, Arrow Functions are used to create a arrow function expression. An alternate to traditional approach mentioned above.

Example

const ctc = (base, variable) => base + variable;

console.log(ctc(30000, 40000)); 

But, it has it's own behavior

• They don't have their own binding and should not be used as methods.

• We cannot use them as constructor

• It cannot use yield within their body and cannot be used as generators.

No own bindings to this, arguments, or super

Regular functions are dynamic. So the value of this depends on how the function is called. If an object calls a method, this refers to that object.

Arrow functions are lexical. They do not create their own this context. Instead, they inherit this from the surrounding scope where they were defined (like looking up to their parent block).

Imagine the Great Hall of Winterfell (the Parent Scope). Lord Eddard Stark is organizing his forces. He sends two warriors south to the Red Keep (the Object) to serve the Crown.

• The Sellsword / Regular Function (Bronn): Bronn's loyalty is dynamic. It depends entirely on who is currently paying him right now. When Cersei Lannister at the Red Keep issues a command and asks, "Who do you fight for?", Bronn looks around at his current employer and says, "I fight for House Lannister." (this = the object that called the method).

• The Loyal Bannerman / Arrow Function (Arya Stark): Arya's loyalty is lexical. Her allegiance was permanently forged in Winterfell the moment she was born. Even though she is physically standing in the Red Keep, and Cersei is the one issuing the command, Arya completely ignores her current surroundings. When asked, "Who do you fight for?", she looks back to her origins and says, "I fight for House Stark." (this = the parent scope where she was created).

Example

const winterfell = {
  houseName: "Stark",

  sendWarriorsSouth: function() {

    const redKeep = {
      houseName: "Lannister",
      
      bronn: function() {
        console.log(`Bronn says: I fight for House ${this.houseName}`);
      },

      arya: () => {
        console.log(`Arya says: I fight for House ${this.houseName}`);
      }
    };

    redKeep.bronn(); 
    redKeep.arya();  
  }
};

winterfell.sendWarriorsSouth();

// Output:
// Bronn says: I fight for House Lannister
// Arya says: I fight for House Stark

Note: Generally arrow function are not use in methods, because object methods usually need to talk to the object they live inside, and arrow functions are physically incapable of doing that.

Cannot be used as constructors

In JavaScript, regular functions can be used to create blueprints for new objects using the new keyword. When you call new RegularFunction(), JavaScript creates a brand new object, binds this to that new object, and links it to the function's prototype.

Arrow functions were designed to be lightweight and fast. To save memory and execution time, JavaScript engines completely removed the .prototype property from arrow functions. Without a prototype, and without the ability to bind a new this, they simply cannot construct objects.

Regular Function:

function Car(model) {
  this.model = model;
}
const myCar = new Car("Honda"); 
console.log(myCar.model);

Arrow Function

const Bike = (model) => {
  this.model = model;
};


const myBike = new Bike("Yamaha"); 

Cannot use yield

A generator function (function*) is a special type of function that can pause its execution, hand a value back to the caller using the yield keyword, and then resume later exactly where it left off. It acts like a state machine.

Example

function* snackMachine() {
  yield "Chips";
  yield "Chocolate";
  return "Empty";
}

const machine = snackMachine();
console.log(machine.next().value); // Output: "Chips"
console.log(machine.next().value); // Output: "Chocolate"

Arrow functions were strictly designed to be single-purpose, run-to-completion expressions. The designers of JavaScript (the TC39 committee) decided that combining the complex, state-pausing mechanics of generators with the ultra-concise syntax of arrow functions would make the language too confusing and harder to parse.

Now, when you are writing modern web apps, like subscribing to an observable stream of user data or handling a button click event in a component you just use an arrow function.

"We cannot solve our problems with the same thinking we used when we created them."

— Albert Einstein

Let's Connect! 🚀

I’m currently deep-diving into the JavaScript, building projects and exploring the internals of the web. If you're on a similar journey or just love talking about JavaScript, let’s stay in touch!

• Connect on LinkedIn: Satpalsinh's Profile

• Follow my Blog: blogs.satpal.cloud

Keep coding and keep building.

An array is a data structure used to store a collection of items. Think of it as a single variable that can hold multiple values under one name.

To know more on Array read my Article on Array : JS Array 1v1

Ways to Declare Array

Array Literal (The Standard Way)

This is the most common and recommended way. It is concise and easy to read.

const GOT = ["Westoras", "Kings Landings" , 1 , false];

Array() Constructor

You can use the built-in Array global object. This behaves differently depending on how many arguments you pass.

// Case A: Multiple arguments (creates an array with these items)
const numbers = new Array(1, 2, 3); // [1, 2, 3]

// Case B: Single numerical argument 
const emptySlots = new Array(5); 
// Creates an array of length 5 with NO items

Array.of()

Introduced in ES6, this was created to fix the Single Argument confusion of the Array() constructor.

const singleNum = Array.of(5); // [5]

Array.from()

This is used to create an array from an array-like or iterable object.

// From a string
const letters = Array.from("Hello"); // ["H", "e", "l", "l", "o"]

// Using a mapping function (2nd argument)
const squares = Array.from([1, 2, 3], x => x * x); // [1, 4, 9]

Spread Operator (...)

Often used to clone an existing array or convert other iterables.

const original = [1, 2, 3];
const clone = [...original];

Arrays Methods

Static Methods

A static method is a function belonging to a class rather than an instance of that class.

Array.isArray()

Think of Array.isArray() as a specialized security guard at a club. His only job is to check if

BTS of isArray

1. The "Are you even an Object?" Check
   First, the guard checks if you are an object. If you are just a piece of text (string), a number, or a simple true/false, he doesn't even look at your ID.
   He says False immediately.

2. The "Hidden Stamp" Check
   If you are an object, he looks for a hidden "Array" stamp inside you. In JavaScript, arrays are "special" objects because they have a .length property that grows and shrinks automatically. Only objects with this specific internal "DNA" get the stamp.
   If he sees the stamp, he says True.

3. The "Mask" (Proxy) Check
   Sometimes, an array wears a mask (called a Proxy). The guard is smart if he sees a mask, he asks the person to take it off so he can check the face underneath. If the person behind the mask is an array, he's happy.
   He checks the real person and says True.

Why not just use instanceof?

You might see people use myList instanceof Array. While that usually works, it has one major weakness:

Imagine two different countries (Iframes). Each country has its own "Array" rules.

• instanceof is like a guard who only recognizes passports from his own country. If an array comes from another country (iframe), he says "I don't know you!"

• Array.isArray() is like a guard who knows what an Array looks like regardless of what country it came from. It's the universal gold standard.

of() & from()

As discussed above it is used to create an Array.

fromAsync()

New available method(2024), that creates an array from an async iterable, iterable, or array-like object and returns the result as a Promise.

const urls = [
  "https://jsonplaceholder.typicode.com/posts/1",
  "https://jsonplaceholder.typicode.com/posts/2",
  "https://jsonplaceholder.typicode.com/posts/3"
]

const responses = await Array.fromAsync(urls, async (url) => {
  const res = await fetch(url)
  return res.status
})

console.log(responses) // [200,200,200]

Instance Methods

Mutator Methods

These methods modify the array they are called on.

• push() / pop(): Add to the end / Remove from the end. (Fast)

• unshift() / shift(): Add to the front / Remove from the front. (Slow, re-indexes everything).

• splice(): The surgical blade. Adds or removes elements at any index.

• sort(): Reorders elements. By default, it converts everything to strings to sort them, which is why [10, 2] becomes [10, 2] because "1" comes before "2".

• reverse(): Flips the array.

• fill(): Replaces a range of elements with a static value.

• copyWithin(): Copies a part of the array to another location within the same array without changing its length.

Accessors Methods

These do not touch the original array. They return a new value or a new array.

• at(): Takes an index and returns the item. It supports negative indices! arr.at(-1) gives you the last item.

• concat(): Merges two arrays into a new one.

• join(): Squashes the array into a string.

• slice(): Takes a "snapshot" of a portion of the array.

• indexOf() / lastIndexOf(): Returns the first or last index where a value is found.

• includes(): Returns true/false if a value exists.

• toString() / toLocaleString(): Converts the array to a string (local version handles dates/currency better).

The New Immutable Methods (ES2023)

These are the modern versions.

• toReversed(): Like reverse(), but leaves the original alone.

• toSorted(): Like sort(), but returns a new sorted array.

• toSpliced(): The safe version of splice().

• with(): The safe way to change one item. arr.with(2, "New") returns a new array with the item at index 2 changed.

Iterators methods

These methods use a callback function to process the array.

• forEach(): Executes code for each item. Returns undefined.

• map() : Transforms each element of an array and returns a new array.

• some(): Checks if at least one item passes a test. Returns Boolean.

• every(): Checks if all items pass a test. Returns Boolean.

• find(): Finds the first item that matches. Returns The Item (or undefined).

• findLast(): Finds the last item that matches. Returns The Item.

• findIndex(): Finds the index of the first match. Returns Number.

• findLastIndex(): Finds the index of the last match. Returns Number.

• reduce(): Boils the array down to a Single Value (like a sum or a single object).

• reduceRight(): Same as reduce, but starts from the end of the array.

Revise Most Common but tricky methods

sort()

The most common mistake with sort() is assuming it sorts numbers correctly by default. In the JS Kingdoms, sort() treats everyone like a string, comparing them by their "dictionary" order rather than their value.

• The Quirk: By default, [10, 2, 22] becomes [10, 2, 22] because "1" comes before "2" in Unicode.

• The Fix: You must provide a compare function.

const powerLevels = [10, 2, 22, 5];

// Correct numeric sort
powerLevels.sort((a, b) => a - b); 
// Output: [2, 5, 10, 22]

// BTS Logic: If (a - b) is negative, 'a' comes first. 
// If positive, 'b' comes first. If 0, they stay put.

reduce()

This is arguably the most powerful yet confusing method. It takes an entire army of data and reduces it into a single value, which could be a number, a string, or even a completely different object.

• The Strategy: It uses an accumulator (the running total) and the current value.

• The Pro Tip: Always provide an initial value to avoid errors with empty arrays.

const treasury = [100, 200, 300];

const totalWealth = treasury.reduce((acc, gold) => {
  return acc + gold;
}, 0); // 0 is the starting point

console.log(totalWealth); // 600

splice()

Unlike slice(), which is a peaceful scout, splice() is a warrior that changes the original array. It is complex because it handles deleting and inserting at the same time.

The Syntax: splice(index, howManyToRemove, itemToInsert1, itemToInsert2...)

const houses = ["Stark", "Lannister", "Targaryen"];

// At index 1, remove 1 item and add "Tyrell" and "Martell"
houses.splice(1, 1, "Tyrell", "Martell");

console.log(houses); 
// ["Stark", "Tyrell", "Martell", "Targaryen"]

flatMap()

Often, you’ll find yourself using .map() followed by .flat(). flatMap() combines these into a single pass, which is more performant and cleaner to read.

• The Strategy: It maps each element using a mapping function, then flattens the result by one level.

const messages = ["Winter is", "Coming soon"];

const words = messages.flatMap(msg => msg.split(" "));
// Output: ["Winter", "is", "Coming", "soon"]

// Without flatMap, you'd get: [["Winter", "is"], ["Coming", "soon"]]

"The best way to predict the future is to create it."
— Peter Drucker

Let's Connect! 🚀

I’m currently deep-diving into the JavaScript, building projects and exploring the internals of the web. If you're on a similar journey or just love talking about JavaScript, let’s stay in touch!

• Connect on LinkedIn: Satpalsinh's Profile

• Follow my Blog: blogs.satpal.cloud

Keep coding and keep building.