Understanding
 JavaScript Modules Ahmad Alfy

No content

JavaScript modules ecosystem may be intimidating,
 but understanding it is vital for web developers. Bundlers Loaders Browserify Webpack CommonJS AMD Import Export

• Self contained piece of code. • Has a very specific functionality. • Can be added or removed from a system as needed. • Can be injected/required by other modules. What is a Module?

1. Maintainability: because a module is self-contained, functionalities can be added/removed from it as it grow. Splitting your code into modules allows you to maintain it without growing complexity. 2. Reusability: Splitting your code into modules allows you to reuse it in the same project or different projects. 3. Name spacing: Using modules reduce the pollution of global environment in JavaScript Why we need modules?

• Before ES6, JavaScript didn’t have native modules. We had to come up with patterns to mimic the modular behavior. • Introduction of modules in JavaScript doesn’t mean we have to deprecate the methods that was being used. Eventually you will have to support a project or deal with a third party code that might not be using classes. How can we use modules in JavaScript

Patterns Object literal

Patterns Revealing module

• The previous approaches used a single global variable to wrap its code and hence creating a private namespace for itself. • It doesn’t address dependency management, meaning which script/module depends upon. • It can lead to namespace collisions like the probability of having two modules can have the same name.

No content

No content

• It’s a volunteering working group started by Mozilla Engineer Kevin Dangoor in 2009 and it is not affiliated with ECMA group and TC39. • Originally started to introduce APIs that will facilitate working with JavaScript outside the browser like servers, command line tools, desktop apps. • One of the features introduced in CommonJS was the Modules. It’s essentially a reusable piece of JavaScript which exports specific objects, making them available for other modules to require.

No content

• No more pollution for the name space. • Dependencies are explicitly declared.

• CommonJS approach is awesome when you are reading dependencies from files in the same disk because it works synchronously. It wasn’t suitable for the web. • The reason is because loading too many modules will block the main thread and halt the browser until all the dependencies are fetched and parsed.

×

AMD API specifies a mechanism for defining modules such that the module and its dependencies can be asynchronously loaded. This is particularly well suited for the browser environment where synchronous loading of modules incurs performance, usability, debugging, and cross-domain access problems. AMD Asynchronous Module Definition https://github.com/amdjs/amdjs-api/blob/master/AMD.md

No content

No content

A common implementation of AMD is Require.js
 http://requirejs.org/docs/whyamd.html

UMD tries to let the authors use both CommonJS and AMD typed modules. As a result, UMD modules are capable of working on both client and server. UMD Universal Module Definition https://github.com/umdjs/umd/blob/master/README.md

No content

No content

No content

Multiple exports per module

Single export per module

No content

https://paulirish.github.io/es-modules-todomvc/

No content

No content

No content

No content

No content

Bundling Bundling is the process of grouping modules (and their dependencies) into a single file in the correct order.

Why? • Reduce the number of requests. • Allows minifiers/uglifiers to work more efficiently. • Browsers support isn’t ideal *yet*.

How? • We define a single or multiple entry points to the bundler • The bundler scan the dependencies and draw a dependency graph. • The bundler start to group all these files together in a single file (or multiple).

No content

No content

No content

Some benefits we get from the bundlers Code splitting Hot Module Replacement Tree shaking Splitting code into various bundles which can then be loaded on demand or in parallel. • Multiple Entry Points: Manually split code using entry configuration. • Prevent Duplication. • Dynamic Imports with Loading on demand (lazy loading)

To Bundle • Ensure your application works across all the browsers • Serving a single file or multiple ones according to 
 your configuration and preferences. • Bundlers will minify and uglify your output. • Get the benefits of some of the bundlers like • Tree shaking • Code splitting • Hot module replacement

To Bundle Not • Eliminate middleware and reduce the dependencies you need to ship your application (debugging, configuring, DX). • Modern browsers run ES6 faster than the compiled code. • Harnessing the power of multiplexing in HTTP2, serving multiple small files will work faster than serving a single file or even multiple bundled files. • Better management for browser caching as only the updated files will be invalidated, not a whole bunch of bundled files.

Further resources • Discussion on GitHub: Can you help me understand the benefit of require.js
 https://gist.github.com/desandro/4686136 • JavaScript Modules: A Beginner’s Guide
 https://medium.freecodecamp.org/javascript-modules-a-beginner-s-guide-783f7d7a5fcc • JavaScript Modules Part 2: Module Bundling
 https://medium.freecodecamp.org/javascript-modules-part-2-module-bundling-5020383cf306 • The state of JavaScript modules
 https://medium.com/webpack/the-state-of-javascript-modules-4636d1774358 • TodoMVC with native ES6 modules
 https://paulirish.github.io/es-modules-todomvc/ • Webpack - The confusing parts
 https://medium.com/@rajaraodv/webpack-the-confusing-parts-58712f8fcad9

No content