VoidZeroがCloudflareに参加
(blog.cloudflare.com)- VoidZeroはVite、Vitest、Rolldown、Oxc、Vite+を生み出した企業であり、今回VoidZeroチーム全員がCloudflareに加わった
- ただし、開発中のプロジェクトは今後もオープンソース・ベンダー中立・コミュニティ主導で維持される
- ViteはVue、SvelteKit、Nuxt、Astro、Solid、Qwik、Angular、React Router、TanStack Startなど多くのJavaScriptフレームワークの基盤であり、CloudflareはViteエコシステム基金に100万ドルを拠出した
- Environment APIは開発中のサーバーコードをNode.jsではなくランタイム上で実行できるようにし、Cloudflare Vite pluginは
workerdでWorkersと同じランタイムモデルをローカルに提供する - AIエージェントがプロジェクト作成、開発サーバー起動、エラー読解、テスト・lint・format・プレビュー配備を繰り返すようになり、高速ビルド、高速テスト、構造化されたエラー、一貫したCLIの重要性が高まっている
- CloudflareツールはViteをCloudflare寄りに引き寄せるのではなく、CloudflareのアプリケーションツールをViteの上へ移していく流れであり、長期的には
cfCLI、フルスタック・エージェント向けのプロバイダー中立プリミティブ、Voidプラットフォームのオープンソース化へつながる計画である
参加と維持される原則
- VoidZeroはVite、Vitest、Rolldown、Oxc、Vite+を生み出した企業であり、今回の変化によってVoidZeroチーム全員がCloudflareに参加した
- Vite、Vitest、Rolldown、Oxc、Vite+はオープンソース、ベンダー中立、コミュニティ主導の方針を維持する
- ViteはMITライセンスと公開開発の方式を維持し、Viteで作られたアプリケーションはどこでも実行可能であるべきだという原則を継続する
- Evan YouとVoidZeroチームは今後もVite、Vitest、Rolldown、Oxc、Vite+を率い続け、Cloudflareはこれらのプロジェクトにエンジニアリングとリソースを投入する
- AstroがCloudflareに参加したときと同様に、Astroもオープンソースでどこにでもデプロイ可能という性格を維持し、既存のロードマップを継続する
Viteエコシステムと100万ドル基金
- ViteはVue、SvelteKit、Nuxt、Astro、Solid、Qwik、Angular、React Router、TanStack Startの基盤として使われており、Next.jsもvinextによりViteベースの実装を持つようになった
- Cloudflareは、Viteの採用を生んだ信頼を維持することを最優先目標とし、その信頼はプロジェクト支援と開発の進め方によって示されるべきだと考えている
- CloudflareはViteコアチームが運営するViteエコシステム基金に100万ドルを拠出し、メンテナーとコントリビューターを支援する
- ViteはVoidZeroやCloudflareより大きなプロジェクトであり、Viteの構築に貢献してきた人々が今後の過程にも参加すべきだという方向性である
ViteとCloudflareの技術的接点
- ViteとCloudflareの協業は2024年のVite Environment APIから始まり、このAPIは開発中のサーバーコードをNode.jsではない環境で実行できるようにする
- Cloudflare Vite pluginで
vite devを実行すると、サーバーコードはWorkers本番環境を動かすオープンソースランタイムworkerd内で実行される - Durable Objects、D1、KV、R2、Workflows、Workers AI、Agents、Service Bindings、Workers RPCが本番と同じランタイムモデルでローカル実行される
- Environment APIはCloudflare専用の開発サーバーを強制せず、Vite内の一般的なメカニズムとプロバイダーごとの実装という構造を可能にする
- Viteは週間ダウンロード数約1億2,900万回、
@cloudflare/vite-pluginは週間ダウンロード数約1,400万回に達している
AIが変える開発ループ
- エージェントは開発サーバー、バンドラー、リンター、フォーマッター、CLIを使い、プロジェクトを作成し、開発サーバーを起動し、エラーを読み、テストを書き、lint・format・プレビュー配備を繰り返す
- AI生成アプリケーションの多くは、高速で広く理解され、学習データとも幅広く互換性のあるViteアプリとして始まる
- エージェントベースの開発では人間よりも多く反復するため、高速ビルド、高速テスト、高速なlint・format、明確で構造化されたエラー、一貫したCLIがより重要になる
- Vitest、Rolldown、Oxc、Oxlint、Oxfmtはそれぞれの分野で高速なツールとして設計されており、Vite+はそれらを単一のCLI、単一の設定モデル、より少ない構成要素にまとめる
- CloudflareダッシュボードはViteで作られており、OxlintはCloudflareコードベースでエンジニアリング時間を日単位で節約しているほか、Astroチームのエージェントハーネス（harness）フレームワークFlueもViteベースへ移行しつつある
フルスタックViteとCloudflare CLI
- 現代のアプリケーションはサーバーレンダリングルート、API、バックグラウンドジョブ、キュー、データベース、オブジェクトストレージ、リアルタイム機能、認証、エージェントやAI機能まで扱うため、ビルドツールの役割はバンドル生成だけでは十分でない
- Viteは速度、単純さ、移植性を維持しながら、アプリケーションのより多くの部分を理解する方向へ拡張されている
- Vite向けデプロイプラットフォームVoidは、現代のアプリケーションフレームワークが何を担うべきか、デプロイがどのような体験であるべきか、アプリケーションのライフサイクル全体を1つのツールチェーンにどこまで統合できるかを試す場だった
- 一部の学びはバックエンド、API、エージェント、デプロイ向けのプロバイダー中立な抽象化とフックとしてVite自体に取り込まれ、CloudflareはWorkersとDeveloper Platform上でそれらのフックのファーストクラス実装を提供する
- Vite本体の変更は従来どおり公開された貢献プロセスに従い、Viteに追加される機能はCloudflare専用ではなく、Viteが動作するあらゆる場所で動く必要がある
- CloudflareはViteをCloudflare側へ移すのではなく、CloudflareのアプリケーションツールをViteの上に載せる方向を選んだ
- 新しい統合CLI
cfのテクニカルプレビューが公開され、アプリケーション向けCLI体験の基盤はViteになる予定である cf devはvite devの上位集合として、同じ速度、同じホットモジュールリプレースメント、同じプラグインモデルにCloudflareランタイムとバインディングを加える方向であるcf buildはアダプター手順なしでViteプロジェクトをネイティブに理解し、cf deployはViteアプリをCloudflareへ簡単にデプロイできるようにすることを目指す
次のステップ
- 短期的にはVite、Vitest、Rolldown、Oxc、Vite+は継続してリリースされ、VoidZeroチームも貢献とリードを続ける
- Cloudflare Vite pluginは引き続き改善され、サーバーコードを正しいランタイムでローカル実行するEnvironment APIの流れは、Cloudflare以外のランタイムも含めてさらに良くなっていく方向である
- 長期的にはCloudflare CLIはViteの上に直接構築された体験へ移行し、Viteはフルスタックアプリとエージェント向けのプロバイダー中立プリミティブを備える予定である
- 時間がたてばVoid platformをオープンソースとして公開し、他の人々がViteとCloudflare上で独自のプラットフォームを構築できるようにする計画である
- 今すぐCloudflareでViteを試すなら、
npm create vite@latestとnpx wrangler deployを実行すればよい
1件のコメント
Hacker Newsの意見
2014年2月3日付けの「Vue.js: JavaScript MVVM made simple (vuejs.org)」という投稿があった: https://news.ycombinator.com/item?id=7169288
Evan Youは美術史とスタジオアート専攻で、Parsons Schoolで作品を素早く見せるためにJavaScriptを学ぶ必要があったようだ
Google Creative Lab 5にいた頃、AngularJSの体験を改善したいという発想からVueを作り、その後はよく知られた歴史のとおりだ
今回のCloudflareによる買収が最終的に何を意味するのかは分からないが、Evanとチームが何年もかけて作ってきた美しいフレームワークとツールには本当に感謝している
最近Cloudflare PagesとWorkersも触り始めたが、基本的なアプリを立ち上げる過程がすでにかなり苦痛が少ないので、今回の協業で自分の生活がもっと楽になりそうだ
聴く価値は十分にある
こうしたプロジェクトのビジネスモデルは結局、1. 人気のある開発者ツールを作り、2. 資金を調達し、3. 優秀な人材を採用し、4. 初期投資を正当化するための**アクハイア(acqui-hire)**を祈る、ということなのだろうか
初期投資家がこうしたアクハイアの道筋をどう感じているのかも気になる。納得できるほどかなり良い金額だったか、あるいは売上への道がほとんど不可能か存在しないと見ていたのだと思う
中立的に言えば、ベンチャーキャピタルのパートナーたちが同じポートフォリオの一部のように扱っていて、あるチームが独立してうまくいかないなら、目標や市場がある程度近い別の場所に統合されることがあるということだ
もっと率直に言えば、結局は誰を知っているか、そして皆が成功したイグジットの話をできるようにすることでもある
この場合、コア製品はMITライセンスなので、チームが金曜日に辞めて月曜日に新しい組織の下でまったくそのまま作業を続けることもできる
AI時代には、この分野の一部の買収は人材と製品のために見える
今回もそういうケースのように見える。Viteは素晴らしい製品で、彼らは素晴らしいチームを作ることができた
企業が人材にどれほど大きなプレミアムを支払えるかを知れば驚くかもしれない
結局ツールが劣化したり、高くなりすぎたり、完全に消えたりすることがあり、新しい所有者が悪い判断をして、リファクタリングや移行を強いられるのにうんざりしている
こうした買収発表はいつも不安になる。「何も変わらず、ロードマップもそのままだ」といった話が多いが、少し計算すれば事業はそんなふうには回らないと分かる
別の話として、仕事でCloudflareを使わなければならないが、私のいる中規模組織ではかなりひどい体験だ。「敵対的なユーザー体験」という不満がよく出る
オープンソースプロジェクトを買収するより、Vercelとユーザー/開発者体験で競争することにお金を使うほうがいいのではないかと思う
残念ながら「敵対的なユーザー体験」という表現は何度も聞いており、改善しようと懸命に取り組んでいる。よければ、どんな問題に遭っているのかもっと聞きたい
独立したままでいるのが常に望ましいが、同時にもっと悪い「新しい家」もあり得るので、うまくいくことを願いつつ見守るという立場だ
Viteが好きだ。自分のプロジェクトに入っていることを忘れさえしなければ、という意味で。人を馬鹿みたいに感じさせていたもののほとんどを、ほぼ設定不要にしてくれた
でもこのニュースはうれしくない
今年初めのAstro関連のニュースも同じだった
プロジェクトを作った人たちにとっては明らかに良いことなのだろうけど、こういう買収には何か不安にさせるものがある
ただ、その次に来ることが少し悲しい。こういうことが何度も繰り返されるのを私たちは二人とも見てきたし、決まり文句の「何も変わらず、すべてが永遠に良いままだ」という話は読み飛ばすことを覚えた
数年前、かなり複雑なプロジェクト、Rust WebAssemblyバインディングを含むモノレポをWebpackからViteへ移行したら、開発ビルドも本番ビルドも分単位から秒単位にまで短縮された。それ以来Webpackは二度と振り返っていない
このニュースにどういう感情を持てばいいのかわからない。特にVite 7からVite 8へ移行したとき、文書化されていない形でプロジェクトが壊れたこともあったが、慎重に楽観している
それでもEvanにはおめでとうと言いたい
面白い話を付け加えると、Fred “fks” がSnowpackが勢いを得られなかったあとにAstroを作った
「その存在をただ忘れていられる」という事実は、自分にとって大きな勝利だ。WebpackはGrunt/Gulpよりは良かったかもしれないが、とてつもなく複雑だった
自分も少し不安だ。いつもではないが、企業に取り込まれる場所は、しばしば素晴らしいプロジェクトが死にに行く場所になる
幸い、オープンソースにはTerraform→OpenTofu、Redis→Valkeyのような話が十分にある
Cloudflareにとってこれに価値がある理由は、AIがCloudflareをより多く推薦するようになる可能性があるからだ
エージェントはすでにViteを探している。Viteを見つけたら、その次のデフォルトとしてCloudflareを選ぶのはとても自然だ。Next.jsについてユーザーをVercelの設定へ案内するのと似ている
これは2,000万ドルの買収かもしれないが、エージェント版SEOの増加によって数十億ドルを生み出す可能性もある
ただ、根底にある主張には同意する。大規模言語モデルの利用が増えるにつれ、Webアプリケーションホスティングの市場シェア獲得に役立つ可能性は高い
LovableはCloudflareを使っているので、おそらくCloudflare Workersにデプロイしているのだろう
純粋にビルド段階という観点だけで見れば、ViteやBunのようなツールは、意味のある形で達成できることはすでにやり切ったように思える
自分がこうしたツールの作者だったとしても、自分も次へ進んだだろう。幸運を祈るし、これまでありがとう
あるいは、不要な「コンポーネント」ライブラリのいくつかを使う前提、もしくはコンポーネントをまったく使わない前提を置く代わりに、カスタムHTML要素のパッケージングに投資することもできたはずだ
こうしたツールには進める先がたくさんあるのに、そちらへ進もうという意思がない。すでに「十分に良い」ものがあるせいで、「もっと良くできるもの」を探していない可能性が高い
さらに、開発組織の管理層が、開発者はもうコードベースに触るべきではなく、実作業は大規模言語モデルにやらせたいと考える流れも加わっている。だから「エージェント」を満足させるために、あらゆる怪しげなものを作っている
これが必ずしも開発者をより困難にするとは限らないが、流れはそう見える。大規模言語モデルにとって、苦痛で難解な、1文字単位で正確な文字列連結に従わせるほうが、汚い人間のように何かを探索させるよりもずっと簡単だからだ
実際の結果は、人間にはより不親切で、ロボットにはより親切なツールになることだ
だから同意しない。人間のために意味のある形で達成できることはまだあるし、彼らはそういうことに深く関心がないように見える
Vite、Bun、uvが単に「ビルドを速くする」だけのプロジェクトなら、収穫逓減があるかもしれない。だがCloudflare、Anthropic、OpenAIによる買収は、このレイヤーの重要性が薄れているのではなく、より戦略的になっていることを示している
これらのツールはソフトウェアサプライチェーンの上にある。依存関係の解決、プロジェクト構造、テスト、ビルド、ランタイム、デプロイ経路、そしてますますAIエージェントの実行ループにまでまたがっている
ソフトウェアを作る基本経路を定義しており、AI生成コードが実際の依存関係、ビルド、テスト、デプロイの制約とぶつかって検証される場所でもある
だから、意味のあることはすべてやり切ったとは思わない。価値は純粋なビルド速度から、ソフトウェアが組み立てられるワークフローレイヤーの支配権へと移っている
「Vite、Vitest、Rolldown、Oxc、Vite+はオープンソースであり、特定ベンダーに縛られず、コミュニティ主導のままである。この点は変わらない」と最も重要な点を先に明確にしたのはありがたい
ただ、過去にあまりにも何度も痛い目を見てきたので、今では買収には非常に懐疑的だ。時間が経たなければこの言葉が守られるかはわからないが、少なくとも公式記録としては明確に残った
これが買収契約や文書のどこかに入っているのかも知りたい
だからその約束は、「当分のあいだはオープンソースで云々のままだ」程度に受け取っておく
Viteは好きだけど、どうやって収益化できるのかがはっきりせず、ずっと気の毒に感じていた。VoidZero 全体も少し無理筋に思えていた。
これが、私が優れたツールを作る仕事をいつもためらってきた理由の一つでもある。何とかして生計を立てなければならないからだ。
だからこそ、作ったチームが当然受け取るべき報酬と持続可能性を得られるようになったのはうれしい。
ツールや価値にお金を払いたがらない層に売らなければならず、最終的には、少しAIエージェントのセッションを回せば機能同等にできる自分自身の無料版と競争することになる。
記録として見るとこうなる。
NPM → Microsoft
Vite → Cloudflare
Bun → Anthropic
Turbopack → Vercel
Remix → Shopify、これはもうほとんど記憶にも残っていない。
Biome、以前のRome → 独立しているがDepotの支援をかなり受けている。
SWC → 独立
esBuild → 独立
私はByteDanceが支援する RsBuild/RsPack を使っている。
Svelte → Vercel
Astro → Cloudflare
夢はいつだって Cloudflare Workers向けの第一級フレームワーク だった。
ごく初期には、文字どおりブログ記事やGitHubリポジトリを見ると、ちょっとしたデモしか作っていなかった。
その後長いあいだ、サーバーサイドレンダリング可能な機能によって「フルスタック」になったと主張していたが、当時はあまりにも出来が悪く、Workersプラットフォームのツールとも十分に統合されていなかった。
これは、開発者が求める意味でのフルスタックではなかった Pages のメッセージとも妙に混ざっていた。
開発環境でこれを動かすのも非常に難しく、当時の
wrangler devはかなり制限されていた。ちなみに今のwranglerはとても良くなっている。この領域ではVercelがCloudflareの昼食を奪ったようなものだった。恥ずべきことではなく、単に開発者向けにきちんと合わせられていなかっただけだ。
そこへごく静かに アダプター が登場し、実質的に流れを変えた。コードベースがついにWorkersへ移植可能だと感じられるようになり、ほぼ完全なCFプラットフォーム対応も続いてやって来た。
今や私たちはAI時代に生きていて、CloudflareはAstroを買収し、WordPressのコピーを出そうとし、Next.jsをvibe codingで作ったかのようだ。
こうした流れはどれも大きく、長く待ち望まれていたものだ。Workersにさらに多くの改善が入る可能性が見えるのは本当に新鮮だ。
しかもEvanは、人々に愛されるツールを継続的に届けてきた 伝説的な人物 なので、なおさら良い。