フロントエンドのモジュール化の開発の歴史

原文参照 Yu Bo はマスターです、私はそれを整理しました。

今日のトピックは、主に AMD CMD の開発に関するフロントエンドのモジュラー開発の歴史についてです。これらの 2 つは一種の仕様であり、実際の製品は AMD と RequireJS であり、CMD の製品は seajs です。それらの出現 これらはすべて COMMONjs に基づいて開発されているため、最初に COMMONjs について説明する必要があります。

COMMONJS

2009 年から 2010 年にかけて、CommonJS コミュニティが集まりました。 CommonJS はもともと ServerJS と呼ばれていましたが、Modules/1.0 仕様の導入後、Node.js 環境で非常に優れたプラクティスを実現しました。 2009 年後半、これらの勤勉な専門家は、ServerJS の成功体験をブラウザ側にさらに広めたいと考え、コミュニティの名前を CommonJS に変更し、同時にモジュール仕様の次のバージョンについて激しく議論しました。相違と対立が生まれ、Modules/1.x (完全に 1.0 の機能をベースにし、変換関数を追加しただけ)、Modules/Async、Modules/2.0 の 3 つの主要な流派が徐々に形成されました。

モジュール/1.x 派: この見解は、1.x 仕様で十分であり、ブラウザーに移植するだけで十分であると考えています。行う必要があるのは、新しいモジュール/トランスポート仕様を追加することです。つまり、変換ツールを使用してモジュールをブラウザ上で実行する前にトランスポート仕様に準拠するコードに変換します。現在、注目に値する実装が 2 つあります: コンポーネントと es6 モジュールです。

Modules/Async 派: この見解は、ブラウザーには独自の特性があり、Modules/1.x 仕様を直接使用すべきではないと考えています。この観点の典型的な代表例は、AMD 仕様とその実装である RequireJS です。これについては後で詳しく説明します。

Modules/2.0 派: この見解は、ブラウザには独自の特性があり、Modules/1.x 仕様を直接使用すべきではなく、可能な限り Modules/1.x 仕様と一致する必要があると考えています。この観点の典型的な代表者は、BravoJS と FlyScript の作成者です。 BravoJS の作成者は CommonJS コミュニティに多大な貢献をしてきました。 FlyScript の作者は、CMD 仕様の前身である Modules/Wrappings 仕様を提案しました。 BravoJS が学術的すぎて、後に FlyScript が自己去勢されて Web サイト全体 (flyscript.org) がオフラインになったのは残念です。この物語は少し悲劇的なので、詳しくは述べません。

上記の 3 つの主要な流派は、Modules/2.0 から始まった製品がすべて問題なく終了したことを意味します。当時は Modules/1.x 標準 ES6 がまだ成熟していませんでした。 Modules/Async を標準とした RequireJS の開発が非常に活発です。

ただし、AMD の RequireJS の実行タイミングには異論があり、モジュールの記述スタイルは物議を醸しており、CommonJS コミュニティによって認識されていません。これら 2 つの点について詳しく説明します。

で事前に a.js をダウンロードします。 AMD にはブラウザの制限があり、コミュニティによって認識されている同期ダウンロードを実現する方法はありません。ただし、AMD では事前に実行され、基本的な Modules/1.0 仕様では必要なときに実行されます。初めて。 Modules/2.0 の見解を持っている人を含め、多くの人はこの違いを受け入れることができません。また、この違いは、Node モジュールと AMD モジュールを共有できないという事実にもつながり、潜在的な対立が生じます。もう 1 つ、つまり、モジュールの記述スタイルが物議を醸しています

AMD スタイルでは、パラメーターを介して依存モジュールを渡すことは、近接性宣言の原則に違反します。近接性の原則は、モジュールが宣言する必要がなく、使用される場合にのみ使用されることを意味します。事前にモジュールを用意しておいてください。最後に、AMD は CommonJS コミュニティから分離し、単独の AMD コミュニティになりました。後で、RequireJS が特に人気があることがわかります

実際、この時点で、それは CommonJS コミュニティの AMD 仕様から独立し、本質的に RequireJS コミュニティに進化しました。その後、RequireJS コミュニティで require メソッドを使用したいと報告する人がたくさんいましたが、最終的には RequireJS の作成者が妥協し、これが中途半端なサポートを得る唯一の方法でした。 (これは疑似サポートであり、その背後には早期実行などの AMD の動作ロジックが存在することに注意してください) AMD の人気は RequireJS 作者の昇進に大きく依存しており、AMD 仕様の進化は RequireJS から切り離せません。

Modules/2.0

BravoJS の作者である Wes Garland は、深いプログラミング スキルを持っており、CommonJS コミュニティでも非常に尊敬されています。しかし、BravoJS 自体は非常に学術的なものであり、Modules/2.0 ドラフト仕様を実証するために書かれたプロジェクトです。この大学は実用的な RequireJS に対して脆弱であり、今では基本的に良い思い出しか残っていません。

現時点では、Modules/2.0 陣営には実用的な派閥もあります。FlyScript は、非常に簡潔な Modules/Wrappings 仕様を提案しています。この簡潔な仕様は、ブラウザーの特殊性を考慮しており、可能な限り互換性もあります。 Modules/1.0 仕様に準拠します。悲しいことに、FlyScript が公式バージョンと公式 Web サイトを立ち上げた後、当時は RequireJS がブームになっていました。この期間中、FlyScript の作者と RequireJS の作者 James Burke の間でいくつかの議論がありました。その後、FlyScript の作者は自己去勢を行い、GitHub 上でプロジェクトと公式 Web サイトをクリアしました。そのとき、彼は次のような一文を公式 Web サイトに残しました。

より良いものを持って帰ってきます。

その間に具体的に何が起こったのかは不明です。その後、Yu おじさんは FlyScript の作者にメールを送って尋ねたところ、相手は私が尊敬する 2 つの理由を教えてくれました:

1. 私はフロントエンドの出身ではありません。RequireJS の作者である James Burke は私よりもブラウザーについてよく知っています。

2. たとえそれがあなたの好みではないとしても、私たちはコミュニティの発展を促進するために協力すべきです。

以上がフロントエンドのモジュール化の開発の歴史の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。