Vergelijking van CommonJS en AMD/RequireJS

Inleiding

In tegenstelling tot webservers als Apache en Microsoft IIS, die beide voorgeconfigureerd zijn, is node.js heel anders. Met node.js bouwen ontwikkelaars webservers vanaf nul. Van de coderingsvaardigheden van een ontwikkelaar wordt verwacht dat hij de webserver beveiligt. Dus, Node.js verschilt van Apache en de rest.

In dit artikel zullen we ons richten op twee belangrijke systeemmodules – AMD en Common.js – in node.js. Voordat we de twee vergelijken, moeten we de verschillen tussen de twee systeemmodules bespreken. Twee leidende vragen die ons helpen de twee te vergelijken zijn: welke is sneller bij het laden van modules in of vanuit de browser en hoe een systeem module te converteren om sommige functies van een andere systeem module te erven.

Dit artikel zal zich niet richten op de basis van node.js amd javascript. Het zal niet ingaan op onderwerpen als “hoe node.js te installeren,” “hoe npm of nave te gebruiken om pakketten te installeren,” of “verschillende versies van node.js voor verschillende projecten.” Ons doel is om de verwarring tussen AMD en Common.js op te lossen. Daarom zullen we licht de nadruk leggen op de kernmodules in node.js, een paar functies en variabelen, en uiteindelijk onze aandacht richten op AMD en Common.js en hoe we een van de systeemmodules kunnen converteren om modules sneller in de browser te laden.

Core, bestand en externe Node-modules

In node.js zijn er drie belangrijke hoofdmodules; Core, bestand en externe node-modules. Laten we eerst beginnen met de bestandsmodule, omdat die gemakkelijker te begrijpen is.

• Bestandsmodule:
  In tegenstelling tot de andere twee modellen, is het bestandsmodel een relatief-pad gebaseerd model. Waarom? Stel dat u een module exporteert via de volgende syntaxis:

 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');};

De manier waarop modules in bestanden worden geladen of geïmporteerd, verschilt nogal van de core- en external_node-modules; daarom worden de andere twee ook wel niet-relatieve modules genoemd.

Note: er zijn verschillende manieren om modules/bestanden te exporteren in node.js. Anonymous function is een andere manier om een module uit een bestand te exporteren.

• Core Modules:
  De volgende modules die de drie belangrijkste modules in node.js omvatten, zijn de core modules. Core Modules zijn niet-relatieve gebaseerde modules. Ze zijn heel anders dan bestandsmodules, vooral wanneer u modules in bestanden vereist (of importeert).

Als we bijvoorbeeld de padmodule in node.js zouden gebruiken, die slashes opknapt om OS-specifiek te zijn, zorgt voor . en .. in het pad, en ook dubbele slashes verwijdert, zouden we het relatieve pad niet opnemen:

var require = require('path') console.log (path.normalize ('/foo/bar/......'));

• external_node modules:
  Deze modules vallen ergens tussen core en bestandsgebaseerde modules in. external_node modules lijken veel op file-based, vooral wanneer u een module exporteert.

module.exports = function () {console.log('called node modules!');} 

Wanneer u echter modules laadt, worden ze heel anders.

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

Daarnaast biedt node.js een aantal belangrijke globale met nuttige functies, die we niet in detail zullen bespreken. timer,console, _filename en_dirname, en proces zijn allemaal voorbeelden van belangrijke globals in node.js. Bijvoorbeeld, _filename en _dirname zijn beschikbaar in elk bestand en geven toegang tot het volledige pad en de directory voor de huidige module.

Nu we een kort begrip hebben van modules in node.js, laten we overgaan tot het belangrijkste aspect, waar we onderscheid maken tussen CommonJS en AMD modules. We zullen de problemen aanpakken van “waarom Common.js zo traag is in het laden van modules vanuit de browser” en “hoe we het kunnen converteren via browserify om bepaalde functies van AMD en Require.js te erven.” .

Introducing CommonJS and 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. 

Laten we bijvoorbeeld eens kijken hoe de twee modules worden geladen in de server side omgeving:

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

Kijkend naar het bovenstaande voorbeeld, wordt het aan de server kant als een goede praktijk beschouwd wanneer de ene module wordt geladen terwijl de andere module wacht op een andere module om te worden geparst.

Met andere woorden, wanneer de foo module wordt geladen, zal de bar niet worden geparsed of verwerkt totdat foo volledig is geladen. Zelfs de server zou zich niet bewust kunnen zijn van de bar-module totdat hij klaar is met de foo-module.

Het gebruik van hetzelfde modulesysteem in de browser wordt niet als een goed idee beschouwd, omdat elk modulesysteem een HTTP-verzoek aan de server zou moeten ontketenen. Dit is een stuk minder efficiënt en minder betrouwbaar in de serveromgeving. Het verslechtert de gebruikerservaring aan de client-zijde. Dit probleem zou kunnen worden opgelost via asynchroon laden van modules.

Dit is waar AMD om de hoek komt kijken. AMD, ook bekend als async module definition, is geïntroduceerd om het asynchroon laden van modules in de browser te ondersteunen –
het lost uiteindelijk de trage snelheid van het laden van modules in de browser op. In overeenstemming met de betekenis van “asynchroon,” worden modules op verschillende tijdstippen getriggerd.

Om iets in een bestand in AMD te exporteren, hoeven we alleen maar een callback functie op te nemen en deze terug te sturen vanuit een define callback functie. Hier is een voorbeeld:

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

Net als de export variabele syntaxis in node.JS, neemt de define functie ook een speciaal argument genaamd exports, welke erg lijkt op die in node.JS.

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

Om het mogelijk te maken om twee modules in de browser te laden, moeten we RequireJS downloaden en installeren. Houd in gedachten, dit is slechts een optie die voorkomt dat ontwikkelaars node.JS code in de browser kunnen gebruiken.]

Waarom hebben we RequireJS nodig om modules te kunnen laden via de asynchrone module definitie?
Daar is de reden voor: omdat de Define functie, die deel uitmaakt van de code hieronder (die ons laat zien hoe we meer dan een module in de browser kunnen laden via de AMD), niet native is voor de browser. Daarom is de beste optie om het te benaderen vanuit een bibliotheek van derden. RequireJS is simpelweg een javascript bestand dat je opneemt in je project.

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

Hoe node.js om te zetten in browser code:

Nu, laten we eens kijken hoe we CommonJS kunnen omzetten om compatibel te worden met AMD/RequireJS via browserify. Het omzetten van CommonJS via browserify stelt node.js in staat om modules in de browser te laden, vergelijkbaar met AMD/RequireJS.

Laten we browserify installeren via de volgende code. Zorg ervoor dat u verbonden bent met het internet tijdens de installatie. De g met koppelteken betekent gewoon global.

npm install –g browserify

U kunt modules maken, deze de naam clientJS geven of een andere naam die u verkiest, en ze uiteindelijk met browserify omzetten naar AMD/RequireJS.

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

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

Nu, om de bovenstaande code te converteren om AMD-compatibel te zijn, met andere woorden, om modules asynchroon te laden, moeten we dit doen via de volgende commandoregelargumenten:

browserify client.js -o amdmodule.js

Je kunt elke gewenste naam toewijzen aan de client. Het hoeft niet altijd client.js te zijn, maar client.js verdient ook de voorkeur. Onthoud, het is maar een bestand. Bovendien kun je meer configuratie over browserify bekijken op http://browserify.org/.

Wrapping up:

Ten slotte moet je opmerken dat niet alle node.JS modules kunnen worden geconverteerd om effectief te werken in de browser. Degenen die afhankelijk zijn van functies die beschikbaar zijn op de server-side zal helemaal niet werken in de browser.

Ik heb zojuist AMD/RequireJS geïntroduceerd als een oplossing die asynchroon laden van modules in de browser mogelijk maakt, wat wordt beschouwd als een goede praktijk. Het asynchroon laden van modules is een stuk sneller en betrouwbaarder dan het gebruik van CommonJS in de browser.