Now Reading
ES modules: A cartoon deep-dive – Mozilla Hacks

ES modules: A cartoon deep-dive – Mozilla Hacks

2023-05-30 00:39:42

ES modules convey an official, standardized module system to JavaScript. It took some time to get right here, although — practically 10 years of standardization work.

However the wait is sort of over. With the discharge of Firefox 60 in Might (currently in beta), all main browsers will help ES modules, and the Node modules working group is at present engaged on including ES module help to Node.js. And ES module integration for WebAssembly is underway as effectively.

Many JavaScript builders know that ES modules have been controversial. However few really perceive how ES modules work.

Let’s check out what drawback ES modules resolve and the way they’re completely different from modules in different module techniques.

What drawback do modules resolve?

When you concentrate on it, coding in JavaScript is all about managing variables. It’s all about assigning values to variables, or including numbers to variables, or combining two variables collectively and placing them into one other variable.

Code showing variables being manipulated

As a result of a lot of your code is nearly altering variables, the way you set up these variables goes to have a huge impact on how effectively you possibly can code… and the way effectively you possibly can keep that code.

Having only a few variables to consider at one time makes issues simpler. JavaScript has a means of serving to you do that, referred to as scope. Due to how scopes work in JavaScript, capabilities can’t entry variables which might be outlined in different capabilities.

Two function scopes with one trying to reach into another but failing

That is good. It implies that while you’re engaged on one operate, you possibly can simply take into consideration that one operate. You don’t have to fret about what different capabilities is perhaps doing to your variables.

It additionally has a draw back, although. It does make it laborious to share variables between completely different capabilities.

What if you happen to do wish to share your variable exterior of a scope? A typical method to deal with that is to place it on a scope above you… for instance, on the worldwide scope.

You most likely keep in mind this from the jQuery days. Earlier than you could possibly load any jQuery plug-ins, you needed to guarantee that jQuery was within the world scope.

Two function scopes in a global, with one putting jQuery into the global

This works, however they’re some annoying issues that end result.

First, your whole script tags have to be in the suitable order. Then you need to watch out to guarantee that nobody messes up that order.

Should you do mess up that order, then in the course of working, your app will throw an error. When the operate goes searching for jQuery the place it expects it — on the worldwide — and doesn’t discover it, it’ll throw an error and cease executing.

The top function scope has been removed and now the second function scope can’t find jQuery on the global

This makes sustaining code difficult. It makes eradicating outdated code or script tags a sport of roulette. You don’t know what may break. The dependencies between these completely different elements of your code are implicit. Any operate can seize something on the worldwide, so that you don’t know which capabilities depend upon which scripts.

A second drawback is that as a result of these variables are on the worldwide scope, each a part of the code that’s inside that world scope can change the variable. Malicious code can change that variable on function to make your code do one thing you didn’t imply for it to, or non-malicious code might simply unintentionally clobber your variable.

How do modules assist?

Modules provide you with a greater method to set up these variables and capabilities. With modules, you group the variables and capabilities that make sense to go collectively.

This places these capabilities and variables right into a module scope. The module scope can be utilized to share variables between the capabilities within the module.

However in contrast to operate scopes, module scopes have a means of constructing their variables out there to different modules as effectively. They will say explicitly which of the variables, courses, or capabilities within the module must be out there.

When one thing is made out there to different modules, it’s referred to as an export. After getting an export, different modules can explicitly say that they depend upon that variable, class or operate.

Two module scopes, with one reaching into the other to grab an export

As a result of that is an express relationship, you possibly can inform which modules will break if you happen to take away one other one.

After getting the flexibility to export and import variables between modules, it makes it loads simpler to interrupt up your code into small chunks that may work independently of one another. Then you possibly can mix and recombine these chunks, sort of like Lego blocks, to create all completely different sorts of functions from the identical set of modules.

Since modules are so helpful, there have been a number of makes an attempt so as to add module performance to JavaScript. At present there are two module techniques which might be actively getting used. CommonJS (CJS) is what Node.js has used traditionally. ESM (EcmaScript modules) is a more recent system which has been added to the JavaScript specification. Browsers already help ES modules, and Node is including help.

Let’s take an in-depth have a look at how this new module system works.

How ES modules work

Once you’re creating with modules, you construct up a graph of dependencies. The connections between completely different dependencies come from any import statements that you simply use.

These import statements are how the browser or Node is aware of precisely what code it must load. You give it a file to make use of as an entry level to the graph. From there it simply follows any of the import statements to seek out the remainder of the code.

A module with two dependencies. The top module is the entry. The other two are related using import statements

However recordsdata themselves aren’t one thing that the browser can use. It must parse all of those recordsdata to show them into information buildings referred to as Module Information. That means, it really is aware of what’s happening within the file.

A module record with various fields, including RequestedModules and ImportEntries

After that, the module document must be became a module occasion. An occasion combines two issues: the code and state.

The code is principally a set of directions. It’s like a recipe for methods to make one thing. However by itself, you possibly can’t use the code to do something. You want uncooked supplies to make use of with these directions.

What’s state? State offers you these uncooked supplies. State is the precise values of the variables at any time limit. After all, these variables are simply nicknames for the containers in reminiscence that maintain the values.

So the module occasion combines the code (the record of directions) with the state (all of the variables’ values).

A module instance combining code and state

What we’d like is a module occasion for every module. The method of module loading goes from this entry level file to having a full graph of module cases.

For ES modules, this occurs in three steps.

  1. Building — discover, obtain, and parse all the recordsdata into module information.
  2. Instantiation —discover containers in reminiscence to put all the exported values in (however don’t fill them in with values but). Then make each exports and imports level to these containers in reminiscence. That is referred to as linking.
  3. Analysis —run the code to fill within the containers with the variables’ precise values.

The three phases. Construction goes from a single JS file to multiple module records. Instantiation links those records. Evaluation executes the code.

Folks speak about ES modules being asynchronous. You possibly can give it some thought as asynchronous as a result of the work is cut up into these three completely different phases — loading, instantiating, and evaluating — and people phases might be executed individually.

This implies the spec does introduce a sort of asynchrony that wasn’t there in CommonJS. I’ll clarify extra later, however in CJS a module and the dependencies beneath it are loaded, instantiated, and evaluated , with none breaks in between.

Nonetheless, the steps themselves will not be essentially asynchronous. They are often executed in a synchronous means. It relies on what’s doing the loading. That’s as a result of not all the pieces is managed by the ES module spec. There are literally two halves of the work, that are coated by completely different specs.

The ES module spec says how it is best to parse recordsdata into module information, and the way it is best to instantiate and consider that module. Nonetheless, it doesn’t say methods to get the recordsdata within the first place.

It’s the loader that fetches the recordsdata. And the loader is laid out in a distinct specification. For browsers, that spec is the HTML spec. However you possibly can have completely different loaders based mostly on what platform you’re utilizing.

Two cartoon figures. One represents the spec that says how to load modules (i.e., the HTML spec). The other represents the ES module spec.

The loader additionally controls precisely how the modules are loaded. It calls the ES module strategies — ParseModule, Module.Instantiate, and Module.Consider. It’s sort of like a puppeteer controlling the JS engine’s strings.

The loader figure acting as a puppeteer to the ES module spec figure.

Now let’s stroll by way of every step in additional element.


Three issues occur for every module in the course of the Building section.

  1. Determine the place to obtain the file containing the module from (aka module decision)
  2. Fetch the file (by downloading it from a URL or loading it from the file system)
  3. Parse the file right into a module document

Discovering the file and fetching it

The loader will deal with discovering the file and downloading it. First it wants to seek out the entry level file. In HTML, you inform the loader the place to seek out it by utilizing a script tag.

A script tag with the type=module attribute and a src URL. The src URL has a file coming from it which is the entry

However how does it discover the following bunch of modules — the modules that essential.js straight relies on?

That is the place import statements are available. One a part of the import assertion known as the module specifier. It tells the loader the place it will possibly discover every subsequent module.

An import statement with the URL at the end labeled as the module specifier

One factor to notice about module specifiers: they generally have to be dealt with otherwise between browsers and Node. Every host has its personal means of deciphering the module specifier strings. To do that, it makes use of one thing referred to as a module decision algorithm, which differs between platforms. Presently, some module specifiers that work in Node gained’t work within the browser, however there’s ongoing work to fix this.

Till that’s mounted, browsers solely settle for URLs as module specifiers. They are going to load the module file from that URL. However that doesn’t occur for the entire graph on the similar time. You don’t know what dependencies the module wants you to fetch till you’ve parsed the file… and you may’t parse the file till you fetched it.

Because of this we’ve got to undergo the tree layer-by-layer, parsing one file, then determining its dependencies, after which discovering and loading these dependencies.

A diagram that shows one file being fetched and then parsed, and then two more files being fetched and then parsed

If the primary thread have been to attend for every of those recordsdata to obtain, a variety of different duties would pile up in its queue.

That’s as a result of while you’re working in a browser, the downloading half takes a very long time.


A chart of latencies showing that if a CPU cycle took 1 second, then main memory access would take 6 minutes, and fetching a file from a server across the US would take 4 years
Based mostly on this chart.

Blocking the primary thread like this might make an app that makes use of modules too sluggish to make use of. This is among the causes that the ES module spec splits the algorithm into a number of phases. Splitting out building into its personal section permits browsers to fetch recordsdata and construct up their understanding of the module graph earlier than getting all the way down to the synchronous work of instantiating.

This strategy—having the algorithm cut up up into phases—is among the key variations between ES modules and CommonJS modules.

CommonJS can do issues otherwise as a result of loading recordsdata from the filesystem takes a lot much less time than downloading throughout the Web. This implies Node can block the primary thread whereas it hundreds the file. And because the file is already loaded, it is sensible to only instantiate and consider (which aren’t separate phases in CommonJS). This additionally implies that you’re strolling down the entire tree, loading, instantiating, and evaluating any dependencies earlier than you come the module occasion.

A diagram showing a Node module evaluating up to a require statement, and then Node going to synchronously load and evaluate the module and any of its dependencies

The CommonJS strategy has just a few implications, and I’ll clarify extra about these later. However one factor that it means is that in Node with CommonJS modules, you need to use variables in your module specifier. You’re executing all the code on this module (as much as the require assertion) earlier than you search for the following module. Meaning the variable can have a price while you go to do module decision.

However with ES modules, you’re build up this entire module graph beforehand… earlier than you do any analysis. This implies you possibly can’t have variables in your module specifiers, as a result of these variables don’t have values but.

A require statement which uses a variable is fine. An import statement that uses a variable is not.

However generally it’s actually helpful to make use of variables for module paths. For instance, you may wish to swap which module you load relying on what the code is doing or what surroundings it’s working in.

To make this potential for ES modules, there’s a proposal referred to as dynamic import. With it, you need to use an import assertion like import(`${path}/foo.js`).

The way in which this works is that any file loaded utilizing import() is dealt with because the entry level to a separate graph. The dynamically imported module begins a brand new graph, which is processed individually.

Two module graphs with a dependency between them, labeled with a dynamic import statement

One factor to notice, although — any module that’s in each of those graphs goes to share a module occasion. It’s because the loader caches module cases. For every module in a selected world scope, there’ll solely be one module occasion.

This implies much less work for the engine. For instance, it implies that the module file will solely be fetched as soon as even when a number of modules depend upon it. (That’s one purpose to cache modules. We’ll see one other within the analysis part.)

The loader manages this cache utilizing one thing referred to as a module map. Every world retains monitor of its modules in a separate module map.

When the loader goes to fetch a URL, it places that URL within the module map and makes a observe that it’s at present fetching the file. Then it’ll ship out the request and transfer on to start out fetching the following file.

The loader figure filling in a Module Map chart, with the URL of the main module on the left and the word fetching being filled in on the right

What occurs if one other module relies on the identical file? The loader will lookup every URL within the module map. If it sees fetching in there, it’ll simply transfer on to the following URL.

However the module map doesn’t simply hold monitor of what recordsdata are being fetched. The module map additionally serves as a cache for the modules, as we’ll see subsequent.


Now that we’ve got fetched this file, we have to parse it right into a module document. This helps the browser perceive what the completely different elements of the module are.

Diagram showing main.js file being parsed into a module record

As soon as the module document is created, it’s positioned within the module map. Because of this each time it’s requested from right here on out, the loader can pull it from that map.

The “fetching” placeholders in the module map chart being filled in with module records

There may be one element in parsing which will appear trivial, however that really has fairly large implications. All modules are parsed as if they’d "use strict" on the prime. There are additionally different slight variations. For instance, the key phrase await is reserved in a module’s top-level code, and the worth of this is undefined.

This completely different means of parsing known as a “parse objective”. Should you parse the identical file however use completely different targets, you’ll find yourself with completely different outcomes. So that you wish to know earlier than you begin parsing what sort of file you’re parsing — whether or not it’s a module or not.

In browsers that is fairly simple. You simply put kind="module" on the script tag. This tells the browser that this file must be parsed as a module. And since solely modules might be imported, the browser is aware of that any imports are modules, too.

The loader determining that main.js is a module because the type attribute on the script tag says so, and counter.js must be a module because it’s imported

However in Node, you don’t use HTML tags, so that you don’t have the choice of utilizing a kind attribute. A technique the neighborhood has tried to unravel that is by utilizing an .mjs extension. Utilizing that extension tells Node, “this file is a module”. You’ll see individuals speaking about this because the sign for the parse objective. The dialogue is at present ongoing, so it’s unclear what sign the Node neighborhood will resolve to make use of in the long run.

See Also

Both means, the loader will decide whether or not to parse the file as a module or not. If it’s a module and there are imports, it’ll then begin the method over once more till all the recordsdata are fetched and parsed.

And we’re executed! On the finish of the loading course of, you’ve gone from having simply an entry level file to having a bunch of module information.

A JS file on the left, with 3 parsed module records on the right as a result of the construction phase

The following step is to instantiate this module and hyperlink all the cases collectively.


Like I discussed earlier than, an occasion combines code with state. That state lives in reminiscence, so the instantiation step is all about wiring issues as much as reminiscence.

First, the JS engine creates a module surroundings document. This manages the variables for the module document. Then it finds containers in reminiscence for all the exports. The module surroundings document will hold monitor of which field in reminiscence is related to every export.

These containers in reminiscence gained’t get their values but. It’s solely after analysis that their precise values will probably be stuffed in. There may be one caveat to this rule: any exported operate declarations are initialized throughout this section. This makes issues simpler for analysis.

To instantiate the module graph, the engine will do what’s referred to as a depth first post-order traversal. This implies it’ll go all the way down to the underside of the graph — to the dependencies on the backside that don’t depend upon the rest — and arrange their exports.

A column of empty memory in the middle. Module environment records for the count and display modules are wired up to boxes in memory.

The engine finishes wiring up all the exports beneath a module — all the exports that the module relies on. Then it comes again up a stage to wire up the imports from that module.

Word that each the export and the import level to the identical location in reminiscence. Wiring up the exports first ensures that all the imports might be linked to matching exports.

Same diagram as above, but with the module environment record for main.js now having its imports linked up to the exports from the other two modules.

That is completely different from CommonJS modules. In CommonJS, your complete export object is copied on export. Because of this any values (like numbers) which might be exported are copies.

Because of this if the exporting module adjustments that worth later, the importing module doesn’t see that change.

Memory in the middle with an exporting common JS module pointing to one memory location, then the value being copied to another and the importing JS module pointing to the new location

In distinction, ES modules use one thing referred to as stay bindings. Each modules level to the identical location in reminiscence. Because of this when the exporting module adjustments a price, that change will present up within the importing module.

Modules that export values can change these values at any time, however importing modules can not change the values of their imports. That being mentioned, if a module imports an object, it will possibly change property values which might be on that object.

The exporting module changing the value in memory. The importing module also tries but fails.

The explanation to have stay bindings like that is then you possibly can wire up all the modules with out working any code. This helps with analysis when you have got cyclic dependencies, as I’ll clarify beneath.

So on the finish of this step, we’ve got all the cases and the reminiscence places for the exported/imported variables wired up.

Now we will begin evaluating the code and filling in these reminiscence places with their values.


The ultimate step is filling in these containers in reminiscence. The JS engine does this by executing the top-level code — the code that’s exterior of capabilities.

In addition to simply filling in these containers in reminiscence, evaluating the code may also set off negative effects. For instance, a module may make a name to a server.

A module will code outside of functions, labeled top level code

Due to the potential for negative effects, you solely wish to consider the module as soon as. Versus the linking that occurs in instantiation, which might be executed a number of instances with precisely the identical end result, analysis can have completely different outcomes relying on what number of instances you do it.

That is one purpose to have the module map. The module map caches the module by canonical URL so that there’s just one module document for every module. That ensures every module is simply executed as soon as. Simply as with instantiation, that is executed as a depth first post-order traversal.

What about these cycles that we talked about earlier than?

In a cyclic dependency, you find yourself having a loop within the graph. Often, it is a lengthy loop. However to elucidate the issue, I’m going to make use of a contrived instance with a brief loop.

A complex module graph with a 4 module cycle on the left. A simple 2 module cycle on the right.

Let’s have a look at how this might work with CommonJS modules. First, the primary module would execute as much as the require assertion. Then it could go to load the counter module.

A commonJS module, with a variable being exported from main.js after a require statement to counter.js, which depends on that import

The counter module would then attempt to entry message from the export object. However since this hasn’t been evaluated in the primary module but, it will return undefined. The JS engine will allocate area in reminiscence for the native variable and set the worth to undefined.

Memory in the middle with no connection between main.js and memory, but an importing link from counter.js to a memory location which has undefined

Analysis continues all the way down to the tip of the counter module’s prime stage code. We wish to see whether or not we’ll get the right worth for message finally (after essential.js is evaluated), so we arrange a timeout. Then analysis resumes on essential.js.

counter.js returning control to main.js, which finishes evaluating

The message variable will probably be initialized and added to reminiscence. However since there’s no connection between the 2, it’ll keep undefined within the required module.

main.js getting its export connection to memory and filling in the correct value, but counter.js still pointing to the other memory location with undefined in it

If the export have been dealt with utilizing stay bindings, the counter module would see the right worth finally. By the point the timeout runs, essential.js’s analysis would have accomplished and stuffed within the worth.

Supporting these cycles is a giant rationale behind the design of ES modules. It’s this three-phase design that makes them potential.

What’s the standing of ES modules?

With the discharge of Firefox 60 in early Might, all main browsers will help ES modules by default. Node can be including help, with a working group devoted to determining compatibility points between CommonJS and ES modules.

Because of this you’ll be capable to use the script tag with kind=module, and use imports and exports. Nonetheless, extra module options are but to return. The dynamic import proposal is at Stage 3 within the specification course of, as is import.meta which is able to assist help Node.js use instances, and the module resolution proposal will even assist clean over variations between browsers and Node.js. So you possibly can anticipate working with modules to get even higher sooner or later.


Thanks to everybody who gave suggestions on this submit, or whose writing or discussions knowledgeable it, together with Axel Rauschmayer, Bradley Farias, Dave Herman, Domenic Denicola, Havi Hoffman, Jason Weathersby, JF Bastien, Jon Coppeard, Luke Wagner, Myles Borins, Until Schneidereit, Tobias Koppers, and Yehuda Katz, in addition to the members of the WebAssembly neighborhood group, the Node modules working group, and TC39.

Lin works in Superior Improvement at Mozilla, with a concentrate on Rust and WebAssembly.

More articles by Lin Clark…

Source Link

What's Your Reaction?
In Love
Not Sure
View Comments (0)

Leave a Reply

Your email address will not be published.

2022 Blinking Robots.
WordPress by Doejo

Scroll To Top