JavaScript Scenario-Based Interview Questions

Heavy synchronous computations block the JavaScript main thread, which is responsible for rendering the UI and handling user interactions. When the main thread is busy, the UI becomes unresponsive or frozen.

To keep the application responsive, the heavy computation should be moved off the main thread or broken into smaller tasks.

1. Use Web Workers (Best Solution for Heavy Tasks)

Web Workers allow running JavaScript in a separate background thread, preventing the main UI thread from being blocked.

Main thread:

};const worker = new Worker("worker.js");

Worker file (worker.js):

 onmessage = function(event) {
 const result = heavyComputation(event.data);
 postMessage(result);
}; 

Benefits:

• Runs computation in a separate thread

• UI remains responsive

• Suitable for CPU-heavy operations

2. Break Work into Smaller Chunks

If Web Workers are not needed, the computation can be split into smaller tasks using setTimeout() or requestIdleCallback().

Example idea:

 function processChunk(data) {
 if (data.length === 0) return;

 // process part of the data
 data.shift();

 setTimeout(() => processChunk(data), 0);
} 

This allows the event loop to handle UI updates between chunks.

3. Use Asynchronous APIs

If the heavy work involves I/O operations such as network requests or file reading, use asynchronous APIs like:

• fetch()

• Promise

• async/await

This prevents blocking the main thread.

Heavy synchronous computations block the JavaScript main thread, which is responsible for rendering the UI and handling user interactions. When the main thread is busy, the UI becomes unresponsive or frozen.

To keep the application responsive, the heavy computation should be moved off the main thread or broken into smaller tasks.

1. Use Web Workers (Best Solution for Heavy Tasks)

Web Workers allow running JavaScript in a separate background thread, preventing the main UI thread from being blocked.

Main thread:

 const worker = new Worker("worker.js");

worker.postMessage(data);

worker.onmessage = function(event) {
 console.log("Result:", event.data);
}; 

Worker file (worker.js):

 onmessage = function(event) {
 const result = heavyComputation(event.data);
 postMessage(result);
}; 

Benefits:

• Runs computation in a separate thread

• UI remains responsive

• Suitable for CPU-heavy operations

2. Break Work into Smaller Chunks

If Web Workers are not needed, the computation can be split into smaller tasks using setTimeout() or requestIdleCallback().

Example idea:

 function processChunk(data) {
 if (data.length === 0) return;

 // process part of the data
 data.shift();

 setTimeout(() => processChunk(data), 0);
} 

This allows the event loop to handle UI updates between chunks.

3. Use Asynchronous APIs

If the heavy work involves I/O operations such as network requests or file reading, use asynchronous APIs like:

• fetch()

• Promise

• async/await

This prevents blocking the main thread.

JavaScript’s event loop manages two main types of task queues:

• Microtasks – High priority tasks (Promises, queueMicrotask)

• Macrotasks – Lower priority tasks (setTimeout, setInterval, setImmediate, I/O)

A custom task scheduler can control when tasks run and their priority, allowing you to manage execution order similar to how browsers handle microtasks and macrotasks.

1. Understand the Execution Order

The event loop processes tasks in this order:

Call Stack
 ↓
Microtask Queue
 ↓
Macrotask Queue

Example behavior:

 console.log("Start");

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

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

console.log("End"); 

Output:

Start
End
Microtask
Macrotask

Microtasks always run before the next macrotask cycle.

2. Creating a Simple Task Scheduler

We can implement a scheduler that manages two queues:

• Microtask queue

• Macrotask queue

Example design:

 class TaskScheduler {
 constructor() {
 this.microtasks = [];
 this.macrotasks = [];
 }

 addMicrotask(task) {
 this.microtasks.push(task);
 queueMicrotask(() => this.runMicrotasks());
 }

 addMacrotask(task) {
 this.macrotasks.push(task);
 setTimeout(() => this.runMacrotasks(), 0);
 }

 runMicrotasks() {
 while (this.microtasks.length) {
 const task = this.microtasks.shift();
 task();
 }
 }

 runMacrotasks() {
 if (this.macrotasks.length) {
 const task = this.macrotasks.shift();
 task();
 }
 }
} 

Usage:

 const scheduler = new TaskScheduler();

scheduler.addMicrotask(() => console.log("Microtask 1"));
scheduler.addMacrotask(() => console.log("Macrotask 1"));
scheduler.addMicrotask(() => console.log("Microtask 2")); 

Expected order:

Microtask 1
Microtask 2
Macrotask 1

A race condition occurs when multiple asynchronous operations run at the same time and update shared state, and the final result depends on which one finishes first. In UI applications this often causes incorrect or stale data to appear.

1. How to Detect the Race Condition

Common symptoms:

• UI shows older data after a newer request

• Results change depending on network speed

• Logs show responses arriving in different order than requests

Example problem:

 let userData;

async function loadUser(id) {
 const res = await fetch(`/api/user/${id}`);
 userData = await res.json();
 render(userData);
} 

If the user quickly triggers:

 loadUser(1);
loadUser(2); 

Possible execution:

Request 1 sent
Request 2 sent
Request 2 finishes → UI shows user 2
Request 1 finishes → UI overwritten with user 1 ❌

This creates incorrect UI state.

2. Fix Using Request ID Tracking

Track the latest request and ignore older responses.

 let latestRequest = 0;

async function loadUser(id) {
 const requestId = ++latestRequest;

 const res = await fetch(`/api/user/${id}`);
 const data = await res.json();

 if (requestId === latestRequest) {
 render(data);
 }
} 

Now only the most recent request updates the UI.

3. Cancel Previous Requests (Best Practice)

Use AbortController to cancel outdated requests.

 let controller;

async function loadUser(id) {
 if (controller) controller.abort();

 controller = new AbortController();

 const res = await fetch(`/api/user/${id}`, {
 signal: controller.signal
 });

 const data = await res.json();
 render(data);
} 

Benefits:

• Prevents unnecessary API calls

• Avoids outdated responses

• Saves network resources

4. Serialize Requests When Order Matters

If operations must execute in sequence, ensure one finishes before the next.

Example:

 let queue = Promise.resolve();

function runTask(task) {
 queue = queue.then(() => task());
 return queue;
} 

This ensures requests run in order.

🚀 Performance & Optimization

Rendering 50,000 DOM elements at once is expensive because DOM operations, layout calculations, and memory usage increase significantly, causing slow performance and UI lag. The goal is to reduce the number of elements rendered and optimize rendering operations.

1. Use Virtualization (Most Effective Solution)

Instead of rendering all rows, render only the rows visible in the viewport.

Concept:

50,000 rows
 ↓
Only render ~30–50 rows visible on screen
 ↓
Update rows while scrolling

Libraries commonly used:

• react-window

• react-virtualized

• TanStack Virtual

Example idea:

<List
 height={600}
 itemCount={50000}
 itemSize={35}
 width={800}
/>

This drastically reduces DOM nodes.

2. Implement Pagination

Load and render data in smaller chunks instead of all at once.

Example:

Page 1 → 100 rows
Page 2 → 100 rows
Page 3 → 100 rows

Benefits:

• Smaller DOM size

• Faster initial load

• Reduced memory usage

3. Use Lazy Loading / Infinite Scrolling

Load rows only when the user scrolls near the bottom.

Concept:

Initial load → 100 rows
Scroll → load next 100 rows
Scroll → load next 100 rows

This prevents loading the entire dataset immediately.

Virtual scrolling (or windowing) improves performance when displaying large lists (e.g., 50k+ items) by rendering only the items visible in the viewport instead of the entire dataset.

The key idea is to simulate the full scroll height while only rendering a small subset of items.

1. Core Concept

Instead of rendering all items:

50,000 rows in DOM ❌

Render only visible items:

Viewport shows ~20 rows
Render only 20–30 rows ✔

But maintain the full scroll height so the scrollbar behaves normally.

2. Layout Structure

Virtual scrolling usually uses three elements:

Scrollable Container
 │
 ▼
Full Height Spacer
 │
 ▼
Visible Items (absolute positioned)

Example HTML:

<div id="container">
 <div id="spacer"></div>
 <div id="list"></div>
</div>

• container → scrollable viewport

• spacer → simulates full list height

• list → contains visible rows only

3. Basic Logic

Important variables:

Total items
Item height
Viewport height
Scroll position

Formula:

startIndex = scrollTop / itemHeight
endIndex = startIndex + visibleItemCount

When users keep a tab open for hours, memory leaks usually occur because objects, DOM nodes, or listeners are unintentionally retained in memory. The goal is to identify what objects keep growing and why they are not being garbage collected.

1. Reproduce the Issue

First, reproduce the problem locally.

Steps:

• Open the app in Chrome DevTools

• Simulate user activity for a long period

• Monitor memory usage over time

Tools:

Chrome DevTools → Performance / Memory Tab

Look for steady memory growth without dropping after garbage collection.

2. Take Heap Snapshots

Use Heap Snapshots to inspect memory allocations.

Steps:

1. Open Chrome DevTools → Memory

2. Take a baseline snapshot

3. Interact with the app

4. Take another snapshot

5. Compare the snapshots

Look for:

• Increasing object counts

• Detached DOM nodes

• Large arrays growing over time

Example pattern:

Snapshot 1 → 10,000 objects
Snapshot 2 → 50,000 objects

3. Check for Detached DOM Nodes

A common leak occurs when DOM elements are removed from the page but still referenced in JavaScript.

Example problem:

 const element = document.createElement("div");
document.body.appendChild(element);

// later removed but still referenced 

If references remain, the browser cannot garbage collect the node.

DevTools can show Detached DOM Trees.

4. Look for Unremoved Event Listeners

Event listeners can keep objects alive.

Example issue:

 button.addEventListener("click", handler); 

If the component is destroyed but the listener isn't removed:

 button.removeEventListener("click", handler); 

The handler may keep references alive.

Common cases:

• Scroll listeners

• Window events

• WebSocket listeners

Measuring JS performance in production helps understand real user experience (RUM – Real User Monitoring) rather than just lab benchmarks. The goal is to track page load times, interaction latency, memory usage, and runtime performance across real users and devices.

1. Use the Performance API

The Performance API provides detailed timing metrics directly from the browser.

Example:

 performance.getEntriesByType("navigation"); 

Important metrics include:

DNS lookup time
Connection time
TTFB (Time To First Byte)
DOM Content Loaded
Page Load Time

Example measurement:

 const timing = performance.getEntriesByType("navigation")[0];
console.log(timing.domContentLoadedEventEnd); 

2. Track Web Vitals

Google’s Core Web Vitals measure user experience.

Key metrics:

Example:

 import { onLCP, onCLS, onINP } from 'web-vitals';

onLCP(console.log);
onCLS(console.log);
onINP(console.log); 

These metrics reflect actual user experience.

3. Real User Monitoring (RUM)

Send performance data from users’ browsers to a monitoring service.

Flow:

User Browser
 │
Collect performance metrics
 │
Send to monitoring backend
 │
Analytics dashboards

Popular tools:

• Sentry

• Datadog

• New Relic

• LogRocket

• Elastic APM

These tools track performance across thousands of real sessions.

V8 (the JavaScript engine used in Chrome and Node.js) improves performance by analyzing runtime behavior and compiling frequently executed code into optimized machine code. However, certain coding patterns can cause V8 to de-optimize, forcing it to fall back to slower execution.

1. V8 Execution Pipeline

V8 uses multiple stages to execute JavaScript efficiently.

JavaScript Code
 ↓
Parser → AST
 ↓
Ignition (Interpreter)
 ↓
TurboFan (Optimizing Compiler)
 ↓
Optimized Machine Code

Explanation:

• Ignition Interpreter
  Executes code first and collects runtime information.

• TurboFan Optimizer
  If a function runs frequently (“hot function”), V8 compiles it into optimized machine code.

This optimization relies on predictable code behavior.

2. Hidden Classes (Object Shape Optimization)

V8 creates hidden classes to optimize object property access.

Example:

 function createUser() {
 return { name: "Alice", age: 25 };
} 

If objects are created with the same property order, V8 can optimize property access.

Bad example:

 const user = {};
user.name = "Alice";
user.age = 25;
user.address = "NY"; 

Adding properties dynamically changes the object’s hidden class, which may reduce optimization efficiency.

Best practice:

 const user = {
 name: "Alice",
 age: 25,
 address: "NY"
}; 

3. Inline Caching

V8 uses inline caching to speed up repeated operations.

Example:

 function getName(user) {
 return user.name;
} 

If user objects always have the same structure, V8 can cache property access and make it very fast.

However, if different object shapes are used:

 getName({ name: "Alice" });
getName({ name: "Bob", age: 30 }); 

V8 may invalidate the cache and de-optimize the function.

1. 🧩 Closures & Functional Patterns

Memoization is a technique where the result of a function is cached based on its inputs, so repeated calls with the same arguments return the cached result instead of recomputing it.

However, in real applications we also need cache invalidation so stale data can be refreshed.

1. Basic Memoization Idea

Example problem:

 expensiveFunction(5) // expensive computation
expensiveFunction(5) // should reuse cached result 

Memoization stores:

input → result

Example:

5 → 25

2. Memoization Utility with Cache

We can implement memoization using a Map.

 function memoize(fn) {
 const cache = new Map();

 return function (...args) {
 const key = JSON.stringify(args);

 if (cache.has(key)) {
 return cache.get(key);
 }

 const result = fn(...args);
 cache.set(key, result);

 return result;
 };
} 

Usage:

 const square = memoize((n) => {
 console.log("Computing...");
 return n * n;
});

square(5); // Computing...
square(5); // Cached result 

3. Adding Cache Invalidation

Sometimes cached results become stale, so we allow manual cache clearing.

 function memoize(fn) {
 const cache = new Map();

 function memoized(...args) {
 const key = JSON.stringify(args);

 if (cache.has(key)) {
 return cache.get(key);
 }

 const result = fn(...args);
 cache.set(key, result);

 return result;
 }

 memoized.clearCache = () => cache.clear();

 memoized.deleteCache = (...args) => {
 const key = JSON.stringify(args);
 cache.delete(key);
 };

 return memoized;
} 

Usage:

 square(5); // compute
square(5); // cached

square.deleteCache(5); // remove specific cache
square.clearCache(); // clear all cache 

A closure occurs when a function retains access to variables from its outer scope even after the outer function has finished executing.

Example:

 function createCounter() {
 let count = 0;
 return function () {
 count++;
 return count;
 };
} 

The inner function remembers count even after createCounter() finishes.

How This Can Cause Memory Leaks

Closures can cause memory leaks when they retain references to large objects or DOM elements that are no longer needed. Because the closure still references them, the JavaScript garbage collector cannot free that memory.

Example Problem

 function setupHandler() {
 const largeData = new Array(1000000).fill("data");

 document.getElementById("btn").onclick = function () {
 console.log(largeData.length);
 };
} 

Problem:

• largeData is captured by the closure.

• As long as the event handler exists, largeData stays in memory.

• Even if the data is no longer needed, it cannot be garbage collected.

Common Situations Where This Happens

1. Event Listeners

Closures in event handlers may keep large objects alive.

Example:

 element.addEventListener("click", () => {
 console.log(largeObject);
}); 

If the listener isn't removed, the closure holds the reference.

2. Timers or Intervals

Closures inside timers can hold references indefinitely.

Example:

 setInterval(() => {
 console.log(bigData);
}, 1000); 

If the interval isn't cleared, bigData stays in memory.

3. Long-lived Callbacks

Closures used in asynchronous callbacks may keep unnecessary data alive longer than expected.

Currying is a technique where a function that takes multiple arguments is transformed into a sequence of functions each taking a single argument.

Example transformation:

add(a, b, c)
→ add(a)(b)(c)

Implementation

 function curry(fn) {
 return function curried(...args) {
 if (args.length >= fn.length) {
 return fn(...args);
 }
 return (...next) => curried(...args, ...next);
 };
} 

Example usage:

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

const curriedAdd = curry(add);

curriedAdd(1)(2)(3); // 6
curriedAdd(1, 2)(3); // 6
curriedAdd(1)(2, 3); // 6 

Real Use Cases

1. Function Reusability

You can create specialized functions by partially applying arguments.

 const multiply = (a, b) => a * b;
const curriedMultiply = curry(multiply);

const double = curriedMultiply(2);

double(5); // 10
double(10); // 20 

This improves code reuse.

2. Event Handlers / UI Logic

Currying helps pass configuration into event handlers.

 const handleClick = (type) => (event) => {
 console.log(type, event.target);
};

button.addEventListener("click", handleClick("login")); 

The handler is pre-configured with "login".

The once() utility ensures that a function executes only the first time it is called. Any subsequent calls return the previously computed result without re-running the function.

Implementation

 function once(fn) {
 let called = false;
 let result;

 return function (...args) {
 if (!called) {
 called = true;
 result = fn(...args);
 }
 return result;
 };
} 

Example

 const init = once(() => {
 console.log("Initialized");
 return 42;
});

init(); // "Initialized"
init(); // nothing printed
init(); // nothing printed 

How It Works

• A closure keeps two variables:

  • called → tracks whether the function has already run.

  • result → stores the result of the first execution.

• On the first call, the function runs and the result is saved.

• On later calls, the stored result is returned without executing the function again.

Debounce ensures a function runs only after a delay since the last call. Useful for events like search input, resize, scroll.

Implementation

 function debounce(fn, delay) {
 let timer;

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

Example

 const handleSearch = debounce((query) => {
 console.log("Searching:", query);
}, 300); 

Every new call resets the timer, so the function runs only once after the user stops triggering events.

Throttle

Throttle ensures a function runs at most once every given interval, no matter how many times it’s triggered.

Useful for scroll events, mouse movement, window resize.

Implementation

 function throttle(fn, limit) {
 let lastCall = 0;

 return function (...args) {
 const now = Date.now();

 if (now - lastCall >= limit) {
 lastCall = now;
 fn.apply(this, args);
 }
 };
} 

Example

 const handleScroll = throttle(() => {
 console.log("Scroll event handled");
}, 200); 

The function executes once every 200ms, regardless of how frequently the event fires.

Key Difference

1. ---

   ⚙️ System Design in Frontend

For an application serving hundreds of millions or billions of users, the frontend architecture must focus on performance, scalability, maintainability, and fast global delivery. The design must ensure users across different devices and regions experience low latency and responsive UI.

1. Layered Frontend Architecture

A scalable frontend is usually structured into clear layers.

UI Components
 │
State Management
 │
API / Data Layer
 │
Backend Services

Layers:

• UI Layer – reusable components and design system

• State Layer – manages app state

• Data Layer – API communication and caching

• Infrastructure Layer – CDN, edge caching, monitoring

This separation makes the codebase maintainable and scalable.

2. Component-Based Design System

Use a component-based framework such as:

• React

• Vue

• Angular

Structure components into:

Atoms → Buttons, Inputs
Molecules → Form Fields
Organisms → Complex UI Blocks
Pages → Full screens

Benefits:

• Reusability

• Consistent UI

• Easier team collaboration

3. Micro-Frontend Architecture

Large applications often split the frontend into independent micro frontends owned by different teams.

Example:

App Shell
 │
 ├── Auth Module
 ├── Dashboard Module
 ├── Payment Module
 └── Notification Module

Tools commonly used:

• Module Federation

• Single-SPA

Benefits:

• Independent deployments

• Smaller teams working in parallel

• Reduced coupling

4. Global Content Delivery (CDN)

To serve billions of users efficiently:

User
 │
CDN Edge Server
 │
Origin Server

Use CDNs such as:

• Cloudflare

• Akamai

• AWS CloudFront

Benefits:

• Reduced latency

• Faster static asset delivery

• Edge caching

5. Code Splitting and Lazy Loading

Avoid loading the entire application at once.

Example:

Initial Bundle
 │
Load page-specific bundles on demand

Techniques:

• Dynamic imports

• Route-based code splitting

This significantly reduces initial page load time.

A global state manager allows different parts of an application to share and react to the same state without passing props through many layers.

The core idea is simple:

State
 │
Store
 │
Subscribers (components)

Whenever the state changes, all subscribers are notified and updated.

Basic Implementation

 function createStore(initialState) {
 let state = initialState;
 const listeners = new Set();

 function getState() {
 return state;
 }

 function setState(updater) {
 state =
 typeof updater === "function"
 ? updater(state)
 : { ...state, ...updater };

 listeners.forEach((listener) => listener(state));
 }

 function subscribe(listener) {
 listeners.add(listener);
 return () => listeners.delete(listener);
 }

 return { getState, setState, subscribe };
} 

Usage Example

 const store = createStore({ count: 0 });

store.subscribe((state) => {
 console.log("State updated:", state);
});

store.setState({ count: 1 });
store.setState((prev) => ({ count: prev.count + 1 })); 

Output:

State updated: { count: 1 }
State updated: { count: 2 }

How It Works

1. State Storage

let state = initialState;

The store holds the current global state.

2. Subscribers

const listeners = new Set();

Components or modules subscribe to state changes.

3. State Updates

setState(...)

When state changes:

• The new state is computed

• All listeners are notified

4. Subscription System

subscribe(listener)

Allows components to react when the state updates.

An offline-first application is designed so that it works without internet connectivity, storing data locally and synchronizing with the server when the connection becomes available. The goal is to provide a seamless user experience regardless of network conditions.

1. Core Architecture

An offline-first app usually has three layers:

UI Layer
 │
Local Data Layer (IndexedDB / Local Storage)
 │
Sync Layer
 │
Remote Server

Flow:

User Action
 │
Write to Local DB
 │
Update UI immediately
 │
Background Sync → Server

This ensures the app remains responsive even when offline.

2. Service Workers for Offline Support

Service workers act as a network proxy between the app and the network.

Responsibilities:

• Cache static assets

• Intercept network requests

• Serve cached content when offline

Example concept:

User Request
 │
Service Worker
 │
 ├─ Cached response (offline)
 └─ Network request (online)

Common caching strategies:

• Cache First

• Network First

• Stale-While-Revalidate

3. Local Data Storage

Offline apps need a persistent local database.

Common options:

• IndexedDB (best for large data)

• LocalStorage (small data)

• Libraries like Dexie.js or PouchDB

Example flow:

User creates note
 │
Save to IndexedDB
 │
UI updates instantly

The app works even without internet.

4. Background Synchronization

When connectivity returns, the app should sync local changes with the server.

Example process:

Offline Action
 │
Store in Sync Queue
 │
Connection Restored
 │
Send Updates to Server

Tools:

• Background Sync API

• Retry queues

• Conflict resolution logic

When multiple teams work on the same codebase, the architecture must ensure clear ownership, modularity, and minimal coupling. The goal is to allow teams to work independently without breaking each other’s code.

1. Domain-Based Modular Structure

Organize the codebase around business domains, not technical layers.

Example:

src/
 auth/
 payments/
 orders/
 notifications/
 shared/

Each domain contains its own:

auth/
 components/
 services/
 hooks/
 api/
 tests/

Benefits:

• Clear team ownership

• Easier maintenance

• Reduced cross-team conflicts

2. Shared Core Layer

Common utilities should live in a shared module.

Example:

shared/
 ui/
 utils/
 hooks/
 config/

Examples of shared resources:

• UI components

• Helper functions

• API clients

• Design tokens

Important rule:

Domains can depend on shared modules
Shared modules must NOT depend on domains

3. Enforce Clear Module Boundaries

Use tooling to prevent accidental coupling between modules.

Techniques:

• TypeScript path aliases

• ESLint dependency rules

• Architecture linting tools

Example dependency rule:

auth → shared 
auth → payments 

Feature flags (feature toggles) allow you to enable or disable features dynamically without redeploying the application. They are widely used for A/B testing, gradual rollouts, canary releases, and safe deployments.

1. Basic Concept

Instead of directly enabling a feature in code:

showNewDashboard();

Use a feature flag:

if (flags.newDashboard) {
 showNewDashboard();
}

Now the feature can be turned on/off remotely.

2. Central Feature Flag Store

Maintain a centralized configuration for feature flags.

Example:

 const flags = {
 newDashboard: true,
 paymentFlowV2: false
}; 

Usage:

 if (flags.newDashboard) {
 renderNewDashboard();
} else {
 renderOldDashboard();
} 

This keeps feature control centralized.

3. Fetch Flags from Backend

In production systems, feature flags are usually fetched from a remote config service.

Flow:

Frontend App
 │
Fetch Feature Flags
 │
Feature Flag Service

Example:

 async function loadFlags() {
 const res = await fetch("/api/feature-flags");
 return res.json();
} 

The app loads flags during startup.

4. Create a Feature Flag Utility

A simple helper function can make feature checks easier.

 function isEnabled(flagName) {
 return flags[flagName] === true;
} 

Usage:

 if (isEnabled("newDashboard")) {
 renderNewDashboard();
} 

🌐 Networking & APIs

🔐 Security & Edge Cases

element.innerHTML = userInput;

<script>alert("XSS")</script>

element.textContent = userInput;

<div>{userInput}</div> 

dangerouslySetInnerHTML
v-html
innerHTML

Server → sets cookie
Browser → stores cookie automatically
JS → cannot access it

Set-Cookie: authToken=abc123; HttpOnly; Secure; SameSite=Strict

localStorage.setItem("token", token); 

XSS attack → JS can read token → token stolen

sessionStorage.setItem("token", token);

let authToken = null;

const obj = {}; obj.__proto__.isAdmin = true; const user = {}; console.log(user.isAdmin); // trueconst obj = {};

function merge(target, source) { for (const key in source) { target[key] = source[key]; } } merge({}, JSON.parse('{"__proto__": {"admin": true}}'));Result:

Object.prototype.admin = true

__proto__
prototype
constructor

If key matches dangerous property → ignore

const obj = Object.create(null);

Use secure libraries

if (Object.hasOwn(obj, key)) {
 // safe access
}

Old lodash versions
deep merge libraries

Main App
 │
Web Worker
 │
Untrusted Code

const worker = new Worker("worker.js"); worker.postMessage(userCode); worker.onmessage = (e) => { console.log("Result:", e.data); };

<iframe sandbox="allow-scripts"></iframe>

DOM access
Cookies
Local storage
Top-level navigation

window.postMessage()

const safeEval = new Function("safeAPI", userCode); safeEval(allowedFunctions);

Your site → loads analytics.js
analytics.js compromised → injects malicious code
Users affected on every page load

User IDs
Session information
Form inputs
Browsing behavior

Third-party script
 │
Injects malicious JS
 │
Steals cookies or tokens

Cookies
LocalStorage
SessionStorage
DOM content
Network requests

🏗️ Core JavaScript Deep Internals

function promiseAll(promises) { return new Promise((resolve, reject) => { const results = []; let completed = 0; if (promises.length === 0) resolve([]); promises.forEach((p, index) => { Promise.resolve(p) .then(value => { results[index] = value; completed++; if (completed === promises.length) { resolve(results); } }) .catch(reject); }); }); }Example

const p1 = Promise.resolve(1); const p2 = Promise.resolve(2); const p3 = Promise.resolve(3); promiseAll([p1, p2, p3]).then(console.log);

[1, 2, 3]

Emitter
 │
Event Triggered
 │
Subscribed Listeners Execute

class EventEmitter { constructor() { this.events = {}; } on(event, listener) { if (!this.events[event]) this.events[event] = []; this.events[event].push(listener); } emit(event, ...args) { if (!this.events[event]) return; this.events[event].forEach(listener => listener(...args)); } off(event, listener) { if (!this.events[event]) return; this.events[event] = this.events[event].filter(l => l !== listener); } once(event, listener) { const wrapper = (...args) => { listener(...args); this.off(event, wrapper); }; this.on(event, wrapper); } }

const emitter = new EventEmitter(); function greet(name) { console.log("Hello", name); } emitter.on("welcome", greet); emitter.emit("welcome", "Lingesh");

Hello Lingesh

Objects that are reachable → kept in memory
Objects that are unreachable → removed

Heap
 ├─ New Space (young objects)
 └─ Old Space (long-lived objects)

Most objects die young
Few objects live long

New Space
 ├─ From Space
 └─ To Space

New Space → Old Space

const config = { theme: "dark" };

const obj = {};
obj.self = obj;

function deepClone(obj, map = new WeakMap()) { if (obj === null || typeof obj !== "object") return obj; if (map.has(obj)) return map.get(obj); const clone = Array.isArray(obj) ? [] : {}; map.set(obj, clone); for (const key in obj) { clone[key] = deepClone(obj[key], map); } return clone; }

const a = { value: 1 }; a.self = a; const copy = deepClone(a); console.log(copy.value); // 1 console.log(copy.self === copy); // trueHow It Works

function greet() { console.log(this.name); } const person = { name: "Lingesh" }; const bound = greet.bind(person); bound(); // LingeshPolyfill Implementation

Function.prototype.myBind = function (context, ...args) { const fn = this; return function (...newArgs) { return fn.apply(context, [...args, ...newArgs]); }; };Example Usage

function greet(greeting) { console.log(greeting + " " + this.name); } const user = { name: "Lingesh" }; const sayHello = greet.myBind(user, "Hello"); sayHello(); // Hello LingeshHow It Works