ビルドの完了を待つ開発者でいっぱいの部屋には、独特の静寂が漂う。目はサブモニターへと泳ぎ、親指はスマートフォンをスクロールする。誰かが、本当は欲しくもないコーヒーを求めて席を立つ。もしあなたがモダンなJavaScriptのコードベースに触れたことがあるなら、この「間」を知っているはずだ。それは単なる休憩ではない。思考の空白なのだ。

私たちはフレームワークについて多くを語る。React、Vue、Svelte、そして来週リリースされるであろう何かが、人々の注目を集める。カンファレンスはフレームワークの発表で完売し、ブログ記事はシンタックスシュガーを詳細に分析する。しかし、そうしたユーザー向けのノイズの底では、コードの書き方そのものを根本から変えてしまうような地殻変動が起きている。革命はフロントエンドフレームワークから来るのではない。ツール層で起きており、それはRustとGoで書かれている。

長年、JavaScriptのツールはJavaScriptで構築されてきた。それは理にかなっていた。Babelは、次世代の構文を今日書く方法を世代を超えて教えてきた。Webpackは、分割されたコードをブラウザが処理できる形にバンドルした。ESLintは、コミット前にバグを検知した。これらのツールは、より小規模なウェブ向けに設計されていた。数千ではなく、数百のモジュールを想定していたのだ。単一のリポジトリを想定しており、共有UIパッケージへの変更が12ものアプリケーションに波及するようなモノレポは想定していなかった。

やがて、アプリケーションは成長した。コードベースは巨大なリポジトリへと膨れ上がった。ツールは変わらないまま、レイテンシが忍び寄ってきた。2秒で終わっていたホットリロードは12秒、30秒へと伸びた。昼食前にフルテストスイートを実行することなど、もはや幻想となった。リンターは、千回もチェックしたはずのファイルで立ち往生する。一つ一つの遅延は、机上では小さく見えるかもしれない。しかし実際には、これらの停止時間は集中力を粉砕する。作業をまとめて行うようになり、修正が機能したか確認する前に躊躇するようになり、フィードバックにかかるコストが高すぎるために実験を避けるようになる。

次世代のツールは、単にJavaScriptの制約から解き放たれることで、そのレイテンシに立ち向かっている。

新しいエンジンルーム

特定のタスクがどのように取り戻されているかを見てみよう。

**Transformation（変換）**といえば、かつてはBabelを指した。それはJSXやstage-3の提案をプレーンなES5に変換する、汎用的なプリプロセッサだった。今でも素晴らしいソフトウェアだが、それはシングルスレッドのJavaScriptがJavaScriptをパースしている状態なのだ。そこに登場したのが、RustベースのツールチェーンであるOXCだ。Babelと同じタスクをこなすが、ベンチマークでは約40倍速く、メモリ消費量は70%も抑えられている。これは漸進的な改善ではない。意識せずに動いていることを忘れてしまうようなツールと、存在を意識せざるを得ないツールの決定的な違いである。

**Bundling（バンドル）**は、最も深刻な痛みを感じる場所だった。Webpackは10年間にわたり標準であったが、その内部構造は異なるスケール向けに構築されている。そのRustによる後継であるTurbopackは、単に再コンパイルが速いだけではない。強力なメモ化を活用して、何が変更されたかを正確に把握し、その部分だけを再構築する。大規模なアプリケーションにおいて、単一のコンポーネントを変更するたびにグラフ全体を走査させるべきではない。Turbopackを使えば、ビルドは瞬時に近いものになる。見守るべきものがないため、プログレスバーさえ消えてしまう。

**Testing（テスト）**にも特有の停滞がある。JestはJavaScriptのテストを再定義したが、ウォッチモードでは、キー入力のたびにコードベースを学習し直しているかのように感じることがある。Vitestは異なるアーキテクチャを採用している。ゼロから依存関係ツリーを構築するのではなく、Viteのモジュールグラフを再利用するため、ウォッチモードでの速度はJestよりも約8.5倍速い。ここでの勝利は単なる速度ではない。一貫性だ。テストランナーと開発サーバーが、プロジェクトの構造についてようやく一致するのだ。

**Linting（リンティング）**も同様のオーバーヘッドに苦しんでいる。ESLintの柔軟性は最大の強みであり、そのルールはAST上で動作する単なるJavaScript関数である。しかし、その柔軟性がサイクルを消費する。Rustで書かれたOxlintは、一般的なケースにスコープを絞ることで爆速を実現している。ESLintよりも50倍から100倍速く動作する。実用的な効果として、エディタの保存アニメーションが終わる前にリンティングが完了する。問題を修正したあとも数秒間残り続ける、あの赤い波線を我慢する必要はなくなるのだ。

Perhaps the most symbolic shift is happening in type checking. Microsoft is currently rewriting the TypeScript compiler in Go. Early benchmarks are striking: VS Code loads roughly 8 times faster with the new implementation, and type checking itself is approximately 10 times faster. Consider what that means. TypeScript isJavaScript’s success story. It is a language that compiles to JavaScript, used to type-check JavaScript ecosystems, and now its own compiler is moving to a native systems language because JavaScript cannot deliver the performance the ecosystem demands. The tool is eating its own path to speed.

None of this replaces React. It does not kill Next.js or make TypeScript obsolete. Frameworks still define your component model and your routing. These new tools simply make everything underneath faster. They are the road, not the car.

When Speed Changes Behavior

Tooling conversations often get stuck in benchmark charts. Numbers are easy to compare. But the real impact sits in human behavior.

When feedback drops from seconds to milliseconds, you do not just finish tasks faster. You finish them differently. You stop hoarding changes. You write a line, see the result, adjust. You run tests because they are instant, not because your pull request requires them. You try the refactor that might not work because undoing it costs nothing. You stay inside the problem instead of waiting for the machine to let you back in.

This is what psychologists call flow. It requires a tight loop between action and consequence. A guitarist cannot play if the amp delays every note. A painter cannot mix color if the brush updates a half-second late. Developers are no different. Latency is not an annoyance. It is a tax on thinking.

The productivity gain, then, is not merely technical. It is habitual. Fast tools train you to experiment. Slow tools train you to hesitate. Over the course of a year, the difference compounds into entirely different software. The team with instant feedback ships more confidently. They break work into smaller pieces because the cost of trying is zero. Their code reviews shrink because bugs get caught in the moment, not in CI twenty minutes later.

The Invisible Work

This is why the headlines are misleading. Frameworks are easy to write about. They have logos, APIs, and Twitter drama. Infrastructure is invisible by design. You do not wake up excited to configure a bundler. You want it to vanish. But vanishing is exactly what good infrastructure does. It carries the weight so the visible layer can stay light.

If you are leading a team or maintaining a legacy codebase, this should inform your priorities. Migrating from React to Vue might reshape your component tree. Migrating from Webpack to Turbopack or from Babel to OXC might reshape your entire workday. The latter is a harder story to sell to management because there is no new homepage demo. There is only a team that stops sighing at their build terminal.

Audit what is actually slowing you down. If you are running a modern monorepo on a toolchain built in 2015, you are not being conservative. You are paying a daily friction tax. The fix is not learning a new frontend paradigm. It is swapping the engine.

The frameworks will keep coming. They will keep getting the tweets and the conference keynotes. But the real shift in how JavaScript feels to write is happening under the hood, in compiled languages that treat your time as expensive. That is the revolution. Not a new way to render a list, but a toolchain fast enough to get out of your way and let you think.