Today describes how to use modules in a standardized manner.
(up to the above)
Specification of Modules
First think about why the module is important?
Because of the module, we can more easily use other people's code, want what function, loaded what module.
However, this has a prerequisite, that is, we must write the same way the module, otherwise you have your writing, I have my writing, it is not a mess of the set! This is even more important given the fact that JavaScript modules are not yet officially regulated.
At present, there are two kinds of standard JavaScript modules: Commonjs and AMD. I mainly introduce AMD, but first start with Commonjs.
Eight, Commonjs
2009, US programmer Ryan Dahl created the Node.js project, which uses JavaScript language for server-side programming.
This sign "JavaScript modular Programming" is officially born. Because frankly speaking, in the browser environment, no module is not particularly big problem, after all, the complexity of the Web page program is limited, but on the server side, must have a module, and the operating system and other applications to interact, or simply can not program.
The modular system of Node.js is realized by reference to COMMONJS specification. In Commonjs, there is a global method require (), which is used to load modules. Assuming there is a mathematical module math.js, you can load it like this.
var math = require ("math");
You can then invoke the method provided by the module:
var math = require ("math");
Math.add (2,3); 5
Because this series is mainly for browser programming, does not involve node.js, so to Commonjs do not do more introduction. As long as we know here, require () is used to load the module.
Nine, browser environment
With the server-side module, it's natural for everyone to want the client module. And it's best to be compatible, a module that doesn't have to be modified, can run on both the server and the browser.
However, due to a significant limitation, the COMMONJS specification does not apply to the browser environment. or the previous section of the code, if run in the browser, there will be a big problem, you can see it?
var math = require ("math");
Math.add (2, 3);
The second line, Math.add (2, 3), runs after the first line require ("math"), so the math.js load must be completed. In other words, if the load time is very long, the entire application will stop there and so on.
This is not a problem for the server side, because all the modules are stored on the local hard drive, can be completed synchronously, waiting time is the hard disk read time. However, for browsers, this is a big problem, because the module is placed on the server side, waiting time depends on the speed of the network, may have to wait for a long time, the browser in the state of "suspended animation."
Therefore, the browser-side module cannot be "Synchronous load" (synchronous) and can only be used for "asynchronous loading" (asynchronous). This is the background of the birth of AMD specification.
Ten, AMD
AMD is the abbreviation for "Asynchronous module definition", meaning "asynchronous modular definition". It loads the module asynchronously, and the load of the module does not affect the operation of the statement behind it. All statements that rely on this module are defined in a callback function, and the callback function will not run until the load is complete.
AMD also uses the Require () statement to load modules, but unlike COMMONJS, it requires two parameters:
Require ([module], callback);
The first parameter [module], which is an array whose members are the modules to be loaded, and the second parameter callback, is the callback function after the success of the load. If you rewrite the previous code into AMD, this is the following:
Require (["math"], function (math) {
Math.add (2, 3);
});
Math.add () is not synchronized with the math module, and the browser does not feign death. So it's clear that AMD is better suited to the browser environment.
Currently, there are two JavaScript libraries that implement AMD specifications: Require.js and Curl.js. The third part of this series will introduce require.js to further explain the usage of AMD and how to put modular programming into combat.