Modularity is very important in a project, a complex project must have many similar functional modules, if you need to rewrite the module every time will be time-consuming and energy consuming. But reference others to write the premise of the module is to have a unified “open posture”, if everyone has their own way of writing, then certainly will be chaotic, the following introduction of several JS modular norms.

Modular process 1: Script tags

This is the original way JavaScript files are loaded. If you look at each file as a module, its interface is usually exposed to the global scope, defined in the Window object. The interface calls of different modules are in the same scope. The concept of namespaces is used to organize the interfaces of these modules.

Disadvantages: 1. Pollution of global scope; 2. Developers must solve the dependency between modules and code base subjectively; 3. Files can only be loaded according to script label writing order; 4

Xie Xiaofei blog special anti crawler link, want to see the latest front-end blog please click here

Modular process 2: CommonJS specification

The core idea of the specification is to allow modules to synchronously load other modules they depend on through the require method, and then export interfaces that need to be exposed through exports or module.exports.

require("module"); require(".. /file.js"); exports.doStuff = function() {}; module.exports = someValue;Copy the code

Advantages: 1. Simple and easy to use 2. Easy to reuse server-side modules

Disadvantages: 1. Synchronous module loading mode is not suitable for the browser environment, synchronous means blocking loading, browser resources are loaded asynchronously. 2

Module. exports and exports

// app.js
var circle = require('./circle');
console.log(circle.area(4));
// circle.js
exports.area = function(r) {
  return r * r * Math.PI;
}Copy the code

// app.js
var area = require('./area');
console.log(area(4));
// area.js
module.exports = function(r) {
  return r * r * Math.PI;
}Copy the code

// app.js
var area = require('./area');
console.log(area(4));
// area.js
exports = function(r) {
  return r * r * Math.PI;
}Copy the code

Modular process 3: AMD specification

The Asynchronous Module Definition (AMD) specification was created because browser modules cannot be loaded synchronously, which affects subsequent Module loading and execution. The AMD standard defines two apis: require([module], callback); 2, define(ID, [depends], callback); The require interface is used to load a series of modules, and the DEFINE interface is used to define and expose a module.

Example:

define("module", ["dep1", "dep2"], function(d1, d2) {
  return someExportedValue;
});
require(["module", "../file"], function(module, file) { /* ... */ });
Copy the code

Advantages: 1. Asynchronously loading modules in the browser environment. 2

Disadvantages: 1. Increased development cost, difficult to read and write the code, the semantics of module definition are not smooth 2

Modular process 4: CMD specification

define(function(require, exports, module) {
  var $ = require('jquery');
  var Spinning = require('./spinning');
  exports.doSomething = ...
  module.exports = ...
})Copy the code

The difference between AMD and CMD

AMD is similar to CMD, but there are some subtle differences. Let’s take a look at the differences: 1. For dependent modules, AMD executes early, while CMD executes late. 2. AMD advocates relying on the front; CMD advocates relying on proximity, requiring only when a module is needed. Look at the code:

// AMD define(['./a', './b'], function(a, b) {// AMD define(['./a', '. }); // CMD define(function(require, exports, Module) {var a = require('./a') a.dosomething (); var b = require('./b');  });Copy the code

3, AMD API default is a when multiple use, CMD API strictly distinguished, praise single responsibility.

Xie Xiaofei blog special anti crawler link, want to see the latest front-end blog please click here

Modularization Process 5: ES6 modularization

The EcmaScript6 standard adds a JavaScript language level module architecture definition. The ES6 module is designed to be as static as possible, so that the dependencies of the module, as well as the input and output variables, can be determined at compile time. Both CommonJS and AMD modules can only determine these things at runtime. In ES6, we use the export keyword to export modules and the import keyword to reference modules. It should be noted that the ES6 standard is not directly related to the current standard, and few JS engines can support it directly. So what Babel is doing is essentially translating the unsupported import into the currently supported require. Although there is not much difference between using import and require today (essentially the same thing), the use of the import keyword is still highly recommended, because once the JS engine is able to parse the IMPORT keyword in ES6, the whole implementation will change considerably. If you start using the import keyword now, future code changes will be minimal.

Example:

import "jquery";
export function doStuff() {}
module "localModule" {}
Copy the code

Advantages: 1. Easy static analysis 2. Future-oriented EcmaScript standard

Advantages: 1. The standard is not implemented in native browsers. 2

To admire the