899 votes

Relation entre CommonJS, AMD et RequireJS?

Je suis très confus au sujet de CommonJS, AMD et RequireJS. Même après avoir lu beaucoup.

Je sais que CommonJS (précédemment ServerJS) est un groupe pour la définition de certains JavaScript cahier des charges (c'est à dire modules) lorsque la langue est utilisée en dehors du navigateur. CommonJS modules de spécification de l'implémentation comme Node.js ou RingoJS, droit?

Quelle est la relation entre CommonJS, Asynchrone de définition de module (AMD) et RequireJS? Est RequireJS de mise en œuvre de CommonJS de définition de module? Si oui, quelle est la DMLA?

812voto

jakee Points 6822

RequireJS implémente l'API AMD (source).

CommonJS est une façon de définir des modules à l'aide d'un exports objet, qui définit le module de contenu. Mettez simplement un CommonJS la mise en œuvre pourrait fonctionner comme ça

// someModule.js
exports.doSomething = function() { return "foo"; };

//otherModule.js
var someModule = require('someModule'); // in the vein of node    
exports.doSomethingElse = function() { return someModule.doSomething() + "bar"; };

Fondamentalement CommonJS indique que vous avez besoin d'avoir l' require -fonction pour récupérer les dépendances, l' exports variable de module d'exportation des matières et certains identificateur de module (qui décrit l'emplacement du module en question par rapport à ce module qui est utilisé pour obliger les dépendances. (source) CommonJS a implémentations différentes, par exemple Node.js que vous avez mentionné.

Parce que CommonJS n'était pas particulièrement conçus avec les navigateurs à l'esprit, il n'entrait pas dans le navigateur de l'environnement si bien (je n'ai pas vraiment de source pour ce faire, il a juste dit partout, par exemple le RequireJS site.). Apparemment, cela a quelque chose à voir avec le chargement asynchrone, etc.

Au contraire, RequireJS implémente AMD, qui est conçu pour s'adapter à l'environnement du navigateur. (source) Apparemment, AMD a commencé comme un offspin de CommonJs format de Transport et évolué dans sa propre définition de module API. D'où les ressemblances entre les deux. La nouvelle chose dans la DMLA est l' define -fonction qui permet au module de déclarer ses dépendances avant d'être chargé. Par exemple, la définition pourrait être:

define('module/id/string', ['module', 'dependency', 'array'], 
function(module, factory function) {
  return ModuleContents;  
});

Donc CommonJS et AMD sont Javascript de définition de module Api qui ont implémentations différentes, mais tous deux viennent de la même origine. AMD est plus adapté pour le navigateur, car il prend en charge le chargement asynchrone des dépendances de modules. RequireJS est une mise en œuvre de la DMLA, alors que dans le même temps, en essayant de garder l'esprit de CommonJS (notamment dans le module identifiants). De vous embrouiller encore plus, RequireJs, tout en étant un AMD mise en œuvre, offre un CommonJS wrapper de sorte CommonJS modules peuvent presque être directement importés dans l'utilisation avec RequireJS.

define(function(require, exports, module) {
  var someModule = require('someModule'); // in the vein of node    
  exports.doSomethingElse = function() { return someModule.doSomething() + "bar"; };
});

Espérons que cela a aidé à clarifier les choses!

212voto

Nate Points 9879

CommonJS est plus que cela - c'est un projet à définir une API commune et de l'écosystème pour le JavaScript. Une partie de CommonJS est le Module de spécification. Node.js et RingoJS sont JavaScript côté serveur runtimes, et oui, à la fois de la mise en oeuvre de modules basés sur la CommonJS Module spec.

AMD (Asynchronous Module Definition) est un autre spécification pour les modules. RequireJS est probablement le plus populaire de la mise en œuvre de la DMLA. Une différence majeure de CommonJS, c'est que AMD indique que les modules sont chargés de manière asynchrone - ce qui signifie que les modules ne sont chargés qu'ils sont, plutôt que le chargement de tous les modules à l'avant.

AMD est généralement plus utilisé côté client (navigateur) de développement JavaScript pour cette raison, et CommonJS Modules sont généralement utilisé côté serveur. Toutefois, vous pouvez utiliser soit le module spec dans l'environnement - par exemple, RequireJS propose des orientations pour l'exécution dans Node.js et browserify est un CommonJS Module de mise en œuvre qui peuvent s'exécuter dans le navigateur.

201voto

mmutilva Points 5226

La réponse courte est:

CommonJS et AMD sont des spécifications (ou formats) sur la façon dont les modules et leurs dépendances doivent être déclarés dans les applications de javascript.

RequireJS est un chargeur de script de la bibliothèque qui est un AMD conforme, curljs est un autre exemple.

CommonJS conforme:

Prises de Addy Osmani du livre.

// 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;

AMD compatibles:

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

Ailleurs, le module peut être utilisé avec:

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

Un peu de contexte:

En fait, CommonJS est beaucoup plus qu'une déclaration d'API et une seule partie de la traite. AMD a commencé comme un projet de spécification pour le module de format sur le CommonJS liste, mais le consensus n'est pas atteint et le développement du format déplacé à la amdjs groupe. Les Arguments autour de qui format est meilleur état que CommonJS tente de couvrir un éventail plus large de préoccupations et qu'il est mieux adapté pour le côté serveur de développement compte tenu de son synchrone de la nature, et que AMD est mieux adapté pour le côté client (navigateur) de développement compte tenu de sa nature asynchrone et le fait qu'il a ses racines dans le Dojo du module de déclaration de mise en œuvre.

Sources:

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X