SeaJSとRequireJSの異同

同じ点は、解決すべき問題は同じで、ブラウザ側のモジュール化開発であり、目標は一致している.
違いは少なくありません.
1.遵守する規範が異なる
RequireJSはModules/AMDの仕様に従っています.
SeaJSはMdoules/Wrappings規格のdefine形式に従っている.
AMD規範はCommonJSコミュニティで議論が大きく、規範にはRequireJSの影が多すぎる.コミュニティの中で多くの人はRequireJSがCommonJSのスローガンを打っていることに反感を持って、AMDが自立することを提案して、例えば最近のこの討論:Split off AMD?
この2つの仕様自体から言えば、Modules/Wrappings仕様はより簡潔で優雅で、信じなければ、それぞれの説明を読むと分かります.
2.factoryの実行タイミングが異なる
RequireJSでは、モジュールにはいくつかの書式がありますが、推奨されています.
1
2
3
4 define(["./a", "./b"], function(a, b) {    a.doSomething();    b.doSomething(); });
SeaJSでは、モジュールには1つの書式しかありません.
1
2
3
4 define(function(require, exports, module) {    require("./a").doSomething();    require("./b").doSomething(); });
SeaJSのモジュール書式は、RequireJSでもサポートされています.議論を容易にするために、defineメソッドのfunctionパラメータをモジュールのfactoryと呼ぶ.RequireJSでもSeaJSでもfactoryを実行する前に、依存するモジュールがダウンロードされていることを確認します.
1
2
3
4
5
6
7
8 /* a.js */ define(factory);
  /* b.js */ define(factory);
  /* c.js */ define(['./a', './b'], factory);
各モジュールには独自のfactoryがあります.AMDの書き込みフォーマットでは、上記の例では、モジュールcのfactoryが実行されると、aとbの2つのパラメータが受信される.これは、c依存のすべてのモジュールが、実行を必要としない可能性がある場合でも、最初から実行されなければならないことを意味します.例えば、
1
2
3
4
5
6
7
8
9 define(function(require) {     // BEGIN    if(some_condition) {      require('./a').doSomething();    } else {      require('./b').soSomething();    }    // END });
AMD仕様では、BEGINではaとbのfactoryが実行されています.Wrappings仕様では、BEGINではaとbのfactoryはまだ実行されておらず、ENDでは条件によりどちらかしか実行されません.
Wrappingsの仕様はより「怠け者」であり、CPUを節約していることがわかる.nodejsなどの環境での使用習慣に合っています.
AMD仕様は、先行実行のみを採用しており、著者の説明:Standards and proposals for JavaScript Modules and jQueryを参照して、2つの理由について言及したが、コミュニティに認められていない.個人的にはトレードオフだと思いますが、Modules/1.0仕様との調和性を破壊する悪いトレードオフです.興味深いのはGoogle Groupを検索することができ、かなりの議論があります.
Wrappings仕様はModules/1.0仕様の習慣をできるだけ残しています.トレードオフポイントは、条件文のrequireについて:
1
2
3
4
5 if(true) {    require('./a').doSomething(); } else {    require('./b').soSomething(); }
nodeなどの環境では、ファイルを直接同期して読み取ることができ、モジュールaのみをロードして実行することができ、モジュールbをロードしないことができるが、ブラウザ側では、これを実現することは困難である(Jscexのような方法で実現できるが、複雑度が急増する).現実に直面して、現在の基本的なすべてのブラウザ側のloaderは、依存するモジュールをダウンロードしています.パッケージ導入の観点から、パフォーマンスに影響を与えることなく、異なる条件でブランチし、同じキャッシュを共有できます.Wrappings仕様の事前ダウンロードと遅延実行は、合理的なバランスです.
3.設計理念が異なる
RequireJSを使用したことがある場合は、次のようなrequireメソッドが非常に柔軟であることがわかります.
1
2
3
4 require('a')  -- gets exports of module a require(['a']) -- fetch module a according to module name scheme require(['a.js'])  -- fetch a.js directly relative to current page require({...})  -- set loader config
少し変わって、やることが违って、个人的には好きではありません.コミュニティにもこのようなスタイルが嫌いな人がたくさんいます.
SeaJSでは、APIのデザインコンセプトは次のとおりです.

は簡単で、職責が単一です.

は規範を守っているが、こだわらない.

適度に柔軟です.

SeaJSの共通APIは8つしかありません:速報マニュアル、職責ははっきりしていて、簡単明瞭です.
規範にこだわらず、SeaJSにはModules/Wrappings規範のmoduleが採用されていないことがわかります.declare. なぜなら、
1
2
3
4
5
6
7 module.declare(function(require, exports, module) {    module.id // module });
  module.declare(function(require, exports) {    module.id // module });
明らかにmoduledeclareはmodule変数をthisと同様に環境の変化に伴って変化させる.初心者にとって、これは迷いをもたらします.直接defineを導入したほうが簡潔明瞭だ.RequireJSの普及に伴い、defineに対する受け入れ度も高く、理解されやすい.もう一つの利点は、SeaJSのモジュールを理論的にはRequireJS上で直接実行できるようにすることです.
適度に柔軟で、例を挙げます.
1
2 seajs.use("./a"); // seajs.use(["./a", "./b"]); //
4.フォーカスポイントに差がある
SeaJSは最初から、今までfocus on webで、ブラウザ側のモジュールローダになるように努力してきました.sea.jsソースコードには、ブラウザに関連するコードしかなく、requirejsのように三掛四ではなく、Rhinoとnodeの下で実行できるようにするコード、さらにはjQueryと統合するためのコードがあります.フォーカスのメリットの1つは、ファイルサイズを減らすことです.
SeaJSの現在のサイズは:3.2 K(gzip)RequireJSのサイズは:5.4 K(gzip)
seajsのソースコードは、現在複数のファイルに分けて開発されており、各ファイルがフォーカスしており、完全なテスト例があります.requirejsは現在も大きなファイルであり、メンテナンスには不利です.
5.最後に、やはり理念が違う
RequireJSには一連のプラグインがあり、機能は強いが、モジュールローダの純粋性を破壊し、個人的には不適切だと思う.
SeaJSはシンプルさを保ち、簡潔さの美しさを追求しようと努力しています.必要がない限り、エンティティを追加しないでください.機能上、SeaJSの利点は、CSSモジュールのロードをサポートすることです.RequireJSは技術的な理由で現在のバージョンは実装されていません.
最後の最後
実際のニーズに合わせて選択すればよいが,モジュール化開発の良い習慣を身につけることが肝心である.
 
変換元:http://lifesinger.wordpress.com/2011/05/17/the-difference-between-seajs-and-requirejs/(必要FQ)