「歴史は過去ではなく、歴史が上演されています。W3Cとブラウザの急速な発展により、フロントエンドのモジュラー開発は徐々にインフラストラクチャになります。すべてが最終的に歴史になり、未来はより良くなります。」 - 私は個人的にYu Boの元のテキストの最後の段落に同意します。 「未来」について話しているので、フロントエンドJSモジュールが開発され続けている場合、そのモジュール形式は将来のWebの標準仕様になり、複数の実装方法を作成する可能性が高いと個人的に信じています。 JSON形式と同様に、最終的には標準になり、ブラウザによってネイティブに実装されます。
非同期モジュールが未来になるための最良の基準は誰ですか？ SAIJはCMD仕様に従い、AMD仕様に従う必要があり、これら2つの異なる形式から始めましょう。
CMD
CMDモジュール依存関係宣言方法：
コードコピーは次のとおりです。
定義（function（require）{
var a = require（ './ a'）;
var b = require（ './ b'）;
//その他のコード..
}）
CMD依存関係は近くで宣言され、内部要求方法によって宣言されます。ただし、非同期モジュールであるため、ローダーはこれらのモジュールを事前にロードする必要があるため、モジュールを実際に使用する前に、モジュール内のすべての依存関係を抽出する必要があります。ローダー抽出であろうと、自動化されたツールを介した事前抽出であろうと、CMDのこの依存宣言形式は、CMDの欠点である静的分析によってのみ実装できます。
CMD仕様の短所
直接圧縮できません：要求はローカル変数です。つまり、圧縮ツールを介して直接圧縮することはできません。必要な変数が交換されている場合、ローダーと自動化ツールはモジュールの依存関係を取得できません。
モジュールには追加のコンベンションがあります。パスパラメーターは文字列操作ではなく、代わりに変数を使用することはできません。そうしないと、ローダーと自動化ツールはパスを正しく抽出できません。
仕様の外側の規則は、仕様の一部ではない限り、より多くのドキュメントを意味します。
注：SEAJS静的分析の実装は、通常の抽出要件パートを使用して、依存関係モジュールパスを取得することです。
AMD
AMDモジュール依存関係宣言方法：
コードコピーは次のとおりです。
定義（['./ a'、 './b']、function（a、b）{
//その他のコード..
}）
AMDの依存関係は事前に宣言されます。この利点の利点は、依存関係が静的分析を必要としないことです。ローダーと自動化ツールの両方が依存関係を直接取得できます。仕様の定義はより単純です。つまり、より強力な実装が生成される可能性があります。これは、ローダーと自動化分析ツールの両方にとって有益です。
AMD仕様の短所
依存関係の事前宣言は、コードライティングではそれほどフレンドリーではありません。
内部モジュールとnodejsのモジュールには一定の違いがあります。
2番目の問題を詳細に説明する必要があります。実際、CMDもAMDの非同期モジュールも、同期モジュール仕様（NodeJSのモジュール）と一致することはありません。 AMDを同期モジュールに変換するには、定義関数のパッケージを削除することに加えて、依存関係を宣言するためにヘッドに必要なものを使用する必要がありますが、CMDは定義関数のパッケージを削除する必要があります。
要約します
仕様に関しては、AMDはよりシンプルで厳密であり、より広範な適用性があります。 requirejsの強力な昇進により、それはほぼ事実上非同期モジュールの海外の標準的なモジュールになっており、主要な図書館はAMD仕様を連続してサポートしています。
しかし、SeajsとCMDから、私たちは多くの良いことをしました：
1.比較的自然な依存書類のステートメントスタイル
2。小さくて美しい内部的な実現
3.慎重な末梢機能設計
4.より良い中国のコミュニティサポート
可能であれば、SEAJがAMDもサポートしていることを望んでいます。開発者の究極の幸福は開発者の大部分です。