少し前に、ネチズンはフロントエンドでrequirejsとseajsを使用することについて尋ねました。私は彼に、あなたの会社が以前にそれ自体で書かれたJavaScriptライブラリまたはJavaScriptフレームワークを持っているかどうか尋ねました。彼の答えは何もなかった。彼は、requirejsとseajsが新しいものと新しいテクノロジーであり、非常に貴重なものであると聞いたので、彼はそれを使いたいと思っていました。
このネチズンの問題により、JavaScriptモジュールのロードテクノロジーについて考えるようになりました。最後の記事では、書いたJavaScriptライブラリの基本構造を示しました。実際、この記事を書く理由の1つは、JavaScriptライブラリの基本モデルを再設計するために、requirejsやSeajsなどのテクノロジーを使用したいということです。このテクノロジーを詳細に知ることができた後、モジュールロードシステムを使用して、JavaScriptライブラリの共通コードとビジネスコードを切り離す問題を解決することが間違っていることがわかりました。モジュールロードシステムの範囲は、JavaScriptライブラリの開発方法を支援するのではなく、異なるJavaScriptライブラリ間の依存関係の問題を解決することです。
では、JavaScriptモジュールロードシステムとは何ですか？
モジュールシステムは、主に、異なるJavaScriptライブラリの操作オブジェクトの命名競合問題と、異なるJavaScriptライブラリ間の依存関係の問題を解決するために使用されます。モジュールロードシステムは、大規模なWebフロントエンドアプリケーションまたは巨大なWebフロントエンドアプリケーションを対象としています。
一般的に、巨大なWebフロントエンドアプリケーションページでは、ページには非常に豊富な機能と複雑なビジネスがあります。さらに、時間が経つにつれて、ページの関数はしばしば変更され、フロントエンドの開発者が新しい機能のために機能的なモジュールを開発することがよくあります。ただし、実際のビジネスのさまざまな機能モジュール間の機能は、互いに浸透し、互いに依存し、複雑な関係を持つ場合もあります。ページが複雑な場合、各フロントエンドライブラリ間の関係を管理および制御することは困難であり、モジュールローディングシステムはこの時点で役立ちます。
ほとんどのプログラマーにとって、このような大きなWebフロントエンドアプリケーションを独立して耐える機会はあまりありません。また、中小規模のWebフロントエンドアプリケーションを開発する多くの機会があります。たとえば、エンタープライズレベルのWebプロジェクトでは、そのようなプロジェクトで使用されるJavaScriptライブラリにはほとんどほとんどありません。各ライブラリの依存関係は簡単に制御できるため、モジュール管理システムを導入する必要はありません。多くの中小規模のインターネット企業のWebページでさえ、おそらくエンタープライズレベルのWebアプリケーションのフロントエンドのWebページほど複雑ではないため、モジュールまたはJavaScriptライブラリの関係は簡単に管理できます。実際、上記の中小アプリケーションはすべて、特定のシナリオまたは特定のシナリオ向けです。したがって、私は個人的に、このようなWebフロントエンドプロジェクトに直面して、最終的に独立したJavaScriptライブラリを形成できると思います。このライブラリの特性は、ライブラリのタイプの特性と似ている必要があります。メインライブラリといくつかのプラグインライブラリです。メインライブラリの目的は、一般性の問題を解決することであり、再利用可能で移行する必要があります。プラグインライブラリの目的は、多くの場合、ビジネスコードに関連しています。ただし、メインライブラリとプラグインライブラリの範囲を区別するために、名前空間機能をライブラリに追加しました。
JavaScriptモジュールロードテクノロジーとHadoopテクノロジーには、いくつかの類似点があります。つまり、どちらも超大型システムのテクノロジーであり、特定の条件下でのみ役割を果たすことができます。したがって、これらのテクノロジーは、大規模なインターネット企業がアプリケーションがより大きく複雑になった後に問題を解決する必要があるため、大規模なインターネット企業から発売されます。システムがまだ初期段階にある場合、これらのテクノロジーを使用することに慎重になることがよくあります。実際の問題を解決するための最も簡単で最も効果的な方法を見つける必要があります。このシステムが将来大きくなると思われる場合は、将来これらのテクノロジーを使用するためにインターフェイスを保持する必要があります。使用が早すぎると、システムスケールが拡大すると、コードのリファクタリングコストが高くなる可能性が非常に高くなります。
モジュールロードシステムの場合、最も適切なシナリオは、大規模なWebフロントエンドアプリケーションモジュール間のデカップリングの問題を解決することです。新しいJavaScriptファイルを書き留めて、モジュールロードテクノロジーをすぐに使用する場合、これはテクノロジーの乱用ではありません。特定のテクノロジーを使用する前に、使用方法や使用方法を検討するだけでなく、使用することが価値があるかどうかを検討する必要があります。
最後に、私は、小規模および中規模のWebフロントエンドが生産展開に使用されていると思います。 JavaScriptは最も複雑ではないため、すべての外部JavaScriptファイルをJavaScriptの外部ファイルにパッケージ化するのが最善です。この利点は、HTTP要求の数を減らすことです。モジュールの読み込みテクノロジーを使用すると、ファイルをパッケージ化するのが非常に面倒になり、実行できません（requirejsやseajsなどのモジュールはすべてファイルに基づいており、各モジュールは独立したファイルです）。