Commonjs--<javascript:not just for browsers any more!>

The CommonJS (http://www.commonjs.org/) specification provides a good vision for JavaScript-hopefully JavaScript will run anywhere.
I. JavaScript changes and Status quo Tools (Browser-compatible)--components (function Modules)--Framework (functional module organization)--Application (Business module organization)

In real-world applications, the performance capabilities of JavaScript depend on the level of API support in the hosting environment. In the Web1.0 era, only the DOM, BOM and other basic support. With the advancement of Web2.0, HTML5 emerged, bringing Web pages into the Web application era, with more and more powerful APIs in the browser for JavaScript calls. However, in the development of the web, there are more standard APIs in the browser, these processes occur in the front end, the specification of the back-end JavaScript is far behind. For JavaScript itself, its specifications remain weak, with the following drawbacks:

(1) No module system
(2) Fewer standard libraries: ECMAScript defines only a subset of core libraries, but there are no standard APIs for common requirements such as file systems, I/O flows, and so on.
(3) There is no standard interface: In JavaScript, there is little definition of a standard unified interface such as a Web server or a database.
(4) Lack of package management system: This results in a basic lack of automatic loading and installation dependencies in JavaScript applications.
Ii. The starting point of Commonjs

The COMMONJS specification is primarily designed to compensate for current JavaScript's lack of standards, and has achieved the basic ability to develop large applications like Python, Ruby and Java, rather than staying in the small scripting phase.

(1) server-side JavaScript application
(2) command-line tools
(3) Desktop GUI application
(4) Hybrid applications
three, COMMONJS module specification

COMMONJS building block export and introduction mechanism makes the user completely unnecessary to consider the variable pollution.

The definition of COMMONJS module is divided into 3 parts: module reference, module definition and module identification.

1. Module definition

In the COMMONJS specification, the exports object is used to export the method or variable of the current module, and it is the only exported export.
In the module, there is a module object that represents the module itself, and exports is the property of the modules. In Nodejs, a file is a module that can be exported as an attribute on a method mount exports object.

/* 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, the Require () method is used to accept the module identity, which introduces 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 Identification

The module identifier is actually a parameter passed to the Require () method, which must be a string that is named after the small hump, or with a "./", ". /"Relative path at the beginning, or absolute path. It can have no filename suffix. js.

Iv. NPM, NodeJS, Commonjs relations

Nodejs has implemented a very easy-to-use module system with reference to COMMONJS's modules specification, and NPM's perfect support for the packages specification makes node applications less effective in the development process.

Node can appear in a more mature posture, without the influence of the commonjs norm. On the server side, COMMONJS can enter the project code of each company in an unusual gesture, without the excellent performance of node.

Reprint Please specify source: http://blog.csdn.net/ligang2585116

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced. Reprint please indicate source: http://blog.csdn.net/ligang2585116!

Commonjs--<javascript:not just for browsers any more!>