-1

私の理解では、適切にファクタリングされたモジュラー コードの利点は、再利用性と整理です。1 つのファイルにまとめて書かれたコードは読みにくく、コードの小さな部分を再利用するには、ステートメントを含めるのではなく、慎重にコピーして貼り付ける必要があります。

特に Javascript に関しては、最近ある例を見て考えさせられました。ページごとに条件付きでJavaScriptを含めていない場合、これは「JSコードを適切にモジュール化することに失敗したことを表します」という趣旨のSOに関するコメントが作成されました。ただし、コードの再利用と構成の観点からすると、ページの読み込み時に何が起こるかを考慮する必要はありません。コードは、多数の個別のファイルに記述され、提供される前に一緒にマッシュされて縮小された場合でも、同じように読みやすくなります。たとえば、rails アセット パイプラインはまさにこれを行います。

初めてアセット パイプラインに出会ったとき、私の頭はぐらぐらし、「必要なときにのみ JavaScript をロードするにはどうすればよいか」と考え始めました。私はいくつかの SO の質問とその問題に関する記事を読み、コードが「コンパイル」された後に何が起こるかについて心配する必要はないのではないかと考え始めました。

モジュール式のコードを書く目的は、純粋に人間レベルの活動ですか?コードが実行され始めたら、モジュール性について心配するのをやめるべきですか? Javascript の場合、スクリプトが含まれる前にマッシュアップされていることを心配する必要がありますか?

4

2 に答える 2

2

パフォーマンスに関して、あなたが実際に話していないことの 1 つは、実際の HTML ブラウザーのダウンロード動作だと思います。ページごとに必要な JavaScript のみを表示することと、ブラウザのキャッシュとダウンロード動作を利用することの間で微妙な境界線を踏む必要があると思います。

たとえば、すべてのページで使用される 20 個の異なる JavaScript スニペットがあるとします。この場合、ブラウザーがダウンロードする必要があるファイルが少ないほど良いため、それらを単一のファイルにコンパイル/縮小するのは簡単です。この単一のファイルはキャッシュすることもできます。つまり、それが静的ファイルであると仮定するか、動的にコンパイルされている場合は (送信されたヘッダーを介して) 静的であるように見えます。

20 個のスニペットのうち、15 個はすべてのページで使用され、残りは断続的に使用されます。もちろん、常に使用される 15 個のスニペットすべてを 1 つのファイルに入れます。しかし、他の人はどうですか？私の意見では、ファイルのサイズと使用頻度を考慮する必要があります。それらが小さく、比較的頻繁に使用される場合は、後でコンテンツをダウンロードするための追加の要求が必要になるため、メイン ファイルの余分なサイズよりも重要であると考えて、それらをメイン ファイルに入れることを検討するかもしれません。コードが大きい場合は、必要な場合にのみ使用する傾向があります。もちろん、一度使用すると、キャッシュに残ります。

このアプローチは、通常、ユーザーがセッションごとに複数のページを読み込むことが予想される Web アプリケーションに最適です。もちろん、広告のランディング ページや、ユーザーがその 1 つのページしか見ることができないようなものを設計している場合は、最初の javasciprt ダウンロードをできるだけ小さく保ち、ユーザーの操作に基づいて必要に応じて新しい JavaScript をロードするだけに頼るかもしれません。

于 2013-03-29T22:57:00.623 に答える
0

この質問のすべての側面は、「場合による」に要約されます。

すべてを詰め込むと 80,000 行のコードになるエンタープライズ レベルのアプリケーションを作成していますか?

もしそうなら、そうです、コンパイル時間は膨大になるでしょう。それを<head>ドキュメントに詰め込むと、人々は待ち時間を感じるでしょう.
既にキャッシュされている場合でも、コンパイル時間だけは明白です。

エンドユーザーには決して見えないウィジェットを何十個も書いていますか?
特にモバイルでは？

その場合は、ダウンロード/コンパイル時間を節約し、代わりにコア機能をロードしてから、追加機能をオンデマンドでロードすることをお勧めします。これは、技術に詳しくないエンドユーザーがモバイル インターネットを期待していることがより多くの調査で示されているためです。コンテンツだけでなく、一般的な待ち時間に関しても、デスクトップ エクスペリエンスと同様のエクスペリエンスを提供する必要があります。

モバイル エクスペリエンス (またはモバイルでのデスクトップ エクスペリエンス) に 5 秒から 8 秒を受け入れて対話のポイントに到達することをいとわない人はますます少なくなっています。考え。

繰り返しになりますが、80,000 行のアプリケーション、または 300kB の JS ファイルを持っている場合、または読み込み前に大量の XML 解析などを行っている場合、別のモバイル エクスペリエンスを提供することなく、モバイルでの統計は次のようになります。特に、メディア サイトや商業/小売サイトの場合は。

したがって、あなたの質問に対する正しい答えは、ターゲットデバイス、サイト/アプリケーションの意図、人口統計、コードに基づいて、良いアイデアと悪いアイデアがあることを除いて、あなたの質問に対する正しい答えはないと言うことです. -base、ユーザーがサイトに頻繁にアクセスする (したがって、キャッシュされたアセットの恩恵を受ける) という予測、コードベースの更新の頻度 (1 つの更新されたモジュールと 20 のキャッシュされたモジュールを含む) 対、完全に無効な 21 モジュールのチャンク。 250,000 人の顧客ベースを持つ 1 つの更新されたラインは、いくつかの理由から検討事項です)...

...もっと...

あなたが何をしているのかを理解してください。
それを実現するために何をする必要があるかを考えてください。
顧客に優れたエクスペリエンスを提供しながら、それを行う方法を考え出してください。

ファイルを結合する方法を知っている。
オンデマンドでロードする方法を理解する。
モジュールをインテリジェントにロードできる (および/または require/AMD を学習できる) 軽いブートストラップを構築する方法を知っている。
これらをツールとして使用して、達成しようとしていることに応じて、可能な限り最高のエクスペリエンスをユーザーに提供してください。

于 2013-03-29T22:53:12.543 に答える