CommonJS to coś więcej - to projekt mający na celu zdefiniowanie wspólnego API i ekosystemu dla JavaScript. Jedną z części CommonJS jest specyfikacja modułu. Węzeł.js i RingoJS są środowiskami Uruchomieniowymi JavaScript po stronie serwera i tak, oba implementują moduły oparte na specyfikacji CommonJS Module.

AMD (Asynchronous Module Definition) to kolejna Specyfikacja modułów. RequireJS {[2] } jest prawdopodobnie najpopularniejszą implementacją AMD. Jedna główna różnica z CommonJS wynika, że AMD określa, że moduły są ładowane asynchronicznie - oznacza to, że moduły są ładowane równolegle, w przeciwieństwie do blokowania wykonania przez oczekiwanie na zakończenie ładowania.

AMD jest ogólnie bardziej używane w rozwoju JavaScript po stronie klienta (w przeglądarce) z tego powodu, a Moduły CommonJS są zwykle używane po stronie serwera. Możesz jednak użyć specyfikacji modułu w dowolnym środowisku - na przykład RequireJS oferuje kierunki działania w Node.js i browserify {[2] } jest powszechną implementacją modułu js, która może działać w przeglądarce.

Krótka odpowiedź brzmiałaby:

CommonJS oraz AMD są specyfikacjami (lub formatami), w jaki sposób moduły i ich zależności powinny być deklarowane w aplikacjach javascript.

RequireJS jest biblioteką script loader, która jest zgodna z AMD, curljs jest kolejnym przykładem.

CommonJS zgodny:

Zaczerpnięte z Książki Addy Osmani .

// package/lib is a dependency we require
var lib = require( "package/lib" );

// behavior for our module
function foo(){
    lib.log( "hello world!" );
}

// export (expose) foo to other modules as foobar
exports.foobar = foo;

Zgodny z AMD:

// package/lib is a dependency we require
define(["package/lib"], function (lib) {

    // behavior for our module
    function foo() {
        lib.log( "hello world!" );
    }

    // export (expose) foo to other modules as foobar
    return {
        foobar: foo
    }
});

Somewhere w przeciwnym razie moduł może być używany z:

require(["package/myModule"], function(myModule) {
    myModule.foobar();
});

Jakieś tło:

Właściwie, CommonJS jest czymś więcej niż deklaracją API i zajmuje się nią tylko część. AMD zaczynało jako szkic specyfikacji formatu modułu na liście CommonJS, ale nie osiągnięto pełnego konsensusu i dalszy rozwój formatu przeniósł się do amdjs group . Argumenty na temat tego, który format jest lepszy, stwierdzają, że CommonJS próbuje objąć szerszy zestaw problemów i że jest lepiej nadaje się do rozwoju po stronie serwera ze względu na jego synchroniczny charakter, A AMD jest lepiej przystosowane do rozwoju po stronie klienta (przeglądarki) ze względu na jego asynchroniczny charakter i fakt, że ma swoje korzenie w implementacji deklaracji modułów Dojo.

Źródła:

• RequireJS-dlaczego AMD?
• Addy Osmani-Learning JavaScript Design Patterns-Modern Modular JavaScript Design Patterns

Cytowanie

AMD :

• jedna przeglądarka - pierwsze podejście
• wybór zachowania asynchronicznego i uproszczonej kompatybilności wstecznej
• nie ma żadnej koncepcji wejścia/Wyjścia pliku.
• obsługuje obiekty, funkcje, konstruktory, ciągi znaków, JSON i wiele innych typów modułów.

CommonJS :

• jeden serwer - pierwsze podejście
• zakładając zachowanie synchroniczne
• obejmuje szerszy zestaw problemy takie jak I/O, system plików, obietnice i inne.
• obsługuje rozpakowane Moduły, może czuć się nieco bliżej ES.next / Harmony specifications, uwalniając cię od wrappera define (), który AMD wymusza.
• obsługuje tylko obiekty jako moduły.

To całkiem normalne organizowanie programu JavaScript w kilku plikach i wywoływanie {[2] } z main js module.

Rzecz w tym, że JavaScript tego nie zapewnia. Nawet dzisiaj w najnowszych wersjach przeglądarek Chrome i FF.

Ale czy jest jakieś słowo kluczowe w JavaScript, aby wywołać inny moduł JavaScript?

To pytanie może być całkowitym upadkiem świata dla wielu, ponieważ odpowiedź brzmi Nie .

In ES5 (wydany w 2009 ) JavaScript nie miał takich słów kluczowych jak import, include , or require.

ES6 saves the day (wydany w 2015 ) proponując import słowo kluczowe ( https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Statements/import ), ale żadna przeglądarka tego nie implementuje.

Jeśli używasz Babel 6.18.0 i transpile tylko z opcją ES2015

import myDefault from "my-module";

Dostaniesz require ponownie.

"use strict";
var _myModule = require("my-module");
var _myModule2 = _interopRequireDefault(_myModule);
function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }

To dlatego, że require oznacza, że moduł będzie być ładowane z węzła.js. Węzeł.js zajmie się wszystkim, od odczytu pliku na poziomie systemu po funkcje zawijania do modułu.

Ponieważ w JavaScript funkcje są jedynymi opakowaniami reprezentującymi Moduły.

Jestem bardzo zdezorientowany co do CommonJS i AMD?

Zarówno CommonJS, jak i AMD to tylko dwie różne techniki, jak przezwyciężyć "defekt" JavaScript, aby załadować Moduły smart.