Analysis – commonJS&AMD & CMD

To outline the three differences:

Historical assembly line:

CommonJS —> AMD —> CMD

Thing in common:

  1. Are the use of string naming, so that the module scope only exists in the current module scope, to solve the problem of namespace, and follow the concept of a module represents a file, a JS system to “split” into multiple modules, modular system.

  2. AMD and CMD both pay homage to CommonJS and have CommonJS in them.

Difference:

  1. CommonJS initially tried to solve this problem by putting all the code on the server side into a single file, which resulted in a complex and bloated file. The browser loaded the JS file and jammed it. Global scope pollution and other problems, and came into being the concept of modular development. And the way it loads modules is synchronous, requiring code to be executed in a “load first, pause, then execute” order, so the network speed is limited.

  2. The AMD specification, while continuing the CommonJS concept of modular development, differs in that AMD follows the asynchronous loading module specification. The method of loading dependent modules is dependency preloading, that is, loading the required dependent modules first, and then executing the callback function, which greatly improves the efficiency.

  3. CMD specification, is by the domestic front-end god, Yu Bo, wrote a JS library – sea-.js, in the process of pushing, put forward a new specification based on CommonJS -CMD. The specification is similar to AMD and is written similarly. But the difference is that CMD follows the philosophy of relying on postpositions. That is, AMD loads all modules required by the module at one time and then executes the callback. The CMD is loaded on demand, that is, the corresponding module is loaded only when it is needed.

  4. Although AMD and CMD stand for requireJS and seaJS respectively, it should be noted that the first two are specifications and the last two are libraries, just module loaders.

1. CommonJS

Introduction: CommonJS, originally called SeverJS, later changed to CommonJS. This defines the specification of the server side module, remember, just the specification, which is popularized by Node (for the server side).

CommonJS provides a standard library (and eventually a specification) for modular JS development by defining apis for common applications that are compatible with different JS interpreters and host environments.

The goal is to provide a standard library that is analogous to Python, Java…

The main function is to define apis for specific objects, provide module.exports to export modules, require to import modules.

On behalf of:

NodeJS

Background:

Due to the limitations of early JS, the project accumulated, will be all code written into a file, easy to lead to the file is too large, loading too long, the browser is easy to card death, the key before the network speed and now vary greatly;

Not only that, but it also leads to the problem of scoped pollution (global pollution), forming namespaces. It is also not easy to interact with other projects’ systems (mainly browser-based applications).

As a result, modular development is inevitable, hence Common Js.

However, in 2009, an American created a Language based onJS, and the specification follows the popular and practical CommonJS specification, which pushed CommonJS to the climax, benefiting from the popularity of Node JS.

The main API:

1. module.exports ------ used to export the current module.2. require-- -- -- -- -- - this onerequireAnd AMDrequireDifferent.Copy the code

Advantages:

  1. Modularization, follow the principle of one module one file.

  2. The coupling is low and does not easily lead to contamination of global variables, because each module is equivalent to a closure that exists in its own namespace module’s scope. Therefore, internal private variables cannot be accessed externally.

  3. Single principle. Each module contains a self-executing function, and this provides two variables, an exports and a module, but the final output value is in module.exports.

  4. Identical, both use module.exorts or exports to export modules and then use the require() function to import modules (synchronization).

  5. Highly reusable, you can import a function between other people’s projects. Module. Exports or exports.

Disadvantages:

  1. Incompatible with browsers and cannot be used directly. Global, Module, require, and exports are not supported by browsers.

  2. Because CommonJS was originally applied on the server, and it was loaded synchronously, notice that it was loaded synchronously. Therefore, when coding, modules must be loaded first, and then executed, which will affect the execution time of the following code, resulting in blocking.

2. AMD

Background:

Because of the CommonJS specification, and because of NodeJS’s popularity, JS has a lot of shine on the server side and can do a lot of things other languages can do (Java, Python, etc.).

However, this is only the server side, after all, the client side does not directly support the CommonJS specification (see CommonJS introduction for details). And JS host is to the browser as the main head, which can not?

So, The Times made hero, AMD hero came.

Introduction:

The appearance of AMD mainly solves the problem of modular development of clients, and AMD continues the spirit of CommonJS specification, which is modular development and defines the module scope in the namespace to prevent the pollution of global variables.

But it’s also very different.

AMD: “Because I load modules asynchronously!! “

On behalf of:

require.JS

What problem was solved?

AMD defines a set of asynchronous loading standards that JS modules rely on to solve the problem of synchronous loading.

The main API:

  1. (Export) Define module:
	// There are many ways, but this method is also recommended by the official website:
	// Anonymous definition module:Define ([dependent1, rely on2.. ] , () = > {// After the dependency is loaded, execute the callback function...
	})
Copy the code
  1. Import module:
	// This is a bit different from commonJS require,AMD requires 2 arguments and has a callback.
	constVariable =require([module name],function() {
		// Execute the callback operation...
	})
Copy the code

Advantages:

  1. Modularity, following the CommonJS concept, a file is a module.

  2. Low coupling, because the namespace is scoped effectively, all external access to private variables is not possible.

  3. Uniformity, both defined by the global variable define function (export) module, global variable require function import module.

  4. High efficiency, since the module is loaded asynchronously, the loading method is “the same” as CommonJS, which uses require to load modules. The syntax is: require([dependency 1, dependency 2…]); , the function () {}). That is, all dependencies must be loaded before the callback function is executed, and the arguments to the callback function must be in the exact order of the modules in the array. The callback function is filled with logic code that depends on those modules. Those that are not related to these dependencies can be written outside, and when the dependencies are loaded, they won’t affect the rest of the code. Asynchronous loading does not affect subsequent code execution.

Disadvantages:

  1. Relationship predisposition, which I personally call “dependency predisposition”. Perhaps because of the design philosophy, ALTHOUGH AMD is asynchronous load module, but it is a one-time load of the corresponding module, and then execute the callback. It doesn’t make any sense, though, that I can’t fight a boss until I have all the equipment I need. But from a human perspective, it’s not so good, so I want to load something when I want to load it, and when I don’t want to load it, you don’t move. See the advantages of CMD below.

  2. There are several ways to write the definition module (although there is a recommendation on the official website – define module). But this is a beginner to me, will produce a lot of doubts, but also wasted a lot of time comparison.

3. CMD

Introduction:

CMD stands for Common Module Definition.

Background:

Thanks to AMD, modular development is no longer unique to the server, but is now possible in browsers. But bring convenience at the same time, also have the place that needs to criticize naturally. For example, as mentioned earlier, AMD is designed to follow relational preloading, that is, dependency preloading specifications, to load modules. This leads to a problem. It’s not humanized enough to feel on demand

Therefore, domestic cattle on the basis of AMD, a seaJS, at the same time in the promotion process, derived a new specification -CMD. CMD is greedy and wants to make a general specification. Grammatically, it’s not. SeaJS, with its single responsibility and strict adherence to the idea that a module is a file, is closer to CommonJS (check which one you want).

SeaJS, based on AMD, has similarities, but only differences.

CMD, in particular, embodies the idea of loading on demand. Can do with synchronous writing, to achieve the effect of loading on demand. See the API introduction below.

The main API:

  1. Define. This global variable is a function that defines modules with 3 arguments: require, exports, module. It is the same as AMD, define function can bring back the call function, are able to achieve the dependency of the front. Exports of exports, modules, modules, modules, modules, modules, etc., exports of exports, modules, modules, etc. (Note that all other methods are commented out before using any of them!!)
	// 1. require:
	// We can load the required dependencies when defining:
	define(function(require,exports,module) {
		// Load modules on demand:
		let a = require(./b)
	})
	
	// 2. exports
	// exports is an object that provides module interfaces:
	define(function(require,exports,module) {
		// Load modules on demand:
		let a = require(./b)
		let a_obj = {
			a: a
		}
		// Export:
		/ / method 01:
		exports.a = a;
		// Export a function.

		/ / method 02:
		// Use return directly instead of exports
		return {
			a: a
		}
	
		// exports cannot be exported directly because module.exports does not change module values: // exports cannot be exported directly because module.exports does not change module values: // exports cannot be exported because module.exports does not change module values.
		/ / error:
		exports = {
			a: a
		}
		/ / the correct:
		module.exports = {
			a: a
		}
	// 3. module:
	moduleExports must be executed synchronously and cannot be executed in a callback:// For example, timer:
	// Incorrect usage
    setTimeout(function() {
      module.exports = { a: "hello" };
    }, 0);

})
Copy the code

Advantages:

  1. It relies on the rear, in line with the design concept of loading on demand, and also in line with the first screen solution of SPA applications.
  2. Simple responsibilities and simple understanding.

Disadvantages:

  1. If you have learned require.js, go to 㛑sea.js and change the array to require.

If you think WHAT I said is wrong, please scan the QR code to tell me, thank you very much!!