105 道问答题，一道一卡105 questions, one card each

In one line: the DOM is the tree of objects the browser builds when it parses your HTML — one node per tag. A DOM event is something that happens on that tree (a click, some typing, a load finishing), and you register functions to respond to it.

Be precise about the key point: the DOM is not the HTML itself, and it is not part of the JavaScript language — it is an API the browser hands you (a Web API). That is why Node has no document. This one pairs with #276.

Why “touching the DOM is slow”: reading and writing a property is not the slow part. The cost is that it can trigger reflow and repaint — the browser has to recompute layout and paint again. Reading offsetHeight and then changing a style, over and over inside a loop, causes layout thrashing, and that is the real performance killer.

This is exactly what makes the virtual DOM worth something (see #330): it batches many operations into one and tries to touch only what changed.

Follow-up: “What is the difference between target and currentTarget on the event object?” — target is the element that was actually clicked, currentTarget is the element this listener is attached to. Event delegation rides entirely on that difference, which is the next question.

In one line: propagation is the browser’s mechanism (capture → target → bubble, see #380); delegation is the trick we play with it — put the listener on the parent and use e.target to work out which child was really clicked.

Delegation solves two problems:

• The number of listeners — a 1000-row table with 1000 listeners costs real memory and real binding time; delegation needs one.
• Dynamic elements — children inserted later already have the behaviour, with nothing to rebind. In practice this is often the bigger win.

The key to writing it is e.target.closest() — the user may have clicked a <span> inside the button, so a bare e.target.matches() misses it.

Follow-up, and this is the one that matters: “Are React events delegated?” — yes, and it is central to the design: React attaches events to the root container (to document before React 17, to the root node from 17 onwards, so that several React versions can coexist on one page), then wraps them in a SyntheticEvent to present one event system that behaves the same across browsers.
The consequence: inside React, e.stopPropagation() does stop propagation between React components, but it cannot stop a native listener — the native one already ran. Landing this point scores well.

In one line: the 2015 edition changed the most, and a dozen or so of its additions are things you use every single day.

Ordered by weight — pick five or six and explain them properly, do not recite the list:

• let / const — block scope (#282)
• Arrow functions — shorter, plus a lexical this (#285)
• Template literals — `${x}`, and they span lines
• Destructuring — const { a, b } = obj, used everywhere in React
• Spread and rest — ..., the basis of immutable updates
• Default parameters
• Promise — the turning point for async (#306)
• class — sugar over prototypes (#302)
• ES modules — import / export (#308)
• Map / Set (#286, #287), Symbol, for…of with iterators, generators

Follow-up: “What came after ES6 that you like?” — answering this makes you look like you keep up: async/await (ES2017), optional chaining ?. and nullish coalescing ?? (ES2020), Object.entries (ES2017), Array.flat (ES2019), at(-1) (ES2022), structuredClone.
Optional chaining and ?? are the two most worth naming, because they cut out a mountain of defensive code.

In one line: the module system built into the language — export to expose, import to pull in, one scope per file, and dependencies are known at compile time.

How it differs from CommonJS, Node’s older scheme — this is the part being tested:

Why does “resolved at compile time” matter? Because a bundler can see who uses what without running the code, so it can drop exports nobody imported (tree shaking) and split code. That is ESM’s real practical value, not prettier syntax.

Follow-up: “Named exports or a default export?” — a default export puts no constraint on the name, since an importer can call it anything, which hurts search and autocomplete; named exports are friendlier to tree shaking and refactoring. In practice: default for “one file, one main thing”, named for a bag of utilities.
“How do you use ESM in Node?” — "type": "module" in package.json, or name the file .mjs. That is why Jest needs --experimental-vm-modules in the Federation course.

In one line: Node’s package manager, plus the largest package registry in the world. It installs dependencies, pins versions and runs scripts.

Three core jobs:

• Install dependencies — read dependencies out of package.json and download the whole tree into node_modules.
• Pin versions — package-lock.json records the exact version and hash of every package, so a teammate and CI install precisely what you did. It has to be committed.
• Run scripts — npm run dev. It also puts node_modules/.bin on the PATH, which is why you can write vitest instead of a full path.

Two distinctions you must be able to make:

• dependencies vs devDependencies — the first is what you need at runtime (React), the second only while developing and building (TypeScript, the test runner, the bundler). A production install can skip the second with npm ci --omit=dev.
• npm install vs npm ci — install will update the lock file when it has to; ci installs strictly from the lock and errors out if the two disagree. CI should use ci.

Follow-up: “What is the difference between ^1.2.3 and ~1.2.3?” — ^ allows minor and patch upgrades (<2.0.0), ~ allows patches only (<1.3.0). It is precisely because ^ exists that the lock file is indispensable — otherwise installing on two different days gives you two different trees.

In one line: start at the entry, walk every import recursively and build a dependency graph, push files through loaders to turn them into JS along the way, and emit a handful of bundles according to your rules.

Four core concepts you have to name:

• entry — where the dependency walk starts.
• output — where the bundles land and what they are called (with [contenthash] for caching).
• loader — turns non-JS into JS. babel-loader handles JSX and new syntax, css-loader makes CSS importable. Loaders run right to left (bottom to top) — that detail gets asked a lot.
• plugin — hooks into the build lifecycle and can do far more than a loader (generate HTML, extract CSS, minify, analyse bundle size).

Why bundling exists at all — that is the real question: early browsers had no modules, they do not understand JSX or TS, and a lot of requests is slow. Bundling buys you modularity, transpilation, merging and minifying, and tree shaking.

Follow-up: “Why is Vite fast?” — asked constantly now. In development Vite does not bundle; it serves modules on demand over the browser’s native ESM, so startup is constant time and does not degrade as the project grows. Dependency pre-bundling runs on esbuild (written in Go, an order of magnitude faster), and only production goes through Rollup.
Webpack bundles everything and then serves it; Vite serves first and transforms on demand — that single sentence gets at the fundamental difference.

In one line: fetch is built into the browser and very bare-bones; axios is a third-party library that does the routine work for you.

“404 does not reject” is the heart of this question, and a real source of bugs: skip the res.ok check and you render an error page as if it were data. People coming over from axios miss this one most often, because axios throws on their behalf.

How to choose: a small project, a tight bundle budget, or only a handful of requests → fetch with your own small wrapper. Interceptors, one place for error handling, upload progress, or an old Node to support → axios.
The more realistic answer: reach for TanStack Query or SWR to manage caching and request state, and whichever one sits underneath hardly matters — because neither fetch nor axios handles caching, deduplication or retries. Answering that way shows you have thought about the layers.