finalized esm story

Author: bevacqua

chapters/ch01.asciidoc

@@ -29,7 +29,7 @@ Relying on consistent API shapes is a great way of increasing productivity, give
 
 === 1.2 A Brief History of Modularity
 
-When it comes to JavaScript, modularity is a modern concept. In this section we'll quickly revisit and summarize the milestones in how modularity evolved in the world of JavaScript.
+When it comes to JavaScript, modularity is a modern concept. In this section we'll quickly revisit and summarize the milestones in how modularity evolved in the world of JavaScript. This section isn't meant to be a comprehensive list, by any means, but instead it's meant to illustrate the major paradigm changes along the history of JavaScript.
 
 ==== 1.2.1 Script Tags and Closures
 
@@ -143,11 +143,42 @@ Needless to say, the delay in introducing this little-known build tool, combined
 
 ==== 1.2.3 Node.js and the Advent of CommonJS
 
-..
+Among the many innovations hailed by Node.js, one was the CommonJS module system -- or CJS for short. Taking advantage of the fact that Node.js programs had access to the file system, the CommonJS standard is more in line with traditional module loading mechanisms. In CommonJS, each file is a module with its own scope and context. Dependencies are loaded using a synchronous `require` function that can be dynamically invoked at any time in the lifecycle of a module, as illustrated in the next snippet.
+
+[source,javascript]
+----
+const mathlib = require('./mathlib')
+----
 
-==== 1.2.4 ES6, `import`, and Babel
+Much like RequireJS and AngularJS, CommonJS dependencies are also referred to by a pathname. The main difference is that the boilerplate function and dependency array are now both gone, and the interface from a module could be assigned to a variable binding, or used anywhere a JavaScript expression could be used.
 
-..
+Unlike RequireJS or AngularJS, CommonJS was rather strict. In RequireJS and AngularJS you could have many dynamically-defined modules per file, whereas CommonJS had a one-to-one mapping between files and modules. At the same time, RequireJS had several ways of declaring a module and AngularJS had several kinds of factories, services, providers and so on -- besides the fact that its dependency injection mechanism was tightly coupled to the AngularJS framework itself. CommonJS, in contrast, had a single way of declaring modules. Any JavaScript file was a module, calling `require` would load dependencies, and anything assied to `module.exports` was its interface. This enabled better tooling and code introspection -- making it easier for tools to learn the hierarchy of a CommonJS component system.
+
+Eventually, Browserify was invented as way of bridging the gap between CommonJS modules for Node.js servers and the browser. Using the `browserify` command-line interface program and providing it with the path to an entry point module, one could combine an unthinkable amount of modules into a single browser-ready bundle. The killer feature of CommonJS, the npm package registry, was decisive in aiding its takeover of the module loading ecosystem.
+
+Granted, npm wasn't limited to CommonJS modules or even JavaScript packages, but that was and still is by and large its primary use case. The prospect of having thousands of packages (now over half million and steadily growing) available in your web application at the press of a few fingertips, combined with the ability to reuse large portions of a system on both the Node.js web server and each client's web browser, was too much of a competitive advantage for the other systems to keep up.
+
+==== 1.2.4 ES6, `import`, Babel, and Webpack
+
+As ES6 became standardized in June of 2015, and with Babel transpiling ES6 into ES5 long before then, a new revolution was quickly approaching. The ES6 specification included a module system native to JavaScript, often referred to as ECMAScript Modules (ESM).
+
+ESM is largely influenced by CJS and its predecessors, offering a static declarative API as well as a promise-based dynamic programmative API, as illustrated next.
+
+[source,javascript]
+----
+import mathlib from './mathlib'
+import('./mathlib').then(mathlib => {
+  // …
+})
+----
+
+In ESM, too, every file is a module with its own scope and context. One major advantage in ESM over CJS is how ESM has -- and encourages -- a way of statically importing dependencies. Static imports vastly improve the introspection capabilities of module systems, given they can be analyzed statically and lexically extracted from the abstract syntax tree (AST) of each module in the system. Static imports in ESM are constrained to the topmost level of a module, further simplifying parsing and introspection.
+
+In Node.js v8.5.0, ESM module support was introduced behind a flag. Most evergreen browsers also support ESM modules behind flags.
+
+Webpack is a successor to Browserify that largely took over in the role of universal module bundler thanks to a broader set of features. Just like in the case of Babel and ES6, Webpack has long supported ESM with both its `import` and `export` statements as well as the dynamic `import()` function. It has made a particularly fruitful adoption of ESM, in no little parts thanks to the introduction of a "code-splitting" mechanism whereby it's able to partition an application into different bundles to improve performance on first load experiences.
+
+Given how ESM is native to the language, -- as opposed to CJS -- it can be expected to completely overtake the module ecosystem in a few years time.
 
 === 1.3 The Perks of Modular Design