39

Perché non utilizzarlo come modello di componente generale per Javascript, incluso Javascript eseguito da browser?Perché CommonJS è indicato solo per le app senza browser?

A prima vista, sembra essere un buon modo per modulare il progetto su cui sto lavorando attualmente, che consiste in una grande base di codice Javascript, con molti componenti, alcuni dei quali interagiscono tra loro.

+0

Bene commonjs è come Adobe AIR credo, è l'API che sogliono eseguito in un browser classico. ma è ancora javascript, con una diversa API. Ad esempio nel browser hai dhtml o dom, beh in common js hai un'altra API che non è rilevante al di fuori di un browser. – user475434

risposta

71

CommonJS è decisamente adatto per il browser, con alcune avvertenze. Il modello del modulo CommonJS è abbastanza bello (secondo il mio giudizio parziale) ed è anche un buon punto di partenza per il sistema di moduli proposto per ECMAScript Harmony (la prossima versione pianificata del linguaggio JavaScript). In particolare, i moduli Harmony non avranno accesso all'oggetto globale ("finestra").

La ragione per cui alcune persone sostengono che i moduli CommonJS non sono adatti per il browser è che non possono essere caricati tramite un tag dello script < senza alcuna assistenza sul lato server. Ad esempio, immagina di avere una libreria markdown che esporta una funzione "convertToHTML". Si potrebbe poi fare un modulo che assomiglia a questo:

var convertToHTML = require("markdown").convertToHTML; 
exports.mangleSomeText = function() { 
    // do something then call convertToHTML 
} 

Questo non funziona tramite un tag script per alcuni motivi (il campo di applicazione non è avvolto, in modo convertToHTML otterrebbe attaccato alla finestra, richiedono wouldn' in genere viene definito e le esportazioni devono essere create separatamente per ciascun modulo).

Una libreria laterale del client con un piccolo bit di aiuto sul lato server potrebbe consentire di caricare facilmente i tag di script. Oppure, una libreria lato client che carica lo script tramite XMLHttpRequest e fa un eval() funzionerebbe anche, sebbene l'esperienza di debug spesso non sia altrettanto buona.

Una soluzione abbastanza ragionevole in questo momento, sebbene sia anche oggetto di un dibattito conflittuale tra i membri di CommonJS, è RequireJS. Utilizzando RequireJS, è possibile scrivere il vostro modulo come questo:

define(function(require, exports, module) { 

var convertToHTML = require("markdown").convertToHTML; 
exports.mangleSomeText = function() { 
    // do something then call convertToHTML 
} 

}); 

Tutto quello che abbiamo fatto è stato aggiungere che definiscono() po 'attorno al modulo. (È probabile che anche un server lo faccia abbastanza facilmente, in modo che non sia nemmeno necessario digitare manualmente la parte define).

Ho utilizzato RequireJS in un paio di progetti e ora trovo un modo semplice per utilizzare i moduli CommonJS senza un bit sul lato server. Ci sono molte altre soluzioni e se non si è dipendenti dall'esecuzione di file JS statici, i moduli CommonJS standard sono un'ottima soluzione.

(ObDisclaimer: ho iniziato il progetto CommonJS, quindi sono chiaramente di parte.)

+0

Ottima risposta, vorrei poter dare più di un voto. – ide

+3

Per essere pedanti, i moduli di ECMAScript Harmony hanno accesso all'oggetto globale, ma non l'ambito lessicale condiviso di primo livello. –

+2

È possibile scrivere un modulo compatibile sia con requirejs che con commonjs? –