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

原文参照 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. たとえそれがあなたの好みではないとしても、私たちはコミュニティの発展を促進するために協力すべきです。

この二つの文はユウおじさんに大きな影響を与えました。 RequireJS についてじっくり勉強するようになり、メールなどで RequireJS にさまざまな提案をするようになったのもそれからです。その後、実際に RequireJS を使用する中で、多くの落とし穴に遭遇しました。 RequireJS は当時非常に人気がありましたが、実際には完璧ではありませんでした。この間、私は FlyScript が去ったときに言ったことについても考えていました。「私はより良いものを持って戻ってきます。」

Yu おじさんは、私は FlyScript の作者ほど偉大ではないと言い、RequireJS についての提案をし続けました。 、しかし彼は受け入れられませんでした。それを採用した後、私は自分でローダーを書くという考えを持ち始めました。

SeaJSです。 SeaJS は、FlyScript の module.declare 改名为 define など、RequireJS から多くのものを借用しています。 SeaJS はモジュール/2.0 の観点から作られていますが、学術的なものはできる限り削除され、多くの実践的なアイデアが追加されています。これは CMD、SeaJs の間接的な製品です。

さて、これで基本的な歴史は終わりました。私が言ったことを理解できるかどうかはわかりませんが、大まかにまとめると、COMMONJS はサーバー側で使用されるため、使用できません。この仕様をブラウザでどのように使用するかについては、新しいものには必ず議論があり、異なる概念や議論が生じるため、AMD にはブラウザに適した CMD 仕様が存在しません。 COMMONJS コミュニティによって認知され、最終的には独立して運用されました。もちろん、その後、CMD の製品である seajs が Yu Bo によって開発されました。

もちろん、これら 2 つの製品はまだ使用されていますが、Webpakc は 3 つの仕様を完全にサポートしています。 、これはフロントエンドのモジュール性の発展の歴史です。フロントエンドの歴史的な発展を理解することは初心者にとっても必要です。実際、元の記事は、誰でも理解しやすいように、私自身のバージョンに変更したものです。ここでは、フロントエンドのモジュール化の歴史に関する情報を検索することもできます。なぜモジュール化が必要なのかを最初に理解することができ、質問しながら学ぶとより早く習得できます。

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