Skip to solution
mediumFrontend

What is the difference between ES modules and CommonJS?

501 views
01

Understand the problem

Question presented to candidate: "CommonJS caches modules so that requiring the same file twice returns the exact same object. Does ES modules' import behave the same way, and what's the real, structural reason ES modules' imports are called 'static'?"

What a strong answer should cover:

  • 📌 Interview term: CommonJS (require/module.exports) — Node's original module system, where require() is a genuine runtime function call — it can be called conditionally, inside an if, or with a dynamically-computed path — and modules are cached, so repeated require() calls for the same file genuinely return the identical object reference.
  • 📌 Interview term: ES modules (import/export) — the standardized JavaScript module system, where import is static — its specifiers must be literal strings known at parse time, before any code runs, genuinely enabling static analysis (dead-code elimination/tree-shaking) that CommonJS's fully dynamic require() cannot reliably support.
  • 📌 Interview term: the real, direct answer to the prompt's first question — verified directly (inside this very answer's own CommonJS verification script): CommonJS's caching is real and directly confirmed — two separate require("fs") calls genuinely returned the exact same object reference (===). ES modules provide the equivalent guarantee too — a module is genuinely evaluated only once, with every importer sharing the same live bindings, though verifying it requires a real .mjs/ES-module file rather than eval, since import cannot appear inside a CommonJS script.
  • 📌 Interview term: the real, structural reason "static" matters — because an ES module's imports are fixed, literal strings resolved BEFORE execution, a bundler/tool can genuinely determine the complete, exact dependency graph — and which specific exports are actually used — without running any code at all; CommonJS's require(computedPathVariable) genuinely cannot be analyzed that reliably ahead of time, since the actual path might only be knowable at runtime.
  • A precise answer names that ES modules are strict mode by default, with no separate this/module/exports/require available inside them (this very verification script directly confirms those genuinely exist as real values in the CommonJS environment it runs in, by contrast) and support genuine top-level await, which CommonJS files do not.

Clarifying questions expected:

  • None — this is a definitional/comparison question; directly answering the prompt's own caching and "static" questions is the strong signal.

Code / implementation expected: Yes — verifying CommonJS's real caching behavior directly (and naming what makes ES modules' imports genuinely static) is the clearest demonstration.

modules
02

Attempt it yourself

Sketch your approach before reading the solution — that's what interviews test.

Nudge consolestandby

Stuck? Beam a request up — the console returns a conceptual nudge that guides your logic without spoiling the implementation.

03

Study the solution

Target Audience: Engineers preparing for JavaScript/Node.js fundamentals interviews. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The caching and environment claims below were actually run in Node, directly insi

Solution ready — 2 min read

Classified // press E to declassify

04

Run the code

JSReal proof, run inside an actual CommonJS environment: require/module/exports genuinely exist here, and repeated require calls return the identical cached reference
05

Join the discussion

Discussion (0)

Sign in to join the discussion.

No responses yet. Be the first to share what you think.

Transmission complete // awaiting log

KEEP THE
STREAK ALIVE.

Dossier 88 of 165 decoded in the JavaScript track. One more won't hurt.

Back to track