Why modules?

Why modules exist

As programs grow, code stops living in one tiny file. A shopping cart has price math, a checkout screen, form validation, analytics, tests, and little helpers. If every file drops its names into the same place, the program becomes a crowded room where anyone can accidentally overwrite anyone else.

A module is JavaScript with a boundary: private names inside, and explicit doors for anything another file may use. Modern JavaScript modules use export for the front desk and import for the visitor list. Older code used IIFEs, namespaces, CommonJS, and AMD to solve parts of the same problem before ES modules became the standard.

Classic browser scripts are simple: place several <script> tags on the page, and they run in order. The catch is that they share one global script scope. Top-level var and top-level function declarations become properties of the global object in browsers, so window.count and window.format appear. Top-level let, const, and class are still global lexical names, but they do not become window properties. The old var and the global object lesson digs into that distinction.

The collision lab runs real classic scripts inside a sandboxed iframe. Toggle the order and watch which feature owns the shared names.

1<script>2var count = 1;3function format() { return "cart:" + count; }4window.cartFeature = format();5</script>6<script>7var count = 99;8function format() { return "profile:" + count; }9window.profileFeature = format();10</script>11<script>12window.report = [cartFeature, profileFeature, format(), window.count];13</script>

This kind of bug is sneaky because each file can look reasonable by itself. The cart file says “I need a count and a format.” The profile file says the same thing. The page only breaks when both are loaded together, and the order decides which definition survives.

Before standard modules, developers often wrapped a feature in an IIFE: an immediately invoked function expression. A function creates function scope, and calling it right away runs the setup. Anything declared inside stays private unless the function returns it or assigns it somewhere public.

1<script>2window.CartApp = (function () {3  var count = 1;4  function format() { return "cart:" + count; }5  return { feature: format() };6}());7</script>8<script>9window.ProfileApp = (function () {10  var count = 99;11  function format() { return "profile:" + count; }12  return { feature: format() };13}());14</script>

The namespace pattern was a huge improvement over loose globals. It made intent visible: “the public cart API is CartApp.” But it still relied on global namespace objects and careful script order. The next patterns add loaders.

CommonJS and AMD are two older module systems you still meet in tools, libraries, and historical code. CommonJS uses synchronous require(id) and module.exports. It was Node’s original module system: perfect when files are on disk and can load immediately. The important mechanics are a wrapper function, an exports object, and a cache after the first load.

1const modules = {Run2  "./math": function (module) {3    module.exports.add = (a, b) => a + b;4  },5  "./cart": function (module, exports, require) {6    const math = require("./math");7    exports.total = (items) => items.reduce(math.add, 0);8  }9};10const cache = {};11function require(id) {12  if (cache[id]) return cache[id].exports;13  const module = { exports: {} };14  cache[id] = module;15  modules[id](module, module.exports, require);16  return module.exports;17}18const cart = require("./cart");19console.log(cart.total([2, 3]));

AMD, often associated with RequireJS, took a different path for browsers. Its shape is define(["dep"], factory): list dependencies, load them asynchronously, then run the factory. You do not need to write AMD for modern browser apps, but recognizing it helps you read older packages.

1define(["./math"], function (math) {2  return {3    total: function (items) {4      return items.reduce(math.add, 0);5    }6  };7});

ES modules are the standard JavaScript module system, standardized in ES2015 and now supported by browsers and Node. A module has its own top-level scope, is always strict, runs once per URL, and shares values only through export and import. In browsers, <script type="module"> is deferred by default, so it waits until parsing is complete instead of blocking the parser like a normal classic script.

1<script type="importmap">2{ "imports": { "cart": "data:text/javascript,..." } }3</script>4<script type="module">5import { count, total } from "cart";6window.moduleTop = typeof count;7console.log(total([2, 3]));8console.log(this === undefined);9</script>

Notice the shift in thinking: modules do not ask, “What names are already on window?” They ask, “Which file exports the thing I need?” That is why the next lessons can teach named exports, default exports, re-exports, import maps, dynamic import, and CommonJS interop as precise tools rather than folklore.

Global script, IIFE, CommonJS, AMD, or ES module?

The patterns have recognizable fingerprints. Sort each snippet by the system it belongs to. If you miss one, read the explanation and look for the clue: window, an immediately called function, require, define, or import/export.

Where you’ll use this

In real front-end work, modules let you split by responsibility. One file can own cart math. Another can render the checkout. Tests can import the math without rendering the page. A future teammate can see the dependency by reading the first line of the file.

1// cart.js2export function total(items) {3  return items.reduce((sum, item) => sum + item.price, 0);4}5 6// checkout.js7import { total } from "./cart.js";8 9export function renderCheckout(items) {10  return "Total: $" + total(items);11}

• Use modules when a helper has a clear job and a small public surface.
• Keep private helpers unexported until another file genuinely needs them.
• Prefer explicit imports over “I hope this global already exists.”
• When reading legacy code, identify which pattern owns loading and sharing before changing names.

Common misconceptions

Key takeaways

• Classic scripts share global names; top-level var and function declarations can appear on window.
• IIFEs create private function scope and usually expose one namespace object.
• CommonJS uses synchronous require, module.exports, and a cache.
• AMD uses define([deps], factory) for asynchronous dependency loading.
• ES modules have private top-level scope, are strict, run once per URL, and share through import/export.

Up next: import & export, the syntax for named exports, default exports, re-exports, and live bindings.