Einführung in die JavaScript-Modulspezifikationen CommonJS, AMD und CMD

Der Inhalt dieses Artikels ist eine Einführung in die JavaScript-Modulspezifikationen CommonJS, AMD und CMD. Ich hoffe, dass er für Freunde hilfreich ist.

Dieser Artikel stammt aus dem Artikel „JS Modular Programming: CommonJS und AMD/CMD gründlich verstehen!“ Der größte Teil der Zusammenfassung des Artikels ist ein Auszug aus dem Originaltext. Ich habe mir nur Notizen gemacht, um das Studium zu erleichtern. Ich werde sie rechtzeitig hinzufügen, wenn ich neue Erfahrungen mache. Bei Verstößen wird der Kontakt gelöscht. Respekt an die Senioren!

Bevor ich anfange, antworten Sie mir: Warum sind Module wichtig?

Antwort: Aufgrund der Module können wir den Code anderer Leute bequemer verwenden und beliebige Module für alle gewünschten Funktionen laden. Allerdings gibt es dafür eine Voraussetzung, das heißt, jeder muss das Modul gleich schreiben, sonst hast du deine Art zu schreiben, und ich habe meine Art zu schreiben, wäre das nicht ein Durcheinander!

Daher wurden die folgenden drei Module standardisiert und dieser Artikel auch veröffentlicht. Lassen Sie mich im Voraus erklären: Die Implementierung der CommonJS-Spezifikation ist node.js, die Implementierung der AMD-Spezifikation (Asynchronous Module Definition) ist require.js und curl.js und die Implementierung der CMD-Spezifikation ist Sea. js.

Modulspezifikationen in JS (CommonJS, AMD, CMD), wenn Sie von js-Modularisierung gehört haben, dann sollten Sie von CommonJS oder AMD oder sogar CMD gehört haben. aber ich habe es mir eigentlich nur vorher angehört. Werfen wir nun einen Blick darauf, was diese Spezifikationen sind und was sie bewirken. Dieser Artikel enthält die Quellen dieser drei Spezifikationen und die Prinzipien der entsprechenden Produkte.

1. CommonJS-Spezifikation

Zuerst dachten alle, dass die offiziell definierte API nur browserbasierte Anwendungen erstellen kann. Das ist zu eng (ich habe ein High-End-Wort verwendet, Quacksalber), und die CommonJS-API definiert viele APIs, die von normalen Anwendungen (hauptsächlich Nicht-Browser-Anwendungen) verwendet werden, und füllt so diese Lücke. Das ultimative Ziel besteht darin, eine Standardbibliothek bereitzustellen, die Python, Ruby und Java ähnelt. In diesem Fall können Entwickler die CommonJS-API zum Schreiben von Anwendungen verwenden, und diese Anwendungen können dann in verschiedenen JavaScript-Interpretern und verschiedenen Hostumgebungen ausgeführt werden.

In Systemen, die mit CommonJS kompatibel sind, können Sie JavaScript verwenden, um die folgenden Programme zu entwickeln:

(1). Serverseitige JavaScript-Anwendungen
(3). Grafische Schnittstellenanwendungen
(4). Hybridanwendungen (wie Titanium oder Adobe AIR)

Im Jahr 2009 erstellte der amerikanische Programmierer Ryan Dahl das Projekt node.js, das JavaScript verwendet Sprache wird für die serverseitige Programmierung verwendet. Dies markiert die offizielle Geburtsstunde der „modularen Javascript-Programmierung“. Denn ehrlich gesagt ist es in einer Browserumgebung kein großes Problem, keine Module zu haben. Schließlich ist die Komplexität von Webprogrammen begrenzt. Aber auf der Serverseite müssen Module vorhanden sein, um mit dem Betriebssystem zu interagieren andere Anwendungen, sonst gibt es überhaupt keine Möglichkeit zu programmieren. NodeJS ist die Implementierung der CommonJS-Spezifikation, und Webpack ist ebenfalls in Form von CommonJS geschrieben.

Das Modulsystem von node.js wird unter Bezugnahme auf die CommonJS-Spezifikation implementiert. In CommonJS gibt es eine globale Methode require() zum Laden von Modulen. Vorausgesetzt, es gibt ein Mathematikmodul math.js, kann es wie folgt geladen werden.

var math = require('math');

Dann können Sie die vom Modul bereitgestellte Methode aufrufen:

var math = require('math');

  math.add(2,3); // 5

Von CommonJS definierte Module sind unterteilt in: {Modulreferenz (erforderlich)} {Moduldefinition (Exporte)} {Modulidentifikation (Modul)}

require() wird verwendet, um externe einzuführen module; exports object Wird zum Exportieren von Methoden oder Variablen des aktuellen Moduls verwendet. Der einzige Exportport repräsentiert das Modul selbst.

Obwohl Node den Spezifikationen von CommonJS folgt, wurden einige Kompromisse eingegangen und einige neue Dinge hinzugefügt.

Nachdem wir jedoch über CommonJS und auch über Node gesprochen haben, denke ich, dass wir zuerst NPM verstehen müssen. Als Paketmanager von Node soll NPM Node nicht bei der Lösung des Installationsproblems abhängiger Pakete unterstützen. Dann muss es auch der CommonJS-Spezifikation folgen. CommonJS WIKI spricht über seine Geschichte und stellt auch Module, Pakete usw. vor.

Lassen Sie uns über das Prinzip und die einfache Implementierung von commonJS sprechen:

1. Prinzip

Der Hauptgrund, warum Browser nicht mit CommonJS kompatibel sind, ist das Fehlen von vier Node.js-Umgebungsvariablen.

module
exports
require
global

Solange diese vier Variablen bereitgestellt werden, kann der Browser das CommonJS-Modul laden.

Hier ist ein einfaches Beispiel.

var module = {
  exports: {}
};

(function(module, exports) {
  exports.multiply = function (n) { return n * 1000 };
}(module, module.exports))

var f = module.exports.multiply;
f(5) // 5000

Der obige Code stellt zwei externe Variablen, Modul und Exporte, für eine Funktion zur sofortigen Ausführung bereit, und das Modul wird in dieser Funktion zur sofortigen Ausführung platziert. Der Ausgabewert des Moduls wird in module.exports abgelegt, wodurch das Laden des Moduls realisiert wird.

2. AMD-Spezifikationen

Nachdem NodeJS auf Basis der CommonJS-Spezifikation herauskam, wurde das Konzept der serverseitigen Module entwickelt. Natürlich möchte jeder clientseitige Module. Und am besten ist es, wenn beide kompatibel sind, sodass ein Modul ohne Modifikation sowohl auf dem Server als auch im Browser laufen kann. Aufgrund einer wesentlichen Einschränkung ist die CommonJS-Spezifikation jedoch nicht für Browserumgebungen geeignet. Oder wenn der obige Code im Browser ausgeführt wird, tritt ein großes Problem auf. Können Sie es sehen?

var math = require('math');
math.add(2, 3);

第二行math.add(2, 3)，在第一行require('math')之后运行，因此必须等math.js加载完成。也就是说，如果加载时间很长，整个应用就会停在那里等。您会注意到 require 是同步的。

这对服务器端不是一个问题，因为所有的模块都存放在本地硬盘，可以同步加载完成，等待时间就是硬盘的读取时间。但是，对于浏览器，这却是一个大问题，因为模块都放在服务器端，等待时间取决于网速的快慢，可能要等很长时间，浏览器处于"假死"状态。

因此，浏览器端的模块，不能采用"同步加载"（synchronous），只能采用"异步加载"（asynchronous）。这就是AMD规范诞生的背景。

CommonJS是主要为了JS在后端的表现制定的，他是不适合前端的，AMD(异步模块定义)出现了，它就主要为前端JS的表现制定规范。

AMD是"Asynchronous Module Definition"的缩写，意思就是"异步模块定义"。它采用异步方式加载模块，模块的加载不影响它后面语句的运行。所有依赖这个模块的语句，都定义在一个回调函数中，等到加载完成之后，这个回调函数才会运行。

AMD也采用require()语句加载模块，但是不同于CommonJS，它要求两个参数：

require([module], callback);

第一个参数[module]，是一个数组，里面的成员就是要加载的模块；第二个参数callback，则是加载成功之后的回调函数。如果将前面的代码改写成AMD形式，就是下面这样：

require(['math'], function (math) {
    math.add(2, 3);
});

math.add()与math模块加载不是同步的，浏览器不会发生假死。所以很显然，AMD比较适合浏览器环境。目前，主要有两个Javascript库实现了AMD规范：require.js和curl.js。

Require.js主要提供define和require两个方法来进行模块化编程，前者用来定义模块，后者用来调用模块。RequireJS就是实现了AMD规范的呢。

三、CMD规范

大名远扬的玉伯写了seajs，就是遵循他提出的CMD规范，与AMD蛮相近的，不过用起来感觉更加方便些，最重要的是中文版，应有尽有：seajs官方doc

define(function(require,exports,module){...});

前面说AMD，说RequireJS实现了AMD，CMD看起来与AMD好像呀，那RequireJS与SeaJS像不像呢？虽然CMD与AMD蛮像的，但区别还是挺明显的，官方非官方都有阐述和理解，我觉得吧，说的都挺好

Das obige ist der detaillierte Inhalt vonEinführung in die JavaScript-Modulspezifikationen CommonJS, AMD und CMD. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!