JavaScript Interview Questions

Yes, JavaScript is case-sensitive, and this trips up beginners constantly. myVariable and myvariable are two completely different identifiers. This applies to variable names, function names, and even built-in keywords. Writing getElementById as getElementByID will throw an error. Always double-check your casing.

let myVariable;
let myvariable;

Client-side JavaScript runs in the user's browser. It handles UI interactions, DOM manipulation, animations, and form validation. It's what makes a page feel responsive without a full reload.

Server-side JavaScript (typically Node.js) runs on the server. It handles API requests, database queries, authentication, and file operations. The key difference? Client-side code is visible to anyone (open DevTools and you can see it), while server-side code stays private. Never put secrets in client-side JavaScript.

• High-Level Language: You write readable code, not raw machine instructions.
• Garbage Collected: Memory is cleaned up automatically - no manual free() calls.
• Interpreted (JIT): Code gets compiled on-the-fly by the engine (V8, SpiderMonkey) for speed.
• Multi-Paradigm: You can write OOP, functional, or procedural code - your choice.
• Prototype-Based: Objects inherit from other objects directly, not from classes (classes are syntactic sugar).
• First-Class Functions: Functions are values - assign them to variables, pass them around, return them.
• Dynamically Typed: Variables can hold any type, and types are checked at runtime, not compile time.
• Single Threaded: One call stack, one thing happening at a time.
• Non-Blocking Event Loop: Async operations (network, timers) don't freeze the main thread.
• Platform Independent: Runs in any browser, on any OS with Node.js, and even on IoT devices.

Read more

JavaScript is dynamically typed . You don't declare types when creating variables - JavaScript figures out the type at runtime. A variable can hold a string one moment and a number the next. This gives you flexibility but can cause sneaky bugs. That's exactly why TypeScript (which adds static types on top of JavaScript) has become so popular.

The secret to JavaScript's speed despite being single-threaded is the event loop. When you hit something slow - a fetch call, a setTimeout - JavaScript registers a callback and immediately moves on to the next line. It does not wait. When the slow operation finishes, the callback is placed in a queue and runs once the main thread is free. This is what keeps the main thread available for other work instead of sitting idle. The flip side: a long-running synchronous loop will freeze everything, since there is only one thread.

In JavaScript, a symbol is a primitive type introduced in ES6 that creates a guaranteed unique identifier. The main use case? Adding properties to objects without risking name collisions. Every Symbol() call creates a brand new, unique value - even Symbol("id") === Symbol("id") is false. You'll see them used in libraries and frameworks to add "hidden" properties to objects.

const mySym = Symbol(8);

BigInt lets you work with integers beyond JavaScript's safe number limit (2^53 - 1). Regular numbers lose precision past that point, which can cause real bugs in financial or scientific apps. You create a BigInt by appending "n" to a number literal or calling the BigInt() constructor. One gotcha: you can't mix BigInt and regular numbers in the same expression without explicit conversion.

const bigNumber = BigInt(35445565654656);
const anotherBigNumber = 3454354543543543n;

High-level languages like JavaScript and Python hide hardware details and let you focus on solving problems quickly. But sometimes you need direct control over memory and CPU.

Low-level languages like C and Assembly shine in embedded systems (think microcontrollers in your car), operating system kernels, device drivers, and anywhere performance is critical - like game engines or real-time audio processing. When every microsecond counts, you want low-level control.

High-level languages (JavaScript, Python, Ruby) let you write code that reads almost like English. You don't worry about memory allocation or CPU registers. Trade-off? Slightly less performance. Low-level languages (C, Assembly) give you direct control over hardware and memory. The code is harder to write and read, but you get maximum performance and minimal overhead. The quick test: if the language manages memory for you, it's high-level. If you're calling malloc yourself, it's low-level.

Developer tools are how you debug, profile, and build efficiently. You'll use them every single day as a developer. Here are the ones that matter most:

• 1. Chrome DevTools:
  • Inspect and live-edit HTML/CSS in real time.
  • Set breakpoints and step through JavaScript.
  • Profile network requests and find performance bottlenecks.
• 2. Visual Studio Code:
  • IntelliSense gives you smart autocomplete as you type.
  • Built-in debugger with breakpoints and watch expressions.
  • Thousands of extensions for any framework or language.
• 3. Webpack:
  • Bundles your JS, CSS, and assets into optimized files for production.

Type coercion is JavaScript quietly converting values behind your back to make an operation work. When you write "5" + 3, JS turns 3 into a string and gives you "53". That's implicit coercion - the engine decides on its own. Explicit coercion is when you do it yourself with Number("5") or String(42). The key interview insight: implicit coercion is the root cause of most == vs === confusion, and why experienced devs almost always prefer strict equality.

Manual type conversion is when you explicitly tell JavaScript to change a value's type, rather than letting the engine guess. You use built-in functions like Number(), String(), Boolean(), parseInt(), or parseFloat(). This makes your intent clear to anyone reading the code. For example, Number("42") gives you 42 as a number, and String(true) gives you "true". Always prefer this over relying on implicit coercion - your future self will thank you when debugging.

JavaScript has a few hard rules for identifiers : they must start with a letter, underscore, or dollar sign (never a number), they're case-sensitive, and they can't be reserved keywords. Beyond the rules, conventions matter: use camelCase for variables and functions, PascalCase for classes, and UPPER_SNAKE_CASE for constants. Following these patterns makes your code instantly recognizable to other JavaScript developers. Read More

Reserved keywords are words that JavaScript has already claimed for its own grammar - things like if, return, class, let, and const. You can't use them as variable or function names because the engine would get confused about whether you mean the keyword or your variable. A common trip-up: class is reserved even in contexts where you're not using classes, and some words like await are only reserved inside async functions.

Before ES6, we only had var, and it caused all sorts of scoping headaches. let was introduced to fix that by giving you block-level scope - a variable declared with let inside an if-block or for-loop stays inside that block.

let also behaves differently with hoisting. While var gets hoisted and initialized as undefined (so you can access it before declaration), let gets hoisted but stays in a "temporal dead zone" until execution reaches the declaration line. Access it too early and you get a ReferenceError instead of a silent undefined - which is actually better because it catches bugs early.

var is the original way to declare variables in JavaScript, and understanding its quirks helps you debug legacy code and ace interview questions.

var has function scope, not block scope. Declare a var inside an if-block and it leaks out into the surrounding function. It also hoists to the top of its scope and initializes as undefined, which means you can use a var before the line where you declared it without getting an error - you'll just get undefined. This silent behavior is a classic bug factory. The classic interview example: a for-loop with var and setTimeout where every iteration prints the same final value. Use let or const in modern code to avoid these traps.

const tells JavaScript "this binding won't change." You must assign a value immediately, and you can't reassign it later. This is why most style guides recommend const as your default choice - it signals intent clearly.

Here's the biggest misconception about const: it does NOT make values immutable. It only prevents reassignment of the variable itself. So a const object can still have its properties changed, and a const array can be pushed to. You just can't point the variable at a completely different object or array. If you need true immutability, look into Object.freeze().

Alert boxes are the blunt instrument of user communication. They block everything - your script pauses, and the user can only click OK. Here's what makes them painful:

• Limited Interaction: The user gets one button. No choices, no input, just "OK." Your entire page freezes until they click it.
• Customization Constraints: You can't style them at all. They look different on every browser and OS, and they'll clash with your carefully designed UI.
• No Input Collection: Alert boxes are one-way. If you need user input, you'd need prompt() or a custom modal instead.

The confirm() box is like alert()'s older sibling - it shows a message but gives the user two buttons: "OK" and "Cancel." It returns true or false based on their choice. You'll see it used for "Are you sure you want to delete this?" type prompts. Unlike alert(), it actually captures a decision from the user Read more . In production apps, custom modals are preferred because confirm() blocks execution and you can't customize the button text or styling.

window.alert() pops up a browser-native dialog with your message and an OK button. The catch? It completely freezes your script and the page until the user dismisses it. That's why it's mostly used for quick debugging during development or critical warnings. Overusing alerts trains users to click OK without reading, which defeats the purpose. For anything user-facing in production, use toast notifications or modals instead.

The prompt() box is the only built-in dialog that collects text input from the user. It shows a message, a text field, and OK/Cancel buttons. Click OK, it returns the typed string. Click Cancel, it returns null. You can also pass a default value as the second argument Read more . Quick tip: always check for null before using the return value, since users can cancel. Like alert() and confirm(), it blocks execution, so use HTML form inputs for real applications.

Arithmetic operators are your basic math toolkit: addition (+), subtraction (-), multiplication (*), division (/), modulus (%), and exponentiation (**). The one that trips people up is +, because JavaScript overloads it for string concatenation too. So 5 + "3" gives you "53", not 8. Also worth knowing: modulus (%) is handy for checking even/odd numbers or cycling through arrays.

= (Assignment Operator): This puts a value into a variable. x = 5; stores 5 in x. It's not asking a question - it's giving an order.

== (Equality Operator): This asks "are these loosely equal?" and lets JavaScript convert types to make it work. So 5 == '5' returns true because JS converts the string to a number first. This is where bugs love to hide.

=== (Strict Equality Operator): This asks "are these exactly the same value AND type?" No conversions, no surprises. 5 === '5' returns false because number and string are different types. This is the one you should use by default. A common interview test: mixing these up in conditions is one of the most frequent JavaScript bugs in code reviews.

Operator precedence is the pecking order that determines which operations run first when multiple operators appear in one expression. Just like in math where multiplication happens before addition, JavaScript has its own hierarchy: grouping () > member access . > NOT ! > arithmetic > comparison > logical AND > logical OR > assignment. When in doubt, use parentheses to make your intent explicit. Code that relies on obscure precedence rules is hard to read and a breeding ground for bugs.

A control structure is how you tell your program to make decisions and repeat work instead of just running line by line from top to bottom. Without them, your code would be a straight line with no branches. The three main types are: sequential (code runs in order, the default), selection (if/else, switch - pick a path based on a condition), and iteration (for, while - repeat a block until a condition changes). Interviewers like to hear you name all three.

Imagine you need to send a "Happy Birthday" email to 10,000 users. You wouldn't write 10,000 lines of send-email code. A loop lets you write the logic once and repeat it as many times as needed. It keeps running a block of code as long as some condition holds true, then stops. Loops are everywhere: processing arrays, reading files line by line, polling for data, or retrying failed operations. The key is always making sure your condition eventually becomes false, or you've got an infinite loop on your hands.

The for...of loop (ES6) gives you the values directly instead of making you deal with index counters. Instead of for (let i = 0; i < arr.length; i++), you just write for (const item of arr). Cleaner and less error-prone. It works on anything iterable: arrays, strings (character by character), Maps, Sets, and even NodeLists from the DOM Read more . One catch: it does NOT work on plain objects. For objects, you need for...in or Object.entries().

The for...in loop walks through the enumerable property names (keys) of an object. It's designed for objects, not arrays. Write for (const key in myObject) and you get each property name as a string, then access values with myObject[key] Read more . Heads up: for...in also iterates over inherited prototype properties, so always use hasOwnProperty() to filter, or better yet, use Object.keys() with forEach for cleaner object iteration.

Reach for a for loop when you know the count upfront, like iterating through an array or running something exactly 10 times. All the loop logic (start, stop, step) lives in one neat line:

for (let i = 0; i < 10; i++) {
  // Executes 10 times
}

Use a while loop when the number of iterations depends on a condition you can't predict, like waiting for user input, polling a server, or processing data until a sentinel value appears:

while (condition) {
  // Executes as long as condition is true
}

break is your emergency exit from a loop or switch block. The moment JavaScript hits it, execution jumps to the first line after the loop. It's perfect for stopping early once you've found what you're looking for - like searching an array and stopping at the first match Read more .

continue is more selective - it skips the rest of the current iteration and jumps to the next one. Use it to skip items that don't meet your criteria without nesting everything inside an if-block. For example, skip invalid entries in an array while processing the rest. Both keywords only affect the innermost loop they're inside.

The default case is your fallback when none of the other case values match - think of it like the else in an if-else chain. You should almost always include one, even if it just logs an unexpected value or throws an error, so you know when something unexpected slips through Read more.

Switch uses strict equality (===) for comparisons, which means it's case-sensitive - "apple" and "Apple" are different cases. If you're matching user input or data from an external source, normalize the case first (e.g., .toLowerCase()) before passing it to the switch, otherwise you'll end up with unmatched cases Read more.

ECMA-262 is the formal specification that defines how JavaScript works - the syntax, semantics, built-in objects, all of it. New language features go through the TC39 proposal process before landing in a new edition of ECMA-262. When you see "ES2023" or "ES6", those are shorthand for specific editions of this spec.

ISO/IEC 22275 is based on ECMA-262 - it's essentially the same JavaScript spec published as an ISO standard. This matters mainly for organizations or governments that require ISO-certified standards for procurement. In day-to-day development you won't encounter it, but it's worth knowing it exists.

Separation of concerns means keeping different responsibilities in different places - HTML structures content, CSS handles presentation, and JavaScript handles behavior. In component-based frameworks it means not mixing data-fetching logic with rendering logic. It makes code easier to maintain and test because each piece only needs to know about its own job.

In non-strict (sloppy) mode, JavaScript silently swallows a lot of mistakes - assigning to undeclared variables creates accidental globals, writing to read-only properties fails silently, and octal literals can cause confusion. These 'helpful' behaviors are actually traps. Always use 'use strict' at the top of your files, or just use ES modules which are strict by default.

The big differences are scope and hoisting. var is function-scoped and hoisted as undefined - you can use it before its declaration and it won't throw. let and const are block-scoped and live in a 'temporal dead zone' until their declaration - accessing them early throws a ReferenceError. Also, const can't be reassigned, though the object it points to can still be mutated.

Almost always use string literals - 'hello' or "hello". They're primitives, fast, and work exactly as you'd expect with ===. String objects (new String('hello')) are wrapper objects and behave oddly - two different new String('hello') instances won't be equal with === because they're different object references. There's virtually no reason to use new String() in real code.

Implicit coercion is JavaScript quietly converting types behind your back during operations - like '5' + 3 giving '53' instead of 8. It's one of the language's most notorious gotcha areas. The rules are complex: + with a string coerces to string, but - coerces to number. Use === instead of == to avoid comparison coercions, and convert types explicitly when you need control.

Explicit conversion means you're deliberately converting a value yourself - Number('42'), String(123), Boolean(0). This is always preferable to letting JavaScript coerce implicitly, because it makes your intent clear and avoids surprises. Number() is stricter than parseInt() - Number('42px') gives NaN, while parseInt('42px') gives 42.

Scoping is the set of rules that determines where a variable is accessible. JavaScript has lexical scoping, meaning scope is determined by where code is written, not where it's called from. Inner scopes can access outer scope variables, but not vice versa - this is the basis of closures and is one of the most important concepts to internalize.

There are three scopes: global (accessible everywhere), function (accessible only within the function it's declared in), and block (accessible only within the {} block, and only for let/const). The addition of block scope in ES6 was a big deal - it lets you limit a variable's lifetime to exactly the loop or if-branch that needs it, rather than the entire function.

Functional programming centers on three ideas: pure functions (no side effects, same input always returns same output), immutability (don't mutate data, create new copies), and higher-order functions (functions that take or return other functions). In practice this means favoring map, filter, and reduce over loops and mutations. Pure functions are trivially testable and easy to reason about.

You have four options: function declaration (function foo() {}) - hoisted and callable anywhere in its scope; function expression (const foo = function() {}) - not hoisted; arrow function (const foo = () => {}) - shorter syntax and lexical this; and the Function constructor - basically never use this in real code since it evaluates a string. In modern code, declarations and arrow functions cover 95% of use cases.

A function expression is a function assigned to a variable rather than declared standalone - const double = function(x) { return x * 2; }. Because it's assigned like any other value, it's not hoisted, so you can only call it after the line it's defined on. You can give function expressions a name (useful for stack traces in debugging), but the name is only accessible inside the function itself.

An anonymous function has no name - common as inline callbacks where you don't need to reuse the function elsewhere. You see them constantly in array methods (arr.map(x => x * 2)), event listeners, and promise chains. The downside is that unnamed functions show up as 'anonymous' in stack traces, which can make debugging harder - so if a callback is complex or reused, give it a name.

The main practical difference is hoisting - declarations are fully hoisted so you can call them before they appear in the code, which can be convenient but also surprising. Expressions aren't hoisted, enforcing a clear 'define before use' order. Most style guides prefer function declarations for top-level reusable functions, and expressions (usually arrow functions) for inline or callback use.

The critical difference is this binding. Regular function expressions get their own this set by how they're called - which causes the classic 'lost context' bug in callbacks and event handlers. Arrow functions capture the this from the enclosing scope at definition time and never change it. Arrow functions also can't be used as constructors and don't have their own arguments object.

Callback hell is when you nest async callbacks three, four, or five levels deep because each operation depends on the previous one's result - you get a triangle of doom that's nearly impossible to read or debug. It was a real problem before Promises and async/await existed. The fix is to use async/await or chain Promises - both flatten the nesting into sequential-looking code that's much easier to follow.

setTimeout(fn, delay) schedules a function to run once after delay milliseconds, returning a timer ID. Pass that ID to clearTimeout(id) to cancel it before it fires - this is important in React components to avoid calling setState after a component has unmounted. Note that the delay is a minimum, not a guarantee - if the main thread is busy, the callback fires later.

setInterval(fn, delay) calls your function repeatedly every delay milliseconds until you stop it. Always capture the returned ID and call clearInterval(id) when you're done - forgetting to clear it is a common memory leak. One gotcha: if your callback takes longer to run than the interval delay, calls can pile up. For that pattern, chain setTimeout calls recursively instead.

Debouncing delays execution until a burst of events stops - each new event resets the timer. The classic example is a search box: you don't want an API call on every keystroke, just when the user pauses typing. Implement it by clearing and resetting a setTimeout on each event. Libraries like Lodash have a battle-tested _.debounce() utility, so use that rather than rolling your own.

Throttling limits how often a function fires regardless of how many events come in - like allowing a call at most once every 200ms. Unlike debouncing (which waits for silence), throttling guarantees regular execution during continuous events. Use it for scroll or mousemove handlers where you want smooth, regular updates without hammering the browser. Lodash's _.throttle() is the pragmatic choice for production code.

Design patterns are named, reusable solutions to common software problems - they're vocabulary for communicating architectural decisions. In JavaScript you'll encounter the Module pattern (encapsulating code with closures), Observer/Pub-Sub (event-driven communication), Factory (creating objects without exposing constructor logic), and Singleton (ensuring one instance). Knowing the names helps you recognize and discuss architectural choices clearly.

Regular numbers cap out at Number.MAX_SAFE_INTEGER (2^53 - 1) before they lose integer precision. BigInt handles arbitrarily large integers exactly, which matters for things like database IDs from 64-bit systems or financial calculations. The big limitation: you can't mix them in arithmetic - 10n + 5 throws a TypeError - you have to convert explicitly. Also, BigInt doesn't support decimal fractions.

toFixed(n) rounds and formats to n decimal places as a string - useful for displaying currency, but remember it returns a string so don't do math on it afterward. toString(base) converts to a string in any base, so (255).toString(16) gives 'ff'. Number.parseInt() and Number.parseFloat() are the same as the global versions. Number.isNaN() is the safe NaN check, and valueOf() is rarely called directly - it's used internally by JavaScript during type coercion.

The Date object represents a moment in time as milliseconds since Unix epoch (Jan 1, 1970 UTC). Create one with new Date() for now, or pass a timestamp, date string, or explicit year/month/day values. One major gotcha: months are zero-indexed (January is 0), which trips up everyone. For anything non-trivial in production - parsing, formatting, timezones - use a library like date-fns or the newer Temporal API rather than fighting the built-in Date.

toLocaleString(locale, options) is the quick way - works on both numbers and dates. For better performance when formatting many values, use Intl.NumberFormat or Intl.DateTimeFormat - create the formatter once and call .format() repeatedly, since constructing the formatter is the expensive part. These APIs handle all the locale quirks - decimal separators, currency symbols, date ordering - automatically.

In practice you'll mostly use querySelector and querySelectorAll since they accept any CSS selector and are more flexible. getElementById is still the fastest for single lookups by id. The older getElementsBy* methods return live HTMLCollections that auto-update as the DOM changes, while querySelectorAll returns a static NodeList - a gotcha that trips people up when looping over elements while mutating the DOM.

A Node is the base type for everything in the DOM tree - elements, text nodes, comments, and even the document itself are all Nodes. An Element is a more specific Node that represents an actual HTML tag with attributes and child elements. HTMLCollection is a live, array-like object from older DOM methods that auto-updates as the DOM changes, which can cause unexpected behavior when iterating - most devs convert it to a real array with Array.from() before looping.

When you click a button inside a div, the click event fires on the button first, then bubbles up through the div, body, and document - that's event bubbling. It's the default behavior for almost all events and is actually really useful for event delegation, where you attach one listener on a parent instead of dozens on each child. You can stop it with event.stopPropagation(), but only do that when you truly need to - it makes debugging event flows much harder.

Event capturing is the opposite of bubbling - the event travels down from the document root to the target element before it fires on that element. In practice you rarely need it, but it's useful when you want to intercept an event before it reaches its target. To opt in, pass true (or { capture: true }) as the third argument to addEventListener - by default it's false, meaning you're in the bubbling phase.

Capturing goes top-down (document to target), bubbling goes bottom-up (target to document) - they're the two phases of the same event journey. Your addEventListener calls use bubbling by default, which is what you want 99% of the time. The real-world implication: event delegation relies on bubbling, and if you ever call stopPropagation() on a child element, the parent's bubbling listeners won't fire.

preventDefault() tells the browser "I'll handle this myself, don't do what you'd normally do." Classic use cases: stopping a form from submitting so you can validate first, preventing a link from navigating for client-side routing, or disabling a right-click context menu. It does not stop bubbling - that's stopPropagation(). Many developers confuse these two, so it's worth keeping them straight.

addEventListener is the right way to attach event handlers - unlike the old onclick property approach, you can attach multiple handlers for the same event without overwriting each other. The handler receives an event object with all the context you need. Always use named functions when you need to remove the listener later - anonymous arrow functions can't be removed because removeEventListener needs the exact same function reference.

Call element.removeEventListener(eventType, handler) with the exact same function reference you used when adding it - that's the critical part. If you used an anonymous function or inline arrow function, you're out of luck, it can't be removed. This is why any listener you might need to clean up should be stored in a named variable. Forgetting to remove listeners is a common source of memory leaks, especially in SPA frameworks where components mount and unmount repeatedly.

Call document.createElement('div'), set whatever properties you need (id, className, textContent, dataset attributes), then insert it with appendChild or insertBefore. For more control, insertAdjacentElement and insertAdjacentHTML give you beforebegin/afterbegin/beforeend/afterend positions. Performance tip: if you're creating many elements at once, build them in a DocumentFragment first and append the fragment in one shot - it's much faster than hitting the DOM repeatedly.

The BOM is everything the browser exposes beyond the DOM - basically the browser itself as an API. window is the global object (all globals are technically properties of window). location lets you read or redirect the current URL. history gives you back/forward navigation and pushState for SPA routing. navigator is where you check things like userAgent, language, or geolocation. screen is rarely used in practice, but tells you about the display resolution.

A JS engine takes your JavaScript source code and runs it - parsing, compiling to bytecode, and optimizing hot paths with JIT compilation. V8 (Chrome/Node.js) is the most relevant one for most devs today, SpiderMonkey powers Firefox, and JavaScriptCore (also called Nitro) is in Safari. The engine is what makes Node.js possible - V8 was extracted from Chrome and embedded into a server runtime.

The call stack is JS's way of tracking where it is in execution - every time you call a function, a new frame gets pushed on the stack, and when it returns it gets popped off. Since JS is single-threaded, the stack can only process one thing at a time. If you see "Maximum call stack size exceeded", that's a stack overflow from infinite recursion. The stack is also what you see in your browser's debugger as the call trace when an error is thrown.

Every time JavaScript runs code, it does so inside an execution context - a wrapper that contains the local variables, the scope chain for looking up outer variables, and the value of this. There's one global execution context when your script starts, and a fresh one is created for each function call. Understanding execution contexts is key to understanding hoisting, closures, and why this behaves the way it does.

The heap is where all your objects, arrays, and functions live in memory - it's the large, unstructured pool that the engine allocates from at runtime. Unlike the stack (which is fast and ordered), heap allocation is more flexible but less predictable. The garbage collector periodically scans for objects that are no longer reachable and frees that memory, which is why holding onto references unnecessarily (like in closures or global variables) can cause memory leaks.

A compiler does all the translation upfront before execution - faster runtime, but requires a build step. An interpreter does it on the fly, line by line - more flexible but traditionally slower. Modern JS engines like V8 use JIT (Just-In-Time) compilation, which is the best of both: it starts running immediately, then identifies hot code paths and compiles those to native machine code. This is why JS performance has improved so dramatically over the years.

this is one of the most confusing parts of JavaScript because its value depends entirely on how a function is called, not where it's defined. In an object method, this is the object. In a regular function, this is the global object (or undefined in strict mode). Arrow functions don't have their own this - they inherit it from the surrounding scope, which makes them great for callbacks inside methods. When in doubt, use bind() or an arrow function to lock in the this you want.

In strict mode, this is undefined inside a plain function call instead of defaulting to the global object. This is actually the safer behavior - before strict mode, accidentally calling a method without an object context would silently mutate global state, which is a nasty bug to track down. Strict mode makes these mistakes throw errors immediately. Arrow functions are unaffected since they don't have their own this regardless of the mode.

Primitives (strings, numbers, booleans, null, undefined, Symbol, BigInt) are stored by value and are immutable - when you copy one you get a completely independent value. Objects (including arrays and functions) are stored by reference - the variable just holds a pointer to the data in the heap. This is why const with objects doesn't prevent mutation: you can change the object's contents, you just can't reassign the variable to point to a different object.

A shallow copy creates a new object with the same top-level properties, but any nested objects or arrays are still shared references to the original. Use spread ({ ...obj } or [...arr]) or Object.assign() to make one. It's fine for flat objects, but if you shallow-copy { user: { name: 'Alice' } } and then change the name, you've changed it in both copies. For deeply nested structures, you need a deep copy.

A deep copy clones everything recursively - nested objects, nested arrays, all the way down - so modifying the copy never affects the original. The classic trick is JSON.parse(JSON.stringify(obj)), but it drops functions, converts Dates to strings, and can't handle circular references. The newer structuredClone() built-in is a much better option for most cases. For edge cases with functions or special types, use a library like Lodash's _.cloneDeep().

Destructuring is a clean ES6 syntax for pulling values out of arrays and objects without writing verbose dot-notation chains. Instead of const name = person.name; const age = person.age; you just write const { name, age } = person. You'll use this constantly - especially in function parameters, when consuming API responses, and with React hooks like useState which returns [value, setter].

The killer use case here is swapping two variables without a temp variable: [a, b] = [b, a]. Before destructuring you needed three lines (let temp = a; a = b; b = temp;) - now it's one. It's a popular interview question because it shows you know destructuring well. To actually reverse an entire array, use arr.reverse() (mutates the original) or [...arr].reverse() if you want to keep the original intact.

JavaScript only returns one value, but that value can be an array or object carrying multiple pieces of data. Return an array when order matters (like useState does: return [value, setter]), or return an object when you want named properties for clarity. At the call site, destructure immediately: const [x, y] = getCoords() or const { width, height } = getDimensions(). Returning an object is usually clearer since callers don't need to remember the order.

Array destructuring is position-based - [a, b] picks the first and second elements regardless of name. Object destructuring is name-based - { x, y } pulls properties with those exact names. You can skip array elements with commas (const [, second] = arr), set defaults, rename, and use rest (...). Once you get the hang of it, you'll reach for destructuring constantly when working with API responses and function parameters.

Mirror the nested structure in your pattern: const [a, [b, c]] = [1, [2, 3]]. The pattern shape has to match the data shape, which can get unreadable if you go more than 2-3 levels deep. For deeply nested data, it's usually better to destructure in multiple steps rather than cramming it all into one expression. You'll hit this pattern with API responses that return coordinates or matrix data.

Add = defaultValue after the variable name in your pattern: const [a = 0, b = 0] = arr or const { name = 'anonymous' } = user. The default only kicks in when the value is undefined - not null, not 0, not empty string. This is really handy when working with optional config objects or partially-defined API responses where some fields might be missing.

Object destructuring lets you pull specific properties out of an object in one clean line - much better than doing const name = person.name; const age = person.age; separately. You'll use this everywhere: in function parameters to pick out just the props you need, when consuming API responses, and when working with framework APIs. Only extract the properties you actually need - it makes the code self-documenting about what data you're working with.

The basics: const { name, age } = person extracts those properties into same-named variables. To rename, use a colon: const { name: fullName } = person. To set a default: const { age = 25 } = person. You can combine both: const { name: fullName = 'Guest' } = person. The colon syntax looks weird at first but you'll internalize it quickly - left side is the object's property name, right side is your new variable name.

Use the rest pattern (...) at the end of your destructuring to scoop up whatever's left: const [head, ...tail] = arr grabs the first element and puts the rest in an array. For objects: const { id, ...data } = response lets you separate the id while keeping everything else together. The rest element must always come last - putting it anywhere else is a syntax error. This is great for extracting a few specific properties while spreading the rest somewhere else.

Use a colon after the property name: const { userId: id } = response extracts the userId property but stores it in a variable called id. This is really useful when an API returns property names that conflict with existing variable names, or when the backend names aren't descriptive enough in your context. Remember: left side of the colon is the object's property name, right side is your new variable name.

Assign defaults inline: const { role = 'user', limit = 10 } = config. If the property is missing or undefined, the default kicks in - but not for null. This is the standard pattern for optional config objects: function init({ timeout = 3000, retries = 3 } = {}) {}. The = {} at the end means the function still works if called with no arguments at all.

Mirror the object's nesting in your pattern: const { address: { city, zip } } = person pulls out city and zip from person.address directly. Note that address itself won't be a variable here - only city and zip are. Nested destructuring can get hard to read if you go too deep; for complex structures, consider destructuring in multiple steps. Also worth adding defaults for nested values since you'll get a TypeError if address is undefined.

Put destructuring directly in the parameter signature: function render({ title, body, author = 'Anonymous' }) {}. This is much cleaner than accessing props.title, props.body inside the function body - the parameter list itself documents what shape of object the function expects. Always add = {} as the parameter default so the function doesn't blow up if called without arguments. You'll see this pattern constantly in React components and Express middleware.

The spread operator (...) unpacks the elements of an iterable - array, string, or object - into individual elements. It's hugely versatile: spread an array into function arguments, merge arrays with [...arr1, ...arr2], or clone/merge objects with {...obj1, ...obj2}. Just remember it's a shallow copy - nested objects are still references.

The rest parameter (...) gathers any remaining arguments into a real array - function sum(...nums) {} means you can call it with any number of values. It must come last in the parameter list, and unlike the old arguments object, it gives you a proper array so all array methods work on it. Prefer rest over arguments in any modern code.

Same syntax (...), completely opposite jobs - context is everything. Spread expands: you're at a call site or inside a literal, pushing elements out. Rest collects: you're in a function signature or destructuring pattern, gathering elements in. Think of spread as 'unpack' and rest as 'pack'.

Just add ...args as your last (or only) parameter: function myFunc(first, ...rest) {}. Everything beyond first lands in rest as a real array - so you can immediately do rest.map(), rest.filter(), whatever you need. This replaces the old arguments hack and is much more readable.

Logical operators don't evaluate more than they need to. With &&, if the left side is falsy, the right side is never run - so user && user.getName() won't blow up if user is null. With ||, if the left side is truthy, the right side is skipped - making value || 'default' a common pattern for fallbacks. It's not just optimization, it's often used intentionally for conditional execution.

The bug with || is that it treats 0, '', and false as falsy, so count || 0 always returns 0 even when count is a valid 0. The ?? operator only triggers the fallback for null or undefined - so count ?? 0 correctly returns 0 when count is 0. Anytime you have a value that could legitimately be 0, false, or an empty string, use ?? instead of ||.

The ?? operator provides a fallback only when the left side is null or undefined - making it the right tool for default values when the actual value could be 0, false, or ''. Write config.timeout ?? 3000 and you'll get 3000 only if timeout was never set, not when it's intentionally set to 0. It's one of those features that fixes a whole class of subtle bugs once you start using it.

Optional chaining (?.) lets you safely access deeply nested properties without manually checking each level for null or undefined. Instead of writing if (user && user.address && user.address.city), you just write user?.address?.city. If any part of the chain is null or undefined, the whole expression returns undefined instead of throwing a TypeError. This was a game-changer for working with API responses.

sort() works on any array but converts elements to strings before comparing by default - which means [10, 9, 2] sorts as [10, 2, 9] because '10' comes before '2' lexicographically. For numbers, objects, or dates, always pass a comparator. Also worth noting: sort() mutates the original array in place, so clone it first with [...arr].sort(...) if you need to preserve the original.

Pass a comparator any time you're sorting anything other than plain strings - numbers, dates, objects, or locale-sensitive text. Use (a, b) => a - b for ascending numbers and (a, b) => b - a for descending. For objects, sort by a property: arr.sort((a, b) => a.name.localeCompare(b.name)). The comparator must return a negative number, zero, or positive number - that's the contract sort() relies on.

slice is non-destructive - it returns a new array with the selected elements and leaves the original untouched. splice mutates the original array: it can remove elements, insert new ones, or do both at once. The easy way to remember: slice is safe to use anywhere; splice is a scalpel that cuts the original. If you find yourself reaching for splice, check if slice + a rebuild would be cleaner.

forEach is tied to arrays and array-like objects - it can't be broken out of early and doesn't work with await properly inside async callbacks. for...of works with any iterable (arrays, strings, Maps, Sets, generators) and supports break, continue, and await. In practice, if you need early exits or async iteration, use for...of; otherwise forEach is fine for simple side effects.

map transforms each element and returns a new array of the same length. filter tests each element and returns a new array with only the elements that pass. reduce walks through the array accumulating a single output value - a sum, an object, a string, whatever you need. In real code you'll use map and filter constantly; reduce is powerful but can be hard to read, so only reach for it when a simpler approach won't do.

some() is like asking 'does any element match?' - it returns true as soon as it finds one match and stops. every() asks 'do all elements match?' - it returns false as soon as it finds one that doesn't. Both short-circuit, so they're efficient. Common use: some() to check if a user has any admin role, every() to validate that all form fields are filled.

flat() just flattens nested arrays - flat() by one level, flat(Infinity) all the way down. flatMap() is map + flat(1) in a single pass, which is useful when your map callback returns arrays and you don't want the result to be an array of arrays. A typical use case is splitting sentences into words: sentences.flatMap(s => s.split(' ')). For anything deeper than one level, stick to flat(depth) separately.

Use an object literal ({}) for one-off data structures - it's simple and clear. Use a constructor function or class with new when you need to create multiple instances that share behavior through the prototype. The literal approach is also slightly faster since the engine doesn't need to set up a prototype chain. In modern code, prefer class syntax over raw constructor functions when you need instances.

Object.keys() gives you an array of property names, Object.values() gives you the values, and Object.entries() gives you [key, value] pairs - all for own enumerable properties only. In practice, entries() is the most powerful because you can destructure it in loops: for (const [key, val] of Object.entries(obj)). It's also the bridge to convert an object into a Map: new Map(Object.entries(obj)).

Object.freeze() makes the object fully read-only at the top level - no adding, removing, or updating properties. Object.seal() locks the shape of the object (no adding or removing) but still lets you update existing property values. The key caveat for both: they're shallow - nested objects are not frozen or sealed, so you need to recursively apply them for deep immutability.

A Set is a collection of unique values - it automatically removes duplicates, which makes it perfect for deduplicating arrays: [...new Set(arr)]. Unlike an array, a Set doesn't have indexed access, but iteration order is guaranteed to be insertion order. Sets use strict equality (===) for comparison, so two different objects that look identical are still considered unique.

WeakSet is like Set but only holds objects, and it holds them weakly - meaning if nothing else references an object, the garbage collector can clean it up even if it's in the WeakSet. You can't iterate over it or check its size, which limits its use cases. The main practical use is tracking whether you've already processed an object without creating a memory leak.

A Map is a key-value store where keys can be any type - objects, functions, primitives, anything. That's the big difference from plain objects where keys are always strings or Symbols. Maps also maintain insertion order and have a .size property. Use a Map when your keys aren't strings, when you need to frequently add/remove entries, or when key-value pairs are the primary purpose of the data structure.

WeakMap is like Map but keys must be objects and are held weakly - when the key object gets garbage collected, the entry disappears automatically. This makes it great for associating private data with objects without causing memory leaks. A classic pattern is using a WeakMap to store private state for class instances: the data is automatically cleaned up when the instance is gone.

Since Map's set() method returns the Map itself, you can chain multiple set() calls: new Map().set('a', 1).set('b', 2).set('c', 3). It's a builder pattern for initializing a Map inline. That said, for larger Maps it's usually cleaner to just pass an array of pairs to the constructor: new Map([['a', 1], ['b', 2]]).

Map uses the SameValueZero algorithm for key equality, which means objects (including arrays) are compared by reference, not value. So map.set([1,2], 'x') and then map.get([1,2]) returns undefined because that's a different array instance. You'd need to hold a reference to the original array to retrieve the value. This trips people up constantly - if you need value-based lookup, stringify the key or rethink your data structure.

Pass an array of [key, value] pairs directly to the Map constructor: new Map([[key1, val1], [key2, val2]]). If your array isn't already in that shape, transform it first - for example, converting an array of objects: new Map(users.map(u => [u.id, u])). That last pattern is really handy for fast O(1) lookups by ID instead of repeatedly calling find().

OOP in JavaScript is a way of structuring code around objects that bundle data and behavior together. Rather than scattered functions and variables, you model things as objects with properties and methods - a User object knows its own name and can log itself in. JavaScript does OOP differently from Java or C++ since it's prototype-based under the hood, but the ES6 class syntax makes it feel familiar.

The 6 OOP principles are: Encapsulation (bundling data and methods, hiding internals), Abstraction (exposing only essential features), Inheritance (child classes reuse parent behavior), Polymorphism (objects of different types used interchangeably), Composition (building from smaller objects), and Interface (defining interaction contracts).

A constructor function is a function used with the new keyword to create and initialize objects. It is named with an uppercase letter by convention. When called with new, a new object is created, this is bound to it, properties are assigned, and the object is returned automatically.

ES6 classes provide a cleaner, more familiar syntax for creating objects and implementing inheritance in JavaScript. They use the class keyword to define blueprints, constructor() for initialization, and the extends keyword with super() for inheritance. Internally, they still use prototypal inheritance.

Object.create(proto) creates a new object with its [[Prototype]] set to the specified proto object. The new object inherits all properties and methods from its prototype. It is a foundational way to implement prototypal inheritance without using constructor functions or classes.

Getters (get keyword) and setters (set keyword) in ES6 classes are special methods that control access to object properties. A getter retrieves a value and a setter updates it. They allow validation, computed values, and encapsulation. Access them like regular properties: obj.name.

If a property and its getter/setter share the same name, accessing the property calls the getter, which tries to access the same property, which calls the getter again, creating infinite recursion. This results in a 'Maximum call stack size exceeded' error. Use a backing property with a different name, often prefixed with an underscore.

A static method is defined with the static keyword inside a class and belongs to the class itself rather than to any instance. It is called directly on the class (MyClass.myMethod()) without needing to create an instance. Static methods are useful for utility functions related to the class.

Synchronous code runs line by line in a single thread, blocking execution until each operation completes. Asynchronous code allows other operations to run while waiting for slow tasks like network requests or timers. Asynchronous patterns include callbacks, Promises, and async/await.

AJAX (Asynchronous JavaScript and XML) is a technique for making asynchronous HTTP requests from a browser to a server without reloading the entire page. It enables dynamic content updates. Modern implementations use JSON rather than XML, and the Fetch API or XMLHttpRequest to make requests.

An API (Application Programming Interface) defines how software components interact. SOAP uses XML with strict contracts. REST uses HTTP methods (GET, POST, PUT, DELETE) for CRUD on resources. A Request is a client message to the server. A Response is the server's reply. Request Body contains payload data. Query Params pass extra info in the URL. JSON and XML are common data formats.

Server-client architecture separates a web app into a server (data storage and logic) and a client (user interface). JavaScript on the client makes HTTP requests to the server, which processes them and returns data. This enables dynamic, data-driven web applications without full page reloads.

A Promise represents the eventual success or failure of an asynchronous operation. The fetch() function makes HTTP requests and returns a Promise that resolves to a Response object. Together, they enable clean asynchronous network requests using .then()/.catch() or async/await.

Use .then(result => {}) on a Promise to handle fulfillment and .catch(error => {}) for rejections. Alternatively, use async/await with a try/catch block for more readable code. Both approaches allow you to work with the resolved value once the asynchronous operation completes.

Use the .catch() method after .then() to handle rejected Promises: promise.then(...).catch(error => {}). With async/await, wrap the await in a try/catch block. Always handle rejections to avoid unhandled promise rejection warnings and to gracefully recover from errors.

Create a Promise using new Promise((resolve, reject) => {}). Call resolve(value) when the asynchronous operation succeeds and reject(error) when it fails. Chain .then() to handle the resolved value and .catch() to handle errors.

async/await is syntax that makes asynchronous code look synchronous. Mark a function with async to make it return a Promise, then use await before a Promise to pause execution until it resolves. Use try/catch to handle errors. It is built on top of Promises and makes async code easier to read.

An async function always returns a Promise. The explicit return value becomes the resolved value of that Promise. Access it using await (inside another async function) or .then(). For example: const result = await myAsyncFn() or myAsyncFn().then(result => {}).

Use Promise.all([p1, p2, p3]) to run multiple Promises concurrently. It returns a new Promise that resolves when all input Promises resolve, providing an array of results. If any Promise rejects, Promise.all() rejects immediately with that error.

Wrap potentially failing code in a try block. If an error is thrown, execution jumps to the catch block where you handle the error. The optional finally block always runs regardless of success or failure, making it ideal for cleanup tasks like closing connections.

Promise.race() resolves or rejects as soon as the first Promise settles. Promise.allSettled() waits for all Promises to settle and returns an array of outcome objects (with status, value or reason) regardless of success or failure. Promise.any() resolves with the first fulfilled Promise, or rejects with AggregateError if all fail.

A module is an independent, reusable piece of code that encapsulates related functionality in its own file scope. ES6 modules use the import and export keywords to share functionality between files, enabling better code organization, avoiding global scope pollution, and explicit dependency management.

Export items using the export keyword: export const name = ... or export default myFunction. Import them with import: import { name } from './module.js' for named exports, or import myFunction from './module.js' for default exports. Use import * as module from './module.js' for all exports.

CommonJS uses require() and module.exports, and it became popular in Node.js. ES Modules use import and export, and they are the standard module system in modern JavaScript for both browsers and Node.js. ES Modules are easier for tools to analyze, which helps with optimizations like tree shaking.

Polyfilling is adding JavaScript code that emulates newer features in older browsers that don't support them natively. A polyfill detects if a feature is missing and provides a fallback implementation, ensuring cross-browser compatibility without requiring users to update their browsers.

Transpiling converts modern JavaScript code (e.g. ES6+) into an equivalent older version (e.g. ES5) that is compatible with older browsers. Tools like Babel handle this automatically. Transpiling converts syntax like arrow functions and classes, while polyfilling adds missing APIs.

Polyfilling adds new API functionality to older environments by implementing missing features in JavaScript code (e.g. adding Array.from to older browsers). Transpiling converts modern syntax to equivalent older syntax (e.g. arrow functions to regular functions). Polyfilling is about features; transpiling is about syntax.

Cookies are sent to the server automatically with every HTTP request and support an expiry date; they are limited to about 4 KB. localStorage is client-side only (never sent to the server), has a larger capacity of around 5 MB, and has no built-in expiry. Use cookies for server-side authentication and session data; use localStorage for client-only preferences and caching.

Event bubbling means that when an event fires on an element, it propagates upward through the DOM tree to all its ancestor elements. For example, clicking a button inside a div will also trigger any click listeners on that div and on the document. You can stop this with event.stopPropagation() inside the handler.

Event capturing is the opposite of bubbling. The event travels from the document root down to the target element before the target handles it. You opt into capturing by passing true as the third argument to addEventListener. The full event lifecycle is: capturing (top-down), target, then bubbling (bottom-up).

Event delegation is a pattern where a single event listener is attached to a parent element to handle events for all its children, relying on event bubbling. It is useful because it reduces the number of listeners (better performance for large lists), and it automatically handles dynamically added child elements without needing to attach new listeners each time.

onclick is an element property that can only hold one handler at a time. Assigning a new function overwrites the previous one. addEventListener can attach multiple independent handlers for the same event without overwriting any of them. It also supports capturing phase listeners and can be removed with removeEventListener, making it the preferred approach.

Call event.stopPropagation() inside an event handler to prevent the event from bubbling up (or capturing down) to ancestor elements. To also prevent any other listeners on the same element from running, use event.stopImmediatePropagation(). To prevent the browser's default action (like following a link), use event.preventDefault(). These methods can be combined as needed.

event.stopPropagation() stops the event from moving to parent or child elements in the event flow. event.preventDefault() stops the browser's default action, like following a link or submitting a form. One controls event movement, while the other controls browser behavior, and sometimes both are used together.

JavaScript has several built-in error types:

• SyntaxError - code with invalid syntax that cannot be parsed (usually a typo)
• ReferenceError - trying to use a variable that was never declared
• TypeError - using a value in a way that does not match its type (e.g. calling something that is not a function)
• RangeError - a value is outside of an allowed range
• URIError - a malformed URI passed to functions like decodeURI()
• EvalError - related to the eval() function (you will rarely see this one)

null.toString();       // TypeError
undeclaredVar;         // ReferenceError
new Array(-1);         // RangeError

You can extend the built-in Error class to create your own error types. This is useful when you want to throw errors with a specific name that makes them easier to identify and catch.

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

try {
  throw new ValidationError("Email is required");
} catch (error) {
  if (error instanceof ValidationError) {
    console.log("Validation failed:", error.message);
  }
}

return exits a function and sends a value back to the caller. throw also stops execution but it signals that something went wrong. The thrown value (usually an Error object) travels up the call stack until it hits a catch block. If it never does, it crashes the program.

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

A common use case is creating a counter or a function factory where each function gets its own private piece of state. Another very common use is the module pattern, where you expose only specific functions and keep everything else private.

function makeMultiplier(multiplier) {
  return function (num) {
    return num * multiplier;
  };
}

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

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

When you use var inside a loop and create a function for each iteration, all those functions share the same variable. By the time any function runs, the loop is already done, so they all see the final value. Using let fixes this because let creates a new binding for each loop iteration.

// Problem with var
for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100);
}
// prints: 3, 3, 3

// Fixed with let
for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100);
}
// prints: 0, 1, 2

A regular function has its own this, which is determined by how it is called. An arrow function does not have its own this at all. It inherits this from the surrounding code where it was written. This is why arrow functions are often used for callbacks inside class methods.

const obj = {
  name: "Alice",
  regularFn: function () {
    console.log(this.name); // "Alice" - this is obj
  },
  arrowFn: () => {
    console.log(this.name); // undefined - this is the global/window
  },
};

obj.regularFn();
obj.arrowFn();

All three let you manually set what this should be inside a function. The difference is when and how they call the function.

• call() - calls the function right away, arguments passed one by one
• apply() - calls the function right away, arguments passed as an array
• bind() - does not call the function immediately, returns a new function with this permanently set

function greet(greeting) {
  console.log(greeting + ", " + this.name);
}

const user = { name: "Alice" };

greet.call(user, "Hello");        // Hello, Alice
greet.apply(user, ["Hi"]);        // Hi, Alice
const boundGreet = greet.bind(user);
boundGreet("Hey");                // Hey, Alice

Inside a class method, this refers to the instance of that class. So if you create const user = new User(), then inside any method of User, this points to user. However, if you pass a method as a callback and call it without the object context, this can get lost.

class Counter {
  constructor() {
    this.count = 0;
  }
  increment() {
    this.count++;
    console.log(this.count);
  }
}

const c = new Counter();
c.increment(); // 1 - this is c

JSON can only represent a limited set of data types. Things JSON does not support:

• Functions are dropped silently
• undefined values are dropped
• Symbol values are dropped
• Circular references cause an error
• Date objects are converted to strings, not back to Date when parsed
• Map, Set, RegExp do not serialize properly

If a property value is a function, undefined, or a Symbol, it is silently removed from the result. If the top-level value itself is a function or undefined, stringify returns undefined (not a string).

const obj = {
  name: "Alice",
  greet: function () { return "hello"; },
  score: undefined,
};

console.log(JSON.stringify(obj));
// '{"name":"Alice"}' - greet and score are gone

Flags are added after the closing slash and change how the regex behaves.

• i - case insensitive, so /hello/i matches "Hello", "HELLO", etc.
• g - global, find all matches (not just the first one)
• m - multiline, makes ^ and $ match the start/end of each line
• s - allows . to match newline characters too

const str = "Hello World hello";
console.log(str.match(/hello/gi)); // ["Hello", "hello"]

test() is a method on the regex object. It takes a string and returns true or false. Use it when you just want to know if the pattern matches. match() is a method on the string. It returns the actual matched text (or null if nothing matched). Use it when you want the matched values.

const pattern = /\d+/; // matches one or more digits

pattern.test("abc123");       // true
"abc123".match(pattern);      // ["123"] - returns the match

yield pauses the generator and hands a value back to the caller. It's essentially a temporary return that can happen multiple times. The next time you call .next(), the function picks up from exactly where it stopped. You can also send a value back INTO the generator by passing it to .next(value), and that value becomes what the yield expression evaluates to inside the function.

function* add() {
  const x = yield "Give me a number";
  const y = yield "Give me another";
  return x + y;
}

const gen = add();
gen.next();    // { value: "Give me a number", done: false }
gen.next(5);   // { value: "Give me another", done: false } - 5 becomes x
gen.next(3);   // { value: 8, done: true }                 - 3 becomes y

A regular function runs from start to finish in one shot and returns one value. A generator function can pause in the middle using yield, return multiple values over time, and resume from where it stopped. A regular function always starts fresh when you call it. A generator object keeps its state between .next() calls.

Each time you call .next(), the generator runs until it hits the next yield statement, then pauses. It returns an object with two keys: value (the yielded value) and done (a boolean: false while the generator still has more to yield, true once it has finished). If you pass a value into .next(value), that value becomes the result of the paused yield expression inside the function.

function* count() {
  yield 1;
  yield 2;
  yield 3;
}

const gen = count();
console.log(gen.next()); // { value: 1, done: false }
console.log(gen.next()); // { value: 2, done: false }
console.log(gen.next()); // { value: 3, done: false }
console.log(gen.next()); // { value: undefined, done: true }

Traps are the methods you define in the handler object. Each trap corresponds to a specific operation on the target object.

• get(target, key) - intercepts property reads
• set(target, key, value) - intercepts property writes
• has(target, key) - intercepts the in operator
• deleteProperty(target, key) - intercepts delete
• apply(target, thisArg, args) - intercepts function calls
• construct(target, args) - intercepts new

The Reflect object is a built-in that provides static methods matching the same operations a Proxy can intercept. For example, Reflect.get(target, key) reads a property the same way bracket notation does, and Reflect.set(target, key, value) sets one. Inside a Proxy trap, you typically call the matching Reflect method to carry out the default behavior after running your custom logic.

const proxy = new Proxy({}, {
  set(target, key, value) {
    console.log("Setting", key, "=", value);
    return Reflect.set(target, key, value); // do the default thing
  }
});

proxy.name = "Alice"; // logs "Setting name = Alice"

You create a worker by passing a script file URL to the Worker constructor. The script runs in its own environment. You communicate with it using messages.

// main.js
const worker = new Worker("worker.js");
worker.postMessage({ task: "compute", data: [1, 2, 3] });

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

// worker.js
self.onmessage = function (event) {
  const result = event.data.data.reduce((sum, n) => sum + n, 0);
  self.postMessage(result);
};

Workers and the main thread communicate through message passing. The main thread sends data to the worker using worker.postMessage(data) and listens for responses via worker.onmessage. The worker does the same using self.postMessage() and self.onmessage. The data is copied (not shared) between threads by default, using the structured clone algorithm.

Web Workers run in an isolated environment with several restrictions:

• No access to the DOM, window, or document
• No access to localStorage or sessionStorage
• Communication with the main thread only happens through message passing
• The worker script must come from the same origin (or use CORS headers)
• Data sent in messages is copied, not shared by reference (unless you use Transferable Objects like ArrayBuffer)

The main defenses against XSS are:

• Never put user input directly into HTML. Use textContent instead of innerHTML when displaying user-provided text
• Escape special HTML characters (<, >, ", &) before displaying them
• Use a Content Security Policy (CSP) header to restrict which scripts are allowed to run
• Use frontend libraries (like DOMPurify) to sanitize HTML if you truly need to render user-provided HTML
• Validate and sanitize all user input on the server side as well

// Vulnerable - never do this
element.innerHTML = userInput;

// Safe - use textContent
element.textContent = userInput;

CSRF (Cross-Site Request Forgery) is when a malicious site tricks a logged-in user into making a request to a site they are already authenticated with. For example, a hidden form on a bad site could silently submit to your bank's "transfer money" endpoint using your existing session cookie. The browser sends the cookie automatically. The key difference from XSS: XSS injects code that runs on the victim's page. CSRF makes the victim's browser fire a request to another site using their real credentials.

CSP is an HTTP response header that tells the browser which sources of scripts, styles, and other resources are trusted. It is one of the most effective defenses against XSS. For example, you can tell the browser to only run scripts from your own domain and block everything else, including any injected inline scripts.

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com