Articles /

Vergleich zwischen CommonJS und AMD/RequireJS

Einführung

Im Gegensatz zu Webservern wie Apache und Microsoft IIS, die beide vorkonfiguriert sind, ist node.js ganz anders. Mit node.js bauen Entwickler Webserver von Grund auf neu auf. Von den Programmierkenntnissen eines Entwicklers wird erwartet, dass sie den Webserver schützen. Damit unterscheidet sich Node.js von Apache und Co.

In diesem Artikel werden wir uns auf zwei wichtige Systemmodule – AMD und Common.js – in node.js konzentrieren. Bevor wir die beiden vergleichen, müssen wir die Unterschiede zwischen den beiden Systemmodulen diskutieren. Zwei Leitfragen, die uns helfen, die beiden zu vergleichen, sind: welches ist schneller beim Laden von Modulen im oder vom Browser und wie kann man ein Systemmodul so konvertieren, dass es einige Funktionen des anderen Systemmoduls erbt.

Dieser Artikel wird sich nicht auf die Grundlagen von node.js und javascript konzentrieren. Er wird keine Themen behandeln wie „wie installiert man node.js“, „wie benutzt man npm oder nave um Pakete zu installieren“ oder „verschiedene Versionen von node.js für verschiedene Projekte“. Unser Ziel ist es, die Verwirrung zwischen AMD und Common.js aufzulösen. Daher werden wir uns leicht auf die Kernmodule in node.js, ein paar Funktionen und Variablen konzentrieren und schließlich unsere Aufmerksamkeit auf AMD und Common.js richten und wie wir eines der Systemmodule umwandeln können, um Module schneller im Browser zu laden.

Kern-, Datei- und externe Node-Module

In node.js gibt es drei wichtige Hauptmodule; Kern-, Datei- und externe Node-Module. Beginnen wir mit dem Dateimodul, weil es einfacher zu verstehen ist.

  • Dateimodul:
    Im Gegensatz zu den anderen beiden Modellen ist das Dateimodell ein Modell, das auf relativen Pfaden basiert. Why? Nehmen wir an, Sie würden ein Modul über die folgende Syntax exportieren:
 module.exports = foo { 'something' : 123 } ; 
 var foo = function () { console.log('foo called'); };
var b = function () { console.log('b called'); }; 
module.exports = { b : b };
module.exports.bar = function () {console.log('bar called');}; 
module.exports.bas = function () {console.log('bas called');};

Die Art und Weise, wie Module in Dateien geladen oder importiert werden, unterscheidet sich deutlich von den Modulen core und external_node, weshalb die beiden anderen auch als nicht-relativ-basierte Module bezeichnet werden.

Hinweis: Es gibt verschiedene Möglichkeiten, Module/Dateien in node.js zu exportieren. Anonyme Funktion ist eine weitere Möglichkeit, ein Modul aus einer Datei zu exportieren.

  • Kernmodule:
    Die nächsten Module, die die drei Hauptmodule in node.js umfassen, sind die Kernmodule. Core Modules sind nicht-relativ basierte Module. Sie unterscheiden sich stark von Dateimodulen, insbesondere wenn man Module in Dateien benötigt (oder importiert).

Wenn wir zum Beispiel das Pfadmodul in node.js verwenden, das Schrägstriche so korrigiert, dass sie betriebssystemspezifisch sind, sich um . und .. im Pfad korrigiert und außerdem doppelte Schrägstriche entfernt, würden wir den relativen Pfad nicht einbeziehen:

var require = require('path') console.log (path.normalize ('/foo/bar/......'));
  • external_node Module:
    Diese Module liegen irgendwo zwischen core und dateibasierten Modulen. external_node-Module sind den dateibasierten Modulen recht ähnlich, vor allem, wenn man ein Modul exportiert.
module.exports = function () {console.log('called node modules!');}

Wenn man jedoch Module lädt, werden sie ganz anders.

var bar = require('bas');bas(); //

Außerdem bietet node.js einige wichtige globale und nützliche Funktionen, auf die wir nicht näher eingehen werden. timer,console, _filename und_dirname, und process sind alles Beispiele für wichtige Globals in node.js. Zum Beispiel sind _filename und _dirname in jeder Datei verfügbar und ermöglichen den Zugriff auf den vollständigen Pfad und das Verzeichnis für das aktuelle Modul.

Nun, da wir ein kurzes Verständnis von Modulen in node.js haben, lassen Sie uns zum Hauptaspekt übergehen, wo wir CommonJS- und AMD-Module unterscheiden. Wir werden die Probleme angehen, „warum Common.js so langsam beim Laden von Modulen aus dem Browser ist“ und „wie wir es über browserify konvertieren können, um bestimmte Funktionen von AMD und Require.js zu erben.“

Einführung in CommonJS und AMD

 CommonJS is a great module for the server side environment, especially when you have immediate access to the filesystem. However, using the same module system in the browser may be less reliable and extremely slow.

Betrachten wir zum Beispiel, wie die beiden Module in der serverseitigen Umgebung geladen werden:

var foo = require('./foo');var bar = require('./bar');// more code here

Betrachten wir das obige Beispiel, so wird es auf der Serverseite als gute Praxis angesehen, wenn ein Modul geladen wird, während das andere Modul darauf wartet, dass ein anderes Modul geparst wird.

Mit anderen Worten, wenn das Modul foo geladen wird, wird das Modul bar nicht geparst oder verarbeitet, bis foo vollständig geladen ist. Selbst der Server kennt das Modul bar möglicherweise nicht, bis er mit dem Modul foo fertig ist.

Dasselbe Modulsystem im Browser zu verwenden, wird als keine gute Idee angesehen, weil jedes Modulsystem eine HTTP-Anfrage an den Server auslösen müsste. Dies ist in der Serverumgebung viel weniger effizient und weniger zuverlässig. Es verschlechtert die Benutzerfreundlichkeit auf der Client-Seite. Dieses Problem könnte durch asynchrones Laden von Modulen gelöst werden.

Hier kommt AMD ins Spiel. AMD, auch bekannt als asynchrone Moduldefinition, wurde eingeführt, um das asynchrone Laden von Modulen im Browser zu unterstützen –
es löst schließlich die langsame Ladegeschwindigkeit von Modulen im Browser. Im Einklang mit der Bedeutung von „asynchron“ werden Module zu unterschiedlichen Zeiten ausgelöst.

Um etwas in eine Datei in AMD zu exportieren, müssen wir einfach eine Callback-Funktion einfügen und sie von einer Callback-Funktion zurückgeben. Hier ein Beispiel:

 define(, function () { var foo = function () { console.log ('foo was called');}; return foo; // function foo is exported});

Genauso wie die Syntax der Exportvariablen in node.JS nimmt auch die define-Funktion ein spezielles Argument namens exports, das dem in node.JS sehr ähnlich ist.

define(, function (exports) {var bas = exports.log = function () {console.log ('bas.log was called'); };});

Um zwei Module im Browser laden zu können, müssen wir RequireJS herunterladen und installieren.

Warum brauchen wir RequireJS, um Module über die asynchrone Moduldefinition laden zu können?
Das liegt daran, dass die Define-Funktion, die Teil des unten stehenden Codes ist (der uns zeigt, wie wir mehr als ein Modul über die AMD in den Browser laden können), nicht im Browser enthalten ist. Daher ist es am besten, über eine Bibliothek eines Drittanbieters auf sie zuzugreifen. RequireJS ist einfach eine Javascript-Datei, die Sie in Ihr Projekt einbinden.

define(, function(foo, bar){ //more code here// more code here });

Wie man node.js in Browser-Code konvertiert:

Lassen Sie uns nun sehen, wie wir CommonJS konvertieren können, um mit AMD/RequireJS über browserify kompatibel zu werden. Die Konvertierung von CommonJS über browserify ermöglicht es node.js, Module im Browser zu laden, ähnlich wie AMD/RequireJS.

Lassen Sie uns browserify über den folgenden Code installieren. Bitte stellen Sie sicher, dass Sie während der Installation mit dem Internet verbunden sind. Das mit Bindestrich geschriebene g bedeutet einfach global.

npm install –g browserify

Sie können Module erstellen, sie als clientJS oder unter einem beliebigen Namen benennen und sie schließlich mit browserify in AMD/RequireJS umwandeln.

module.exports = function () {console.log('bas was called');}
exports.log = function () {console.log('bar.log was called');}

Um den obigen Code nun AMD-kompatibel zu machen, mit anderen Worten, um Module asynchron zu laden, müssen wir dies über die folgenden Befehlszeilenargumente tun:

browserify client.js -o amdmodule.js

Sie können jeden beliebigen Namen als Client vergeben. Es muss nicht immer client.js sein, aber auch client.js ist wünschenswert. Denken Sie daran, dass es sich nur um eine Datei handelt. Außerdem können Sie weitere Konfigurationen über browserify unter http://browserify.org/.

Zusammenfassung:

Abschließend sollten Sie beachten, dass nicht alle node.JS-Module so konvertiert werden können, dass sie effektiv im Browser funktionieren. Diejenigen, die von Funktionen abhängen, die auf der Serverseite verfügbar sind, werden im Browser überhaupt nicht funktionieren.

Ich habe gerade AMD/RequireJS als eine Lösung vorgestellt, die asynchrones Laden von Modulen im Browser ermöglicht, was als gute Praxis gilt. Das asynchrone Laden von Modulen ist viel schneller und zuverlässiger als die Verwendung von CommonJS im Browser.

Leave a Reply