概要#

Rspack を選ぶ理由?#

Rspack は当初、複雑なバンドル要件を持つ大規模なモノリシックアプリプロジェクトを多数維持している技術会社である ByteDance で発生したパフォーマンス問題を解決するために作成されました。本番環境のビルド時間は 10 分、場合によっては 30 分にもなり、コールドスタート時間は数分を超えることもありました。多くのバンドラーと最適化のアイデアを試した後、共通の要件セットが浮かび上がりました。

• 開発モードの起動パフォーマンス。 npm run dev は、開発者が 1 時間に何度も呼び出す可能性があるコマンドです。起動時間が 10 ～ 15 秒を超えると、エンジニアリングの生産性が低下します。
• 高速ビルド。 npm run build は CI/CD パイプラインで使用され、マージの生産性とアプリケーションの配信時間に直接影響します。大規模なアプリケーションでは、これらのパイプラインの実行に 20 ～ 30 分かかる場合があり、バンドル時間が主な要因であることがよくあります。
• 柔軟な構成。 さまざまな人気のあるバンドラーを試してみたところ、現実のプロジェクトに対応しようとすると、1 つの構成ですべてを解決することは多くの問題に直面することがわかりました。 webpack の大きな利点は、柔軟性があり、各プロジェクトのカスタマイズされた要件に対応しやすいことです。これは、webpack から移行しようとするレガシープロジェクトに大きな移行コストをもたらす可能性があります。
• 本番環境での最適化機能。 既存のバンドルソリューションにはすべて、十分にきめ細かいコード分割など、本番環境向けに最適化する場合にさまざまな制限がありました。 Rspack には、マルチスレッドなどの Rust 固有の機能を活用して、これらの最適化をゼロから再考する機会があります。

Rspack の現状#

2024 年 8 月現在、webpack の API と機能のほとんどをカバーしているため、本番環境に対応できるとみなしている Rspack 1.0 をリリースしました。

Rspack は現在、コミュニティのほぼすべてのローダーと互換性があります。最もダウンロードされている webpack プラグイン 50 個のうち、80% 以上が Rspack で使用できるか、代替手段があります。

Rspack の最新情報については、Rspack ブログ を参照してください。

Rspack の将来#

Rspack はすでに多くのプロジェクトのニーズを満たしていますが、webpack のすべての機能に到達するにはまだいくつかのギャップがあります。優先順位はコミュニティからのフィードバックに基づいて決定されるため、ご要望をお聞かせください!

コミュニティパートナーとのコラボレーション#

Rspack の真のパフォーマンスの利点を引き出すために、コミュニティ内のフレームワークチームやツールチェーンをサポートすることを非常に喜んでいます。フレームワークまたはツールチェーンに高性能なビルドエンジンの需要がある場合は、お知らせください!

プラグイン機能の強化#

Rspack はすでに完全な Loader インターフェースと webpack プラグイン API のほとんどを実装しています。私たちの目標は、プラグイン API の 100% の互換性を実現することではありませんが、コミュニティからのフィードバックに基づいて主流の要件を実装するよう最善を尽くします。同時に、プラグイン通信のコストを削減し、より多くのプラグイン API を実装できるように、高性能なプラグイン通信ソリューションも模索しています。

継続的なパフォーマンスの改善#

パフォーマンスは、Rspack 開発の核となるセールスポイントであり、焦点です。将来的には、より高性能な同時実行/マルチコア対応アルゴリズム、より高性能なキャッシュソリューション、より高性能なプラグイン通信ソリューションなどを模索します。

テストスイートの拡張#

今日、Rspack は主に webpack のテストケースのサブセットを使用してテストされています。将来的には、これらのテストをさらにカバーするとともに、テストスイートを拡張し、コミュニティプロジェクトを含めて、Rspack リリース全体での互換性を確保します。

webpack との比較#

webpack はおそらく最も成熟した最新のバンドラーであり、活発なエコシステム、柔軟な構成、豊富な機能を備えています。

• Rust 言語の効率性: webpack の競合他社は、特に大規模なプロジェクトでは、パフォーマンスに基づいて頻繁に webpack に異議を唱えています。 Rspack は、パフォーマンスを優先するように特別に設計された Rust 言語を使用してこれを解決し、速度とメモリ管理の両方でベンチマークを上回っています。 Rust は、C++ などの他のネイティブ言語の一般的な落とし穴を回避するための多くのコンパイラの安全対策も提供します。

• 高度に並列化されたアーキテクチャ: webpack は、JavaScript のマルチスレッドのサポートが弱いという制限を受けています。対照的に、Rspack のネイティブコードは、最新のマルチコア CPU を最大限に活用します。

• 不可欠なバンドル機能の組み込み実装: webpack のフックシステムは、コミュニティによって貢献された膨大な数のローダーとプラグインを可能にすることで有名です。残念ながら、これらのサードパーティパッケージは、著者が webpack の内部構造に関する深い知識を持っていない場合や、フックシステムが本質的にアルゴリズムの相互作用を制限しているために、パフォーマンスのボトルネックにつながることがよくあります。 Rspack は、パフォーマンスを向上させるための主要な機能の組み込みプラグインを提供します。

• 最適化されたホットモジュールリプレイスメント (HMR): プロジェクトの規模に関係なく、HMR の優れたエクスペリエンスを確保するには、通常のバンドルよりもビルド時間がさらに厳しく要求されます。 Rspack には、この要件に対処するための特別な増分コンパイル戦略が組み込まれています。

Vite との比較#

Vite は優れた開発者エクスペリエンスを提供しますが、本番環境のビルドで Rollup に依存しているため、他の JavaScript ベースのアルゴリズムと同様のパフォーマンスコストに直面します。 webpack と Rollup の同じトレードオフも適用されます。たとえば、optimization.splitChunks 機能の柔軟性の欠如などです。

esbuild との比較#

esbuild は、一部の JavaScript プラグインを除いて、ほぼすべての操作を Golang で実装することにより、非常に優れたパフォーマンスを実現しています。ただし、esbuild の機能セットは、HMR や optimization.splitChunks 機能がないなど、webpack ほど完全ではありません。

Turbopack との比較#

Turbopack は Rspack のように Rust で実装されていますが、Turbopack は再設計されたアーキテクチャと構成で最初からやり直しました。これにより、いくつかの利点がありますが、webpack とその広範なエコシステムに依存するプロジェクトにとっては、移行コストがより高くなります。

Rollup との比較#

RspackとRollupはどちらもバンドルツールですが、その焦点とする領域が異なります。Rollupはライブラリのバンドルに適しており、Rspackはアプリケーションのバンドルに適しています。そのため、RspackはHMRやバンドル分割など、アプリケーションのバンドルに特化した多くの機能を最適化しています。Rollupは、Rspackよりもライブラリに適したESM出力を生成します。また、コミュニティにはRollupをある程度カプセル化し、viteやwmrのようにアプリケーションのバンドルに対してよりフレンドリーなサポートを提供するツールも多く存在します。現在、RspackはRollupよりもプロダクションビルドのパフォーマンスが優れています。

Parcelとの比較#

Rspackの全体的なアーキテクチャは、Parcelと多くの類似点を共有しています。例えば、どちらもCSSアセットをファーストクラスの要素として扱い、フィルターベースのトランスフォーマーをサポートしています。しかし、Parcelはすぐに使えるユーザビリティに重点を置いており、Rspackはより高レベルなフレームワークやツールに対して柔軟な構成を提供することに重点を置いています。ParcelはUnified GraphやHTMLをファーストクラスの要素にするなどの革新的な機能を設計しました。Rspackも将来的にこれらの機能をサポートする予定です。

次のステップ#

Rspackを使い始めるには、クイックスタートをお読みください。

私たちとのコミュニケーションには、GitHub DiscussionsとDiscordをご利用ください。