00:00:00V+ の最終的な一般公開バージョンは、おそらく
00:00:03使っていて楽しいものになるでしょう。
00:00:06− ゲストはエヴァン・ユーさんです。
00:00:07− エヴァン・ユーさん。
00:00:09− エヴァン・ユーさん。
00:00:10− エヴァン・ユーさん！
00:00:10− 私は Vue と Vite を開発しました。
00:00:14現在は VoidZero という会社を経営しています。
00:00:16− Vite と Vite+ はどう違うのですか？
00:00:19− 開発体験は、今の Vite と
00:00:21全く同じように感じられるはずです。
00:00:22ただ、より高度なことをしたい場合には、
00:00:24あらゆる面で強力にサポートしてくれます。
00:00:26− チームやエヴァンさん自身は、AI をどのように活用していますか？
00:00:28− Angular のコンパイラを Rust に移植するといった、
00:00:30クレイジーな実験を始めています。
00:00:32− React Server Components についてはどうお考えですか？
00:00:34− 最初からずっと懐疑的でした。
00:00:36− 普段、ポッドキャストの導入では
00:00:39ゲストに自己紹介をお願いしているのですが、
00:00:40これを見ている人でエヴァンさんのことを
00:00:42知らない人がいたら、逆に驚きです。
00:00:44それほど有名ですからね。
00:00:46誰もが知っている、あるいは
00:00:48ほとんどの人がエヴァンさんを知っているはずです。
00:00:49− 少なくとも、Vite か Vue の名前は絶対に聞いたことがありますよね。
00:00:53− ええ。私は Vue と Vite を作り、
00:00:57現在は VoidZero という会社で
00:00:59さらに多くのオープンソースプロジェクトに取り組んでいます。
00:01:03Rolldown、Vitest、OXC などがあります。
00:01:07Vue や Vite の方が知名度は高いかもしれませんが、
00:01:11VoidZero で取り組んでいるプロジェクトも
00:01:14かなり面白いものばかりです。
00:01:15Rolldown は Rust 製のバンドラーで、
00:01:18OXC はパーサーからリゾルバー、トランスフォーマー、
00:01:22ミニファイアに至るまでを網羅した
00:01:25完全な Rust 製ツールチェーンです。
00:01:28OXC の上には、OX Link と OX Format もあります。
00:01:32これは ESLint 互換のリンターと、
00:01:35Prettier 互換のフォーマッタです。
00:01:37他にも開発中のものはありますが、ひとまずそんなところです。
00:01:41− まずはオープンソースについてお話ししましょう。
00:01:45− ええ、いいですよ。
00:01:45非常に多くのプロジェクトを抱えていますが、
00:01:47時間はどのように配分しているのですか？
00:01:50− 私自身がすべてのプロジェクトで
00:01:52コードを書いているわけではありません。
00:01:53実を言うと、会社を始めてからは
00:01:56コードを書く時間はかなり減りました。
00:01:58社内には、私よりもはるかに
00:02:01Rust に精通したエンジニアが何人もいますし、
00:02:03彼らは今や完全に AI に心酔しています。
00:02:05Rust のコードの半分は彼らが書き、半分は Claude Code や
00:02:10Cursor が書いているような状態です。
00:02:12私の役割は、DX（開発体験）に関する多くの決定や、
00:02:17次に注力すべきことの判断、
00:02:22そしてもちろん、
00:02:25これらをどうやって利益を生むプロダクトにするか
00:02:28といったビジネス面の検討です。
00:02:31これについてはまだ模索中ですが。
00:02:32最近の会社経営に
00:02:34必要なあらゆる業務をこなしています。
00:02:39− 新しいオープンソースプロジェクトの
00:02:41アイデアはどこから生まれるのですか？
00:02:43社内のニーズから、他の人の問題も
00:02:45解決できるかもしれないと気づくことが多いのでしょうか？
00:02:48− 実は、すべては Vite から始まっているんです。
00:02:49Vite を作った当初は、単なるハックでした。
00:02:53プロトタイプとして作り始め、
00:02:56その後にバンドラーが必要だと気づきました。
00:03:01最初は、完全にアンバンドルされた
00:03:03ネイティブ ESM 開発サーバーからスタートしましたよね？
00:03:07単純なコードならそのアイデアで十分でしたが、
00:03:10巨大な依存関係を取り込み始めると、
00:03:13すべてをアンバンドルで読み込むのは
00:03:16スケールしないことが分かりました。
00:03:18例えば lodash-es は約 700 個ものファイルがあります。
00:03:21そこで、依存関係をまとめるための
00:03:24何かが必要だと考えました。
00:03:26当時は Rollup、esbuild、Webpack がありました。
00:03:28Webpack は ESM を出力しないため使えませんでした。
00:03:30Rollup は esbuild に比べると
00:03:34かなり低速でした。Webpack よりは速いですが。
00:03:41結局、依存関係の事前バンドルには
00:03:47圧倒的に速い esbuild を使い、
00:03:50ソースコードはアンバンドルされた ESM として配信しました。
00:03:53これは非常にうまく機能しました。
00:03:56次にプロダクション環境ですが、
00:03:59当初は esbuild ですべてを
00:04:00バンドルしてしまおうと考えていました。
00:04:02しかし、esbuild はチャンク分割の制御が
00:04:04非常に限られていることに気づきました。
00:04:06大規模なアプリを構築する場合、
00:04:08例えばライブラリの依存関係を vendor チャンクに入れて
00:04:10キャッシュ効率を上げたい、といった制御が不可欠です。
00:04:11ソースコードを変更してもそのチャンクのハッシュは変わらず、
00:04:14ユーザーが再訪した際に
00:04:17常にキャッシュを利用できるようにしたいわけです。
00:04:19esbuild ではこうした最適化が
00:04:21ほとんどできませんでした。
00:04:24デフォルトのチャンク分割の挙動が一つあるだけで終わりです。
00:04:26プラグインシステムも柔軟性に欠けていました。
00:04:28あるプラグインがあるファイルを処理すると決めたら、
00:04:32もう他のプラグインは手を出せない、といった具合です。
00:04:33一方で、私たちは Rollup を使い込んでいて、
00:04:35そのプラグインシステムを熟知していました。
00:04:38そこで、プロダクション環境のバンドルには Rollup を使い、
00:04:39開発時の事前バンドルには esbuild を使うことにしました。
00:04:41それぞれの長所を組み合わせた形です。
00:04:44実際、現在の Vite 6 もまだ
00:04:47この組み合わせに基づいています。
00:04:49多くの人にとってこれで十分機能していましたが、
00:04:53もちろん課題もありました。esbuild は Go、
00:04:56Rollup は JavaScript で書かれています。
00:04:59そのため、プロダクションビルドは
00:05:02Rspack のような完全 Rust 製のバンドラーに比べると低速です。
00:05:05また、開発サーバーでは esbuild と Rollup で
00:05:08プラグインシステムが異なるため、
00:05:10開発時の依存関係には適用できないプラグインが、
00:05:13プロダクションビルド時には適用されるといった状況が起きます。
00:05:15ESM と CommonJS が混在するグラフにおいて、
00:05:20両者のハンドリングが微妙に違ったり、
00:05:23ツリーシェイキングの挙動に差があったりします。
00:05:26どちらも優れたツールではありますが、
00:05:27私たちはこうした不整合をパッチで修正して
00:05:31なんとか動作させてきました。
00:05:35しかし心の底では、異なる二つのものを
00:05:40無理やり繋ぎ合わせているだけだと分かっていました。
00:05:41プロダクションビルドを高速化し、
00:05:43かつ開発環境と本番環境の整合性を高めるには、
00:05:47両方をこなす単一のバンドラーを持つのが最善です。
00:05:52ただ、esbuild は高速ですが、拡張性が高くありません。
00:05:55コードベースはすべて Go です。
00:05:57esbuild の作者である Evan Wallace 氏は
00:05:59数学の天才で、esbuild を驚異的に速くしましたが、
00:06:01他人がそれを拡張したり、フォークしたり、
00:06:03その上にレイヤーを維持したりするには向いていません。
00:06:07容易なことではないんです。
00:06:10また、彼はお金にも名声にも執着がないので、
00:06:13自分がやりたくないことをやるよう彼を説得するのは不可能です。
00:06:15そこで考えました。Rollup を速くできないかと。
00:06:18いくつかの実験は行われましたが、
00:06:22根本的に JavaScript 製なのでシングルスレッドです。
00:06:22ワーカープールや、ワーカー内でのプラグイン実行を試したり、
00:06:25Rollup のメンテナが SWC の Rust パーサーを
00:06:29組み込もうとしたりしましたが、
00:06:31パフォーマンスの顕著な改善は見られませんでした。
00:06:35Rust と JS が混在するシステムでは、
00:06:40常にデータの受け渡しにコストがかかるからです。
00:06:42巨大な文字列をやり取りし、メモリのコピーが発生すれば
00:06:44さらに遅くなります。
00:06:47パーサーだけを Rust にしても、他が JavaScript なら、
00:06:50Rust による恩恵はデータ転送のコストで相殺されてしまい、
00:06:54結局パフォーマンスはほぼ変わりませんでした。
00:06:57つまり、Rollup を劇的に高速化するのは技術的に不可能でした。
00:06:59残された選択肢は、Vite のために完全に設計された、
00:07:02圧倒的に高速なバンドラーをゼロから書き直すことでした。
00:07:05それがすべての探求の始まりです。
00:07:07当初のアイデアは、
00:07:10Rollup を Rust でフォークすることでした。
00:07:12フォークというか、移植ですね。
00:07:15プロジェクト名が Rolldown なのはそのためです。
00:07:17Rollup（巻き上げる）に対して Rolldown（巻き下ろす）。
00:07:21直接の移植として始まりましたが、すぐに
00:07:27JavaScript のコードを Rust にそのまま移すのは
00:07:28不可能だと気づきました。JS は動的言語ですから。
00:07:30TypeScript を使っていても、
00:07:33自由自在に状態を変更できてしまいます。
00:07:36一方、Rust はメモリ、ライフサイクル、
00:07:41所有権などに対して非常に厳格です。
00:07:47JavaScript とは全く異なる構造にする必要があります。
00:07:50既存の JS コードを Rust のような言語に
00:07:54単純に移植することはできず、
00:07:57実質的には書き直しになりました。
00:07:59また、私たちは「いいとこ取り」をしたいと考えました。
00:08:02Rollup 自体は非常にスリムなコアを持っています。
00:08:05しかし、Rollup を
00:08:09実用レベルで動作させるには、
00:08:12Node.js のリゾルバー（node-resolve）などが必要です。
00:08:13node_modules を解決するのは標準機能ではありません。
00:08:16さらに、CommonJS をサポートするプラグインも追加しなければなりません。
00:08:19Rollup コアは ESM 専用だからです。
00:08:23他にも define、inject、replace といった
00:08:26数多くのプラグインが必要になります。
00:08:30これらの機能は esbuild では組み込みですが、
00:08:33Rollup ではプラグインが必要でした。
00:08:37さらに悪いことに、JS の世界におけるこれらのプラグインの多くは、
00:08:40個別にフル AST 解析、変換、コード生成を行っています。
00:08:42つまり各プラグインが、
00:08:44前のプラグインから渡されたコードを受け取り、
00:08:48再度解析し、変換し、
00:08:49新しいコードとソースマップを生成しているのです。
00:08:51そして最後にそれらすべてのソースマップを統合します。
00:08:53プラグインを増やすたびにこの工程が繰り返されるため、
00:08:54JavaScript のビルドシステムはどんどん遅くなっていくのです。
00:08:58そこで、これらを組み込みにする必要があると考えました。
00:09:02つまり、esbuild のようなスコープを持ちつつ、
00:09:06Rollup のような API 形状を持つもの、それが Rolldown です。
00:09:08しかし Rolldown を作るには、
00:09:11パーサーやトランスフォーマー、
00:09:13ミニファイア、リゾルバーが必要になります。
00:09:16それらをどうやって用意するか？
00:09:19そこで登場するのが OXC です。
00:09:23OXC はそれらすべてを提供する、
00:09:25低レイヤーの言語ツールチェーンセットです。
00:09:27作者の Boshen 氏は当時 ByteDance で働いていて、
00:09:29私は以前からこのプロジェクトに注目していました。
00:09:31OXC の作者である Boshen 氏は、
00:09:33現在は VoidZero のエンジニアリング担当副社長です。
00:09:35彼が創業後すぐに加わったわけではありません。
00:09:37当初から誘っていましたが、彼は最初
00:09:42迷っている様子でした。
00:09:45それでも私たちは OXC の上で Rolldown を作り始めました。
00:09:47「これは本物だ」と確信していたからです。
00:09:49利用可能なあらゆる選択肢を検討しましたが、
00:09:51構成要素が一つ一つ独立したクレート（Crate）として使え、
00:09:54かつ合成可能で、
00:09:56圧倒的に高速なものを求めていました。
00:09:58OXC と SWC を比較すると、
00:10:03同じ Rust 製であっても、OXC のパーサーは
00:10:06SWC の 3 倍も高速です。
00:10:10これは設計上の決定や、低レイヤーにおける
00:10:14技術的なこだわりの積み重ねによるものです。
00:10:17Boshen 氏は入社前から、
00:10:20解析やリンティングのパフォーマンスに執着していました。
00:10:25例えば、
00:10:30OXC は「アリーナ・アロケーター」を使用し、
00:10:33AST のためのメモリ割り当てを
00:10:36連続したメモリチャンクに一括で行います。
00:10:38巨大なメモリを確保して、そこに AST を直接配置するんです。
00:10:41これにより、メモリ解放が速くなるだけでなく、
00:10:43OX Link での高速な JS プラグイン実行など、
00:10:46面白いことが可能になりました。
00:10:49メモリ構造が安定しているため、メモリ全体を
00:10:53コピーすることなく JavaScript に渡し、
00:10:56JS 側でデシリアライズできるからです。
00:11:01多くの利点がありましたが、当時プロジェクトを見て
00:11:03非常に感銘を受けた私は、
00:11:07Rolldown を OXC 上で構築することを決め、
00:11:10最終的に Boshen 氏を仲間に引き入れました。
00:11:12現在、会社のスコープは実質的に、
00:11:14パーサーから始まる
00:11:17垂直な Rust スタックの構築になっています。
00:11:20バンドリング、Vite、さらには
00:11:25リンター、フォーマッタ、テストランナーまで網羅しています。
00:11:28そして次のステップとして、
00:11:30実は以前から取り組んでいるのですが、
00:11:33これらすべてを一貫したパッケージにまとめることです。
00:11:36アプリを動かすためだけに、5 つもの個別のツールを
00:11:38インストールする必要をなくしたいんです。
00:11:39また、6 つも 7 つもある設定ファイルも
00:11:44必要ありません。
00:11:45一つの設定ファイルにまとめ、
00:11:47すべて同じパーサー、トランスフォーム、
00:11:51リゾルバーに基づいているため、確実に連携します。
00:11:54「予想外の挙動」もなくなります。
00:11:57例えば Webpack と Jest を併用する場合、
00:12:00解決ロジックが共通ではないため、それぞれ個別に設定が必要です。
00:12:03私たちのビジョンは、
00:12:06あらゆる場所で一貫して動作する垂直スタックを構築し、
00:12:09開発体験を極限までシンプルかつ
00:12:12高速にすることです。
00:12:15パフォーマンスは非常に重要です。
00:12:18当たり前のこととして話してきましたが、
00:12:20Rolldown が Rollup より 20 倍速いとか、
00:12:24OX Link が ESLint より 50〜100 倍速い、
00:12:27OX Format が Prettier より 30〜40 倍速いといった投稿を
00:12:30見たことがあるかもしれません。
00:12:32私たちの目標は互換性を保つことで、
00:12:34大規模なリファクタリングなしで移行でき、
00:12:39劇的な高速化という恩恵だけを享受できるようにすることです。
00:12:41テスト、リンティングなどすべてが
00:12:43より速く、スムーズになります。
00:12:45そうすれば、開発者は
00:12:50より多くのアプリを、より速く構築できるようになります。
00:12:53− 「Vue のためのビルドツールが欲しい」というところから、
00:12:57「この部分も改善したい」「あの部分も」と
00:12:59どんどん話が広がっていくのが素晴らしいですね。
00:13:01そして今や垂直スタック全体を
00:13:05所有している。非常に印象的ですし、仕事が早いです。
00:13:06収録前に話していたのですが、
00:13:10以前の職場でレガシーなプロジェクトに携わった時、
00:13:10Webpack を使っていてビルドに 50 分もかかっていました。
00:13:13何が起きているのか分かりませんでしたが、
00:13:16私が最初に言ったのは「すぐに Vue に切り替えよう」でした。
00:13:21CSS を一行変えるだけで、
00:13:24再ビルドに 2 分も待たなければなりませんでした。
00:13:26これはあり得ないと思いましたね。
00:13:29HMR（Hot Module Replacement）が必要です。
00:13:33ファイルを保存した瞬間に変更が反映されるべきですから。
00:13:34Vue は間違いなくそれを助けてくれました。
00:13:37Vue の普及の速さと
00:13:40その進歩は本当に驚異的です。
00:13:43NPM の月間ダウンロード数が 2 億回くらいという
00:13:47とんでもない数字を見ました。
00:13:50− 少し前に、週間ダウンロード数が 5,000 万回を超えました。
00:13:51− 気が遠くなるような数字ですね。
00:13:55− 5,000 万という数字には、AI が生成した
00:13:57使い捨てのアプリによる水増しも含まれているでしょう。
00:13:59それでも、多くの人々、あるいは
00:14:02多くの AI エージェントが利用している証拠です。
00:14:05− Betaslack のエンジニアチームも Vue の大ファンなんです。
00:14:07バックエンドに Rails、フロントエンドに Vue を使っています。
00:14:10彼らからいくつか質問を預かっているので、順を追って聞いていきますね。
00:14:14バンドリングの話が出ましたが、
00:14:16彼らは Rails で import maps を使っているそうです。
00:14:19バンドリングの未来をどう見ていますか？
00:14:22import maps を使えば、
00:14:25それほどバンドルする必要はなくなりますよね。
00:14:29− 実は Rolldown のドキュメントに、
00:14:30まさにそのための専用ページがあるんです。
00:14:32タイトルは「なぜ今さらバンドラーが必要なのか？」です。
00:14:34− もしかして、よく聞かれる質問ですか？
00:14:39− ええ。DHH（David Heinemeier Hansson）氏も
00:14:43「No Bundle, No Build」を強く主張していますから、
00:14:47無視できないトピックです。
00:14:51import maps はある程度までは機能しますが、
00:14:57アンバンドルという概念が有効なのは、一定の規模までです。
00:15:00モジュール数が 1,000 未満なら、
00:15:04グラフ全体が数百ミリ秒で読み込まれるので、
00:15:08全く問題ありません。
00:15:12その制約内で開発しているなら、素晴らしい選択です。
00:15:15デフォルトで遅延読み込みされますし、
00:15:17巨大なアプリでも各ページが独立していれば、
00:15:20部分的なグラフの読み込みで済むので
00:15:22うまく機能します。Vite が開発環境でうまくいくのもそのためです。
00:15:24しかし、それは万能薬ではありません。
00:15:25私たちが Vite 自体で気づいた課題であり、
00:15:27Rolldown で「フルバンドルモード」に
00:15:29取り組んでいる理由でもありますが、
00:15:32アンバンドルモードにはモジュール数がボトルネックになるという限界があります。
00:15:33世の中には、開発環境で
00:15:35数千ものモジュールを読み込むアプリが数多くあります。
00:15:373,000 モジュールもあれば、ブラウザが悲鳴を上げます。
00:15:40ボトルネックはネットワーク層にあります。
00:15:42ネイティブ ESM では、
00:15:43モジュールごとに HTTP リクエストを送って取得します。
00:15:46インポートの階層が深い場合、
00:15:47最初のモジュールを取得して初めて「あ、追加でこれらが必要だ」
00:15:49と気づき、それらを取りに行く、という工程が繰り返されます。
00:15:49グラフ全体をたどるまで、
00:15:52最初のインポート元モジュールを実行できないのです。
00:15:54回線が細い環境では、
00:15:57最初の描画までに何度もネットワーク往復が発生します。
00:15:59数千モジュールある場合、その悪影響は増幅されます。
00:16:02ローカル開発の Vite サーバーですら、
00:16:053,000 モジュールを超えると、読み込みに 1〜2 秒かかります。
00:16:07これが実際のネットワーク経由のプロダクション環境なら、
00:16:09どうなるか想像できますよね？
00:16:10バンドルしてしまえば 100 ミリ秒で済むはずのものが、です。
00:16:13一定の閾値を超えたなら、
00:16:15バンドリングという「無料の最適化」を利用すべきです。
00:16:19バンドリングやビルドツールを避けようとする主な要因は、
00:16:21ツールの設定に疲れ果ててしまったことだと思います。
00:16:23バグに直面したり、設定の迷宮にハマったりして。
00:16:26Webpack があまりに複雑だったので、
00:16:29みんな「バンドラーの設定なんて、
00:16:33自分の仕事じゃない、やりたくない」と思うようになりました。
00:16:34「ビルドステップ」と聞いただけで、
00:16:36拒否反応を示し、避けたいと考えるようになっています。
00:16:40私たちがこれらのツールセットでやりたいのは、
00:16:42概念を極限まで分かりやすくすることです。
00:16:46巨大で複雑なアプリをシンプルにするのは難しいですが、
00:16:48新しいアプリを立ち上げる際には、
00:16:49アプリが極端に複雑でない限り、何も考えなくていい状態にしたいのです。
00:16:52「Vite を使っているから大丈夫だ」と思えるように。
00:16:54Ruby on Rails のコミュニティには「Vite Rails」といった、
00:16:56Rails で Vite をうまく動かすための取り組みもあります。
00:16:57ビルドなしの構成にも利点はあります。
00:17:00依存関係や、予期せぬ不具合の原因となるものを
00:17:02減らせるという安心感があります。
00:17:04「依存関係をアップデートしたらビルドが壊れる」といった
00:17:07ビルドシステムへの不信感から、それを避けたいという心理は理解できます。
00:17:10しかし最終的には、
00:17:13技術が十分に洗練され安定しているなら、
00:17:16ユーザーに最高の UX を提供したいはずです。
00:17:18完全なアンバンドルに固執することは、
00:17:20アプリの規模に非常に厳しい制限を課すことになります。
00:17:24最適化についても考え続けなければなりません。
00:17:29あるページで不必要に多くのものをインポートしていないか、
00:17:35モジュールをいかに賢くキャッシュするか。
00:17:39アンバンドルの Rails であっても、
00:17:41適切にキャッシュするためにモジュールに刻印を押すような
00:17:43事前処理のようなステップが結局は必要になります。
00:17:45まともに動作させるには、否応なしに最適化に気を配る必要があります。
00:17:48かなりの数のユースケースで機能するとは思いますが、
00:17:50すべてをカバーできるわけではありません。
00:17:53世の中には機能が非常に多い、超大規模なアプリもあります。
00:17:56そうした人たちにまでアンバンドルを強いて、
00:17:58最適化不可能なパフォーマンスの泥沼に閉じ込めるわけにはいきません。
00:18:00− 詳しくない方のために、
00:18:01Vite と Vite+ はどう違うのですか？
00:18:05ユーザーはそこから何を得られるのでしょう？
00:18:07− Vite+ については、今まさにその定義を
00:18:09微調整しているところです。
00:18:12例えば、JavaScript 開発を
00:18:15始めたばかりの初心者が、
00:18:18何もインストールされていない新しい PC を持っているとします。
00:18:21どうすれば、ゼロの状態から HMR やベストプラクティス、
00:18:25リンティング、フォーマット、テスト設定が済んだアプリを
00:18:29手に入れられるでしょうか？
00:18:32現状では、学ばなければならないことが多すぎます。
00:18:33まず「Node.js とは何か」から始まり、
00:18:36そのインストール方法、バージョン管理、
00:18:38どのパッケージマネージャーやビルドツール、
00:18:40リンターを使うべきかといった
00:18:44すべての問いに答えを出さなければなりません。
00:18:46私たちはそうした問いをすべて排除したい。
00:18:49「これを起点に始めればいい」という推奨設定を提供します。
00:18:52極端な話、Node.js を自分で入れる必要すらありません。
00:18:53今実験しているのは、
00:18:54「curl [https://vplus.dev/install](https://www.google.com/search?q=https://vplus.dev/install) | bash」といったコマンド一つで、
00:18:57「vp new」でプロジェクトを作成し、
00:19:00「vp dev」ですべてが整った環境が立ち上がる仕組みです。
00:19:04リンター、フォーマッタ、テストランナー、バンドラーが完備され、
00:19:06モノレポの構築も可能です。
00:19:09ライブラリのバンドリングもサポートします。
00:19:13lint-staged や変更履歴（Changelog）の管理機能も
00:19:17組み込む予定です。
00:19:20また、大規模なモノレポライブラリ向けに
00:19:23「vp run」というランナーも用意しています。
00:19:27pnpm run に似ていますが、より高度で、
00:19:29Nx のようにタスクの実行順序を解析し、
00:19:31賢くキャッシュしてくれます。
00:19:35これらは任意で利用できるものです。
00:19:38こうした追加機能が不要なら、
00:19:40これまでの Vite と全く同じように使えます。
00:19:41開発体験は、今の Vite と
00:19:45全く同じように感じられるはずです。
00:19:47ただ、より規模を拡大し、
00:19:52エンタープライズレベルのモノレポを作りたい時もずっと支えてくれます。
00:19:55すでに現場で実績のある
00:19:56確かな技術の上で構築されていますから。
00:20:01それが私たちの提供したい価値です。
00:20:04現在、多くの既存ユーザーを私たちの
00:20:06オープンソース製品へと導いています。
00:20:08Webpack から Vite へ、ESLint から OX Link へといった流れです。
00:20:11Vite+ が提供するのは、
00:20:14「JavaScript の世界に飛び込む時、
00:20:16最も速くシンプルな道はどれか？」という問いへの答えです。
00:20:19そして、AI との親和性も非常に高くしています。
00:20:22− オープンソースプロジェクトの背後に会社がいると聞くと、
00:20:24一部の機能をペイウォール（有料化）するのではと
00:20:28警戒する人も多いですよね。
00:20:32でも、エヴァンさんの考えでは、
00:20:34Vite+ がやることは自分でもできますよね？
00:20:37ただ、設定が非常に大変なだけで。
00:20:41Vite+ はそれを便利に一つにパッケージ化したもの。
00:20:45だから、機能を切り出して有料にするわけではない、と。
00:20:48− ええ。Vite+ のライセンスの考え方についても、
00:20:50以前少し触れましたね。
00:20:55「会社の規模が一定の閾値を超えたら有料」といった方針です。
00:20:59ただ、多くの関心を寄せてくださっている企業と対話し、
00:21:05より多くの人に届けて価値を創出することと、
00:21:12私たちが収益を得て持続可能であることの
00:21:14最善のバランスを模索し、考えを進化させてきました。
00:21:17おそらく、その有料化の閾値はかなり引き上げる予定です。
00:21:20支払う必要があるのはごく一部の巨大企業だけになるでしょう。
00:21:23大多数のユーザーは無料で利用できるはずです。
00:21:26また、単に機能を有料にするのではなく、
00:21:29サービスに近い形態のアイデアも練っています。
00:21:33Vite+ と連携して、
00:21:36コード品質を向上・監視し、
00:21:37改善のためのヒントやアイデアを提示するようなサービスです。
00:21:41私たちの専門知識を、AI エージェントを通じて
00:21:45スケール可能な形で提供できるからです。
00:21:48今はそうした方向性を探っています。
00:21:52− なるほど。Vite+ がすべてを便利にしてくれるとして、
00:21:54AI が既存のツールを組み合わせて代行できるのでは？
00:21:57AI にリンターやビルド環境を
00:22:01構築させた経験はありますか？
00:22:03AI は学習データの関係で古い技術に依存しがちで、
00:22:06混乱を招くこともあるのではないかと思うのですが。
00:22:08− 実際、AI が構築したアプリで
00:22:11Vite 4 などが使われているのをよく目にします。
00:22:15私たちが新バージョンを出し、新機能をリリースしても、
00:22:18モデルがそれらを学習するまでには時間がかかるからです。
00:22:21モデルは常に最新のトレンドや技術から遅れをとります。
00:22:24そこで私たちが考えているのは、例えば
00:22:29Vite+ の新バージョンをリリースする際、
00:22:31専用のエージェント用定義ファイル（agent.md）やスキルも同梱することです。
00:22:35Vite+ をアップグレードすると、
00:22:37エージェント用設定の関連箇所がパッチされ、
00:22:39パッケージ内で更新されたスキルにリンクされます。
00:22:42また、プロンプトを提示して、
00:22:45「このバージョンからこのバージョンへ上げるには、
00:22:49このプロンプトをエージェントに渡せばスムーズにいく」
00:22:54といったガイドもできます。
00:22:57こうしたことは、ツール開発者が主導すべきだと思っています。
00:23:02一つ気づいたことがあります。
00:23:06OX Link や OX Format、Vitest は
00:23:11OpenClaw でも使われていますよね？
00:23:14OpenClaw は驚異的なコードベースです。
00:23:17JavaScript だけで 5 万 4,000 行もあり、
00:23:21猛烈なスピードで開発が進んでいます。
00:23:25作者は中身を読まずに次々とマージしているようで、
00:23:28中には意味不明な記述もたくさんあります。
00:23:33OX Link をアップデートしたり導入したりする PR を見ると、
00:23:36存在しないオプションが「幻覚」によって捏造されていたりします。
00:23:38「そんなオプションはないですよ」と突っ込みたくなります。
00:23:39また、型チェックが通るようにするために、
00:23:40「このルールをオフにすれば型チェックが通るな」
00:23:42といった対処を AI がしてしまうこともあります。
00:23:44ガードレールを与えないと、AI は近道を選んでしまいます。
00:23:45さらに重要なのは、OpenClaw の作者である
00:23:47Peter 氏は、もともと TypeScript 開発者ではないということです。
00:23:49たまたま手段として TypeScript を選んだだけで、
00:23:50ツールの専門家でもなければ、この分野の経験も浅い。
00:23:52それを AI が補っています。
00:23:54しかし AI に使われるツールの作者から見れば、
00:23:57AI の限界がどこにあるかは一目瞭然です。
00:23:59私たちがそれを指摘し続けなければ、
00:24:03彼のコードは 3 ヶ月以内に崩壊するでしょう。
00:24:08AI 時代に私たちが提供できる価値は、
00:24:15「どうすれば壊さずに、最速で出荷できるか？」
00:24:17ということにあると考えています。
00:24:21AI を使って最速で機能追加し続けるにはどうすべきか。
00:24:25エージェントのおかげで、コードが世に出る速度は
00:24:28劇的に上がっています。
00:24:31でも、それらの機能は適切にレビューされていますか？
00:24:32一日に 20 個も PR をマージして、
00:24:39コードベースは健全に維持されていると言えるでしょうか？
00:24:41コードの「健康状態」は非常に不安定なものです。
00:24:44人間による開発と同様に、
00:24:49機能を次々と出した後は立ち止まり、
00:24:52「整理整頓が必要だ。積み上がった
00:24:57技術的負債を返済しよう」と考える必要があります。
00:24:59AI エージェントを使えば開発が加速する分、
00:25:03技術的負債も猛スピードで蓄積されます。
00:25:04ですから、その負債を返済するためにも AI を活用すべきなのです。
00:25:07これは多くの人が見落としている、
00:25:11今まさに解決策が求められている分野です。
00:25:13− OpenClaw のコードベースを覗いてみましたが、
00:25:17確かになかなかの混沌ぶりでした。
00:25:18監視なしで AI を野放しにして好き勝手やらせると
00:25:20どうなるかを示す、格好の例ですね。
00:25:24ここ数週間のネット上のトレンドとして、
00:25:27その動向を追うのは非常に興味深かったです。
00:25:31AI の役割についてもう一つ。
00:25:33AI エージェントがより使いやすくなるように、
00:25:35フォーマッタやリンターの作り方を変える予定はありますか？
00:25:39それが未来の形になるのか、それとも
00:25:44単に高速なフォーマッタやリンターを作ることが
00:25:47結果として AI 時代に役立っている、ということでしょうか？
00:25:48ツールが速ければ、AI エージェントもサクサク動けますしね。
00:25:52− それは非常に良い着眼点ですね。
00:25:54私たちもちょうどその問題を考え始めたところです。
00:25:57もともとこれらのリンターやフォーマッタは、
00:26:00膨大なスコープを抱えていました。
00:26:0210 年もの歴史があり、本番環境で使い古され、
00:26:05無数のカスタムルールやレガシーな事例がある
00:26:07ESLint や Prettier との互換性を目指していたからです。
00:26:11100% の互換性を実現するのは並大抵のことではありませんでしたが、
00:26:14ついに最近、ESLint プラグインの完全互換を達成しました。
00:26:15ESLint のプラグインテストをすべてパスし、
00:26:17フォーマッタも Prettier との 100% 準拠を果たしました。
00:26:20この二つのマイルストーンを達成したことで、
00:26:23自信を持って人々にツールの移行を勧められるようになりました。
00:26:25では「その次は何か？」ということになります。
00:26:26AI エージェントが利用する場合、
00:26:29リンティングやフォーマットはどう適応すべきか。
00:26:31これは現在、私たちが積極的に取り組んでいる問いです。
00:26:34− 答えはまだこれから、といったところですね。
00:26:37ええ、まだ進化の途中です。
00:26:39AI は間違いなくコーディングの世界を大きく変えていますし、
00:26:41今後が楽しみです。
00:26:44− 再び Vite+ の話題に戻りましょう。
00:26:46ViteConf 2025 で披露された際、
00:26:50「vite install」という機能を見せてくれました。
00:26:53あの機能は今も健在ですか？
00:26:56また、Vite+ は Bun のようなツールと
00:27:00どの程度オーバーラップするのでしょうか？
00:27:02− 鋭い質問ですね。
00:27:07ViteConf の時から、いくつか変更がありました。
00:27:11Vite+ の最終的な一般公開バージョンは、
00:27:14ある意味で Bun のような使い心地になると思います。
00:27:17オンボーディング体験についてお話ししたように、
00:27:20「さらっぴん」の PC で
00:27:25「今すぐ Web アプリを作り始めたい」と思ったら、
00:27:27コマンドを一つ叩くだけで
00:27:31「vp」というグローバルなバイナリが手に入ります。
00:27:35プロジェクトの中にいる時、
00:27:37「.node-version」ファイルがあったり、
00:27:39package.json に packageManager フィールドがあったりしますよね。
00:27:41それらは JS 開発環境の指定によく使われるものです。
00:27:44「vp run build」を実行すれば、
00:27:48あるいは単に「vp build」や「vp lint」を実行するだけで、
00:27:51JavaScript の実行が伴うあらゆる場面で、
00:27:53Vite+ が自動的に正しい Node.js バージョンと
00:27:56パッケージマネージャーを選択して実行してくれます。
00:28:00Vite+ を有効にしているプロジェクトはもちろん、
00:28:02たとえ Vite+ を使っていないプロジェクトであっても、
00:28:05これら標準的な環境指定ファイルがあれば、
00:28:07Vite+ は nvm の代わりとして機能します。
00:28:09Corepack の代わりにもなります。
00:28:13バージョンのことを考える必要がなくなります。
00:28:17開発ワークフローにおいて、
00:28:20npm run を使うのをやめて、vp run を使う。
00:28:26そうすれば常に
00:28:29正しい Node とパッケージマネージャーが使われます。
00:28:31「install」機能についてですが、
00:28:34独自の新パッケージマネージャーを作るわけではありません。
00:28:37Corepack に近いものですが、
00:28:41Anthony Fu 氏が作った「ni」というツールをご存知でしょうか？
00:28:44ni は、実行時に
00:28:47プロジェクトに最適なパッケージマネージャーを自動推論し、
00:28:50run、install、uninstall などを適切に処理します。
00:28:54Vite+ の install は実質的にその機能に、
00:28:58パッケージマネージャー自体の管理を加えたものです。
00:29:00Corepack がやっていることですね。
00:29:05何もインストールされていない状態でプロジェクトに入り、
00:29:08package.json に「pnpm の特定バージョン」と
00:29:10書かれていたとします。
00:29:13「vp install」を実行すれば、自動的に
00:29:17そのバージョンの pnpm があるかチェックし、
00:29:19なければ自動でインストールした上で
00:29:22「pnpm install」を実行してくれます。
00:29:26私たちはリンティングやフォーマットにとどまらず、
00:29:29JS 開発における共通のワークフロー全体を
00:29:31解決したいと考えています。
00:29:34初心者が悩むような問題をすべて排除したいんです。
00:29:36最初にプロジェクトを立ち上げる際、
00:29:40最新の LTS 版 Node.js を使い、pnpm を推奨設定にします。
00:29:43その情報はプロジェクトファイルに書き込まれます。
00:29:45次からは、常に正しい組み合わせで
00:29:46作業ができるというわけです。
00:29:51− ちなみに、なぜ pnpm を推奨しているのですか？
00:29:54− 機能セット、正確性、ディスク効率、速度、
00:29:57そして「catalog」といった優れたワークスペース支援機能の
00:29:59バランスが最も優れているからです。
00:30:00ワークスペース向けのあらゆる機能を
00:30:04比較検討した結果、やはり pnpm が
00:30:06最も高いレベルでまとまっていると判断しました。
00:30:07Bun がとてつもなく速いのは知っていますが、
00:30:09多くのケースで pnpm も十分に高速です。
00:30:12また、将来的にランタイムやマネージャーとして
00:30:15Bun をサポートする可能性も排除していません。
00:30:18「Bun を使いたい」と指定すれば、
00:30:20Bun で処理を回すようにもできるでしょう。
00:30:22− Vite 7（Vite 6 の次期版）は旧正月明けに
00:30:25リリース予定だと仰っていましたね。
00:30:26− はい、その通りです。
00:30:29− 正式リリースに向けて、
00:30:30ベータ版で特に注力していることは何ですか？
00:30:35− とにかく安定性です。
00:30:38エコシステム CI（継続的インテグレーション）を
00:30:41非常に大規模に展開していて、
00:30:44Vite に依存している数多くの下流プロジェクトでテストを回しています。
00:30:46最近では、SvelteKit のすべてのテストが
00:30:50Vite 7 上でパスしました。これは大きな成果です。
00:30:54安定性は最も重要な要素ですから。
00:30:58考えてもみてください。
00:30:59私たちは、実績ある二つのバンドラーを、
00:31:03ゼロから自作した新しいものに入れ替えようとしているんです。
00:31:06飛行中の飛行機のエンジンを積み替えながら、
00:31:11その後もスムーズに飛び続けることを願っているようなものです。
00:31:14これ以上ないほど慎重に進める必要があります。
00:31:19− 以前も聞こうと思っていたのですが、Rust を選んだのは
00:31:22単にチームに Rust の知識があったからですか？
00:31:25TypeScript 界隈では Go が好まれる印象があります。
00:31:26言語間の移行がスムーズだという理由で。
00:31:30TypeScript チーム自身も、コンパイラの
00:31:33移植先として Go を検討していますし。
00:31:36− 確かに TypeScript チームが Go を選ぶのは、
00:31:37先ほど言ったように、Go の方が移植しやすいからでしょうね。
00:31:38メンタルモデルが非常に近いですから。
00:31:40一方で、私たちにとって Go のネックになったのは、
00:31:42WebAssembly（Wasm）のサポートが不十分だったことです。
00:31:45出力されるバイナリが巨大になってしまいますし、
00:31:49Wasm 環境でのパフォーマンスも
00:31:53Rust に比べると見劣りします。
00:31:56Rust を選んだ理由には、
00:31:57優れた人材が揃っていたことも大きいです。
00:32:00すでにこのエコシステムに情熱を注ぎ、
00:32:03精通している人たちがいた。
00:32:05基礎となる技術を探していた時、
00:32:07OXC ほど実装が洗練され、
00:32:09かつ合成可能なパーサーやツールチェーンは他にありませんでした。
00:32:11OXC は、その上に新しいものを構築するために作られています。
00:32:13Go の世界には、これに相当するものが見当たりませんでした。
00:32:16esbuild も独自のパーサーを持っていますが、
00:32:19それは巨大な一枚岩（モノリシック）なシステムの一部です。
00:32:22パーサーだけを取り出して使うようなことはできません。
00:32:26また、esbuild の define や inject、変換といった機能は、
00:32:29最高のパフォーマンスを出すために、
00:32:31わずか 3 回の AST スキャンで実行されるよう実装されています。
00:32:34つまり 1 回のスキャンの中で、
00:32:38変換、注入、修正といった異なる関心事が
00:32:40混在して処理されているのです。
00:32:45これは拡張性を重視するシステムには不向きです。
00:32:48私たちは、さらに多くの変換機能を追加し、
00:32:50ユーザーがそれらを自由にオンオフできるようにしたい。
00:32:53独自のトランスフォーマーを書けるようにもしたい。
00:32:54リンターについても、綺麗に階層化することで、
00:32:56多くの人が同時に開発に参加できるようにしたいと考えました。
00:33:00手に入る選択肢から考えて、Rust が最適でした。
00:33:03Rust は非常に高速ですしね。
00:33:06ただ、Rust で優れたトランスフォーマーを書くのは確かに骨が折れます。
00:33:09ビジターパターンやトランスフォームの
00:33:13パイプラインに最適なアーキテクチャを見出すまで、
00:33:17かなりの時間を費やしました。
00:33:21メモリの所有権の問題、例えば
00:33:23ツリーの深い階層を探索しながら親要素を変更しようとすると、
00:33:25非常に厄介なことになります。
00:33:28ですが、私たちは解決策を見つけました。
00:33:31Go ならもっと楽だったでしょうが、
00:33:34ブラウザ上でも動作させたいという目標がありました。
00:33:38Rolldown はブラウザで動かすことができ、
00:33:40しかも非常に高速です。
00:33:44esbuild もブラウザで動きますが、
00:33:49Wasm に関しては Rust の方が優れています。
00:33:53− Rust での開発チームの話に関連して、
00:33:54チームやエヴァンさん自身は AI をどう活用していますか？
00:33:57チーム内の多くの人が使っているという
00:33:59お話がありましたが、
00:34:01AI は今の仕事において十分に役立っていますか？
00:34:04Web サイト制作のような一般的な開発なら、
00:34:06GitHub に学習データが溢れていますが、
00:34:10エヴァンさんが取り組んでいるのは
00:34:14かなり低レイヤーで技術的な難易度が高い分野ですよね。
00:34:17それでも AI は助けになりますか？ それとも
00:34:19やはり手書きのコードが中心なのでしょうか？
00:34:21− 間違いなく役に立っています。
00:34:23この分野の変化は本当に早いです。
00:34:27去年の今頃、私はまだ懐疑派でした。
00:34:30「試してみたけど、自分の仕事には向かないな。
00:34:33レイヤーが低すぎるから」と思っていました。
00:34:38ところが、OXC のリードである Boshen 氏が、
00:34:41社内で最も深く AI に心酔したんです。
00:34:43彼はとんでもない実験を始めました。
00:34:45先月などは、エージェントを並列でぶん回して、
00:34:46AI と一緒に一週間で 60 個もの PR を出していました。
00:34:51Angular のコンパイラを Rust に移植するという
00:34:56クレイジーな実験も始めて、
00:35:02「AI に丸投げして、動くか見てみようぜ」と。
00:35:04それが、どういうわけか動いているんです。
00:35:06将来的に、その方面での成果をお見せできるかもしれません。
00:35:11AI の能力に対する私たちの認識は、
00:35:15数ヶ月ごとにアップデートされています。
00:35:20新しいモデルが出るたびに、
00:35:22活用環境（ハーネス）が洗練されるたびに、
00:35:26「プランニングモード」の活用や
00:35:28エージェント用設定ファイルの記述といった
00:35:31新しいプラクティスが生まれるたびに。
00:35:36そうした小さなコツを積み重ねていくと、
00:35:40「なるほど、確かにどんどん良くなっている」と実感します。
00:35:44もちろん活用度は人それぞれです。
00:35:45私たちは社内で AI の使用を推奨していますが、
00:35:48あくまで本人が適切だと思う範囲に任せています。
00:35:52Claude の最高プランなどを自由に使えるよう
00:35:55毎月のクレジットも支給しています。
00:35:59使いこなしているメンバーは非常に満足していますし、
00:36:02発信も積極的です。
00:36:05実際、非常に優れた PR を次々と出してくれています。
00:36:06結局は、いかに使いこなせるか次第ですね。
00:36:10モデル自体の素の能力も重要ですが、
00:36:14それをどう活用するかの環境層、つまり
00:36:16ハーネス層も極めて重要です。
00:36:19これはかつての JS フレームワーク黎明期に似ています。
00:36:24誰もが独自のやり方を試行錯誤している状態です。
00:36:27やっていることは大体似通っていますが、
00:36:30ある手法が数ヶ月もすれば当たり前になっていく。
00:36:34非常に競争の激しい分野ですし、モデルも同様です。
00:36:36Sonnet 3.5 の次（3.7）が出ようとしていたり、
00:36:41DeepSeek も新モデルを出そうとしていたり。
00:36:45進化は止まりません。
00:36:48適切な舵取り（ステアリング）さえあれば、
00:36:49AI は極めて有能だということは明らかです。
00:36:51ただ、その舵取りの部分が今も極めて重要なんです。
00:36:56Rust の知識がゼロの人が、AI を使ったからといって
00:36:58OXC のコードベースで作業できるとは思えません。
00:37:01そもそも、何をどうプロンプトすればいいかさえ分からないでしょう。
00:37:03しかし、もともと OXC に精通している
00:37:07Rust エンジニアが AI を手にすれば、
00:37:08生産性は飛躍的に向上し、
00:37:12より多くの機能を、より速く届けることができます。
00:37:14それが私の現時点での結論です。
00:37:16ちなみに、社内のエンジニアたちに比べれば、
00:37:20私が AI を使って生成するコードの量は微々たるものです。
00:37:25私は主にリサーチや、アイデアの壁打ち相手として使っています。
00:37:31− コーディングの進化は本当に凄まじいですね。
00:37:34いくつものサブエージェントをどう使い分けるか、
00:37:36どう並列化するか、リポジトリに
00:37:40どんな markdown ファイルを置くべきか。
00:37:43最新情報を追い続けるだけでも一苦労です。
00:37:45常に変化していますから、
00:37:50最終的にどんな形に落ち着くのか興味深いです。
00:37:53− 少し Vite の話に戻りましょう。
00:37:55Vite 6 では React Server Components (RSC) をサポートしましたね。
00:37:59ただ、私の個人的な意見としては、RSC は
00:38:02開発チームが期待したほどの「決定打」にはなっていない気がします。
00:38:06TanStack のように受け入れられなかったメタフレームワークもありますし、
00:38:10Remix に至っては独自の方向へ進んでしまいました。
00:38:15RSC について、なぜ期待ほど広まっていないとお考えですか？
00:38:19− 私はずっと保守的な立場をとってきましたし、
00:38:21最初からずっと懐疑的でした。
00:38:25だから、Vue で同様のものを実装しようとは
00:38:29一度も思いませんでした。
00:38:33And also like, we don't really rule out the possibility
00:38:35for us to support BUN in our runtime
00:38:37根本的な問いは「具体的にどんな問題を解決しようとしているのか？」です。
00:38:40RSC は過剰にプッシュされていたように思います。
00:38:42人々の期待を煽るために、
00:38:44あらゆるサイトを速くする魔法の杖のように
00:38:49宣伝されてきました。
00:38:52しかし実際に登場してみると、人々は気づいたんです。
00:38:54「これ、全部に使うべきものじゃないな」と。
00:38:58恩恵があるのは特定のケースだけで、
00:39:00それ以外ではトレードオフの塊にすぎません。
00:39:04サーバー側にあるパーツとのやり取りは、
00:39:06すべてネットワーク往復を伴うことになります。
00:39:10これは「オフライン・ファースト」の体験にとっては
00:39:15致命的だというのが私の持論です。
00:39:17また、ハイドレーション（Hydration）のコストからも
00:39:21完全には逃れられません。
00:39:24クライアント側のハイドレーションを減らした分を、
00:39:27サーバー側に付け替えているだけですから。
00:39:28リクエストごとにサーバーでより多くの負荷がかかります。
00:39:30ネット上の陰謀論では、
00:39:33Vercel がサーバーの計算リソースを売るために推進しているなんて言われますが、
00:39:36さすがにそれはないでしょう。
00:39:40ただ、RSC を使うとサーバーの負荷が増え、
00:39:43より多くの計算時間が消費されるのは事実です。
00:39:46一方で、ロジックをサーバーに置くことで
00:39:48バンドルサイズを削減できるといった利点もありますが、
00:39:49その問題は、Node.js サーバーを動かさなくても
00:39:51他に解決する方法がいくらでもあります。
00:39:55これらはあくまで私の個人的な意見ですが、
00:39:57フロントエンドの世界では「アーキテクチャこそが重要」と言われます。
00:39:58SPA でいいのか、SSR が必要なのか。
00:40:02RSC はさらに踏み込んだ選択肢です。
00:40:04「本当に RSC が必要なのか？」という問いは極めて重要で、
00:40:09かつ答えるのが非常に難しい。
00:40:13「Yes」と答えるなら、相応のコストを支払う覚悟が必要です。
00:40:17RSC が広く普及しなかった理由の一つは、
00:40:21あまりにも複雑すぎることだと思います。
00:40:26概念自体の説明も難しければ、仕組みの解説も難しい。
00:40:29私たちはかなり深く関わったので分かりますが、
00:40:32システム全体を動かすには
00:40:35ビルドツールレベルでの綿密な調整が必要です。
00:40:39素の RSC がどう動いているのかを
00:40:41正確に理解している人はごくわずかでしょう。
00:40:44大抵の人は、Next.js による実装を通して知るだけです。
00:40:46平均的な開発者が一人で、React と Vite や Webpack を使って
00:40:48RSC 環境をゼロから構築するのはまず不可能です。
00:40:54日常的な開発の延長線上にあるものではありません。
00:40:59だからこそフレームワークが必要になる。
00:41:04それが前提の技術です。
00:41:08しかしフレームワークで RSC を採用するには、
00:41:11「どうすれば良好な DX（開発体験）で提示できるか」という
00:41:14大きな設計上の決断を迫られます。
00:41:18そして Next.js は、それを完璧にこなしたとは言い難い。
00:41:23「use server」「use client」の混同、
00:41:25「use server」にした瞬間に、今まで動いていたものが
00:41:30パタリと動かなくなるグラフの断絶。
00:41:33使える機能が制限され、読み込んだ依存関係が
00:41:36「use server」に対応していなければ
00:41:37また「use client」に戻らなければならない。
00:41:39こうした細かな DX の不満（ペーパーカット）の積み重ねが、
00:41:41人々に「宣伝されているメリットを得るために、
00:41:42この先ずっとこの煩わしさに耐え続ける価値があるのか？」
00:41:45という疑問を抱かせたのです。
00:41:51人々が二の足を踏むのは当然だと思います。
00:41:54また、フレームワーク作者にとっても状況は同じです。
00:41:57Vercel は React チームと密接な関係にあるので、
00:42:01共同で素早く試行錯誤できました。
00:42:03しかし「サードパーティ」にとってはそうではありません。
00:42:07技術的には Vercel もサードパーティですが、
00:42:09Remix や TanStack にとって、この問題に取り組むのは
00:42:13容易なことではありませんでした。
00:42:16React チームによる API の更新は、
00:42:22常に Next.js が優先されているように見えましたから。
00:42:26それを批判するつもりはありません。
00:42:28Vercel は彼らにとっての「設計パートナー」であり、
00:42:31共に機能を磨き上げ、世に出すというのは
00:42:34理にかなっています。
00:42:37ただその結果、Next.js が事実上
00:42:39唯一の RSC の入り口になってしまい、
00:42:42かつその体験も決して手放しで喜べるものではなかった。
00:42:44それが、期待したほど普及しなかった理由だと思います。
00:42:45そもそも、RSC が完璧な DX を備えた理想の世界であっても、
00:42:49万能薬にはなり得ないというのが私の考えです。
00:42:51どこで使うべきか、どこで使うべきでないか、
00:42:53十分な教育が必要です。あまりにトレードオフが多すぎます。
00:42:57− Vue にも同様の機能を実装してほしいという
00:42:59圧力はなかったようですね。背景には Vercel の存在もありますし。
00:43:01Vercel は Nuxt Labs（Vue のメタフレームワーク
00:43:05Nuxt を開発しているチーム）を買収しましたよね。
00:43:07Vercel 傘下になってから、Nuxt と Vue の関係は
00:43:09どのように変化しましたか？
00:43:12− 正直なところ、あまり変わっていません。
00:43:14買収後も Vercel はかなり自由にやらせてくれているようで、
00:43:16Nuxt チームはこれまで通りの開発を続けられて満足しています。
00:43:19Nuxt を Vercel 上でより快適に動くようにし、
00:43:21「一級市民」にしようとする動きはあるでしょう。
00:43:23ただ、Vercel もコミュニティからどう見られているかは自覚しており、
00:43:25これ以上イメージを損なわないよう細心の注意を払っているはずです。
00:43:28Nuxt を買収したからといって、
00:43:30ユーザーが嫌がることを Nuxt に強いるようなことは、
00:43:32彼らが最も避けたいことでしょうから。
00:43:34− 残念ながら、エヴァンさんは大事な電話のために
00:43:38ここで席を外さなければなりません。
00:43:41貴重なお時間と、すべての質問に対する
00:43:45洞察に満ちたご意見をいただき、本当にありがとうございました。
00:43:49今後ポッドキャストに呼んでほしいゲストがいれば、
00:43:52ぜひコメント欄で教えてください。
00:43:59一般的なフィードバックも
00:44:03大歓迎です。
00:44:04Spotify や Apple Podcasts など、
00:44:07お好みのプラットフォームで私たちを見つけてください。
00:44:11それではまた次回。さようなら。
00:44:13− さようなら。
00:44:16− さようなら。
00:44:19− 楽しかったです、ありがとうございました。
00:44:24− ご参加いただき、本当にありがとうございました。
00:44:27And somehow it's working.
00:44:29So maybe we'll have something along that lane in the future.
00:44:33But yeah, so I think like we are constantly being like update
00:44:39and like our perception of like the reach of capability of AI
00:44:43is just being refreshed every few months
00:44:46with new models coming out,
00:44:48with better harnesses being implemented
00:44:51and better these new practices like use plan mode
00:44:55and then say write your agents MD.
00:45:00This is like use these tips and tricks.
00:45:03So when you apply these little things, you realize, okay,
00:45:06like it is indeed getting better and better.
00:45:08And so adoption still, usage still varies by people, right?
00:45:13We don't like, we encourage everyone at the company
00:45:18to use it to the extent where they see fit, right?
00:45:22We give them a monthly credit
00:45:24so they can use clock of max if they want.
00:45:27So I think some are really happy about it
00:45:33and actually pretty vocal about it.
00:45:36And obviously they are lending really good PRs, right?
00:45:40I think it really depends like on how well you can use it.
00:45:45It's part of it, it's just the raw model capability.
00:45:49Part of it is like the harness you're using,
00:45:52but I think the harness layer
00:45:54is kind of like JavaScript frameworks back in the days.
00:45:57It's like everyone is just like doing their version of it.
00:46:00And they're doing more or less the same thing.
00:46:03Maybe this thing has a few different tricks up their sleeves,
00:46:08but a few months later, everyone is doing it, right?
00:46:11So it's just gonna be sort of like this
00:46:13very competitive field and model is the same.
00:46:17Like every few months,
00:46:18like you see Sono 5 is about to drop.
00:46:21I think a DeepSeek is about to drop a new model.
00:46:23It's like, it's just gonna get better and better.
00:46:26And I think it's pretty clear that AI is extremely capable
00:46:32with the right steering,
00:46:34but I think the steering part is still extremely important.
00:46:37You can't expect someone who has zero knowledge of Rust
00:46:41to be able to work in the OXC code base, even with AI.
00:46:45See, you probably wouldn't even know how to prompt like, right?
00:46:50But someone who has been already efficient in OXC
00:46:54as a Rust engineer himself with AI
00:46:58becomes much more productive
00:47:00and can ship more features faster, okay?
00:47:03So I think that is my general take on it.
00:47:08So I would say I'm probably like the one who,
00:47:13the amount of code I produce with AI is very, very little,
00:47:16very minimal compared to other engineers in the company.
00:47:20I use it more for research and just like a sounding board.
00:47:25- You know, it's certainly a weird world,
00:47:27the sort of coding is going in
00:47:29and I'm finding it sort of hard to stay on top of learning
00:47:32how many sub-agents you're supposed to use,
00:47:34parallel agents, what markdown file you're supposed to have
00:47:37in your repo now.
00:47:38It's, yeah, it's changing all the time.
00:47:40So it's curious to see where we sort of land on that
00:47:43in the future.
00:47:43- If we were to go back to Veet just for a bit.
00:47:47So in Veet 7, you released React server component support.
00:47:52And in my opinion, React server components
00:47:54hasn't been the slam dunk that the team thought it would be.
00:47:57I mean, there are some meta premix that are not acceptable,
00:48:00like tan stack.
00:48:01And I think remix have even gone their own complete direction.
00:48:04So what are your thoughts on React server components
00:48:07and why you think hasn't landed as well as it should have?
00:48:10- Yeah, I have always been really conservative about it
00:48:14or I've been a skeptic from day one.
00:48:17That's why we never considered implementing
00:48:20something similar in view.
00:48:23I think the fundamental idea here is what exact problem
00:48:28is it trying to solve?
00:48:30And I think it was what it was being pushed, right?
00:48:35I think in trying to hype people up,
00:48:38it's being sort of advertised as the silver bullets.
00:48:40That's gonna be the best thing ever.
00:48:42That's gonna make all your websites faster.
00:48:44Turns out when it lands, people realize, okay,
00:48:48like maybe I shouldn't use it in all cases.
00:48:51It only applies to a certain type of cases
00:48:54where it will benefit you.
00:48:56And then in other cases, it's just a bunch of trade-offs.
00:48:59Because like the parts that lives on the server,
00:49:04you now all the interactions actually have to go
00:49:06to a network round trip.
00:49:08And that's actually pretty good,
00:49:10pretty bad for like offline first experience, in my opinion.
00:49:14And then you can't really fully escape the hydration costs,
00:49:20in my opinion.
00:49:21And you are offsetting a lot of client-side hydration cost.
00:49:26You're offloading that to the server, right?
00:49:29Now you're bearing the cost of every request
00:49:31you're doing more work on the server.
00:49:33So people have these like theory, conspiracy theory,
00:49:38where like the cell is pushing it to sell or compute.
00:49:44I don't really think that is what it is, right?
00:49:47But it is also true that using ISC
00:49:51means you have more server load.
00:49:52You're running more things on the server,
00:49:54you're using more compute minutes.
00:49:56And ultimately there are other benefits like say,
00:49:59if you put a part of your thing on the server,
00:50:01you save the bundle size.
00:50:02There are a lot of different ways to solve that problem,
00:50:06which doesn't necessarily involve
00:50:07you having to run no JS server, right?
00:50:10And a lot of this is my personal opinion, right?
00:50:14Like in front end, we tend to say, okay,
00:50:17like architecture really matters.
00:50:19Do you want to use an SPA?
00:50:21Do you need server-side rendering, right?
00:50:24ISC is even more specific.
00:50:27Like, do you need ISC is a very important question
00:50:31and a very hard question to answer.
00:50:33And when you say yes,
00:50:35you also need to be aware of the cost you're paying
00:50:37because I think one of the reasons
00:50:39it didn't get really well adopted is first of all,
00:50:43it's extremely complicated.
00:50:46The thing itself is hard to explain.
00:50:48How it works is hard to explain.
00:50:50We had to like go really deep
00:50:52because it actually requires built tool level orchestration
00:50:56to make the whole system work, right?
00:50:58And then, so very few people actually understand
00:51:02how raw ISC works.
00:51:04Most people know about it through the implementation
00:51:07in Next.js because raw ISC is something that an average user
00:51:11wouldn't be able to set up by themselves, right?
00:51:14You'd have to really understand how to all fits together
00:51:17to be able to put something up from scratch
00:51:20with plain React and Vite or Webpack, right?
00:51:23It's not for the day-to-day development, right?
00:51:27So you want to use a framework.
00:51:29That is what's built for.
00:51:30But in order to use ISC in a framework,
00:51:33the framework has to make design decisions
00:51:36to sort of how do you present ISC
00:51:39in a way that would give you the decent DX?
00:51:42And I think Next.js didn't nail it, I would say, right?
00:51:47Like the use server, use client confusion,
00:51:51the mixed graph where like when you make something use server
00:51:55and something, these things just stop working.
00:51:58Like you're limited to only be using these things
00:52:01and then you have to import a dependency
00:52:03and the dependency is like, it doesn't work on use server.
00:52:06Now you have to use client again, right?
00:52:08So this kind of back and forth,
00:52:10I think it's just like a lot of these little paper cuts
00:52:12in DX makes people think, okay,
00:52:15like in order to get the claimed benefits,
00:52:20now I have to also just put up with this annoyance of DX
00:52:24all the time, forever into the future.
00:52:27Is it really worth it, right?
00:52:28So yeah, so I think it's fair that people are like,
00:52:35do I really want to use it?
00:52:37And also like even for framework authors, right?
00:52:40Vercel had this really close relationship with the React team
00:52:42so they can collaborate and iterate on it fast.
00:52:45But for third party, I wouldn't even say third party
00:52:49because technically Vercel is third party, right?
00:52:52But for other frameworks like remix and test stack,
00:52:57it's not that straightforward for them to work on,
00:53:02to work on this problem because a lot of these API iterations
00:53:06from the React team is like prioritizing Next.js.
00:53:08So I think I'm not really criticizing them for it
00:53:13because it's like, okay, Vercel is their design partner.
00:53:15They want to partner with Vercel
00:53:17to get this feature polished and ship it,
00:53:19which makes sense, right?
00:53:21But I think, and because of that,
00:53:25like Next.js essentially was the only real way
00:53:29for people to use RSC.
00:53:31And that experience hasn't been super great.
00:53:33So I think that's why it just didn't pan out as it could.
00:53:38And also like, I think the general premise
00:53:41of even in an ideal world where RSC has like perfect DX,
00:53:46I still don't think it's going to be a silver bullet
00:53:49in all cases, right?
00:53:50So you need to be fully educated
00:53:52on where it makes sense, where not.
00:53:54So just too many trade-offs.
00:53:57- I assume there's been no sort of push
00:53:59to implement something similar in view
00:54:01because obviously linking is back to Vercel.
00:54:03They bought Nuxt Labs,
00:54:05which is the sort of meta framework on top of Vue
00:54:08for piecing it all together.
00:54:09How's that sort of relationship been between Nuxt and Vue
00:54:13now that Vercel own them?
00:54:14- Honestly, it didn't change much.
00:54:18I think Vercel has been pretty hands-off since the acquisition
00:54:21so the Nuxt team is just happy to be able
00:54:24to keep doing what they do.
00:54:25There are probably some efforts to say,
00:54:30make Nuxt work better on Vercel,
00:54:32make a first-class citizen.
00:54:34But I think the thing is Vercel is aware
00:54:38that some of the images it has in the community
00:54:43and they would be really careful not to damage it further.
00:54:47And so after acquiring Nuxt, right,
00:54:50the last thing they'd want to do
00:54:52is to force Nuxt to do things people don't like.
00:54:54- Unfortunately, Evan had to leave early
00:54:56to take an important call,
00:54:58but we really appreciate his time
00:55:00and all his insightful opinions on all the questions we asked.
00:55:04If you have any future guests you'd love on the podcast,
00:55:06please let us know in the comments.
00:55:08And if you have any feedback in general,
00:55:10also let us know too.
00:55:11We'd love to hear it.
00:55:12Find us on anywhere you listen to podcasts
00:55:15like Spotify or Apple Podcasts.
00:55:17And until next time, it's a bye from me.
00:55:20- Bye from me.
00:55:21- Bye from me.
00:55:21- It's a pleasure, thank you all.
00:55:23- Thank you very much for joining us.