Next.js 12 のベンチマーク結果は説得力があります。しかし、切り替える価値はありますか？

最近のチーム ビルディング イベントで、JavaScript 開発者がツールを Rust に移行している理由について講演しました。それは非常に評判の良い講演であり、私たちはそれを世界と共有することがクールだと判断しました. それで、ここにあります。これは、読むために書かれたトークの編集版で、Podcast チャンネルにスクリーンキャストがあります。それでは、まっすぐに飛び込みましょう。

バックグラウンド

ソフトウェアの一般的な傾向は、開発者がアプリケーションの構築に使用するツールを、アプリケーションの構築に使用するのと同じ言語で作成することです。たとえば、pip は Python で作成され、Composer は PHP で作成され、Maven は Java で作成されます。ツールを作成する人はほとんどの場合、ツールを使用する人でもあるため、これは理にかなっています。そのため、選択した言語で作業する方が簡単です。

JavaScript も例外ではありません。Gulp と Bower から babel と Webpack まで、すべて JavaScript で記述しました。これは私たちにとってはうまくいきましたが、いくつかの問題がありました。

JavaScript の問題

問題を確認するには、JavaScript のプロパティを確認する必要があります。JavaScript は、Web ページ用の軽量なスクリプト言語です。確かに、バックエンドからデータベースまで、あらゆる場所で使用されていますが、もともとはページを輝かせるために最初に作成され、それ以外はすべて 2 番目でした。

これは、ジャストインタイム コンパイルが可能で、シングルスレッドのインタープリター言語です。はい、はい、私は複数のインスタンスをスピンアップし、Web ワーカーと通信することについて知っています... しかし、私の意見では、それはマルチスレッドではありません。

より大きな問題は、他の言語と比較して、コンソールでの実行がかなり遅いことです。

JavaScript はページ上では優れていますが、コンソール上ではちょっと苦手です。

ある日、大勢の JavaScript 開発者が暗い部屋に集まり、飲みすぎた後、誰かが次のように言いました。

「ねえ、もし…聞いてくれたら… JavaScript を構築するツールを JavaScript で書かなかったら?」

集団のあえぎがあり、椅子が投げられ、喧嘩が勃発し、ほこりが落ち着いた後、誰もがそれを試すことに同意しました.

OK、私はそれを作り上げたかもしれませんが、結果は同じです。現在、JavaScript 以外の言語で JavaScript ビルド ツールを作成しています。

しかし、なぜ錆びるのですか？

一言で言えば… 速度とバッファオーバーフロー .

Rust は、パフォーマンスと安全性のために設計されたマルチパラダイムの汎用プログラミング言語です。C++ に似ていますが、ミレニアル世代やズーマー向けです。これは、メモリの安全性を強化し、「安全な」同時実行性を持つシステム言語です。構文は C++ に似ており、さらに重要なことに、C++ とほぼ同じくらい高速です。

有望な主張

現在、JavaScript ツールを Rust ベースのツールに置き換えようとするプロジェクトが数多く出回っています。いくつかの例として、ParcelJS、Deno、ESBuild、Speedy Web Compiler (SWC) があります。それらはすべて、置き換えようとしているものよりも高速に実行すると主張しています。笑いが必要な場合は、esbuild の比較を確認してください。

この投稿では、すべてをチェックするわけではありませんが、Next.js を介して SWC を詳しく見ていきます。

スピーディ Web コンパイラ (SWC)

SWC は、次世代の高速開発ツール用の拡張可能な Rust ベースのプラットフォームです。つまり、ビルダーを構築するためのフレームワークです。コンパイルとバンドルの両方に SWC を使用できます。最新の JavaScript 機能を使用して JavaScript / TypeScript ファイルを取得し、すべての主要なブラウザーでサポートされている有効なコードを吐き出します。

最新の Next.js Rusty ツール

Next.js は、バージョン 12 で SWC ベースの Rust コンパイラを導入しました。Next.js サイトでは、ローカルでの更新が最大 3 倍速く、本番ビルドが最大 5 倍速いと主張しています。

それは私にとって検証可能な主張のように聞こえます。だから私はそれをテストしました。

バージョン 11 と 12 でまったく同じプロジェクトを作成し、同じ 400 の生成されたコンポーネントを追加しました。これにはReact Benchmark Generatorを使用しました。プロジェクト間の唯一の違いは Next.js のバージョンで、それ以外はすべて同じでした。

結果はかなり説得力がありました。Next.js 11 の場合は次のとおりです。

Next.js 12 の場合は、次のようになります。

Next.js 12 は、Next.js 11 が 1 分 40 秒で実行したことを実行するのに 12 秒かかりました。これは約 8 倍高速です。したがって、彼らは明らかに誇張していませんでした。

また、Next.js 12 が 12 秒かかるとは思っていませんでした。嬉しい偶然だったと思います。

誇大宣伝する価値はありますか？

ここで明らかな疑問は次のとおりです。

結局のところ、私たちが構築しているアプリケーションは同じですよね? これはエンドユーザーのエクスペリエンスを変更するのではなく、開発者のエクスペリエンスのみを変更します。すでに正常に動作していたものを修正するのはなぜですか?

うまくいかなかったからです。前に述べたように、JavaScript はページでは優れていますが、コンソールではうまく機能しません。開発者のマシンは強力な獣であり、この力を利用しないことはひどい無駄です。また、高価な廃棄物でもあります。

クラウドベースの CI でデプロイおよびテストされる大規模なプロジェクトに取り組んでいる 20 人の開発者のチームにいるとします。毎日、チームの各メンバーが複数の修正と機能をプッシュします。次のようなことが起こる可能性があります。

CI が無制限の同時ビルドを提供するが、ビルドの分単位またはプロセッサ時間の秒単位で料金が請求される場合、Next.js は文字通り、Next.js 12 の 8 倍の費用がかかります。

一方、固定価格と固定数の同時ビルドが提供される場合、ビルド キューが大きくなるとしばらく待つか、実行できる同時ビルド数を増やすために料金を支払う必要があります。

いずれにせよ、ビルドが遅いと、時間やお金、あるいはその両方のコストがかかります。

結論

JavaScript は素晴らしい言語であり、JavaScript がなければインターネットは成り立たないでしょう。しかし、ツールを構築するためにそれを使用する必要はありません。それには、Rust のように、より難しく、より良く、より速く、より強力な言語があり、それで問題ありません。JavaScript から離れることはありませんし、より高速な Rust ベースのツールのために JavaScript ベースのビルド ツールを破棄することは裏切りではありません。率直に言って、ブードゥーなマルチスレッドを取得するためだけに、複数の JavaScript インスタンスに苦しむつもりはありません。