Top interview questions

The doctype is the first line of the document. It tells the browser to render the page in standards mode, following the current HTML and CSS specs.

Without it, browsers fall back to quirks mode, which imitates old browser bugs from the 1990s for backwards compatibility. Layout can then differ between browsers: for example, the box model, table sizing and some percentage heights behave differently.

• <!DOCTYPE html> is the only doctype you need for HTML5
• it is not a tag, it is an instruction to the parser
• it is case-insensitive

Semantic HTML means using elements that describe the meaning of the content, not just how it looks: <header>, <nav>, <main>, <article>, <section>, <aside>, <footer>, <button>, <h1>–<h6>, instead of a pile of <div>s.

Why it matters:

• accessibility: screen readers use landmarks and headings to navigate, and native elements come with keyboard support and roles for free
• SEO: search engines understand the structure and the main content
• maintainability: the markup is easier to read

A <div onclick> pretending to be a button is the classic anti-pattern: it is not focusable and does not respond to Enter or Space.

Block elements (<div>, <p>, <h1>, <ul>, <section>) start on a new line and take the full width available. Width, height, margin and padding all apply.

Inline elements (<span>, <a>, <strong>, <em>) flow inside a line of text and are only as wide as their content. Width and height are ignored, and vertical margins do not push other lines away.

Inline-block elements (like <button> and <input>) sit in the line like inline but respects width, height and vertical spacing.

The default comes from the browser stylesheet; CSS display can change any element.

A plain <script> blocks HTML parsing: the parser stops, downloads the file, runs it, then continues.

• async: downloads in parallel and runs as soon as it arrives, pausing parsing at that moment. Order between async scripts is not guaranteed. Good for independent scripts like analytics.
• defer: downloads in parallel and runs after parsing finishes, just before DOMContentLoaded, in document order. Good for your app code that needs the DOM.

type="module" scripts are deferred by default. Putting a plain script at the end of <body> is the older way to get similar behaviour.

• localStorage: about 5 MB per origin, persists until cleared, never sent to the server
• sessionStorage: same API, but scoped to one tab and cleared when that tab closes
• cookies: about 4 KB, can have an expiry, and are sent with every HTTP request to their domain

Both storage APIs are synchronous and string-only, so you store objects with JSON.stringify. They are readable by any script on the page, so never put auth tokens there if you can avoid it: an XSS bug can steal them.

For sessions, prefer an HttpOnly cookie, which JavaScript cannot read. For larger or structured client data, use IndexedDB.

Start with native semantic HTML, it covers most needs:

• real <button>, <a href>, <label> and form controls
• a logical heading order and landmarks (<main>, <nav>)
• alt text on images, enough colour contrast, visible focus styles
• everything usable with the keyboard alone

ARIA (role, aria-label, aria-expanded, aria-live…) adds meaning for assistive tech when HTML has no native element, for example a custom tabs widget or a live status message. It changes only what screen readers announce, not behaviour.

The first rule of ARIA: no ARIA is better than bad ARIA. If a native element exists, use it.

HTML has built-in constraint validation. Attributes such as required, type="email", min/max, minlength/maxlength and pattern make the browser block submission and show a message.

Good form basics:

• every input has a <label for> (or is wrapped in one)
• use the right type (email, tel, number, date) for mobile keyboards
• name attributes, since that is what gets submitted
• autocomplete hints such as autocomplete="email"

From JavaScript you can use checkValidity(), setCustomValidity() and the :invalid CSS pseudo-class.

Client-side validation is only for user experience: always validate again on the server.

Without it, mobile browsers assume the page was built for desktop and render it in a virtual viewport about 980px wide, then zoom out. Your media queries never match and the text is tiny.

<meta name="viewport" content="width=device-width, initial-scale=1"> tells the browser to make the layout viewport equal to the device width at 100% zoom, so responsive CSS works.

Avoid user-scalable=no or maximum-scale=1: blocking pinch-zoom is an accessibility problem.

Every element is a rectangular box made of four layers, from the inside out:

• content: the text or image itself
• padding: space inside the border, takes the background colour
• border
• margin: transparent space outside the border, separating it from other boxes

By default (box-sizing: content-box), width and height apply to the content only, so padding and border are added on top. A width: 200px box with 20px padding and a 1px border is actually 242px wide.

DevTools shows this as the coloured box diagram in the Computed panel.

With border-box, the width and height you set include padding and border. Adding padding shrinks the content area instead of making the box bigger.

That makes layouts predictable: two width: 50% columns with padding still fit side by side, which they would not with the default content-box.

That is why almost every reset (and Tailwind's preflight) applies it to everything, including pseudo-elements. Margin is never included in either model.

When several rules target the same element, the one with the highest specificity wins. It is compared as three numbers (IDs, classes, elements):

• IDs: #nav is (1,0,0)
• classes, attributes, pseudo-classes: .btn, [type="text"], :hover are (0,1,0)
• elements and pseudo-elements: p, ::before are (0,0,1)

The columns are compared left to right, so one ID beats any number of classes. Inline style beats all of them, and !important beats inline. With equal specificity, the rule that comes last wins.

* and combinators add nothing; :where() counts as zero, and :is()/:not() take their most specific argument.

• static (default): normal flow; top/left and z-index have no effect
• relative: stays in the flow, but can be nudged with offsets. Its main job is being the containing block for absolute children
• absolute: removed from the flow, positioned relative to the nearest positioned ancestor (any non-static position), or the page if there is none
• fixed: removed from the flow, positioned relative to the viewport, so it stays put on scroll
• sticky: behaves like relative until a scroll threshold (top: 0), then sticks within its parent

A common gotcha: a parent with transform or filter becomes the containing block even for fixed children.

Flexbox is one-dimensional: it lays items out in a row or a column, and sizes them based on their content. Great for nav bars, toolbars, button groups, centering, and lists that wrap.

Grid is two-dimensional: you define rows and columns, and place items into that structure. Great for page layouts, card galleries, dashboards and anything that must line up in both directions.

A rule of thumb: flexbox is content-out (items decide their size), grid is layout-in (the container decides). They combine well: a grid page layout with flex inside each card.

The modern answers:

• Flexbox on the parent: display: flex; justify-content: center; align-items: center
• Grid on the parent: display: grid; place-items: center (the shortest option)
• Absolute positioning: position: absolute; inset: 0; margin: auto with a set size, or top: 50%; left: 50%; transform: translate(-50%, -50%) for unknown sizes

For horizontal-only centering of a block with a width, margin: 0 auto still works. For inline content and text, text-align: center.

Remember the parent needs a height for vertical centering to be visible.

• px: fixed (a CSS pixel, not a device pixel)
• em: relative to the current element's font size (for font-size itself, the parent's), so it compounds when nested
• rem: relative to the root font size (on html), usually 16px, so it is predictable and respects the user's browser font setting
• %: relative to the parent (width for widths and padding, font size for font size)
• vh / vw: 1% of the viewport height / width

Common practice: rem for font sizes and spacing, em for things that should scale with their own text (button padding), px for borders. On mobile, 100vh can be taller than the visible area; use 100dvh.

Media queries apply styles only when a condition is true, usually the viewport width: @media (min-width: 768px) { … }.

Mobile-first means writing the base styles for small screens and adding min-width queries to enhance for larger ones. Benefits:

• the simplest layout is the default, so phones load the least CSS overrides
• it forces you to prioritise content
• styles build up instead of being undone

Desktop-first uses max-width queries and tends to pile up overrides. Beyond width, you can query prefers-color-scheme, prefers-reduced-motion, hover and orientation. Pick breakpoints where your content breaks, not for specific devices.

Scope: var is function-scoped; let and const are block-scoped (inside {}).

Hoisting: all three are hoisted, but var is initialised to undefined, while let/const stay in the temporal dead zone until their line runs, so using them earlier throws a ReferenceError.

Re-assignment: const cannot be re-assigned, but the object it points to can still be mutated.

• Default to const, use let when the value changes, avoid var.

A closure is a function bundled with the variables of the scope where it was created. It can still read and update them after that outer function has returned.

Real uses:

• private state (counters, caches) without classes
• function factories such as makeMultiplier(2)
• once, memoize, debounce, which all keep state between calls
• event handlers that remember data from when they were attached

JavaScript runs on one thread with a call stack. Async work (timers, I/O, fetch) is handed to the browser or Node, and its callbacks wait in queues.

The loop: run all synchronous code → empty the microtask queue (promise callbacks, queueMicrotask, await continuations) → take one macrotask (timer, I/O, event) → microtasks again → render (in the browser) → repeat.

So the promise callback runs before setTimeout(…, 0), even though both are "async".

this depends on how a function is called, not where it is written:

• obj.method(): this is obj
• a plain call fn(): undefined in strict mode (the global object otherwise)
• new Fn(): the newly created object
• fn.call(x) / apply / bind: whatever you pass
• arrow functions have no own this; they use the one from the surrounding scope

A classic bug is passing obj.method as a callback, which loses this. Fix it with bind or an arrow function.

=== (strict equality) compares value and type with no conversion. == converts types first, with surprising rules ('' == 0 and null == undefined are true).

Always use ===. The one common exception is x == null, which checks for both null and undefined.

Objects are compared by reference with both operators: two different objects with the same contents are not equal.

Before code runs, the engine sets up each scope. Declarations are "moved to the top":

• function declarations are hoisted completely, so you can call them before their line
• var is hoisted and initialised to undefined
• let, const and class are hoisted but stay uninitialised (temporal dead zone)
• function expressions and arrow functions follow the rules of the variable that holds them

A promise stands for a value that will be ready later. It is pending, then either fulfilled or rejected, and you react with .then/.catch/.finally.

async functions always return a promise. await pauses the function (not the thread) until the promise settles, so async code reads top to bottom. Errors are handled with try/catch.

• Debounce: run only after the calls have stopped for ms (search box, window resize end)
• Throttle: run at most once every ms while the calls keep coming (scroll, mousemove)

Both are closures that keep a timer or a timestamp between calls.

A shallow copy ({...obj}, Object.assign, arr.slice()) copies only the top level. Nested objects are still shared.

A deep copy duplicates every level. Use structuredClone(obj), which handles Dates, Maps, Sets and cycles but not functions or DOM nodes. JSON.parse(JSON.stringify(x)) loses Dates, undefined, functions and Maps.

• no own this: they use this from the surrounding scope, which is great for callbacks
• no arguments object; use rest parameters
• cannot be called with new and have no prototype
• shorter syntax with an implicit return: x => x * 2

Don't use them as object methods that need this, or as constructors.

This is a classic mix of hoisting, the event loop and loop scope:

1. var loop + setTimeout prints 3 3 3: one shared i, and the timers run after the loop
2. let loop prints 0 1 2: each iteration gets its own j
3. The synchronous log runs first, then microtasks, then timers

Interviewers want the reasoning (one variable vs one per iteration, and the queue order), not just the answer.

TypeScript is JavaScript plus a static type system. It compiles to plain JavaScript, and types are erased at runtime: they only exist while you write and build code.

Benefits:

• many bugs (typos, wrong arguments, undefined access) are caught before the code runs
• much better editor support: autocomplete, inline docs, safe renames
• types act as documentation and make refactoring large codebases safer

Costs: a build step, some learning curve, and the fact that types cannot validate data coming from outside (API responses, user input) at runtime.

For describing object shapes they are almost interchangeable. The differences:

• type can name any type: unions ('a' | 'b'), tuples, primitives, mapped and conditional types. interface only describes object shapes.
• interface supports declaration merging: declaring it twice merges the members (used to extend library types like Window). A type cannot be re-opened.
• interface extends with extends; type composes with intersections (&). extends reports conflicts more clearly.

A common rule: interface for object shapes and public APIs, type for unions and everything else. Consistency within a codebase matters more than the choice.

• any switches type checking off. Anything can be assigned to it and you can do anything with it, so errors spread silently. Avoid it.
• unknown is the safe version: anything can be assigned to it, but you cannot use it until you narrow it (typeof, instanceof, a type guard). Use it for JSON.parse results, catch errors and other untrusted input.
• never is the type with no values: a function that always throws, or a branch that can never happen. It is used for exhaustiveness checks.

void is different again: a function returns nothing useful.

Generics are type parameters: they let a function, class or type work with many types while keeping the relationship between input and output.

Without generics you would write any and lose the type information. With function first<T>(arr: T[]): T | undefined, calling it with string[] returns string | undefined.

TypeScript usually infers T from the arguments. You can restrict it with a constraint (T extends { id: number }) and give it a default (T = string).

Everyday examples: Array<T>, Promise<T>, useState<T>, and typed API helpers like fetchJson<T>(url).

• Partial<T>: all properties optional (update payloads)
• Required<T>: all properties required
• Readonly<T>: all properties read-only
• Pick<T, 'a' | 'b'>: keep only some keys
• Omit<T, 'password'>: drop some keys
• Record<K, V>: an object with keys K and values V
• ReturnType<typeof fn> and Parameters<typeof fn>: types taken from a function
• Awaited<T>: the resolved type of a promise
• NonNullable<T>, Exclude<U, X>, Extract<U, X>: filter unions

They let you derive types from one source of truth instead of copying them, so a change to User flows everywhere.

Narrowing is how TypeScript refines a broad type (like string | number) to a more specific one inside a branch, by following your runtime checks:

• typeof x === 'string'
• x instanceof Date
• 'swim' in animal
• equality and truthiness checks (if (user))
• discriminant checks (shape.kind === 'circle')

A user-defined type guard is a function whose return type is a type predicate like value is Fish. When it returns true, TypeScript narrows the argument. Assertion functions (asserts value is string) narrow by throwing instead.

Be careful: the compiler trusts your guard, so a wrong implementation lies to it.

A discriminated union is a union of object types that all share a literal "tag" property, such as kind or status. Checking the tag narrows the whole object, so each branch knows exactly which fields exist.

It is the standard way to model state: { status: 'loading' } | { status: 'success'; data: T } | { status: 'error'; error: string }. Impossible states (data and error at once) cannot be expressed.

For exhaustiveness, assign the value to never in the default branch. If someone adds a new variant and forgets to handle it, the code stops compiling.

"strict": true in tsconfig.json turns on a family of checks, including noImplicitAny, strictNullChecks, strictFunctionTypes and strictPropertyInitialization. New projects should always enable it.

strictNullChecks is the most important one. Without it, null and undefined are allowed in every type, so user.name compiles even when user might be missing. With it, null and undefined are separate types, and you must handle them before use (with a check, ?., or ??).

That catches the single most common JavaScript runtime error: "cannot read properties of undefined".

The virtual DOM is a lightweight tree of plain JavaScript objects describing what the UI should look like. When state changes, React calls your components again to build a new tree.

Reconciliation is the diff between the old and new trees. React then applies only the minimal set of real DOM changes, because touching the real DOM is the expensive part.

The diff uses two shortcuts to stay fast (roughly O(n)):

• a different element type at the same position means "throw away the subtree and rebuild"
• in lists, keys tell React which child is which across renders

The point is not that the virtual DOM is "faster than the DOM", it is that you write declarative UI and React works out the updates.

A key gives each list item a stable identity so React can match items between renders. It decides which DOM nodes (and which component state) to keep, move, create or delete.

Using the index breaks when the list is reordered, filtered or has items inserted at the top: the indexes shift, so React reuses the wrong component for the wrong data. Symptoms are inputs keeping the wrong text, wrong checkboxes ticked, or broken animations.

• Use a real id from the data (todo.id)
• The index is fine only for static lists that never reorder
• Changing a component's key on purpose forces a full remount, a handy way to reset state

Props are inputs passed from a parent. They are read-only inside the child; the parent owns them.

State is data a component owns and changes over time with useState or useReducer. Updating state triggers a re-render of that component and its children.

• Data flows one way: parents pass state down as props
• A child changes parent data by calling a callback prop (onChange)
• If a value can be computed from props or other state, do not store it in state; calculate it during render

A controlled input gets its value from React state and updates it through onChange. React is the single source of truth, so validation, formatting and conditional UI are easy.

An uncontrolled input keeps its own value in the DOM. You set a defaultValue and read it when needed, through a ref or FormData on submit.

• Controlled: instant validation, dependent fields, live previews
• Uncontrolled: simple forms, file inputs (always uncontrolled), fewer re-renders
• Libraries like React Hook Form are mostly uncontrolled for performance

A common warning is switching from uncontrolled to controlled because value started as undefined; initialise with ''.

State updates are not applied immediately. Inside one render, count is a fixed snapshot, so all three calls set it to the same value (0 + 1).

Use the functional update form when the new value depends on the old one: setCount(c => c + 1). React queues the updater functions and runs them in order, so three calls add 3.

Batching means React groups several state updates into a single re-render. Since React 18 this is automatic everywhere: event handlers, promises, timeouts and native listeners.

useEffect runs code after React has painted, to sync with something outside React (subscriptions, timers, the DOM, network).

• No array: runs after every render
• []: runs once after mount
• [a, b]: runs when a or b changed (compared with Object.is)

The function you return is the cleanup. It runs before the effect runs again and on unmount: unsubscribe, clear timers, abort fetches.

In development, StrictMode mounts, unmounts and remounts each component, so effects run, clean up and run again. This is deliberate: it exposes missing cleanup. It does not happen in production.

• useMemo(() => value, deps) caches a computed value between renders
• useCallback(fn, deps) caches a function (it is useMemo(() => fn, deps))
• React.memo(Component) skips re-rendering a component when its props are shallowly equal

They work together: React.memo is useless if the parent passes a new object or arrow function each render, so you stabilise those props with useMemo/useCallback.

Use them for expensive calculations, props to memoised children, or effect dependencies. Do not wrap everything: memoisation has its own cost. With the React Compiler (stable in 2025), much of this is done automatically at build time.

A custom hook is a function whose name starts with use and that calls other hooks. It lets you reuse stateful logic (not state itself) between components: each component calling it gets its own independent state.

Good candidates: fetching, debouncing, media queries, local storage, form fields, subscriptions. Custom hooks replaced most HOCs and render props because they compose without wrapper components.

Context passes a value deep into the tree without threading props through every level. You create it with createContext, provide it near the top and read it with useContext (or use).

Good for values that change rarely: theme, current user, locale, feature flags.

The cost: when the provider's value changes, every consumer re-renders, even if it only uses one field. Passing a new object literal each render makes this happen on every parent render.

• Memoise the value with useMemo
• Split contexts (state and dispatch, or by concern)
• For fast-changing global state, use a store with selectors

A component re-renders when:

• its state changes
• its parent re-renders (props changing or not, unless it is memoised)
• a context it reads changes
• a store hook it uses returns a new value

Re-rendering is not the same as DOM updates: React still diffs and may change nothing. Optimise only when you measure a real problem with the React DevTools Profiler.

Fixes:

• move state down closer to where it is used
• pass expensive children as children so they are not re-created
• React.memo plus stable props
• virtualise long lists (TanStack Virtual)
• useTransition / useDeferredValue for heavy updates

Next.js is a React framework. React gives you components; Next.js adds everything around them that a production app needs:

• file-based routing with nested layouts
• server rendering (SSR, static generation, streaming) for fast first loads and SEO
• Server Components and Server Actions, so data access and mutations live next to the UI
• API endpoints (route handlers) in the same project
• built-in image, font and script optimisation, code splitting and caching
• zero-config bundling (Turbopack) and easy deployment

The short answer: better performance and SEO with less setup than a client-only React app built with Vite.

• CSR (client-side rendering): the server sends an almost empty page and JavaScript builds it in the browser. Slow first paint, weak SEO, fine for dashboards behind login.
• SSG (static site generation): HTML is built once at build time and served from a CDN. Fastest, but data is only as fresh as the last build.
• ISR (incremental static regeneration): static pages that are regenerated in the background after a time (revalidate: 60) or on demand, so you get static speed with fresh-ish data.
• SSR (server-side rendering): HTML is generated on every request. Always fresh and personalised, but costs server time per request.

In the App Router you do not pick a function per page: a route is static by default and becomes dynamic when it uses request data (cookies(), headers(), searchParams) or uncached fetches.

In the App Router, every component is a Server Component by default. It runs on the server, can be async, can read databases and secrets directly, and ships no JavaScript to the browser.

'use client' at the top of a file marks a boundary: that file and everything it imports become Client Components. They are still pre-rendered to HTML on the server, then hydrated so they can use state, effects, event handlers and browser APIs.

• Keep 'use client' as low in the tree as possible (the button, not the page)
• Server Components can render Client Components and pass them serialisable props
• To put server content inside a client component, pass it as children
• 'use client' does not mean "client only", it means "also runs on the client"

Folders inside app/ define URL segments, and special files define what each segment renders:

• page.tsx: the UI for that route (makes it publicly reachable)
• layout.tsx: shared UI that wraps child routes and keeps its state across navigation
• template.tsx: like a layout but remounts on every navigation
• loading.tsx, error.tsx, not-found.tsx: automatic Suspense and error boundaries

Layouts nest: the root layout (with <html> and <body>) wraps a section layout, which wraps the page.

Useful conventions: (group) folders organise routes without affecting the URL, _private folders are ignored, and @slot folders create parallel routes. <Link> gives client-side navigation with prefetching.

A folder in square brackets is a dynamic segment: app/blog/[slug]/page.tsx matches /blog/anything. [...slug] is a catch-all and [[...slug]] an optional catch-all.

The page receives params, which since Next.js 15 is a Promise you must await.

generateStaticParams returns the list of params to pre-render at build time (SSG). Paths not in the list are rendered on demand on first request and then cached, unless you set dynamicParams = false to return 404 instead.

In Server Components you just await the data: fetch, an ORM query, or a file read. No useEffect, no API route in between, and secrets stay on the server.

• Run independent requests in parallel with Promise.all to avoid waterfalls
• Wrap slow parts in <Suspense> so the rest of the page streams first
• Deduplicate shared calls with React cache() (fetch with the same URL is deduped per request automatically)

On the client, use a library like TanStack Query or SWR for data that changes with user interaction, or pass a promise from a Server Component and read it with use().

Fetch on the server by default, and go client-side only for highly interactive data.

Since Next.js 15, caching is opt-in: fetch is not cached by default and GET route handlers are dynamic.

Ways to cache and refresh:

• Time-based: fetch(url, { next: { revalidate: 3600 } }) or export const revalidate = 3600 on a route
• On-demand: tag data (next: { tags: ['posts'] }) and call revalidateTag('posts') or revalidatePath('/blog') after a mutation
• Cache Components (Next.js 16): the 'use cache' directive caches a function, component or page, with cacheLife and cacheTag controlling lifetime and invalidation

Static routes are also cached as HTML at build time, and the client keeps a router cache of visited segments. router.refresh() refetches the current route.

A Server Action is an async function marked with 'use server' that runs on the server but can be called from the client, usually as a form's action or from an event handler. Next.js creates the POST endpoint for you.

They replace most "write" API routes: validate input, write to the database, then call revalidatePath / revalidateTag or redirect.

• Forms work before JavaScript loads (progressive enhancement)
• Pair with useActionState for errors and pending state, useOptimistic for instant UI
• Treat them as public endpoints: always check authentication and validate input (Zod), because anyone can call them

Node.js is a JavaScript runtime built on Chrome's V8 engine, plus libuv, a C library that provides the event loop, async I/O and a small thread pool.

Your JavaScript runs on one main thread. When code starts I/O (a database query, a file read, an HTTP call), Node hands it to the operating system or the libuv thread pool and moves on. When the work finishes, its callback is queued and the event loop runs it.

So one thread can serve thousands of connections, because most of a web request is waiting, not computing.

• Great for: APIs, real-time apps, proxies, streaming
• Weak for: CPU-heavy work (image processing, big calculations), which blocks the thread for everyone

Each turn of the loop goes through phases, each with its own queue of callbacks:

• timers: expired setTimeout / setInterval callbacks
• pending callbacks: some deferred system I/O errors
• poll: wait for new I/O and run I/O callbacks (most of your code runs here)
• check: setImmediate callbacks
• close callbacks: e.g. socket.on('close')

Between every callback, Node drains the microtask queues: first process.nextTick, then promise callbacks.

The loop exits when there are no timers, pending I/O or handles left.

• process.nextTick(fn): runs right after the current operation, before promise callbacks and before the loop continues. Highest priority.
• setImmediate(fn): runs in the check phase, right after the current poll phase.
• setTimeout(fn, 0): runs in the timers phase, after at least 1 ms.

From the main module, the order of setTimeout vs setImmediate is not guaranteed. Inside an I/O callback, setImmediate always runs first.

Recursive nextTick calls can starve the event loop, because I/O never gets a turn. Prefer setImmediate or queueMicrotask unless you really need nextTick.

Blocking code makes the single JavaScript thread wait until it finishes, so no other request, timer or callback can run. Non-blocking code starts the work and returns immediately, with the result delivered later via a callback or promise.

Common ways to block by accident:

• sync APIs like fs.readFileSync or crypto.pbkdf2Sync inside a request handler
• huge JSON.parse / JSON.stringify calls
• heavy loops, sorting large arrays, catastrophic regexes

Fixes: use async APIs, move CPU work to worker threads or a separate service, split work into chunks, and stream large data instead of loading it all.

CommonJS (require / module.exports) is Node's original system. Loading is synchronous and happens at runtime, so you can require conditionally.

ES modules (import / export) are the JavaScript standard. Imports are static and resolved before code runs, which enables tree-shaking, top-level await and live bindings.

Node picks the system by file: .mjs is ESM, .cjs is CommonJS, and .js follows "type": "module" in package.json.

• ESM has no __dirname or require; use import.meta.dirname / import.meta.url
• ESM can import CommonJS; recent Node versions can also require() synchronous ESM
• New projects should default to ESM

A stream processes data piece by piece (chunks) instead of loading it all into memory. Four types:

• Readable: a source (fs.createReadStream, an HTTP request)
• Writable: a destination (a file, an HTTP response)
• Duplex: both (a TCP socket)
• Transform: modifies data passing through (gzip, encryption)

Streaming a 2 GB file uses a few KB of memory and the client starts receiving bytes immediately. Use stream.pipeline to connect them, because it forwards errors and cleans up all streams, which .pipe() does not.

Handle errors where you can recover:

• sync code and await: try/catch
• promises: .catch()
• callbacks: check the error-first argument (err, data)
• emitters and streams: an 'error' listener

Uncaught exceptions and unhandled rejections (the default since Node 15) crash the process. Use process.on('uncaughtException') and 'unhandledRejection' only to log and exit, never to keep running, because the app may be in a broken state. Let a process manager (PM2, Kubernetes) restart it.

Separate operational errors (network down, bad input: handle them) from programmer errors (bugs: crash and fix).

• worker_threads: extra JavaScript threads in the same process. They can share memory (SharedArrayBuffer) and pass messages. Use for CPU-heavy work (image resizing, parsing, hashing) without blocking the main thread.
• cluster: forks several Node processes that share one server port. Use to use all CPU cores for an HTTP server. Each worker has its own memory.
• child_process: runs another program (spawn, exec, fork), e.g. ffmpeg or a Python script.

Today, many teams skip cluster and run one process per container, scaling with Kubernetes or PM2 instead.

Express keeps an ordered list of middleware and routes. For each request it runs the matching functions in the order they were registered. Each one receives (req, res, next) and must either:

• end the response (res.send, res.json), or
• call next() to pass control to the next function

next('route') skips to the next matching route, and next(err) skips straight to error-handling middleware.

If a middleware does neither, the request hangs until the client times out. Order matters: express.json() must come before routes that read req.body, and auth before protected routes.

Error middleware is a function with four arguments: (err, req, res, next). Express recognises it by the argument count, so you must declare all four even if you do not use next.

It runs when a handler throws synchronously or calls next(err). Register it after all routes, so it catches errors from everything above.

A good central handler:

• maps known errors to status codes (validation → 400, not found → 404)
• logs unexpected errors with the request ID
• hides stack traces and internals from clients in production

In Express 4, a rejected promise inside an async handler is not caught: the error middleware never runs, the request hangs and you get an unhandled rejection. Fixes:

• wrap every handler in try/catch and call next(err)
• use a small asyncHandler wrapper (below) or the express-async-errors package

In Express 5, rejected promises are forwarded to next(err) automatically, so a plain throw inside an async handler works.

Either way, keep one central error middleware instead of sending error responses from every route.

• req.params: named parts of the path. For route /users/:id and URL /users/42, req.params.id is '42'. Use them to identify a resource.
• req.query: the query string. /users?role=admin&page=2 gives { role: 'admin', page: '2' }. Use for filtering, sorting, pagination.
• req.body: the request payload of POST/PUT/PATCH. Empty unless a body parser like express.json() runs first.

All values from params and query are strings (or arrays), so convert and validate them before use.

REST (Representational State Transfer) is an architectural style for APIs over HTTP. Key ideas:

• resources identified by URLs, named with nouns: /users/42/orders, not /getOrders
• HTTP methods express the action: GET reads, POST creates, PUT/PATCH update, DELETE removes
• stateless: each request carries everything needed (e.g. a token); the server keeps no session between requests
• representations: clients get JSON (or other formats) describing the resource
• correct status codes and cacheable responses
• a uniform interface (HATEOAS in the strict definition)

In practice most "REST" APIs are resource-oriented JSON over HTTP and skip HATEOAS.

• GET: read. Safe and idempotent.
• POST: create or trigger an action. Neither safe nor idempotent: two calls can create two orders.
• PUT: replace a resource. Idempotent.
• PATCH: partial update. Not guaranteed idempotent (e.g. "increment by 1").
• DELETE: remove. Idempotent: deleting twice leaves the same state (the second call may return 404).
• HEAD/OPTIONS: metadata and CORS preflight. Safe.

Safe = does not change state. Idempotent = repeating the request has the same effect as doing it once. This matters for retries: clients and proxies can retry idempotent requests safely. For POST, use an Idempotency-Key header so retries do not double-charge.

• 200 OK success with a body; 201 Created after POST (add a Location header); 204 No Content success with no body (DELETE)
• 301/308 permanent redirect; 304 Not Modified for cache validation
• 400 Bad Request malformed or invalid input; 422 is sometimes used for validation errors
• 401 Unauthorized not authenticated (missing or bad token); 403 Forbidden authenticated but not allowed
• 404 Not Found; 409 Conflict (duplicate email, version conflict); 429 Too Many Requests
• 500 unexpected server error; 502/503/504 upstream or availability problems

Never return 200 with { error: … } in the body: clients, monitoring and caches rely on the code.

Offset pagination: ?page=3&limit=20 → LIMIT 20 OFFSET 40.

• simple, supports "jump to page 7" and total counts
• gets slow on deep pages (the DB still scans skipped rows) and items can be skipped or duplicated when rows are inserted or deleted between requests

Cursor (keyset) pagination: ?after=<cursor>&limit=20, where the cursor encodes the last item's sort key → WHERE (created_at, id) < (…) ORDER BY created_at DESC, id DESC LIMIT 20.

• fast at any depth using an index, and stable while data changes
• no random page jumps

Use offset for small admin tables, cursor for feeds, infinite scroll and large datasets. Always cap limit.

By default, the browser's same-origin policy stops JavaScript on https://app.com from reading responses from https://api.com. CORS lets the server opt in, using response headers like Access-Control-Allow-Origin.

For "non-simple" requests (JSON body, custom headers, PUT/DELETE), the browser first sends an OPTIONS preflight request to ask permission.

In Express, use the cors package with an explicit allowlist. With cookies you need credentials: true and you cannot use the * wildcard origin.

CORS is enforced by browsers only; it does not stop curl or server-to-server calls, so it is not access control.

Authentication (authn) answers who are you? It verifies identity: password, passkey, OTP, SSO login.

Authorisation (authz) answers what are you allowed to do? It checks permissions for an already-identified user: can this user delete this project?

Authentication comes first; authorisation runs on every protected request.

In HTTP terms: failed authentication → 401 Unauthorized (despite the name); authenticated but not permitted → 403 Forbidden.

A common bug is checking authentication only: any logged-in user can read /invoices/123 even when it belongs to someone else (broken object-level authorisation).

Server sessions: after login the server stores session data (in Redis or a DB) and sends a random session ID in a cookie. Each request looks the session up.

• easy, instant logout and revocation
• needs a shared session store across instances

JWT: the server signs a token containing the claims (user ID, roles, expiry). The server verifies the signature without a lookup.

• stateless, good across services and for mobile or third-party APIs
• hard to revoke before it expires, so keep it short-lived and add refresh tokens

For a classic web app on one domain, a session in an HttpOnly cookie is usually simpler and safer. JWTs shine for distributed systems and APIs consumed by many clients.

A JWT is three Base64URL parts joined by dots: header.payload.signature.

• header: algorithm and type, e.g. {"alg":"HS256","typ":"JWT"}
• payload: claims such as sub (user ID), exp (expiry), iat, iss, aud, roles
• signature: HMAC (shared secret) or RSA/ECDSA (private key) over the header and payload

The payload is encoded, not encrypted: anyone can read it, so never put secrets in it.

Verification: recompute or check the signature, then validate exp, iss and aud. Pin the accepted algorithm in the server config, so alg: "none" or algorithm-confusion tricks are rejected.

localStorage: easy to send in an Authorization header, and immune to CSRF. But any XSS can read it and send it to an attacker, who can then use it from anywhere until it expires.

HttpOnly cookie: JavaScript cannot read it, so XSS cannot steal the token (it can still make requests while the page is open). Cookies are sent automatically, so you must handle CSRF with SameSite and/or CSRF tokens.

The usual recommendation: keep tokens in HttpOnly; Secure; SameSite=Lax (or Strict) cookies. A common SPA pattern is a short-lived access token in memory plus a refresh token in an HttpOnly cookie.

Never store plain text or use encryption (reversible) or a fast hash like MD5 or SHA-256: GPUs try billions of guesses per second.

Use a slow, purpose-built password hashing function: Argon2id (current first choice), bcrypt or scrypt. They have a tunable work factor so each guess is expensive.

A salt (random, unique per user, stored with the hash) means identical passwords get different hashes and defeats precomputed rainbow tables. bcrypt and Argon2 generate and embed the salt for you.

Optionally add a pepper: a secret kept outside the database (in a secrets manager) and mixed into the hash.