CommonJS -- <JavaScript: not just for browsers any more!>, Commonjsbrowsers
The CommonJS (http://www.commonjs.org/) specification creates a beautiful vision for JavaScript-hopefully JavaScript can run anywhere.
I. JavaScript changes and Status Quo tools (browser compatibility) --> components (functional modules) --> frameworks (functional module Organization) --> Applications (business module organization)
In practical applications, the performance of JavaScript depends on the degree of API support in the host environment. In the era of Web1.0, only basic support for DOM and BOM is supported. With the advancement of Web, HTML5 has emerged and brought Web pages into the Web application era. More and more powerful APIs have emerged in browsers for JavaScript calls. However, with the development of Web, more standard APIs are available in browsers, and these processes occur at the front end, but the backend JavaScript standards are far behind. For JavaScript itself, its specifications are still weak and have the following defects:
(1) No Module System
(2) fewer standard libraries: ECMAScript only defines some core libraries, but there is no standard API for common requirements such as file systems and I/O streams.
(3) No standard interface: In JavaScript, almost no standard unified interface, such as a Web server or database, has been defined.
(4) Lack of package management system: as a result, JavaScript applications do not have the ability to automatically load and install dependencies.
Ii. Starting Point of CommonJS
The CommonJS specification was proposed mainly to make up for the shortcomings that currently JavaScript does not have standards. It has reached the basic capabilities for developing large applications such as Python, Ruby, and Java, rather than staying in the small script stage.
(1) server-side JavaScript applications
(2) command line tool
(3) graphic desktop applications
(4) hybrid applications
Iii. CommonJS module specification
The Export and Import Mechanism of CommonJS build modules makes it unnecessary for users to consider variable pollution.
CommonJS defines modules in three parts: module reference, module definition, and module identification.
1. module definition
In the CommonJS specification, the exports object is used to export methods or variables of the current module, and it is the unique export exit.
In a module, there is a module object, which represents the module itself, and exports is the attribute of the module. In NodeJS, a file is a module that can be exported by attaching the exports object as an attribute.
/* math.js */exports.add = function(){var sum = 0, i = 0, args = argumetns, l = args.length;while(i < l){sum += args[i++];}return sum;};
2. Module reference
In the CommonJS specification, use the require () method to accept the module identifier, so as to introduce the API of a module to the current context.
/* program.js */var math = require('math');exports.increment = function(val){return math.add(val, 1);};
3. Module ID
The module identifier is actually a parameter passed to the require () method. It must be a string that matches the name of a small camper or ". /",".. or absolute path. It can have no file name suffix. js.
Iv. NPM, NodeJS, and CommonJS relationships
NodeJS draws on the CommonJS Modules specification to implement a very easy-to-use module system. NPM's perfect support for the Packages specification makes Node applications get twice the result with half the effort during development.
Node can appear in a more mature posture, without the impact of CommonJS specifications. On the server side, CommonJS can enter the project code of each company in an ordinary way, without the excellent performance of Node.
Please indicate the source of reprint: http://blog.csdn.net/ligang2585116
Copyright Disclaimer: This article is an original article by the blogger and cannot be reproduced without the permission of the blogger. Reprint please indicate the source: http://blog.csdn.net/ligang2585116!