新世代のビルドツールを比較します

過去1年間に多くの新しい開発ツールが上陸し、Webpack、Babel、Rollup、Parcel、Create-React-Appなど、ここ数年でフロントエンド開発を支配してきたツールのすぐ後に噛み付いています。

これらの新しいツールは、まったく同じ機能を実行するように設計されておらず、それぞれに達成しようとしている異なるものとそこに到達する機能があります。違いにもかかわらず、これらのツールは共通の目標を共有しています。開発者エクスペリエンスを改善します。

目次

1. なぜこれらのツールがすべて到着しているのですか？
2. これらは既存のツールとどう違うのですか？
3. 実験
4. 同等の機能
5. esbuild
6. 雪だるま
7. vite
8. WMR
9. 特徴の比較
10. まとめます

具体的には、それぞれを評価して、彼らが何をしているのか、なぜ私たちが必要なのか、そして彼らのユースケースを概説したいと思います。比較は必ずしも公平ではないことを理解しています。繰り返しますが、この記事で私たちが見ていることのいずれかが直接の競合他社であるとはまったく変わりません。実際、SnowpackとViteは、実際に特定のタスクにEsbuildをフードの下で使用しています。私たちの目標は、タスクを実行して仕事を容易にする開発者ツールのランドスケープをよりよく見ることです。このようにして、私たちはそこにどのようなオプションがあるか、どのように積み重ねられているかを見るので、必要なときに最良の選択をすることができます。

もちろん、これらはすべて、ReactとPreactuctを使用して私の経験によって色付けされます。私はこれらのフレームワークライブラリにもっと精通していますが、他のフロントエンドフレームワークへのサポートも検討します。

これらの新しい開発者ツールに関する素晴らしい記事、ストリーム、ポッドキャストがたくさんありました。私がより多くのコンテキストにお勧めするShoptalkショーのエピソードがいくつかあります。エピソード454では、Viteとエピソード448がWMRとSnowpackの作成者を特集しています。これらのエピソードから際立っていることは、開発者環境を近代化するためにこれらのツールを構築するために膨大な量の作業があったことです。

なぜこれらのツールがすべて到着しているのですか？

部分的には、これらのツールはJavaScriptツールの疲労に対する反応として到着していると思います。2016年にJavaScriptを学習することについてこの記事でうまく撮影されたものです。また、単一のバニラJavaScriptファイルを作成することと、自分のコードのラインを書く前に200メガバイトのツーリング依存関係をダウンロードすることとの間に不足している中盤を埋めます。依存関係リストなしではバッテリーが含まれており、JavaScriptエコシステムの層が崩壊する傾向の一部です。

Snowpack、Vite、およびWMRはすべて、ブラウザ内のネイティブJavaScriptモジュールによってすべて有効になっています。 2018年に、Firefox 60は、デフォルトでECMAScript 2015モジュールを有効にしてリリースされました。それ以来、すべての主要なブラウザエンジンは、ネイティブJavaScriptモジュールをサポートしています。 Node.jsは、2019年11月にネイティブJavaScriptモジュールも出荷されました。2021年には、ネイティブJavaScriptモジュールが今日ロック解除されている可能性をまだ発見しています。

これらは既存のツールとどう違うのですか？

開発サーバーにWebpack、ロールアップ、または小包を使用するかどうかにかかわらず、ツールはソースコードとnode_modulesフォルダーからコードベース全体をバンドルし、Babel、TypeScript、またはPostCSSなどのビルドプロセスを通じてこれらを実行し、バンドルコードをブラウザにプッシュします。これにはすべて作業が必要であり、キャッシュと最適化に陥ったすべての作業の後でも、開発サーバーをより大きなコードベースでクロールするためにサーバーを遅くすることができます。

Snowpack、Vite、およびWMR開発サーバーは、このモデルに従いません。代わりに、ブラウザがインポートステートメントを見つけてモジュールに対してHTTPリクエストを行うまで待ちます。このリクエストが作成された後にのみ、ツールは要求されたモジュールとモジュールのインポートツリー内のリーフノードに変換を適用し、ブラウザに提供します。これにより、開発サーバーにプッシュする過程で作業が少ないため、事態が大幅に高まります。

この写真にはEsbuildがないことに気付くでしょう。何よりもまずバンドラーです。他のツールのやり方では、サイドステップバンドルはありません。代わりに、ESBUILDは、高価な変換を回避し、並列化を活用し、GO言語を使用することにより、コードを非常に高速に処理します。

実験

React Docsのサンプルアプリの1つを取り、この記事でカバーされている各ツールで再構築しました。私が一緒に行ったプロジェクトは、ヨギタ・ヴェルマによるスナップショットでした。以下は、元のリポジトリへのリンクと、それぞれ異なるビルドツールを使用して、4つのバージョンのスナップショットを使用したリポジトリへのリンクです。後で各ビルドステップの出力を比較します。このアプリを再構築することで、ReactルーターやAxiosなどのかなり標準のReact依存関係をツールに引き込むという開発者エクスペリエンスをテストすることができました。

同等の機能

個々のツールの詳細に入る前に、それらはすべて、次の機能をボックスからサポートしています（さまざまな程度）：

• ネイティブJavaScriptモジュールのファーストクラスサポート
• タイプスクリプトコンパイル（ただし、タイプチェックではありません）
• JSX
• 拡張性のためのプラグインAPI
• 組み込み開発サーバー
• CSSバンドルとCSS-in-JSライブラリのサポート

これらのツールはすべて、TypeScriptをJavaScriptにコンパイルできますが、タイプエラーがある場合でもそうします。適切なタイプチェックの場合、TypeScriptをインストールしてTSC -NoemitをルートJavaScriptファイルで実行するか、またはエディタープラグインを使用してタイプエラーを監視します。

OK、各ツールを見てみましょう。

esbuild

EsbuildはEvan Wallace（FigmaのCTO）によって作成されました。その主な機能は、ノードベースのバンドラー（独自のベンチマークで）よりも速いビルドステップ10×-100×を提供することです。これは、Create-React-Appのようなもので見つけるかもしれない開発者の便利さの多くを提供しません。しかし、ビルドステップにEsbuildを使用するCreate-React-App-Esbuild、Estrella、Snowpackなど、これらのギャップを埋めるエスビルドのスターターがますますポップアップしています。

Esbuildは非常に新しいです。まだ1.0バージョンに到達しておらず、生産の使用の準備ができていませんが、それほど遠くありません。 SMARTデフォルトで直感的なJavaScriptおよびコマンドラインAPIを提供します。

ユースケース

Esbuildは、バンドラーの世界で完全なゲームチェンジャーです。 EsbuildとNodeのバンドラーの速度差が乗算される大きなコードベースで最も役立ちます。 Esbuildが1.0を獲得すると、大規模な生産サイトで非常に役立ち、ビルドが完了するのを待つ時間を大幅に節約できます。残念ながら、エスビルドが安定するまで、大きな生産サイトは待つ必要があります。それまでの間、サイドプロジェクトのバンドルに速度を追加するのは良いことです。

EsbuildのLightning-Fast Speedは、あなたがしているあらゆる種類の仕事にとってボーナスになります。ビルドが実行されるのを待つのに費やす時間が少ないことは、常に開発者エクスペリエンスに適しています！これを考慮して、クイックアプリケーションをプロトタイプ化する場合は、Esbuildよりも高いレベルのものから始めたいと思うかもしれません。そうしないと、JavaScriptエコシステムで予想される便利さを得る前に、依存関係を引き出して環境を構成するのに時間を費やす必要があります。また、バンドルのサイズを可能な限り最小限に抑えたい場合は、ロールアップとTerserを使用する場合があります。

設定

私は、EsbuildでのReactプロジェクトをナイーブな方法で開始することにしました。NPMEsBuild、React、Reactdomのインストールです。 src/app.jsxファイルとdist/index.htmlファイルを作成しました。次に、次のコマンドを使用して、アプリをdist/bundle.jsファイルにコンパイルしました。

 ./node_modules/.bin/esbuild src/app.jsx  -  bundle -platform = browser -outfile = dist/bundle.js

ブラウザでindex.htmlをホストして開いたとき、「死の白いスクリーン」と「猛攻撃の参照エラー：プロセスが定義されていない」コンソールエラーに会いました。ドキュメントとCLIの両方は、これを防ぐために何をする必要があるかを正確に説明していますが、それは初心者にとってはちょっとした「ゴッチャ」かもしれません。

 -define：process.env.node_env = \ "production \"

または、引用を逃れるためにこのように書かれたNPMスクリプトにesbuildを含めている場合：

 -  define：process.env.node_env = \\\ "production \\\"

この定義の引数は、ノード環境変数を期待するブラウザにバンドルされたライブラリに必要です。 VUE 2.0もこれらを期待しています。デフォルトでブラウザの準備が整った環境変数や船舶が予想されないため、事前に同じ問題はありません。

定義の引数でコマンドを実行した後、私の「Hello World」Reactアプリは完全に機能していました。 JSXは.jsxファイルを使用して箱から出して動作します。とはいえ、Reactは手動でインポートする必要があり、その後、JSXはReact.CreateElementに変換されます。ただし、JSXに自動インポートを追加したり、事前にJSXを構成する方法があります。

使用法

Esbuildは、開発サーバーに - サービスオプションを提供します。これにより、ファイルシステムをバイパスし、メモリから直接モジュールを提供し、ブラウザが古いバージョンのモジュールをプルしないようにします。ただし、ライブ/ホットリロードは含まれていないため、保存後にブラウザをリフレッシュしていることに気付くでしょう。これは理想的な体験ではありません。

新しくリリースされたウォッチ機能を使用することにしました。これは、ソースファイルが保存されるたびにコードを再コンパイルするようにesbuildに指示します。しかし、保存された変更を確認するためにサーバーが必要です。 Luke JacksonのServorなど、開発サーバーパッケージを引き込むことができます。

 npmインストールサーバー -  save-dev

その後、Esbuild JavaScript APIを使用してサーバーとして起動し、同時にEsbuildのウォッチモードを実行できます。 Watch.jsと呼ばれるプロジェクトのルートにファイルを作成しましょう。

 // watch.js
const esbuild = require（ "esbuild"）;
const servor = require（ "servor"）;

esbuild.build（{
  //ここでesbuildにオプションを渡す...
  エントリーポイント：["src/app.jsx"]、
  アウトティア：「dist」、
  定義：{"process.env.node_env"： '"production"'}、
  見る：本当、
}）;

async function serve（）{
  console.log（ "from：http：// localhost：8080/"）;
  サーバーを待っています（{
    //ここでサーボーにオプションを渡す...
    ブラウザ：本当、
    root：「dist」、
    ポート：8080、
  }）;
}

仕える（）;

次に、コマンドラインでnode watch.jsを実行します。これにより、DEVサーバーが優れていますが、繰り返しますが、ホットモジュールの交換や速い更新は得られません（つまり、クライアント側の状態は保存されません）。しかし、これは私のテストのニーズには十分でした。

ファイルを保存するたびにアプリケーション全体をbund弾していますが、Esbuildが遅くなる前にかなり大規模なアプリケーションを使用する必要があります。このツールを設定した後、変更からすぐにフィードバックを得ていました。私のコンピューターは2012年からIntel i7を使用しているため、確かに最高のマシンではありません。

ライブリロードといくつかのReactデフォルトを備えたESBUILDの事前に構成されたバージョンが必要な場合は、このリポジトリをクローンできます。

サポートされているファイル

Esbuildは、それがあなたのスタイルであれば、JavaScriptにCSSをインポートできます。メインの出力JavaScriptファイルと同じ名前の出力ファイルにCSSをコンパイルします。また、デフォルトでCSS @importステートメントをバンドルすることもできます。 CSSモジュールのサポートはありませんが、計画はあります。

Esbuildのプラグインのコミュニティが増えています。たとえば、VUEシングルファイルコンポーネントとSvelteコンポーネントで利用できるプラグインがあります。

EsbuildはJSONファイルで動作し、構成なしでそれらをJavaScriptモジュールにバンドルすることができます。

また、javaScriptに画像をインポートして、それらをデータURLに変換するか、出力フォルダーにコピーすることもできます。この動作はデフォルトでは有効ではありませんが、ESBuild Configオブジェクトに次のように追加して、どちらのオプションを有効にしてもできます。

ローダー：{'.png'： 'dataurl'} // jsバンドルのデータURLに変換
ローダー：{'.png'： 'file'} //出力フォルダーへのコピー

コード分​​割は進行中の作業のように見えますが、ほとんどがESM出力形式でそこにあり、プロジェクトの優先事項のように見えます。また、ツリーシャッキングはデフォルトでエスビルドに組み込まれており、オフにすることができないことに言及する価値があります。

生産ビルド

Esbuildコマンドで「Minify」および「Bundle」オプションを使用すると、ロールアップ/Terserパイプラインと同じくらい小さいバンドルが作成されません。これは、esbuildがバンドルサイズの最適化を犠牲にして、できるだけ少ないパスでコードを通過するためです。ただし、違いはかなり無視できる場合があり、プロジェクトに応じて、バンドル速度の増加には価値があります。 Snap Shotアプリケーションのクローンで、Esbuildは177 KBのバンドルを作成しました。これは、RollupとTerserを使用するViteが生産する165kbよりもはありません。

全体

Esbuildは非常に強力なツールです。しかし、あなたがコンフィグのセットアップをゼロに慣れている場合、それは難しいかもしれません。もっと必要な場合は、Esbuildを使用する次のツールであるSnowpackをご覧ください。

雪だるま

Snowpackは、SkypackとPikaの作成者によるビルドツールです。それは素晴らしい開発サーバーを提供し、「バンドルされていない開発」哲学で作成されました。ドキュメントを引用するには、「必要なからではなく、必要なのでバンドラーを使用できるはずです。」

デフォルトでは、Snowpackのビルドステップはファイルを単一のパッケージにバンドルするのではなく、ブラウザで実行されるバンドルされていないEsmodulesを提供します。 Esbuildは実際には依存関係としてそこに含まれていますが、アイデアはJavaScriptモジュールを使用し、必要なときにEsBuildにのみバンドルすることです。

Snowpackには、JavaScriptフレームワークを使用して使用するためのガイドのリストや、それらのためのテンプレートの束など、いくつかのかなり滑らかなドキュメントがあります。ガイドの一部はまだ進行中の作業ですが、Reactのような他の人は素晴らしく明確です。また、SnowpackはSvelteを一流の市民として扱っているようです。私は実際に、Svelte Summit 2020でのRich Harrisの「未来的なWeb開発」の講演のスノーパックについて最初に聞いたことがあります。つまり、今後のSvelteメタフレームワークSveltekitはSnowpackを搭載することになっていますが、その後Viteに切り替えられました（次はレビューします）。

ユースケース

束縛されていない展開を2倍にしたい場合は、雪パックが良い選択です。少数のモジュールを使用してソースコードを作成する場合があります。これは、バンドルされていないビルドを備えた大きなリクエストウォーターフォールを作成していないことを意味します。束ねた複雑さと技術的な借金が必要でない場合は、雪だるまが最適です。良いユースケースは、フロントエンドフレームワークをサーバーレンダリングまたは静的アプリケーションに徐々に採用している場合です。ノードエコシステムからできるだけ少ないツールを引き込むことはできますが、宣言的なフロントエンドフレームワークのメリットが得られるでしょう。

第二に、私はスノーパックがエスビルドの周りの素晴らしいラッパーであると主張します。 ESBUILDを試してみたいだけでなく、フロントエンドフレームワーク用の開発サーバーと事前に書かれたテンプレートが必要な場合は、雪のパックを間違えることはありません。 Snowpack構成のビルドステップでESBUILDを有効にすると、行ってもいいです。

現在の状況にあるので、Snowpackは、プラグインを引き出して自分で構成する必要があり、非常にファンシーな最適化されたプロダクション対応ビルドステップが必要な場合に自分で構成する必要があるため、雪のパックはCreate-React-Appのようなゼロ構成ツールに最適ではないと主張します。

設定

コマンドラインにジャンプして、スノーパックでプロジェクトを始めましょう。

 mkdir snowpackproject
CD SnowPackProject
npm init #fill defaults 
npmインストールスノーパック

それでは、package.jsonに次のことを追加しましょう。

 // package.json
「スクリプト」：{
  「スタート」：「スノーパック開発」、
  「ビルド」：「スノーパックビルド」
}、

次に、構成ファイルを作成します。

 // MacまたはLinux
snowpack.config.jsをタッチします
// Windows
New-Item Snowpack.config.js

Snowpackの最も魔法の部分は、構成ファイルに1つの無邪気なキー値ペアを設定するときに起こると思います。これを構成ファイルに貼り付けます。

 // snowpack.config.js
module.exports = {
  packageoptions：{
    「ソース」：「リモート」、
  }
};

出典：リモートは、ストリーミングインポートと呼ばれるものを有効にします。ストリーミングインポートにより、スノーパックは、Skypackからのcdnインポートに、ベアインポート（例えば、「React」からの輸入）をCDNインポートに変換することにより、NPMのインストールをバイパスできます。

先に進んで、index.htmlファイルを作成しましょう。

 



  >
  <title> Snowpackストリーミングインポート</title>


  <div> </div>
  
  <script type="module" src="app.js"> </script>

そして最後に、app.jsxファイルを追加します。

 // app.jsx
「React」からの輸入反応
「React-dom」からReactdomをインポートする
const app =（）=> {
  return <h1 id="雪パックストリーミングインポートへようこそ">雪パックストリーミングインポートへようこそ！</h1>
}
Reactdom.render（<app></app>,document.getElementbyid('root '））; 0

npmは、どの段階でも反応または反応をインストールしなかったことに注意してください。しかし、このような雪パック開発者サーバーを起動する場合：

 ./node_modules/.bin/snowpack dev

…私たちのアプリはまだ機能しています！

Node_Modulesフォルダーから引き出す代わりに、SnowpackはNPMレジストリをホストするCDNであるSkypackからNPMパッケージを引き下げ、ブラウザで動作するように事前に最適化されています。 Snowpackは、./_snowpack/pkg urlで提供します。

使用法

これは、ノード/NPMベースのワークフローから大きな一歩です。私たちが実際に見ているのは、新しいCDN/JavaScriptモジュールベースのワークフローです。

ただし、アプリをそのまま実行してプロダクションビルドを実行した場合、スノーパックはエラーを投げます。これは、構築時に使用する反応と反応のバージョンを知る必要があるためです。これを修正して、snowpack.deps.jsonに書き込みます。これは、以下を実行することで自動的に作成できます。

 ./node_modules/.bin/snowpack add react
./node_modules/.bin/snowpack add react-dom

NPMからパッケージをダウンロードすることはありませんが、スノーパックビルドに使用されるパッケージのバージョンを記録します。

1つの警告は、Skypackがプロダクションバージョンのパッケージを出荷するため、開発者エラーメッセージを逃したことです。

ストリーミングインポートを使用していなくても、Snowpack Development Serverは、依存関係ごとにnode_modulesから各依存関係を1つのJavaScriptファイルにバンドルし、それらのファイルをネイティブJavaScriptモジュールに変換し、ブラウザに提供します。これは、ブラウザがこれらのスクリプトをキャッシュし、変更された場合にのみ再リケストできることを意味します。開発サーバーは、自動的に保存を再リッシュしますが、クライアント側の状態を保持しません。ノードからのすべての依存関係は、レガシーモジュール形式またはノードAPIを使用しているかどうかに関係なく、箱から出しているように見えました（悪名高いProcess.ENVなど）。

Reactでクライアント側の状態を保存するには、React-Refreshが必要です。これには、依存関係として独自のバベルパッケージが必要です。これらはデフォルトでは含まれていませんが、より最大のReactテンプレートを使用して使用できます。テンプレートは、80 MBで重量を計るために、React-Refresh、よりきれいな、Chai、およびReact Testing Libraryを引き込みます。

 npx create-snowpack-app my-react-project  -  template @snowpack/app-template-react

サポートされているファイル

JSXはサポートされていますが、繰り返しますが、デフォルトで.JSXファイルを使用してのみです。 Snowpackは、反応または事前に使用されているかどうかを自動的に検出し、JSX変換に使用する機能をそれに応じて決定します。ただし、JSXをこれ以上カスタマイズしたい場合は、プラグインを介してバベルを引き込む必要があります。また、VUEシングルファイルコンポーネント、そしてもちろん、Svelteコンポーネント用に利用できるスノーパックプラグインもあります。さらに、SnowpackはTypeScriptをコンパイルしますが、タイプチェックにはTypeScriptプラグインが必要です。

CSSはJavaScriptにインポートでき、実行時にドキュメント

に投げられます。 CSSモジュールは、.module.css拡張子を持っている限り、スコーピングのために箱から出してサポートされています。

インポートされたJSONファイルは、デフォルトのエクスポートとしてオブジェクトを使用してJavaScriptモジュールにキャストされます。 Snowpackは画像をサポートし、それらをプロダクションフォルダーにコピーします。バンドルされていない哲学に沿って、SnowpackにはバンドルにデータURLとして画像が含まれていません。

生産ビルド

デフォルトのスノーパックビルドコマンドは、基本的に正確なソースファイル構造を出力フォルダーにコピーします。 JavaScriptにコンパイルするファイル（TypeScript、JSX、JSON、.VUE、.SVELTE）の場合、個々のファイルを個別のブラウザに優しいJavaScriptモジュールに変換します。

これは正常に機能しますが、ソースコードが多くのファイルに分割されている場合、リクエストの大きな滝を引き起こす可能性があるため、生産には優れていません。 Snap Shotアプリケーションでは、184kbのソースファイルで終わり、Skypackからさらに105 kbの依存関係をリクエストし、かなり大きな滝を作りました。

ただし、SnowpackはEsbuildを依存関係として引き出し、EsbuildがSnowpack構成に「最適化」オブジェクトを追加して、コードをバンドル、マイニー、コンパイルできるようにすることができます。

 // snowpack.config.js
module.exports = {
  最適化する： {
    バンドル：本当、
    マニフィー：本当、
    ターゲット：「ES2018」、
  }、
};

これにより、Esbuildが提供する最適化機能を使用してコードが実行されるため、これらのオプションを追加するだけで、Esbuildで以前に行ったのと同じビルドを取得できます。

Esbuildはまだ1.0に達していないため、Snowpackは、生産ビルドにWebpackまたはロールアッププラグインを使用することをお勧めします。どちらも構成する必要があります。

全体

Snowpackは、フル機能の開発サーバー、詳細なドキュメント、およびインストールしやすいテンプレートを使用した軽量開発者エクスペリエンスを提供します。アプリケーションをバンドルするかどうか、どのようにしたいかを決定する必要があります。開発者サーバーとより意見的なビルドステップの両方を提供するツールが必要な場合は、リストの次のツールであるViteをご覧ください。

vite

Viteは、Vue Creator（およびHades Speedrunner）Evan Youによって開発されました。 ESBUILDがビルドステップに集中し、雪パックが開発サーバーに集中する場合、Viteは、完全な開発サーバーとロールアップを使用した最適化されたビルドコマンドの両方を提供します。

ユースケース

真剣なCreate-React-AppまたはVue CLIの競合他社が必要な場合、Viteはバッテリーが含む機能が付属しているため、束で最も近いものです。 Lightening-Fast Development ServerとZero-config最適化された生産ビルドにより、構成なしでゼロから生産に到達できることができます。 Viteは、小さなサイドプロジェクトまたは大規模な生産アプリケーションの両方で使用できるツールです。 Viteの適切なユースケースは、かなりのシングルページアプリです。

なぜViteを使用しないのですか？ Viteは意見のあるツールであり、あなたはその意見に反対するかもしれません。ビルドにロールアップを使用したくないかもしれません（Esbuildの速さについて話してきました）、またはあなたのツールにBabel、Eslint、およびWebpackローダーのエコシステムを箱から出して提供することを望むかもしれません。

また、Zero-configサーバー側のレンダリングメタフレームワークをレンダリングする場合は、nuxt.jsやnext.jsなどのWebパックベースのフレームワークに留まる方が良いでしょう。

設定

Viteには、EsbuildやSnowpackよりも意見の高いデフォルトがあります。そのドキュメントは明確で詳細です。エヴァンが創造者であり、すべてであるため、私たちはVueを完全にサポートしているので、ViteはVue開発者にとって明確な幸せな道です。とはいえ、Viteはフロントエンドフレームワークで使用でき、テンプレートのリストを提供して開始することもできます。

使用法

Viteの開発サーバーは非常に強力です。 Viteは、プロジェクトのすべての依存関係を、Esbuildを備えた単一のネイティブJavaScriptモジュールに一緒にプリバンドを使用し、重度のキャッシュされたHTTPヘッダーで提供します。これは、最初のページのロード後に輸入依存関係をコンパイル、サービング、または要求する際に時間が無駄にならないことを意味します。また、Viteはクリアなエラーメッセージを提供し、コードの正確なブロックとライン番号を印刷してトラブルシューティングを提供します。繰り返しになりますが、ノードAPIまたはレガシー形式を使用した依存関係を引き込む問題はありませんでした。それらはすべて、ブラウザにアクセサリー可能なエスモジュールにシムに入れられているように見えました。

ViteのReactおよびVueテンプレートは、ホットモジュールの交換を可能にするプラグインを引き込みます。 VUEテンプレートは、単一のファイルコンポーネント用のVueプラグインとJSX用のVueプラグインを引き込みます。 Reactテンプレートは、React-Refreshプラグインを引きます。いずれにせよ、どちらもホットモジュールの交換とクライアント側の状態保存を提供します。確かに、彼らはバベルパッケージを含むいくつかの依存関係を追加しますが、viteでJSXを使用する場合、バベルは実際には必要ありません。デフォルトでは、JSXはesbuildと同じように動作します。それはReact.createelementに変換されます。 Reactを自動的にインポートすることはありませんが、その動作は構成できます。

そして、私たちがそれに取り組んでいる間、ViteはSnowpackやWMR Doのようなストリーミングの輸入をサポートしていません。つまり、通常どおりNPMインストール依存関係を意味します。

クールなことの1つは、Viteにはサーバー側のレンダリングの実験的サポートが含まれていることです。選択したフレームワークを選択し、クライアントに直接出荷する静的HTMLを生成します。現時点では、このアーキテクチャを自分で構築する必要があるように見えますが、それでも、これはメタフレームワークスがViteの上に構築される良い機会のように見えます。 EvanあなたはすでにVitePressと呼ばれる作業を持っています。これは、Viteを使用することの利点を備えたVuepressの代替品です。また、SveltekitはViteを依存関係リストに追加しました。 CSSコードの分割包含は、SveltekitがViteに切り替えた理由の一部であるように見えます。

サポートされているファイル

CSSの場合、Viteは、私たちが見ているすべてのツールの中で最も多くの機能を提供します。 CSSモジュールだけでなく、CSSインポートのバンドルをサポートします。ただし、npm postcssプラグインをインストールしてpostcss.config.jsファイルを作成することもできます。Viteは、これらの変換をCSSに自動的に適用し始めます。

CSS Preprocessorsをインストールして使用できます。NPMプリプロセッサをインストールし、ファイルを適切な拡張子（.FileName.scssなど）に変更すると、Viteが対応するプリプロセッサの適用を開始できます。そして、概要で述べたように、ViteはCSSコードスプリッティングをサポートします。

画像はデフォルトでパブリックURLにインポートされますが、URL文字列の最後にrawパラメーターを使用して、文字列としてバンドルにロードすることもできます。

JSONファイルはソースにインポートし、単一のオブジェクトをエクスポートするEsmoduleに変換できます。また、指定されたインポートを提供することもできます。ViteはJSONファイルのルートフィールドを調べてインポートを見つけ、残りをトレシェーします。

生産ビルド

Viteは、多くの最適化を備えた事前に設定された生産ビルドにロールアップを使用します。意図的に、ほとんどのユースケースに十分なゼロコンフィグビルドを提供します。

ビルドには、予想されるロールアップ機能が付属しています。バンドリング、縮図、木の揺れです。しかし、コードスプリットの動的なインポートや「非同期チャンク荷重」と呼ばれるものなど、エキストラも入ります。これは、別のモジュールをインポートするJavaScriptモジュールを要求する場合、ビルドが事前に最適化され、両方を同時に（非同期）ロードすることができます。

スナップショットアプリでViteのデフォルトビルドを実行しているのは、5kb JavaScriptファイルと1つの160kb JavaScriptファイル（合計165kbの合計で）で1つになり、プロジェクト内のすべてのCSSが自動的に2.71kbファイルに自動的に削除されました。

全体

Viteの意見を述べた性質により、現在のツールを伴う真剣な競争相手になります。開発者エクスペリエンスを本当にシームレスにし、生産対応のビルドを箱から出すために、多くの作業が行われました。

WMR

Viteと同様に、WMRは、開発サーバーとビルドステップの両方を提供する別の意見のあるビルドツールです。それは、Preactの作成者であるJason Millerによって構築されたので、それは間違いなくPreact開発者にとって幸せな道です。ジェイソン・ミラーは、JSパーティーポッドキャストにゲストとして登場したときにWMRの背後にある考えを説明しました。

プアクトは小さく、軽量プロジェクトをやりたいと思うなら本当に良いことです。そのためのツールはどこにありますか？多くの有名なサイトによって生産で使用されるWebパックベースのツールがありますが、それはヘビー級のツールです。プロトタイピングツールはどこにありますか？それが一方でした。一方、私とたまたまプアクトチームに参加していた他の人がたくさんいます。私たちはしばらくの間、バンドラーの生態系の傍観者であり、人々を突き刺し、現代のコードを書いて現代のコードを出荷するというこのアイデアをさらに進めるために移動できる方向に合意を得ようとしていました。

これは、WMRが最新のコードの作成と出荷に関するものであり、プロジェクトでより軽いツールを可能にすることであることがわかります。

あなたはWMRが何を表しているのか疑問に思っているかもしれませんか？何もない！ 「Webモジュールランタイム」と「ウェットモジュールの交換」という名前は浮き抜けられましたが、NPMと同様の偽の略語です。

WMRは、プアクトと同じ冷酷なバンドルサイズのパージで構築されているため、わずか2.6 MBの重量がわずかで、npmの依存関係が正確に含まれています。それでも、ホットモジュールを補充する開発サーバーや最適化された生産ビルドなど、非常に素晴らしい機能の多くを詰め込むことができます。

ユースケース

できるだけ早くプアクトを使用してプロトタイプを作成しようとしている場合は、WMRを使用します。構成はなく、ダウンロードには数秒しかかかりません。スーパーチャージされた静的ファイルサーバーを使用するような気がします。 TypeScript、最適化されたビルドステップ、静的HTMLレンダリングにより、WMRは小規模のサイズのアプリケーションを出荷するのに必要なすべてを提供します。その小さなサイズは、ライブラリをすばやく試したり、アイデアをデモするのにも最適です。

Preact、React、またはVanilla JavaScriptを使用していない場合、WMRはあなたのためのツールではないかもしれません。 Preactチームは、他のフレームワークにまだテンプレートを提供していません。ドキュメントは、私たちが見た他のツールほど詳細ではありません。これは、幸せな道から遠く離れるほど、ソースを掘り下げることを意味します。したがって、多くのカスタマイズが必要な場合は、お勧めできません。

設定

プアクトを使用している場合、迅速なNPMインストールを除き、絶対にゼロセットアップが必要です。 PREACTの代わりにWMRとの反応を使用するには、現在2つのステップがあります。まず、HTM/ReactのエイリアスHTM/PREACT、およびPackage.jsonのES反応に反応します：

 「エイリアス」：{
  「HTM/PREACT」：「HTM/React」、
  「React」：「ES-React」
}、

次に、ES反応からインポートをコンポーネントに追加します。

 // rootddomはルートレンダリングでのみ必要です
{es-reacdy 'から{race、racemddom、}をインポートします。

これは、実際に慣れている通常のReactパッケージを使用しているのではなく、ES反応から反応を引き込むことを意味します。これは、WMRがネイティブJavaScriptモジュールと互換性があるパッケージに依存しているためです。 Reactはデフォルトでネイティブモジュールを使用せず、代わりにUMDモジュールと呼ばれる古いスタイルのモジュールを使用します。 ES-Reactは、Reactを引き込みますが、Webプラットフォームと互換性のあるエクスポートを提供するパッケージです。

これは、ツールを使用して避難および抽象化するのではなく、Webプラットフォームのネイティブプリミティブを使用するというWMRの哲学を示しています。

別のオプションは、アプリケーションでSkypackインポートを使用することです。これは、ブラウザで動作するように事前に最適化されています。

 'https://cdn.skypack.dev/react'からのインポートReact;
'https://cdn.skypack.dev/react-dom'からReactdomをインポートします。

WMRは、ブラウザで実行される最新のコードを書いていることを期待しています。これは、ノードAPIまたはレガシーモジュールシステムを使用する依存関係を引き込む場合、何らかの構成を実行する必要があることを意味する場合があります。スナップショットアプリを動作させるには、ノードモジュールに飛び込み、ライブラリを1つか2つ変換してネイティブJavaScriptモジュールの構文を使用する必要がありました。これにより、古いライブラリを使用している場合は遅くなる可能性があります。プアクトエコシステムはすべて、ブラウザで実行するように最適化されており、マッサージを必要としないはずです。これは、WMRの事前のハッピーパスに固執するもう1つの理由です。

WMR用のプラグインがあります。ビルドステップでロールアッププラグインをサポートするプラグインAPIを公開します。 HTMLを模倣するプラグインや、ファイルシステムベースのルーティングを備えたプラグインなど、ドキュメントにはますます多くのWMR固有の例があります。

WMRはさまざまなフレームワークをサポートしていますが、事前に構築されたテンプレートはありません。そして、最初はJSX変換を構成することはかなり難しいと感じました。 All that said, Jason has confirmed there are plans to make JSX more configurable and that wmr is intended to be framework-agnostic. JSX is planned to work out of the box in regular JavaScript files.

使用法

To get started you can either run this command in the command line:

 npm init wmr your-project-name

Or alternatively, you can run these commands to manually build up your application:

 npm init -y
npm install wmr
mkdir public
touch public/index.html
touch public/index.js

Then add an script import in the body of your index.html (again make sure to use type="module"):

 <script type="module" src="./index.js"></script>

Now you can write a Preact hello world into your index.js file:

 import { render } from 'preact';
render(<h1 id="Hello-World">Hello World!</h1>, document.body);

And finally start your development server:

 node_modules/.bin/wmr

Now we have a full hot module replacement development server which will immediately respond to any changes to our source-code.

wmr uses a tool called htm when transforming JSX, which provides some awesome benefits. Let's say we're writing a counter using Preact in wmr and make a mistake:

 import { render } from 'preact';
import { useState } from 'preact/hooks';
function App() {
  const [count,setCount] = useState(0)
  return 
  <button onclick="{()=">{setCount(cout 5)}}>Click to add 5 to count</button> // HIGHLIGHT
  <p>count: {count}</p>
  >
}
render(<app></app>, document.body);

count is misspelled in the onClick handler function, so running this results in an error. Usually, we would have to rely on our tooling and a source map to gather information about where the bug is located, but wmr takes a different solution. With htm, this gets as close as you can get to native JSX in the browser by using tagged template literals. So, where writing React or Preact code usually looks like this:

 <mycomponent>I am JSX. I am not actually valid Javascript</mycomponent>

…htm looks more like this:

 html`I am about as close as it gets to JSX as you can get while being able to run in the browser`

Now, if we're debugging our code and open the “Sources” panel in DevTools, we should see a script that's almost identical to what the source code looks like in the editor.

This way, we can properly investigate where bugs are located in the browser without having to use sourcemaps. Sure, this specific example is pretty contrived, but you can see how this could be really useful because it means wmr doesn't need source maps in your developer environment.

wmr supports streaming imports by default, so bare imports will be pulled down from the npm registry. This is done through a complex process which examines all of the source in the npm package, removes all the tests and metadata, and converts it to a single native JavaScript import. Similar to Snowpack, it's possible to build a complex app without using npm to install anything. In fact, wmr is the first tool to support this idea.

Supported files

As far as the other types of files wmr supports, CSS files can be imported in JavaScript, and CSS modules are supported as well.

There isn't any built-in support for either Vue single file components or Svelte components. However, wmr's build step works with Rollup plugins and the development server can be configured with Polka/Express middleware, so it's possible to use these to convert imports into Vue and Svelte components. In fact, I wrote a small plugin for Vue Single file Components to show how this might be done.

We can't import images into JavaScript as data URLs in wmr without a plugin. Instead, we need to import them using a syntactically correct JavaScript method. So, if we have, say, a picture of a dog in our public folder we might include it in a Preact component like this:

 function Dog() {
  return <img src="%7Bnew" url import.meta.url alt="dog hanging out">
}

And once the build step runs, the image is copied and accessible from the distribution folder. There is hot module replacement for images in the development server, so changes with images are immediately reflected in the browser.

One more note on file support: JSON can be imported, and is converted into a JavaScript object for use. But when actually building an application, we'd need the Rollup JSON plugin.

Production build

wmr provides a production build step that includes bundling, minification and tree-shaking without any additional dependencies. Having a look at the source of wmr, it looks like rollup and terser are used under the hood, and minified versions of these are included in the wmr package. The wmr bundle for the Snap Shot app was 164KB so it created a bundle just a tiny bit smaller than total size of the two JavaScript files created by Vite.

There is also a way to configure wmr is such a way that it renders an application to static HTML and hydrates on the browser using preact-iso. This means wmr can be used as a meta-framework for Preact, similar to Next.js.

全体

I love the experience of using wmr to prototype both React and Preact applications. It feels great to get started with a tool that is ridiculously small but provides developer conveniences that get close to matching heavyweight bundlers.

Feature comparison

We have just covered a lot of ground! Rather than scroll up and down this article to compare results, I've compiled everything here to see how the tools stack up when they're side-by-side. I've even included additional comparisons for features that we didn't explicitly cover.

Use cases

設定

Development server

Production build

Other features

まとめます

I'm super excited about building JavaScript applications with any and all of the tools we just looked at. Whether we're writing a small side project or a big production site, all these tools speed up feedback loops and increase productivity. They've opened up the gates to ask what's necessary for the JavaScript ecosystem and whether we can start losing the cruft brought by legacy modules and browsers. These tools are going to lower the barrier to entry for new developers by providing a leaner, faster developer environment with fewer abstractions between the code that gets written and the code that runs in the browser.

If you're getting sick of waiting for your dependencies to download and your build steps to run, I'd recommend giving this new generation of tooling a try.

Further reading

• “Comparisons with Other No-Bundler Solutions” (Vite)
• “Let's Learn esbuild! (with Sunil Pai)” (Jason Lengstorf)
• Through the pipeline: an exploration of frontend bundlers (Andrew Walpole)

Other new JavaScript tooling to check out

• Rome – A full toolchain including linting, compiling, bundling, test-running and formatting
• SWC – A rust-based JavaScript/TypeScript compiler
• Deno – A runtime for JavaScript and TypeScript (similar to Node.js)

以上が新世代のビルドツールを比較しますの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。