引擎与类型十问10 questions on the engine and types

In one line: the engine is the program that turns JS source into something the machine can run. Chrome and Node use V8, Firefox uses SpiderMonkey, Safari uses JavaScriptCore.

Roughly the pipeline: source → parse into an AST → emit bytecode → the interpreter starts running it while watching which parts run over and over (the hot paths), and hands those to the JIT compiler to be turned into machine code. Interpret first, compile later — that is what lets JS start instantly and still hit near-native speed where it counts.

Follow-up: “What is the difference between the engine and the runtime?” — this is the real question. The engine only executes the language itself. It knows nothing about setTimeout, fetch, document or fs — those are APIs the host environment (browser or Node) hands you.
So “is the event loop part of the engine?” — no, it belongs to the runtime (see #305). Getting this distinction right earns real credit.

Another follow-up, on memory: the engine manages two areas — the call stack (execution contexts, primitive values) and the heap (objects, arrays, functions). Which lines up exactly with the next question.

In one line: Read-Eval-Print-Loop — read a line, evaluate it, print the result, wait for the next one. Typing node in a terminal drops you into one, and the DevTools Console in a browser is one too.

What you use it for: checking a bit of syntax, seeing what an API returns, working out a quick number. Not for multi-line logic — changing one line means retyping the lot.

Follow-up: “What does let x = 1 print in a REPL?” — undefined. It prints the value of the expression, and the value of a variable declaration is undefined. A small detail, but it shows whether you have actually used one.

In one line: a primitive sits on the stack and holds the value itself; a reference value sits on the heap, and the stack holds only an address.

Seven primitive types (learn the list — they will make you count them): string, number, boolean, undefined, null, symbol, bigint.
Everything else is a reference type: objects, arrays, functions, Date, Map, Set, regexes… (arrays and functions are objects underneath).

Three differences you can observe:

• Immutability — a primitive value cannot be changed.s.toUpperCase() returns a new string; the original never moved.
• Comparison — primitives compare by value, references compare by address. So {} === {} is false, and so is [1] === [1].
• Assignment — a primitive gets copied; a reference copies only the address, so two variables point at the same object. That is #284.

Follow-up: “What is typeof null? ” — "object", a bug that has survived 30 years because fixing it would break too much. Test for null with x === null.
“How do you reliably detect an array?” — Array.isArray(x). Never typeof, which just says "object".

In one line: conversion (casting) is what you write on purpose; coercion is the engine doing it behind your back.

Two rules cover almost all coercion — hold on to these and you can derive most of the trick questions:

• + becomes concatenation the moment one side is a string; every other arithmetic operator (-, *, /) converts to number. Hence 1 + "1" === "11" but "3" - 1 === 2.
• An object in an operation goes through valueOf() first, then toString(). An array’s toString() joins its elements with commas, so [] + [] gives an empty string and [] + {} gives "[object Object]".

Memorise the six falsy values (everything else is truthy): false, 0, "", null, undefined, NaN.
Watch out — [] and {} are both truthy, so check arr.length to tell whether an array is empty.

Follow-up: “What is the difference between parseInt and Number?” — parseInt("42px") gives 42 (it reads from the front until it cannot go on), while Number("42px") gives NaN (the whole string has to be valid). So validate user input with Number; parseInt waves dirty data straight through.

In one line: === returns false straight away when the types differ; == converts both sides to one type first, then compares.

The == conversion rules are convoluted, but four points cover practice:

• null == undefined is true, and neither one is == to anything else (not 0, not "").
• Number against string → the string becomes a number.
• A boolean involved → the boolean becomes a number (true→1, false→0). That is why [] == false is true: []→""→0, and false→0.
• Object against primitive → the object becomes a primitive.

The conclusion: use === everywhere. The one == that everybody accepts is x == null — it rules out null and undefined in a single check.

Follow-up: “NaN === NaN?” — false. NaN is not even equal to itself. Test it with Number.isNaN(x) — not the global isNaN, which coerces first, so isNaN("abc") is true.
“Is there anything stricter?” — Object.is(x, y). It differs from === in exactly two places: Object.is(NaN, NaN) is true, and Object.is(0, -0) is false. This is what React uses to decide whether state changed.

In one line: && and || stop evaluating the moment the result is decided, and they hand back an operand, not a boolean.

• a && b — returns a if a is falsy, otherwise b. “Both must be true”, so one falsy value ends the job.
• a || b — returns a if a is truthy, otherwise b.
• a ?? b (nullish coalescing) — returns b only when a is null or undefined.

The difference between || and ?? is a frequent follow-up and a real source of bugs: count || 10 gives you 10 when count is 0, because 0 is falsy. For default values, reach for ??.

The most common React use is conditional rendering: {loading && <Spinner />}. Here is the trap: if the left side is list.length and the list is empty, then 0 && … returns 0, and React renders that 0 — a stray “0” shows up on the page out of nowhere. Write list.length > 0 && … instead.

In one line: var is function-scoped, hoists to undefined and can be redeclared; let / const are block-scoped, have a TDZ and cannot be redeclared; const on top of that cannot be reassigned.

The TDZ (temporal dead zone) is the stretch between the start of the block and the let / const line itself. The variable really is hoisted, but flagged as “not usable yet”, so reading it throws instead of handing you undefined. That is deliberate — it makes mistakes surface early.

Follow-up: “Can you change the properties of a const object?” — yes. const locks the binding (the name cannot point at anything else), not the value. To freeze the contents, use Object.freeze().

Another follow-up — the classic loop question: for (var i…) with setTimeout prints three 3s; let prints 0 1 2. Because let creates a fresh binding on every iteration, while var has one single i the whole way through. This gets asked together with closures (#298).

In one line — get this sentence exactly right: JavaScript is always pass by value. It is just that when the value happens to be an object, the “value” being passed is an address. The precise name for this is pass by sharing.

Why does the wording matter? Because it explains two things that look like a contradiction:

• obj.n = 2 inside the function does show up outside — both variables point at the same object.
• obj = { n: 2 } inside the function does not show up outside — all you did was point the parameter variable inside the function at a new object; the outer variable still points at the old one.

If this really were pass by reference, the second case would change the outside too. So it is pass by value.

Follow-up: “How do you avoid mutating the caller’s data?” — copy it first. { ...obj } and arr.slice() are shallow copies (one level only; nested objects are still shared). For a deep copy use structuredClone(obj) — native in modern browsers and Node 17+, and better than JSON.parse(JSON.stringify()), which drops undefined and functions, turns Date into a string, and cannot handle circular references at all.

This one ties straight into React: React compares references to decide whether state changed, which is exactly why “I changed a property and the UI did not move” happens — you have to build a new object.

In one line: a Set holds unique elements, checks membership in O(1), and has no indices; an array allows duplicates, has order and indices, and its includes is O(n).

When to use a Set: deduping, and answering “have I seen this before?” inside a loop — the second is where the performance gap is biggest, because an array includes turns O(n) into O(n²).

Follow-up: “Can a Set dedupe identical objects?” — no. A Set uses SameValueZero (≈===), and two objects with the same contents are still two different references. To dedupe by content, key them yourself in a Map.
“What about NaN?” — a Set stores NaN only once. That is the only difference between SameValueZero and ===.

In one line: a Map takes keys of any type, guarantees insertion order, has size, and is iterable on its own; an object’s keys can only be strings or symbols, and it drags a prototype chain along with it.

How to choose:

• Use an Object for records with a fixed shape (one user, one config), for anything you serialise to JSON, and when the field names are written into the code.
• Use a Map when the keys are dynamic, entries come and go often, there are a lot of them, or the keys are not strings.

Follow-up: “Why is an object a prototype pollution risk?” — because even an empty object “has” inherited keys like toString and constructor. Use an object as a dictionary and if (dict[key]) reports a hit when the user types "constructor". A Map does not have this problem; if you must use an object, build it with Object.create(null).
“And WeakMap?” — its keys must be objects, and it does not hold off garbage collection. Good for hanging extra data on an object without leaking memory.