A brief discussion on several specifications of JS front-end modularization

Preface

There is a scenario where the client runs for a long time, but the legal department and the data department need to collect some information from users. After this information is collected, it needs to be processed accordingly and then reported to the server. The client provides a pure js execution engine and does not require a WebView container. iOS has the mature JavaScriptCore, and Android can use the V8 engine. Such an engine is equipped with an SDK that accesses the basic capabilities and data computing capabilities of Native. It can be seen as a castrated version of the Hybrid SDK with additional data processing capabilities.

Is the problem over? Two libraries are also needed when processing logic: cheerio and sql. Because they are all Node projects, they cannot be directly executed in a pure js environment. So the demand has changed——packaging the Node project into the UMD specification. This way it can run in a pure JS environment. The following article will analyze the various specifications. In fact, these are just a few specifications for front-end modularization.

The value of front-end modular development

With the rapid development of the Internet, front-end development is becoming more and more complex. This article will start from the problems encountered in actual projects, describe what problems modularization can solve, and use Sea.js as an example to explain how to perform modular development of the front end.

Annoying naming conflicts

We start with a simple habit. When I work on a project, I often abstract some common, low-level functions and separate them into separate functions, such as

function each(arr) {
// Implementation code} 

function log(str) {
// Implementation code}

I extracted these codes and unified them into util.js, and imported the file where needed. It looked great, and my colleagues in the team were very grateful to me for providing such a convenient toolkit.

Until the team grew bigger and people started to complain

Xiao Yang: I defined an each method to iterate over objects, but there is already an each method in util.js. I need to change the method name every time, so I can only call it the eachObject method. <br>Zhang San: I defined a log method, but there is a problem with Wang Wu’s code. Who can take a look?

There were more and more complaints, and finally we referred to the Java approach and introduced namespaces to solve the problem. So the util.js code becomes

var org = {};

org.Utils = {};

org.Utils.each = function (arr) {

// Implementation code};

org.Utils.log = function (str) {

// Implementation code};

The code may look low-level, but in fact, the evangelist of namespace in the front-end field is Yahoo! YUI2 project, look at the code below, is Yahoo! An open source project

if (org.cometd.Utils.isString(response)) {

return org.cometd.JSON.fromJSON(response);

}

if (org.cometd.Utils.isArray(response)) {

return response;

}

Although namespaces can greatly solve the conflict problem, every time a method is called, a lot of namespace-related code needs to be written, which deprives coding of its fun.

Another way to do this is with a self-executing function.

(function (args) {

//...

})(this);

Cumbersome file dependencies

Continuing with the above scenario, in many cases it is necessary to develop common components at the UI layer so that the project team does not need to reinvent the wheel. One of the most frequently used components is dialog.js

<script src="util.js"></script>

<script src="dialog.js"></script>

<script>

org.Dialog.init({ /* pass in configuration */ });

</script>

Although the public group will write usage documents and send emails to inform all members (project address, usage, etc.), some people still ask "why is there a problem with dialog.js?" The final result of the investigation is basically that util.js is not introduced

<script src="dialog.js"></script>

<script>

org.Dialog.init({ /* pass in configuration */ });

</script>

Naming conflicts and file dependencies are two classic problems in front-end development. After continuous thinking and research by developers, modular solutions have been born. Take CMD as an example.

define(function(require, exports) {

exports.each = function (array) {

// ...

};

exports.log = function(message) {

// ...

};

});

Through exports, you can provide an interface to the outside world. The dialog.js code becomes

define(function(require, exports) {

var util = require('./util.js')

  

exports.init = function () {

// ...

};

});

When using it, you can obtain the interface exposed by exports in util.js through require('./util.js'). The require method has solutions in many other languages: include,

The benefits of modularity

1. Module version management: Through configurations such as aliases and with build tools, module version management can be easily achieved

2. Improve maintainability: Modularization can achieve a single responsibility for each file, which is very beneficial to code maintenance.

3. Front-end performance optimization: For front-end development, asynchronous loading of modules is very beneficial to page performance.

4. Share modules across environments: The CMD module definition specification is very similar to the NodeJS module specification, so through the NodeJS version of Sea.JS, you can easily share modules across servers and browsers.

CommonJS Specification

CommonJS is a specification for server-side modules. NodeJS adopts this specification. CommonJS loads modules synchronously, so subsequent operations can only be performed after loading is complete.

Due to the characteristics of the server, the loaded module files are generally stored on the local hard disk, so they are loaded quickly without considering asynchronous methods.

In the CommonJS modular specification, each file is a module with independent scope, variables, and methods, which is invisible to other modules. The CommonJS specification stipulates that within each module, the module variable represents the current module. It is an object, and its exports attribute is the external interface. To load a module, you actually load the module.exports attribute of the module. The require method is used to load the module.

// Person.js

function Person () {

this.eat = function () {

console.log('eat something')

}

  

this.sleep = function () {

console.log('sleep')

}

}

  

var person = new Person();

exports.person = person;

exports.name = name;

  

// index.js

let person = require('./Person').person;

person.eat()

Differences between CommonJS and ES6 modules

1. CommonJS modules output copies of values, while ES6 modules output references to values

2. CommonJS modules are loaded at runtime, while ES6 modules are output interfaces at compile time

CommonJS modules export an object (module.exports property), which is generated only after the script is run.

The module mechanism of ES6 is that when the JS engine performs static analysis on the script, it will generate a read-only reference when it encounters the module loading command import. When the script is actually executed, it will use this read-only reference to get the value from the loaded module.

AMD Specifications

AMD (Asynchronous Module Definition) is the standardized output of module definition in the process of promoting Require.JS. AMD advocates front-end dependency. It is a superset of the CommonJS modularization specification that works on browsers. Its feature is asynchronous, which takes advantage of the browser's concurrency capabilities to reduce module dependency blocking.

AMD API

define(id?, dependencies?, factory);

id is the name of the module and is an optional parameter. dependencies specifies the list of modules that the module depends on. It is an array and an optional parameter. The output of each dependent module will be passed into the factory as a parameter in turn.

require([module], callback)

The AMD specification allows the output module to be compatible with the CommonJS specification. In this case, the define method is as follows:

define(['module1', 'module2'], function(module1, module2) {

function foo () {

// ...

}

return { foo: foo };

});


define(function(require, exports, module) {

var requestedModule1 = require('./module1')

var requestedModule2 = require('./module2')

function foo () {

// ...

}

return { foo: foo };

});

Advantages: Suitable for loading modules in a browser environment, and can load multiple modules in parallel

Disadvantages: Increases development costs, cannot be loaded on demand, but loads all dependencies in advance

CMD Specification

CMD is the standardized output of module definition in the process of Sea.JS promotion. CMD advocates relying on proximity.

The CMD specification is kept as simple as possible and is compatible with the Module in the CommonJS specification. Modules written using the CMD specification can run in NodeJS.

CMD module definition specification

In CMD, if the require dependency description uses an array, it is loaded asynchronously. If a single dependency uses a string, it is loaded synchronously.

AMD is the standardized output of module definition during the promotion of RequireJS, and CMD is widely recognized during the promotion of SeaJS. SeaJS comes from Ant Financial YuBo in China. The difference between the two, Yu Bo said in 2012:

RequireJS and SeaJS are both very good module loaders. The differences between them are as follows:

• There is a difference in positioning between the two. RequireJS wants to be a module loader for browsers, and also wants to be a module loader for environments such as Rhino/Node. SeaJS focuses on the web browser side, and can easily run on the Node server side through Node extensions
• There are differences in the standards followed by the two. RequireJS follows the AMD (Asynchronous Module Definition) specification, and SeaJS follows the CMD (Common Module Definition) specification. The difference in specifications leads to the difference in APIs. SeaJS is more concise and elegant, and closer to CommonJS Modules/1.1 and Node Modules specifications.
• There are differences in the community concepts of the two. RequireJS is trying to get third-party libraries to modify themselves to support RequireJS, but only a few communities have adopted it. SeaJS does not force anything, but adopts an independent packaging approach to "embrace all rivers and seas", and currently has a relatively mature packaging strategy.
• There is a difference in code quality between the two. RequireJS has no obvious bugs, and SeaJS has no obvious bugs.
• There are differences in the support for debugging etc. between the two. SeaJS can realize the automatic mapping function in Fiddler through plug-ins, and can also realize automatic combo and other functions, which is very convenient. RequireJS has no support for this.
• The plug-in mechanisms of the two are different. RequireJS takes the form of reserving interfaces in the source code, where code written for the plug-in is left. The plug-in mechanism adopted by SeaJS is consistent with the way Node opens itself up, allowing plug-in developers to directly access or modify it, which is very flexible and can implement various types of plug-ins.

UMD Specification

UMD (Universal Module Definition) was created with the trend of big front-end, hoping to provide a cross-platform solution for front-end and back-end (supporting AMD, CMD, and CommonJS module methods).

Implementation principle:

1. First determine whether the Node.js module format is supported (whether exports exist). If so, use the Node.js module format

2. Determine whether the AMD module format is supported (define exists). If it exists, use the AMD module format.

3. If the first two do not exist, make the module public to the global (window or global)

// if the module has no dependencies, the above pattern can be simplified to

(function (root, factory) {

if (typeof define === 'function' && define.amd) {

// AMD. Register as an anonymous module.

define([], factory);

} else if (typeof exports === 'object') {

// Node. Does not work with strict CommonJS, but

// only CommonJS-like environments that support module.exports,

// like Node.

module.exports = factory();

} else {

// Browser globals (root is window)

root.returnExports = factory();

}

}(this, function () {

  

// Just return a value to define the module export.

// This example returns an object, but the module

// can return a function as the exported value.

return {};

}));

Some people may ask, why is AMD written in the above judgment, but why is there no CMD? Because the front-end building tool webpack does not recognize the CMD specification, using CMD requires referencing tools, such as Sea.JS

To be honest, if you want to judge CMD, how do you write the UMD code?

(function(root, factory) {

if (typeof define === 'function' && define.amd) {

// AMD. Register as an anonymous module.

define([], factory);

} else if (typeof define === 'function' && define.cmd) {

//CMD

define(function(require, exports, module) {

module.exports = factory()

})

} else if (typeof exports === 'object') {

// Node. Does not work with strict CommonJS, but

// only CommonJS-like environments that support module.exports,

// like Node.

module.exports = factory();

} else {

// Browser globals (root is window)

root.returnExports = factory();

}

}(this, function() {

// Just return a value to define the module export.

// This example returns an object, but the module

// can return a function as the exported value.

return {};

}))

Back to the topic

How Cheerio is packaged into a normal JS execution environment.

With the help of webpack, you can easily generate a umd standard package.

module.exports = {

entry: './src/cheerio.js',

output: {

filename: 'cheerio.js',

// export to AMD, CommonJS, or window

libraryTarget: 'umd',

// the name exported to window

library: 'cheerio',

globalObject: 'this'

}

}

Summarize

The underlying rendering kernel of mobile phones (whether iOS or Android) is similar to the Chrome v8 engine. When the v8 engine executes JS code, it first compiles the code into machine code in memory using the MacroAssembler assembly library and then sends it to the CPU for execution. It does not parse and execute line by line like other JS engines. Therefore, the statically loaded ES6 module specification is more helpful for the V8 engine to realize its value. The CommonJS, AMD, and CMD specifications loaded at runtime are not conducive to the V8 engine to perform well.

In NodeJS development projects, Node9 already supports ES6 syntax and can fully use the ES6 module specification. The birth of NodeJS is based on Google's v8 engine. There is no reason not to consider the maximum potential of v8.

In browser JS development projects, it is definitely not appropriate to use the CommonJS specification because it takes time to load files from the server. Whether to use the native ES module specification or Sea.js depends on the specific scenario. If you want the page to load as quickly as possible, Sea.js is suitable; if it is a single-page website, it is suitable to use the native ES6 module specification. Another point is that Chrome is not the only browser. For browsers that do not use the v8 engine, the advantage of using the ES6 native specification is reduced a little.

The above is a brief discussion of the details of several specifications for JS front-end modularization. For more information about JS front-end modularization, please pay attention to other related articles on 123WORDPRESS.COM!