background

  1. Js takes on more and more heavy tasks. Other languages like Java have modular technologies such as packages.
  2. Js implements modularity by executing functions immediately
    var myModule = (function(){
        var var1 = 1;
        var var2 = 2;
        function fn1(){}function fn2(){}return {
            fn1: fn1,
            fn2: fn2 }; }) ();Copy the code

Currently, there are two common JavaScript module specifications: CommonJS and AMD

  1. CommonJS is a modular solution to the server side born with Node JS. Exports/module. Exports/module. Exports/module.

  1. Define modules. According to the CommonJS specification, a single file is a module. Each module is a separate scope, that is, variables defined inside the module cannot be read by other modules unless they are defined as properties of the Global object

  2. Module output: The module has only one exit, the module.exports object, into which we need to put the content the module wants to export

  3. Load modules: Load modules using the require method, which reads a file and executes, returning the module.exports object inside the file

Exports and Module. exports

  1. Module.exports starts with an empty object {}
  2. Exports is a reference to module.exports
  3. Require () returns module.exports instead of exports

Awkward Browser

If you look closely at the code above, you’ll see that require is synchronous. The module system needs to read the contents of the module file synchronously and compile the execution to get the module interface.

This is easy and natural to implement on the server side, however, there are many problems to implement on the browser side.

On the browser side, the best and easiest way to load JavaScript is to insert script tags in document. But script tags are inherently asynchronous, and traditional CommonJS modules don’t load properly in a browser environment.

One solution is to develop a server-side component that statically analyzes the module code and returns the module to the browser side with a list of its dependencies. This works fine, but requires additional components to be installed on the server and a series of underlying architectures to be adjusted as a result.

Another solution is to encapsulate module definitions with a standard set of templates, but there are disagreements about how modules should be defined and loaded:

AMD

AMD is an Asynchronous Module Definition. It is a specification for modular development on the browser side

Because it is not JavaScript native support, page development using AMD specification needs to use the corresponding library function, also known as RequireJS. In fact, AMD is the standardization of module definition of RequireJS in the promotion process

RequireJS addresses two main problems

Multiple JS files may have dependencies. The dependent file must be loaded to the browser earlier than the dependent file. When JS is loaded, the browser will stop rendering the page

CMD

CMD is the Common Module Definition, CMD specification is developed in China, just as AMD has a requireJS, CMD has a browser implementation SeaJS, SeaJS to solve the same problem as requireJS, There are just differences in how modules are defined and when modules are loaded (run, parse, so to speak)

The syntax sea-.js advocates one file per module, following a uniform writing style

AMD is different from CMD

There’s a bunch of articles on the Internet about the difference between the two, just to summarize it

The most obvious difference is the way dependencies are treated in module definition

AMD advocates dependency preloading. CMD advocates nearby dependency when defining a module, and requires only when a module is used. This distinction has its advantages and disadvantages, but there is a gap in syntax

Final solution

In June 2015, ECMAScript2015, also known as ES6, was released. JavaScript finally implemented module functionality at the level of language standards, making it possible to determine module dependencies and input and output variables at compile time. Unlike CommonJS, AMD and the like, which need to be determined at run time (tools like FIS can only preprocess dependencies, which is essentially runtime resolution), it has become a common modular solution for browsers and servers.

In ES6, the import command can specify the interface exposed by the export command to load a module (the interface is not specified, and the export default is loaded by default). So modules are loaded at compile time, which is called compile-time loading or static loading.

As you can see, in CommonJS you import the entire module as an object and then get some property on that object.

As a result, the compile-time loading of ES6 will be much more efficient, as well as bring other benefits, such as the introduction of macros and type systems that can only be implemented by static analysis.

Unfortunately, browser and node.js support isn’t good at this point, and as of press time, only Chrome61+ and Safari10.1+ are partially supported.

However, you can use tools such as Babel with the associated plugin (see Babel Notes) to convert the ES5 syntax to node.js. If you want to run it in a browser, you can add the Babel configuration and add AMD define functions as an outer layer to the module file. Combine this with a loader such as RequireJS.

Features:

Load at compile time.