Porównanie CommonJS i AMD/RequireJS

Wprowadzenie

W przeciwieństwie do serwerów WWW, takich jak Apache i Microsoft IIS, z których oba są wstępnie skonfigurowane, node.js jest zupełnie inny. Z node.js, programiści budują serwery internetowe od podstaw. Oczekuje się, że umiejętności programisty w zakresie kodowania zabezpieczą serwer WWW. W ten sposób Node.js różni się od Apache’a i reszty.

W tym artykule skupimy się na dwóch głównych modułach systemowych – AMD i Common.js – w node.js. Zanim porównamy te dwa, musimy omówić różnice między tymi dwoma modułami systemowymi. Dwa pytania przewodnie, które pomogą nam porównać te dwa moduły to: który z nich jest szybszy podczas ładowania modułów w lub z przeglądarki oraz jak przekonwertować jeden moduł systemowy, aby dziedziczył niektóre cechy innego modułu systemowego.

Ten artykuł nie będzie się skupiał na podstawach node.js amd javascript. Nie będzie obejmował tematów takich jak „jak zainstalować node.js,” „jak używać npm lub nave do instalacji pakietów,” lub „różne wersje node.js dla różnych projektów.” Naszym celem jest rozwianie nieporozumień pomiędzy AMD i Common.js. Dlatego położymy lekki nacisk na podstawowe moduły w node.js, kilka funkcji i zmiennych, a ostatecznie skierujemy naszą uwagę na AMD i Common.js i jak możemy przekonwertować jeden z modułów systemowych, aby szybciej ładować moduły w przeglądarce.

Core, File and External Node Modules

W node.js, istnieją trzy główne ważne moduły; Core, file i zewnętrzne moduły węzła. Zacznijmy od modułu plików, ponieważ jest on łatwiejszy do zrozumienia.

• Moduł plików:
  W przeciwieństwie do dwóch pozostałych modeli, model plików jest modelem opartym na ścieżkach względnych. Dlaczego? Powiedzmy, że chcesz wyeksportować moduł za pomocą następującej składni:

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

Sposób, w jaki moduły są ładowane lub importowane do plików, jest zupełnie inny niż w przypadku modułów core i external_node; dlatego dwa pozostałe są również znane jako moduły oparte na nierelacyjnych ścieżkach.

Uwaga: istnieją różne sposoby eksportowania modułów/plików w node.js. Funkcja anonimowa jest innym sposobem eksportowania modułu z pliku.

• Moduły podstawowe:
  Kolejne moduły, które zawierają trzy główne moduły w node.js są modułami podstawowymi. Moduły rdzeniowe są modułami nie opartymi na relacjach. Różnią się one bardzo od modułów plików, zwłaszcza gdy wymagasz (lub importujesz) moduły do plików.

Na przykład, jeśli mielibyśmy użyć modułu ścieżki w node.js, który naprawia ukośniki, aby były specyficzne dla systemu operacyjnego, zajmuje się . i .. w ścieżce, a także usuwa zduplikowane ukośniki, nie uwzględnilibyśmy względnej ścieżki:

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

• moduły external_node:
  Te moduły mieszczą się gdzieś pomiędzy modułami rdzeniowymi a opartymi na plikach. Moduły external_node są dość podobne do file-based, zwłaszcza gdy eksportujesz moduł.

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

Jednakże, gdy ładujesz moduły, stają się one zupełnie inne.

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

Dodatkowo node.js dostarczają kilka ważnych globalnych z przydatnymi funkcjami, których nie będziemy omawiać w szczegółach. timer,console, _filename i_dirname, oraz process są przykładami ważnych globali w node.js. Na przykład, _filename i _dirname są dostępne w każdym pliku i dają dostęp do pełnej ścieżki i katalogu dla bieżącego modułu.

Teraz, gdy mamy już krótkie zrozumienie modułów w node.js, przejdźmy do głównego aspektu, gdzie rozróżniamy moduły CommonJS i AMD. Zajmiemy się problemami „dlaczego Common.js jest tak powolny w ładowaniu modułów z przeglądarki” oraz „jak możemy go przekonwertować poprzez browserify, aby dziedziczył pewne cechy AMD i Require.js”. .

Wprowadzenie CommonJS i 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. 

Na przykład rozważmy, jak dwa moduły są ładowane w środowisku po stronie serwera:

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

Patrząc na powyższy przykład, uważa się za dobrą praktykę po stronie serwera, gdy jeden moduł jest ładowany, podczas gdy drugi moduł czeka na parsowanie innego modułu.

Innymi słowy, kiedy moduł foo jest ładowany, bar nie będzie parsowany lub przetwarzany, dopóki foo nie zostanie całkowicie załadowany. Nawet serwer może nie być świadomy modułu bar, dopóki nie skończy z modułem foo.

Używanie tego samego systemu modułów w przeglądarce nie jest uważane za dobry pomysł, ponieważ każdy system modułów musiałby wywołać żądanie HTTP do serwera. Jest to o wiele mniej wydajne i mniej niezawodne w środowisku serwerowym. To pogarsza wrażenia użytkownika po stronie klienta. Ten problem może być rozwiązany przez asynchroniczne ładowanie modułów.

To jest miejsce, gdzie AMD wchodzi. AMD, znane również jako asynchroniczna definicja modułu, zostało wprowadzone, aby wspierać asynchroniczne ładowanie modułów w przeglądarce –
rozwiązuje to ostatecznie problem wolnego tempa ładowania modułów w przeglądarce. Zgodnie ze znaczeniem słowa „asynchroniczny”, moduły są wyzwalane w różnym czasie.

Aby wyeksportować coś w pliku w AMD, musimy po prostu dołączyć funkcję wywołania zwrotnego i zwrócić ją z funkcji wywołania zwrotnego define. Oto przykład:

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

Tak jak składnia zmiennej eksportowej w node.JS, funkcja define również przyjmuje specjalny argument o nazwie exports, który jest dość podobny do tego w node.JS.

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

Aby umożliwić załadowanie dwóch modułów w przeglądarce, musimy pobrać i zainstalować RequireJS. Należy pamiętać, że jest to tylko opcja, która uniemożliwia programistom używanie kodu node.JS w przeglądarce.]

Dlaczego potrzebujemy RequireJS, aby móc ładować moduły poprzez asynchroniczną definicję modułu?
Oto powód: ponieważ funkcja Define, która jest częścią poniższego kodu (pokazującego nam, jak możemy załadować więcej niż jeden moduł w przeglądarce poprzez AMD), nie jest natywna dla przeglądarki. Dlatego najlepszą opcją jest dostęp do niej z biblioteki innej firmy. RequireJS to po prostu plik javascript, który dołączasz do swojego projektu.

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

Jak przekonwertować node.js na kod przeglądarki:

Teraz zobaczmy, jak możemy przekonwertować CommonJS, aby stał się kompatybilny z AMD/RequireJS poprzez browserify. Konwersja CommonJS przez browserify pozwala node.js ładować moduły w przeglądarce podobnie jak AMD/RequireJS.

Zainstalujmy browserify za pomocą poniższego kodu. Proszę upewnić się, że jesteś podłączony do Internetu podczas instalacji. Łącznik g oznacza po prostu globalny.

npm install –g browserify

Możesz tworzyć moduły, nazywać je clientJS lub dowolną nazwą, którą preferujesz, i ostatecznie przekonwertować je na AMD/RequireJS używając browserify.

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

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

Teraz, aby przekonwertować powyższy kod na kompatybilny z AMD, innymi słowy, aby ładować moduły asynchronicznie, musimy to zrobić za pomocą następujących argumentów wiersza poleceń:

browserify client.js -o amdmodule.js

Możesz przypisać dowolną nazwę, którą wolisz jako klienta. Nie zawsze powinien to być client.js, ale client.js, też jest preferowany. Pamiętaj, że jest to tylko plik. Ponadto możesz sprawdzić więcej konfiguracji na temat browserify na stronie http://browserify.org/.

Zawijanie:

Na koniec należy zauważyć, że nie wszystkie moduły node.JS można przekonwertować tak, aby działały efektywnie w przeglądarce. Te, które zależą od funkcji dostępnych po stronie serwera, w ogóle nie będą działać w przeglądarce.

Właśnie przedstawiłem AMD/RequireJS jako rozwiązanie, które pozwala na asynchroniczne ładowanie modułów w przeglądarce, co jest uważane za dobrą praktykę. Ładowanie modułów asynchronicznie jest o wiele szybsze i bardziej niezawodne niż używanie CommonJS w przeglądarce.