なぜVite
問題
ESモジュールがブラウザで利用可能になる前に、開発者にはJavaScriptをモジュール化された方法で執筆するためのネイティブメカニズムがありませんでした。これが、「バンドリング」の概念に精通している理由です。これは、ソースモジュールをブラウザで実行できるファイルにクロール、プロセス、連結するツールを使用しています。
時間が経つにつれて、 Webpack 、 Rollup 、 Parcelなどのツールを見てきました。これにより、Frontend開発者の開発エクスペリエンスが大幅に向上しました。
ただし、ますます野心的なアプリケーションを構築するにつれて、扱っているJavaScriptの量も劇的に増加しています。大規模なプロジェクトが何千ものモジュールを含めることは珍しくありません。 JavaScriptベースのツーリングのパフォーマンスボトルネックにヒットし始めています。多くの場合、開発サーバーをスピンアップするのに不当に長い待ち時間（時には数分！）がかかります。ホットモジュールの交換（HMR）であっても、ファイルの編集には数秒かかることがあります。遅いフィードバックループは、開発者の生産性と幸福に大きな影響を与える可能性があります。
Viteは、エコシステムでの新しい進歩を活用することにより、これらの問題に対処することを目的としています。ブラウザでのネイティブESモジュールの可用性、およびコンパイルツーネイティブ言語で記述されたJavaScriptツールの台頭です。
サーバーのスタートが遅い
開発サーバーをコールドスタートするとき、バンドラーベースのビルドセットアップは、提供する前にアプリケーション全体を熱心にクロールして構築する必要があります。
Viteは、最初にアプリケーションのモジュールを2つのカテゴリの2つのカテゴリに分割することにより、DEVサーバーの開始時間を改善します。依存関係とソースコード。
依存関係は、ほとんどが開発中に頻繁に変化しない単純なJavaScriptです。いくつかの大規模な依存関係（たとえば、数百のモジュールを持つコンポーネントライブラリなど）も、処理するのに非常に費用がかかります。依存関係は、さまざまなモジュール形式（ESMまたはCommonJSなど）で出荷される場合があります。
esbuildを使用したVite Pre-Bundles依存関係。 Esbuildは、JavaScriptベースのバンドラーよりも10〜100倍速い依存関係とプリバンドルの依存関係で書かれています。
ソースコードには、多くの場合、変換が必要な非プレーンJavaScript（JSX、CSS、またはVUE/SVELTEコンポーネントなど）が含まれており、非常に頻繁に編集されます。また、すべてのソースコードを同時にロードする必要があるわけではありません（例:ルートベースのコードスプリッティングを使用）。
Viteは、ネイティブESMを介したソースコードを提供します。これは、基本的にブラウザがバンドラーの仕事の一部を引き継ぐことです。VITEは、ブラウザが要求するように、ソースコードをオンデマンドで変換して提供する必要があります。条件付き動的インポートの背後にあるコードは、現在の画面で実際に使用された場合にのみ処理されます。
遅い更新
ファイルがバンドラーベースのビルドセットアップで編集されると、明らかな理由でバンドル全体を再構築することは非効率的です。更新速度は、アプリのサイズとともに直線的に劣化します。
一部のバンドラーでは、DEVサーバーはメモリでバンドリングを実行するため、ファイルが変更されたときにモジュールグラフの一部を無効にする必要がありますが、バンドル全体を再構築してWebページをリロードする必要があります。バンドルの再構築は高価になる可能性があり、ページをリロードすると、アプリケーションの現在の状態が吹き飛ばされます。これが、一部のバンドラーがホットモジュールの交換（HMR）をサポートする理由です。ページの残りに影響を与えることなくモジュールが自体を「ホット交換」できるようにします。これによりDXが大幅に改善されますが、実際には、HMRの更新速度でさえ、アプリケーションのサイズが大きくなるにつれて大幅に低下することがわかりました。
Viteでは、HMRはネイティブESMを介して実行されます。ファイルが編集される場合、Viteは編集されたモジュールとその最も近いHMR境界（ほとんどの場合モジュール自体のみ）の間のチェーンを正確に無効にする必要があり、アプリケーションのサイズに関係なくHMRの更新を一貫して高速にします。
また、ViteはHTTPヘッダーを活用してフルページのリロードをスピードアップします（繰り返しますが、ブラウザにさらに作業を行わせます）:ソースコードモジュール要求は304 Not Modifiedを介して条件付きになり、依存モジュール要求はCache-Control: max-age=31536000,immutableを介して強くキャッシュされるため、キャッシュされた後にサーバーを再びヒットしません。
Viteの速さがどれほど速いかを経験したら、バンドルされた開発に再び我慢しても構わないと疑っています。
生産用バンドルの理由
ネイティブESMは現在広くサポートされていますが、生産中の未解除ESMの発送は、ネストされた輸入によって引き起こされる追加のネットワークラウンド旅行のため、依然として非効率的（HTTP/2であっても）です。生産で最適な読み込みパフォーマンスを取得するには、ツリーシェーキング、レイジーロード、一般的なチャンク分割（より良いキャッシングのため）でコードを束ねる方が良いです。
開発サーバーと生産ビルド間の最適な出力と行動の一貫性を確保することは容易ではありません。これが、多くのパフォーマンスの最適化を箱から出して焼く事前に構成されたビルドコマンドを備えたViteが出荷する理由です。
Esbuildにバンドルしてみませんか？
ViteはESBUILDを活用してDEVのいくつかの依存関係を事前に抑えることができますが、Viteは生産ビルドのバンドラーとしてEsBuildを使用していません。
Viteの現在のプラグインAPIは、 esbuildバンドラーとして使用することと互換性がありません。 esbuildがより高速であるにもかかわらず、ViteがRollupの柔軟なプラグインAPIとインフラストラクチャの採用は、エコシステムでの成功に大きく貢献しました。とりあえず、Rollupはより良いパフォーマンスと柔軟性のトレードオフを提供すると信じています。
Rollupは、パフォーマンスの改善にも取り組んでおり、 V4でパーサーをSWCに切り替えています。そして、Rolldownと呼ばれるRustport of Rollupを構築するための継続的な取り組みがあります。 Rolldownの準備ができたら、ViteでロールアップとEsbuildの両方を置き換え、ビルドパフォーマンスを大幅に改善し、開発とビルドの間の矛盾を削除できます。詳細については、Evan You's ViteConf 2023 Keynoteをご覧ください。
Viteは他のバンドルされていないビルドツールとどのように関係していますか？
PREACTチームによるWMRは、同様の機能セットを提供するように見えました。 ViteのUniversal RollupプラグインAPI for Dev and Buildは、それに触発されました。 WMRは維持されなくなりました。 PREACTチームは、 @preaCtjs/Preset-Viteを使用してViteを推奨しています。
Snowpackは、バットのないバンドルネイティブのESM開発サーバーでもあり、Viteと非常に似ています。 Viteの依存関係バンドリングは、Snowpack V1（現在esinstall ）にも触発されています。雪だるまはもはや維持されていません。 Snowpackチームは現在、Viteを搭載した静的サイトビルダーであるAstroに取り組んでいます。
@web/dev-server （以前はes-dev-server ）は素晴らしいプロジェクトであり、Vite 1.0のKOAベースのサーバーセットアップはそれに触発されました。 @web傘プロジェクトは積極的に維持されており、Viteユーザーにも利益をもたらす可能性のある他の多くの優れたツールが含まれています。