Lesson 25 of 80

ES Modules vs CommonJS

Q: Compare ES Modules and CommonJS: timing, what an import actually gives you, and why it matters for tooling.

A strong answer covers: require() is synchronous and can be called anywhere/conditionally; import is hoisted and statically resolved before the module runs; CommonJS require() returns a copy of exports at that moment; ESM imports are live bindings that reflect later changes; ESM's static structure is what enables tree-shaking; CommonJS's dynamic require() calls prevent bundlers from fully analyzing the dependency graph ahead of time.

Two competing module systems with genuinely different rules for loading, timing, and what an import actually is — not just different syntax for the same idea.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

A module does `export let count = 0` then later `count++`. A different file does `import { count } from './mod.js'`. After the increment, what does the importer see?

The updated value — ESM exports are live bindings, not snapshotsStill 0 — imports capture a copy of the value at import timeundefined, because count was reassigned after being exported

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on ES Modules vs CommonJS

What interviewers actually ask about this, and what a strong answer has to cover.

Compare ES Modules and CommonJS: timing, what an import actually gives you, and why it matters for tooling.

A strong answer covers

require() is synchronous and can be called anywhere/conditionally; import is hoisted and statically resolved before the module runs
CommonJS require() returns a copy of exports at that moment; ESM imports are live bindings that reflect later changes
ESM's static structure is what enables tree-shaking; CommonJS's dynamic require() calls prevent bundlers from fully analyzing the dependency graph ahead of time

Likely follow-ups

How would you conditionally load a module in ESM, given that import statements can't be inside an if?
What actually breaks if you mix require() and import in the same Node project incorrectly?
Why do live bindings matter in practice — can you think of a bug they'd cause if you expected a snapshot instead?

Practice these with the AI interviewer →

The plain-language idea

// CommonJS (Node's original system)
const { add } = require("./math");     // synchronous, runs at the require() call
module.exports = { multiply };

// ES Modules (the language standard)
import { add } from "./math.js";       // hoisted, resolved before any code runs
export function multiply() {}

They look similar but differ in ways that actually matter:

Timing. require() runs synchronously, wherever you write it, like a function call. import statements are hoisted and resolved before the module's own code runs — you can't conditionally import inside an if.
What you get. CommonJS require() gives you a copy of module.exports at that moment. ES Modules exports are live bindings — if the exporting module later changes the exported variable, every importer sees the new value.
Static vs dynamic. ESM imports are statically analyzable (tools can determine the whole dependency graph without running code) — that's what makes tree-shaking possible. CommonJS's require() can be called conditionally or computed at runtime, so bundlers can't always know the full graph ahead of time.

require() copies; import stays linkedStep 1 of 4

const { add } = require('./math') — runs synchronously, exactly where it's written.

What people usually miss

Watch out

Tree-shaking needs ESM's static structure. A bundler can only safely delete unused exports if it can see the whole import/export graph without executing code — CommonJS's dynamic require() calls make that analysis unreliable.
import is hoisted, require() is not. You can call require() conditionally inside an if; a top-level import statement can't be conditional (dynamic import() — the function form — exists specifically for that case).
Node supports both, distinguished by .mjs/.cjs extensions or the "type" field in package.json — mixing them incorrectly is a common real-world source of confusing "require is not defined" or "Cannot use import" errors.

Why this matters in interviews

Explaining why tree-shaking requires ESM (not just knowing the syntax difference) is what separates "used both" from "understands why the ecosystem moved to ES Modules."