Vite+ とか Void とか、Deno 社と VoidZero 社の Cloudflare 買収とかって、何が起きてるの?をまとめる。
自分は2002年からこのサイトを作り始め、当初は「HTML 小技集」みたいな流れでわずかに JavaScript に触ってきた。2013年に SIer に新卒入社して Java からプログラミングをようやくまともに学び、段々と「フロントエンド開発」と呼ばれる世界があることを知る。
このサイトに残っている最古のブログ記事が、2016-01-11 のモノ。その頃から独学で勉強を始めたが、なにやら JavaScript の文法でコードを書いてサーバが作れる「Node.js」ってのがあるらしい。npm っていうので必要なツールをサクッと落とせるらしい?作者のウェブサイトに行って Zip ファイルをダウンロードしたりしなくていいの?インターネットに繋がっていない会社では Java プロジェクトでも Ant や Maven を使ったことがなかったから衝撃的だった。フロントエンドの JS は HTML (というか JSP) の中にベタ書き、少しでも楽に書けるようにと jQuery モドキを自作してなんとかかんとかやっていた。そんな一方で、なんか超モダンな開発環境が世の中には存在するらしいぞ!?と知り、独学を続けて2017年には転職して一気にステップアップできた感じ。
あれから約10年。2025年から休職している間に AI がバカほど発達していて、開発者体験の変化はワケワカメ。npm パッケージとして提供されるツールでも内部は Rust 言語で書かれている、というような謎の状態が「別に普通のこと」になりつつある。おまけに2026年10月9日、「次世代の Node.js」とされていた Deno の開発組織を Cloudflare 社が買収してしまい、Deno の開発は終了するそうだ。そういえば数ヶ月前の6月4日には、Vite を作ってた VoidZero 社も同じく Cloudflare 社が買収していた。何が起きてるんだ…?!
個人開発ではココ1年ほど、React + Hono + Cloudflare Workers といった構成でちょくちょくウェブアプリを作っていたものの、何か大幅に知識のキャッチアップが必要なんじゃないかと思って、改めて勉強することにした。
目次
- 一昔前の JavaScript の話をしましょう
- 2020年に近付いてきた・よりモダンな開発環境とは
- コマンドで比較する VoidZero 社製品の開発体験
- 使い分けをもう一度おさらい
- 各ツールをビジネス的に見ると
一昔前の JavaScript の話をしましょう
勢いでググり直した情報なので、年月が不正確かも。誤りがあったら教えて欲しい。
サーバサイド JS が誕生するまで
- JavaScript 自体は1995年に登場。基本的な言語仕様はあったものの、各ブラウザベンダが好き勝手に API (メソッド) を追加し、そしてそれをどのように実行するかという挙動に関しても手探り・雑なところが多かった。所詮はウェブページをちょっと動かすための「オマケ機能」な扱いで、「DyanmicHTML」なんて HTML の一部みたいな言われ方すらしていた
- 2004年の Gmail、2005年の Google Maps を通じて、Ajax (非同期通信) による「今までにないリッチで動的な挙動」が脚光を浴びる。このあたりから、「一度読み込んだら終わりな静的なウェブページ」という概念が更新され、「ウェブアプリケーション」という、「ブラウザ上で動く GUI アプリケーション」のような用途が発展してきた
- 2008年、Google が V8 という「JavaScript エンジン」を開発。それまでのブラウザは JavaScript のコードを1行ずつ読み込んで実行する、完全な「インタプリタ」だったゆえに動作が遅かった。それに対して V8 エンジンは JIT コンパイル (実行時コンパイラ) の仕組みを導入。これにより JavaScript の処理がマシン語にコンパイルされるため圧倒的な動作速度を叩き出した
- 2009年、ライアン・ダールという開発者が、当時のウェブサーバで問題になっていた「C10K 問題」への対策として、V8 エンジンを基盤に利用して JavaScript でサーバを作ろうと考え、Node.js が生まれる。
- 翌年2010年には npm の仕組みも整備。誰かが作ったライブラリを自分のコードに「インポート (
require())」して開発するスタイルが普及した (CommonJS によるモジュール管理) - 2013年頃には「LAMP 構成はもう古い、時代は MEAN スタック」なんて言われたりもしてましたね
- 翌年2010年には npm の仕組みも整備。誰かが作ったライブラリを自分のコードに「インポート (
この辺までが「サーバサイド JS」の誕生。この2010年頃まではまだ、jQuery を公式サイトからダウンロードし、自分のサイト上に .js ファイルを配置して読み込むような開発手法も、別におかしなモノじゃなかった。
AltJS の乱立時代
- 2010年に CoffeeScript というモノが出てくる。最終的には JavaScript に変換できるのだが、違う書き味で書ける「AltJS」の走りだ
- 2011年には Google から「Dart」が出てくる。JavaScript にも変換できるし、iOS・Android 向けのネイティブコードにも変換できる、クロスプラットフォーム対応を目指した言語だった
- 2012年には Microsoft から「型付きの AltJS」として TypeScript が登場する。この頃まではまだ「AltJS、みんなはどれ使うー?」なんて話してるレベル感だった
JavaScript の国際規格である ECMAScript の策定が遅れていたので、各自が「俺の思う最強の JS 発展言語」を作り始めていた。将来的に採用予定の構文を先行して使えるようにしていたりして、あとでうまいこと「当時のブラウザでも理解できる、遅れてる JS コード」に変換するようなことをしていた。
タスクランナー・トランスパイラ・バンドラーの発展
- 2009年、RequireJS という考え方が出てくる。Node.js が出たか出てないかぐらいの時に、「ブラウザ上で、複数のファイルをモジュール的にインポートしたいっすね」と考えた人がいた
- AMD、非同期でモジュールを読み込むという仕組みもあった
- 2011年に登場した Browserify は、Node.js の
require()によるモジュール読み込みを辿っていき、単一の JS ファイルに束ねる「バンドラー」というツールの、ほとんど元祖といっていい- 開発者は Node.js が動く環境で、ファイルを分割して見通しの良いコードが書ける。でもブラウザがそれをそのまま、複数の JS ファイルをデタラメな順番にロードしては動作に問題が出る。そこで Browserify は
require()の関係を辿り、適切な流れでコードが並び、1ファイルにまとめることで、ブラウザがロードする JS をdist/script.jsの1ファイルだけに束ねることに成功した
- 開発者は Node.js が動く環境で、ファイルを分割して見通しの良いコードが書ける。でもブラウザがそれをそのまま、複数の JS ファイルをデタラメな順番にロードしては動作に問題が出る。そこで Browserify は
段々と「Node.js や npm パッケージを使って、ブラウザ向けの JS コードを効率よく開発しますか」という風潮が出来てきた感じ。
- 2011年に Grunt が登場。2013年には Gulp が登場
- これらは「タスクランナー」であり、定義したタスクを決められた順番にこなすためのツールであった。Browserify を始めとした多数のプラグインを組み合わせることで、「AltJS からのトランスパイル」→「1ファイルにまとめるバンドル」→「Minify (コードの短縮化・難読化)」→「
dist/ファイルに書き出し」みたいなタスクを管理しやすくなった- まぁこの頃はまだ npm のグローバルインストールとローカルインストールも区別が適当で、パッケージごとのバージョン管理も適当、Python 界隈の
requirements.txtみたいな乱暴さがあったけど… - 「こんなことせんでも Makefile で良いんじゃねえの?」という古くからのエンジニアもいたが、当時のブラウザシェアは IE が首位。IE は Windows 向けのブラウザであり、Windows で開発して IE でプレビューする、という時に UNIX 系由来の仕組みである Makefile は合わなかったと思われる。WSL なんてまだないし、VirtualBox は2007年登場だがそれを扱いやすくする Vagrant 1.0 も2012年リリース。MacOS 向けの Homebrew も2009年登場で、まだまだなんというか「UNIX マシン」という見方がキツかった。PC スペック的にも、この時代に「仮想環境に Linux 立てて開発しようよ」と考える人は少なかった
- Grunt・Gulp ともに、JavaScript だけでなく HTML と CSS の処理、開発サーバの Watch 起動みたいなことも兼ねていたのだが、とにかく自分でやりたいことに合わせたプラグインを大量に探して書かなきゃいけなくて大変だった
- まぁこの頃はまだ npm のグローバルインストールとローカルインストールも区別が適当で、パッケージごとのバージョン管理も適当、Python 界隈の
そうこうしている内に、徐々に ES2015 と呼ばれる JavaScript の新しい構文の仕様策定が進んでいく。「じゃあ新しい構文で JS 書いて、開発効率上げていきたくね?」となってきた。
- 2014年、Babel というトランスパイラが登場。最新の JS の構文で書かれたコードを解析して、古い環境でも動くようにコード変換をしてくれた
- JS の界隈では「CoffeeScript のように全く異なる言語構文から JavaScript の構文に直すこと」も、「新しい構文の JS を古い構文に調整すること」も、まとめて「トランスパイル」「コンパイル」とあまり区別なく適当に呼ぶので、以降の説明でも言葉が揃ってませんスミマセン
- 本来的には「高級言語同士の変換」ならトランスパイル、より低レイヤーな機械語などに変換するのを「コンパイル」と呼ぶ方が適切だと思う。だから V8 がやっているのは JIT「コンパイル」だけど、Babel や TypeScript は「トランスパイル」をやっている、というのが区別としてはより正確かと
// 当時 const やアロー関数が理解できるブラウザなんてなかった
const add = (a, b) => a + b;
// Babel に変換させると、こういうレガシーなコードに変換してくれた
var add = function(a, b) { return a + b; };
- Babel 単体では「バンドル」作業ができないので、2012年に開発が始まり、2014年に初回リリースされた Webpack というバンドラーを組み合わせるのが流行った
- 開発者から見ると、Webpack の設定ファイルが最初に見えて、その中に Babel を呼び出す (Babel-Loader) 設定が書いてある、という関係で、Babel と Webpack がそれぞれ何を担っているのか正確にはよく知らないまま、なんやかんや動かしてた気がする
- Babel 自体は、インポート・エクスポートを CommonJS 形式に変換していた。
require()がそのままで理解できるブラウザはないので、Webpack が内部的にrequire()の挙動を再現するようなコードを入れて、1ファイルにまとめていた - Browserlify が「バンドル」時に Babel による「トランスパイル」もまとめてやっちゃおう、という Babelify とか、なんかよく知らんプラグインも大量にありましたな
「モダン・フロントエンド開発」と「速度問題」
そうこうしているうちに、「AltJS」の人気シェアが TypeScript に固まりつつある。Microsoft 製という開発母体の安心感もあるし、「型が書いてある以外はほぼそのまんま JavaScript として読める」という分かりやすさがウケたと思われる。TypeScript 自身も ES2015 のような次世代の構文を先駆けて記述できるよう対応しており、TypeScript のトランスパイラは「TS 内の型情報を削って JS に直すだけ、独自の言語機能を盛り込まない」というところも分かりやすかったのかと。
ついでにいうとこの時期は、同じく Microsoft 製の VSCode の登場も重なる。初版は2008年だが2013年頃に人気が出始めた Sublime Text、2014年の GitHub による Atom エディタなどもあったが、2015年に登場した VSCode は「Electron ベースなのに軽量爆速で動く」という衝撃を与えた。
さらについでに言うと、一般のノート PC で SSD が当たり前になってきたのも2014~2015年頃からかな、という印象。それまではエディタが重たくても HDD や SSHD ならなんとなくみんな我慢できていたが、ハードウェアが高速化し、VSCode の謎技術により「Node.js ベースの製品が爆速なんだが…!?という衝撃を体感、Chrome ブラウザに搭載された V8 エンジンも最適化がどんどん進んで、Chrome ブラウザ上で非同期通信を多用するウェブアプリがキビキビ動く時代になってきた。
そうすると出てくるのは、コレまでの開発ツールに対する実行速度への不満だ。
- Babel 自体は JS 製だったので、トランスパイルが遅いと言われ始めた
- TypeScript 公式のトランスパイラ
tscも TypeScript 自体で実装されており、結局内部的には JavaScript で JavaScript へのトランスパイルを行っていたので、プロジェクトベースの肥大化に合わせてビルドに時間がかかるようになった
この話は後の Vite+ 周りに繋がってくる。
SPA 発展・Node.js 開発環境でのビルド・バンドル作業などは当たり前に
Ajax から始まった非同期通信が馴染んできたことで、フロントエンドには SPA の流れが一気に来た。当初は Angular.js (2009年~) ぐらいしかなかったが、jQuery (2006年~) の「HTML 構造・CSS の見栄え・JS の処理」がごちゃまぜになってしまう問題を改善できるほぼ唯一の回答だった。後に Promise として正式に策定される概念を取り入れた $q といった非同期処理の取り扱いもフロントエンドで実装できて便利だった。
2013年には当時の Facebook が React を発表。仮想 DOM という革新的なアイデアで魂が震える開発者が続出 (1人しかいなかったかもしれんけど)。
2014年には Vue.js が登場。開発した Evan You 氏は Angular.js の開発にも携わっていたそうだ。このあと出てくる VoidZero 社とは、彼が立ち上げた会社だ。
Angular に関しては構文が一新した v2 が2016年、さらに構文が大きく変わった v4 が2017年に登場しており、「SPA 3強」と言われる中では唯一「フルスタックフレームワーク」といえる作りになっている。例えば React 本体は非同期通信するためのメソッドなんかを提供しないが、Angular には HttpClient という Angular の世界に統合された Fetch API みたいなモノが備わっているとか、そういうヤツ。自分が React をよく使うようになった今でもあまり好きでないのが、「React 一人ではウェブアプリを成立させるための機能が足りなすぎて、複数パッケージの導入が必須になってしまう」というところなんよな…。2010年代は本当にこのライブラリの選定や相性問題で苦労した。
2020年に近付いてきた・よりモダンな開発環境とは
Vite 登場・「開発速度短縮戦争」突入
ほんで Vue.js を作っていた Evan You 氏が、2020年になって Vite という開発ツールを発表する。元々は Vue 3 の開発サーバ起動やライブリロードを高速化するツールだったが、後に Vue に限定せず React や Svelte など色んなライブラリに対応するようになった。
Vite の特徴はその圧倒的な動作速度で、2020年発表の esbuild というトランスパイラを内部で使っていた。この esbuild は Go 言語製で、「えっ、Node.js ベースの開発環境なのに、Go 言語なんか出てくるの!?」という驚きがあった。ちなみに本番ビルド時は Rollup というバンドラを使っていて、コチラは JS 製だっためビルド速度はイマイチだったが、設定の柔軟性、本番ビルド後のコードの最適化が esbuild より得意だったために、内部的に併用されていたという。
ちなみにこの頃、TypeScript ベースで CLI ツールを作る時なんかは tsup というビルド・バンドルツールがよく使われており、この内部も Go 言語製の esbuild だった。
2021年には Rust 言語製の SWC が登場。コレは esbuild の競合となるトランスパイラ・バンドラ。「速い代わりに拡張性が少なかった esbuild」と比べて、Babel のような機能の柔軟性を持ちつつも esbuild に迫る速さを両立させている。
「次世代 Node.js」が出てくる
Rust 言語というのは、2018年に登場した Deno でも採用されている。Deno は Node.js の開発者であるライアン・ダールが開発していて、Node.js での反省を活かして作った「次世代の Node.js」とでも言うべき JS 実行基盤だ。TypeScript をそのまま実行したりもできる他、Formatter・Linter・Test ツールなども内包していたので、Deno でコードを書いて、Deno で修正やテストをやって、$ deno serve ./main.ts でサーバを起動する。外部パッケージなしでも済むくらいのオールインワンなツールだった。その代わり、Node.js への互換性は当初ほとんど取られておらず、Node.js・npm にあった膨大なエコシステムが流用できないということで、人気は伸び悩んだ。
2021年には Bun というランタイムも出てくる。コチラは「爆速な動作」「シングルバイナリ配布」「Node.js 完全互換を目指す」というコンセプトの代物だ。元々は Zig という言語で開発されていたが、2026年8月には Rust に移植された。JS のエンジンも V8 ではなく、Safari などで使われている JavaScriptCore というモノを使っており、Node.js 互換を目標にしつつも中身はより高速動作を狙った、攻めた構成になっている。
Deno も Bun も、軽いドッグフーディングはしたことがあるが、Node.js・npm の世界の資産を安定して動かしたいと思っていた自分は、未だに Node.js をメインにしている。
Vitest・Vite+・Void とか何か色々出てきたよ?
Vite が開発サーバとビルドを行うツールなのは分かってた。使ってた。でも「Vitest」というのは、どこの出身なんや?と思ってしばらく使ってなかった。よくよく調べたら、別に Vite にネーミングだけ便乗したような代物ではなくて、Vite と同じ Evan You 氏が作ったテスティングツールだった。Jest より導入が楽で、動作もサクサクしてて使い勝手はとても良い。
そしたらなんか今度は2026年9月に Vite+ (vite-plus) なるモノが正式発表されたとかで少し賑わってた。
そしてそれと同時並行するように開発が進んでいた Void も、2026年10月に発表される。この時ようやく、Evan You 氏が VoidZero 社という会社を立ち上げていて、その中の製品群として Vite・Vitest・Vite+・Void といった名前が出てくるのだ、という関係を知った。そして VoidZero 社は Cloudflare 社に買収された。
コマンドで比較する VoidZero 社製品の開発体験
さて、2020年以降のモダンな開発ツールとして、「Vite」「Vite+」「Void」という3種類が、同じ VoidZero 社からリリースされているワケだが、コレってどう違うんでしょう。実際に見ていこうと思います。
Vite を使う構成例
自分はそれまで Angular + NestJS + Postgres といった構成で Iaas VM にウェブアプリをデプロイしていた。
昨年の2025年ぐらいからは、無料でデプロイできる DB 付きサーバ環境というのが Cloudflare Workers + D1 SQLite くらいしかないなということになり、Clouflare Workers をデプロイ先に選ぶようになった。配信するコンテンツやサーバサイドも軽量に作りたいので、NestJS のような重厚なフレームワークから Hono に切り替えた。
というワケで最近は、フロントエンドは React Router を SPA モードで動かし、バックエンドの API サーバは Hono で作るという構成に落ち着いている。その流れで開発ツールに Vite を使うようになり、デプロイコマンドには Cloudflare が提供する Wrangler CLI を使っている。ざっくりと自分が用意しているコマンドは以下のとおり。
package.json- React Router を使っているため、ビルドコマンドが
react-router buildになっているが、コレは内部的にvite buildを呼んでいる
- React Router を使っているため、ビルドコマンドが
{
"scripts": {
"dev": "vite dev",
"fmt": "prettier",
"lint": "eslint",
"test": "vitest",
"build": "npm run generate-types && tsc && react-router build",
"deploy": "wrangler deploy"
},
"dependencies": {
"hono": "4.13.13",
"react": "19.3.1",
"react-dom": "19.3.1",
"react-router": "8.4.0"
},
"devDependencies": {
"@cloudflare/vite-plugin": "1.64.0",
"@react-router/dev": "8.4.0",
"@types/node": "26.6.5",
"@types/react": "19.3.0",
"@types/react-dom": "19.3.0",
"react-router-hono-server": "4.1.4",
"typescript": "6.0.3",
"vite": "8.3.4",
"wrangler": "4.151.1"
}
}
vite.config.ts- Vite の設定ファイル・ココにプラグインを入れていくことで、「バックエンドは Hono」「フロントエンドは React Router」「実行基盤は Cloudflare Workers」といった構成を示せて、開発サーバの構成だったりビルド資材の最適化だったりが行われる
import { cloudflare } from '@cloudflare/vite-plugin';
import { reactRouter } from '@react-router/dev/vite';
import { reactRouterHonoServer } from 'react-router-hono-server/dev';
import { defineConfig } from 'vite';
export default defineConfig({
plugins: [
cloudflare({
viteEnvironment: { name: 'ssr' }
}),
reactRouterHonoServer({
runtime: 'cloudflare',
serverEntryPoint: './server/index.ts'
}),
reactRouter()
]
});
- フロントエンド開発は、実際はいくつかライブラリを入れている
- ky による Fetch、Zustand によるグローバルストア、CSS 周りとして TailwindCSS と daisyUI
- フロントエンド・サーバサイドともに Zod を使って、開発時は生成型を利用しつつ、実行時も Zod でチェックや変換を行っている
- 依存パッケージの記載は省略したけど、Formatter は Prettier、Linter は ESLint、Test には Vitest をよく使う
- …といいつつ Prettier はその整形が気に食わないので個人開発では省略してるけどw
- テスティングフレームワーク、昔は Jest、その前は Mocha とかも使ってましたな
こんな感じで、必要なツールを個別に選定して入れていってるって感じで、VoidZero 社製ツールは Vite と Vitest くらいかな。テスト書かないくらい小規模なプロジェクトなら Vitest も入れずに Vite だけ。
Vite を使うだけでは、デプロイ先の環境は別に縛られない。この例では Wrangler CLI を使って Cloudflare Workers にデプロイすることが前提になっているが、別に単に Hono バックエンドをビルドして、Docker コンテナに詰めてビルドして Kubernetes にデプロイ、とかしても何にもおかしくはない。
まぁこの辺は2020~2025年を対象にすれば、よく見かけるような構成なんじゃないでしょうか。
なお、Vite 8 からは VoidZero 社の自社製ツールである Oxc・Rolldown・tsdown (いずれも Rust 製) が内部的に利用されるようになり、esbuild + Rollup 時代よりも高速化し、挙動のズレを解消した。
- 2024年頃に Oxc が登場。Rust 製なのは SWC と同じだが、より高速になっている
- Oxc がコードを解析、トランスパイルする。Rolldown がバンドルする。tsdown はこの2つを取り持つ CLI ツール、といった関係
Vite+ を使う構成例
Vite+ は、Vite や Vitest といった VoidZero 社製のツールを組み合わせて、「オールインワンな開発環境・開発ツール群」を一括提供する仕組みになっている。コマンドとしては vp というモノになる。
# Vite+ は専用のインストールコマンドが要る。npx とかではインストールできない
# 自分は後述の `$ void init` コマンドで `$ vp` コマンドが一緒に自動インストールされてしまったのでそれをそのまま使うことにする
$ vp --version
VITE+ - The Unified Toolchain for the Web
vp v1.0.0
# プロジェクト雛形作成
$ vp create
package.jsonに書かれる npm-run-scripts は以下のとおり$ npm run dev=vp run website#dev$ npm run ready=vp check && vp run -r test && vp run -r build
devDependenciesにvite-plusが書かれているのみ、依存パッケージがコレだけ- プロジェクト雛形としては本当に最低限で、実際に React や Hono を使うのかどうか、といったところは自分で組んでいくことになる
npm-run-scripts は簡素だが、グローバルにインストールされる vp コマンド自体が、以下のようなコマンドを提供している。
$ vp dev(Vite : Oxc・Rolldown)$ vp fmt(Oxfmt)$ vp lint(Oxlint)$ vp check(Format・Lint・Type Check をまとめて実行)$ vp test(Vitest)$ vp build(Vite : Oxc・Rolldown・tsdown)$ vp preview(Vite ビルド後・Vite で開発サーバ起動っぽい)
この辺、通常の Vite なら Prettier・ESLint・tsc・Vitest・Wrangler を使ったりしてパッケージが散在していたところ、Vite+ は内包する自社ツールで統一されている。いずれも Rust 製の高速なツール群によって支えられている。
ビルド後のデプロイ用コマンドについては、Vite+ は提供しない。Cloudflare Workers 向けにデプロイするなら wrangler コマンドを用意するとか、Docker ビルドとかするならそのための準備を別途する必要がある。
ちなみに、ボイラープレートコードそのままで試したところ、ビルドに失敗した。まだベータ感あるかも。
$ npm run ready
error: Build failed with 1 error:
[plugin rolldown-plugin-dts:generate]
Error: spawn EBUSY
vp コマンドは色んなコマンドのシンボリックリンクやラッパースクリプトを兼ねていて、bun コマンドを叩いてみたらなんか勝手にインストールされて bun コマンドが使えるようになった。w
# 以下のコマンドで実体がどこに置かれたか分かる
$ vp env which bun
VITE+ - The Unified Toolchain for the Web
~/.local/share/vite-plus/package_manager/bun/1.4.3/bun/bin/bun
Package: bun@1.4.3
Source: registry fallback
Void を使う構成例
Vite に加えて Formatter・Linter・Test ツールなんかが同梱されてるのが Vite+ だ、ということは分かった。じゃあ Void (void コマンド) は何なの?というのを見ていく。
実際に動かすと分かるのだが、void コマンドは Hono サーバ + SPA によるウェブアプリケーションを立ち上げ、Cloudflare Workers にデプロイすることまでを一気通貫で提供するツールとなっている。
# プロジェクト雛形作成
$ npx void init
void コマンドは npx で呼び出せるのだが、進め方次第で vp コマンドも自動インストールしてくれる。
void init時に、Vite+ による全部入りプロジェクトにするか、Vite だけを直接使うかを選択できる- フロントエンドは React・Vue・Svelte・Solid が選べる
- Hono サーバを入れるか、サーバサイドを用意せず SPA 的にデプロイするかが選べる (その場合は SSR 用のコードが勝手に生成される)
void init 後はどうなるかというと、以下のような感じ。
- Vite+ を選択した場合 →
vpコマンドがグローバルインストールされる :~/.local/share/vite-plus/bin/vppackage.jsonを見ると内部はvpコマンド$ npm run dev=vp dev$ npm run build=vp build$ npm run preview=vp preview
dependenciesには Hono・React・Zod が最初から入るdevDependenciesにはtypescript・vite・void・vite-plusの他、あとは React 向けパッケージが入る- Format・Lint・Test の定義はないけど、
vp fmt・vp lint・vp testコマンドを直接叩けば良さそう。なぜ npm-run-scripts に用意されないのかは不明$ vp fmt --initとすると初期設定をvite.config.tsに書き込んでくれる
- Vite 単体を選択した場合
package.jsonを見ると中身はviteコマンド。こっちの方が素の Vite を使ってる感が強くて Vite からの移行はしやすいかも$ npm run postinstall=void prepare$ npm run dev=vite$ npm run build=vite build$ npm run preview=vite preview
dependenciesは Hono・React・Zod 構成で同一devDependenciesはtypescript・vite・voidで、vite-plusがない- やはり Format・Lint・Test はない。この場合
vpコマンドもないので別途なんらかのインストール作業が必要
そして特徴的なのが、void コマンドから Cloudflare Workers にデプロイができる点。大体以下のようなコマンドで行けるはず。
# Cloudflare にログインする
$ npx void cloudflare login
# Workers にデプロイする・内部で使用する D1 とか関連するモノのセットアップとかも自動っぽい
$ npx void deploy
その他、Cloudflare との連携を前提としたコードが書けるようになっている。
- 例えばコード中で
void/dbをimportすることで D1 が使える- ベースは Hono 製のサーバなこともあり、Cloudflare に依存するようなバインディングを使っていなければ Node.js・Bun・Deno 向けのビルドも可能みたい
$ void deployは内部的に$ cf deployコマンドをベースに動いている模様
ところで、cf コマンドも登場するみたいですよ
Cloudflare Workers を前提とした開発、デプロイというと2019年から Wrangler CLI が公式提供されていたが、2026年10月に、Cloudflare から新しい CLI として cf が発表された。
- Wrangler CLI を置き換えつつ、対応範囲を Cloudflare 全体の操作へと拡げた新コマンド。当面は内部的に Wrangler 時代の資産が動く模様
- Cloudflare Workers という実行環境は、開発言語を JavaScript・TypeScript に限定せず、Python や Rust などもデプロイできる。そのためか
cfコマンドはvoidコマンドよりも汎用的な作りになっている - Wrangler CLI が登場した2019年時点ではまだ Vite がなく、Wrangler 内部では esbuild が動いて各言語を処理していた
- JS・TS は esbuild で処理、Rust は手前で WASM 化、Python は生の
.pyファイルのままデプロイされ Pyodide という WASM 版の Python インタプリタで実行、といった切り分けをしているとか
- JS・TS は esbuild で処理、Rust は手前で WASM 化、Python は生の
cfコマンドからは Vite の使用をデフォルトにする。ただ Rust や Python Worker としての動作が必要になった場合は Wrangler が内部的に動く- AI フレンドリで体系的なコマンドを提供するための作り直し、ということみたい
- Cloudflare Workers という実行環境は、開発言語を JavaScript・TypeScript に限定せず、Python や Rust などもデプロイできる。そのためか
$ cf buildは「言語を問わず Coudflare Workers にデプロイできる状態にする」総合ビルドコマンドとなり、そのまま$ cf deployに繋げられる
# cf コマンドは npm でインストールできる
$ npm install -g cf
# プロジェクト雛形作成
$ cf init
package.jsonを見ると内部はcfコマンド$ npm run dev=cf dev$ npm run typecheck=cf workers types && tsc$ npm run build=cf build$ npm run deploy=cf deploy
dependenciesなしdevDependenciesにはcf・typescript・vite・@cloudflare/vite-pluginがデフォルトで入っている
とりあえず動くサーバサイド TypeScript コード辺のみがある状態。Hono とか React とかは入ってないボイラープレート。Format・Lint・Test はナシ。
使い分けをもう一度おさらい
- Node.js はなんですか
- JS コードで書いて、サーバを起動できる「サーバ・実行環境」
- npm によるパッケージ管理のエコシステムが時間とともに充実している。好みのパッケージを組み合わせれば「俺が思う最強の開発環境」を作れるものの、それが面倒なことも増えてきた
- Deno とはなんですか
- Node.js 開発者がその反省を活かして作った、「サーバ・実行環境」+「Format・Lint・Test といった開発ツールを内蔵したオールインワン開発環境」
deno fmt・deno lint・deno check・deno test・deno serveなどのコマンドがあるdeno deployコマンドで、Deno Deploy という公式提供するプラットフォームにウェブアプリをデプロイできた- コマンドラインツールなら
deno compileで単一実行ファイルにできたりもした。CLI ツール作りにも使える - 【悲報】Deno 社は2026年10月に Cloudflare 社に買収され、Deno は2027年10月頃に開発終了の予定。Deno Deploy プラットフォームもサービス終了予定
- Bun とはなんですか
- Node.js との完全互換を目指しつつ、より軽量・高速な動作を目指す「サーバ・実行環境」+「オールインワン開発環境」。ゼロコンフィグで動かせること、シングルバイナリで提供することという方針が強い
- 現時点の最新版 v1.4.3 時点では
bun check・bun testコマンドがあり、Format・Lint 用コマンドも次バージョンから導入される予定 bun build --compileで Deno のようにシングルバイナリも作れる- 【特徴】Bun は2025年末に Anthropic 社に買収されており、Claude Code のランタイム・ツールチェーンとして使われている
ココまでが、JavaScript の実行基盤としての3種類。以降は VoidZero 社が開発したツールの整理。
- Vite : Node.js 上で爆速で動く、ウェブアプリの開発に特化した「開発・ビルドツール」
- Vite 8 から、内部では Oxc・Rolldown・tsdown といった Rust 製ツールが動くようになり、最近より高速化している
- Vitest : Node.js 上で爆速で動く「テストツール」
- Vite と同様に、内部では Oxc・Rolldown といった Rust 製ツールを活用して高速化している
- Vite+ : Vite・Vitest の他、Oxfmt・Oxlint など Rust 製の自社ツールで固めた「オールインワンな開発ツール群」
- 呼び出しは
vpコマンドで統一されているが、内部的には別々にツールが作られている、というところが Bun の設計思想とは少し違うところ - ただし「色んな人が開発したツールをまとめている」のではなく、全て自社開発ツールであり、どれも Rust で実装されていて、「Node.js 環境やこれまで培われてきた膨大な npm のエコシステムを前提に動くのに超高速」が売りになっている
- 呼び出しは
- Void : Vite や Vite+ をベースにして、Cloudflare Workers に Hono アプリをデプロイするまでをオールインワンで提供するために作ったコマンド
- Void だけはあえて Cloudflare と密結合 (ベンダロックイン) した作りになっている
- 【特徴】そうこうしていたら VoidZero 社は Cloudflare 社に買収された
最後に出てきた Void コマンドは、Cloudflare Workers へのデプロイができるというところで、Cloudflare 社が提供するコマンドと被ってない?というところもおさらい。
cf: Cloudflare の全サービスの操作を網羅するための新世代のコマンド- Wrangler CLI よりも扱える対象が広くなる他、AI エージェントにも優しいインターフェイスになるとか
- 内部的な実装には Wrangler 時代の資産がしばらくは残るみたい
cfコマンド自体は「ウェブアプリケーション向けの開発環境!」みたいな Opinionated なボイラープレートを提供しないので、Cloudflare 全体の操作用 CLI として独立した立ち位置という理解で OK
こうしてみると、VoidZero 社のツールは Node.js という実行基盤はブラさずに、徐々にカバーする範囲を拡げていった感じがする。
- 開発・ビルド部分の効率化だけなら → Vite をベースに導入して、あとは好きな npm パッケージを入れていく
- Prettier・ESLint・Jest が遅くて嫌なら → Vite+ で Oxfmt・Oxlint・Vitest を一括導入
- 実は
oxfmt・oxlintもvitestと同様に単体の npm パッケージとして独立してインストール可能 - React を使うのか Hono を使うのか、そもそもウェブアプリじゃなくて CLI ツールを作るのか、といったところの想定は Vite+ にはないため、自分で必要な npm パッケージを入れていく
- 実は
- Cloudflare Workers にズッポリベンダロックインしてウェブアプリケーションを作りたいなら → Void で環境構築からデプロイまでまとめちゃう
- ボイラープレートコードが Hono + React 前提になっていたりして分かりやすい
- ウェブアプリを作る気がない (CLI ツールが作りたいとか) なら Void は向かないかと
- (Cloudflare Workers 使うのやっぱやめたー、となった時のお引っ越しは手間がかかるかも)
Vite は Webpack 以降のプロジェクト雛形としてもうほとんどデファクトスタンダードみたいな立ち位置の開発・ビルドツールになりつつある。Vitest も、Jest 以降のテストツールとして個別に導入がしやすいだろう。
Cloudflare Workers 人気に乗っかって、新規プロジェクトの開発を極限まで効率化したいなら、Void にベンダロックインされるのはアリかもしれない。もちろん可搬性は下がる。
既存プロジェクトの高速化狙いだったら Vite+ への段階的な移行が良さそう。もしくは個別に Prettier を Oxfmt に、ESLint を Oxlint に差し替えるよう入れていくのも良さげ。
各ツールをビジネス的に見ると
途中、買収の話もしてきたが、各ツールのビジネス的な絡みも押さえておくと面白い。
- Node.js
- Linux Foundation 傘下の、OpenJS Foundation という非営利団体が管理している
- Google・MS・Amazon などなど各社が出資しており、基盤としてベンダロックインが発生しにくい
- Cloudflare 社
- Deno 社を買収 : Node.js・Deno の知見を合わせて、Cloudflare Workers の根幹である
workerdランタイムの最適化が強化できる?- Cloudflare Workers は V8 エンジンの Isolate 技術を利用しているため、V8 エンジンを採用してきた Node.js・Deno の開発者のノウハウが有用か
- VoidZero 社を買収 : Vite・Vitest・Vite+・Void などの「爆速な開発ツール」群を手に入れ、「Cloudflare Workers にデプロイさせる動線」を確立できる?
- Deno にも Linter などは内蔵されていたが、Deno そのものは「サーバランタイム」であり、Node.js ほどのデファクトスタンダードにもならなかったため、Node.js ベースで動く VoidZero 社の開発ツールがわざわざ欲しかった?
- Deno 社を買収 : Node.js・Deno の知見を合わせて、Cloudflare Workers の根幹である
- Anthropic 社
- Bun を買収 : Claude Code (AI エージェント) は「Node.js 向けのコード」を読み書きする使われ方が多かった
- そのため、「Node.js とは異なる構造」を採用した Deno を買収するよりも、「Node.js の完全互換を目指して開発される、爆速で軽量な Bun」の方が好都合だったと思われる
- Bun がシングルバイナリで提供されることも、開発者の PC に Claude Code と一緒にインストールさせやすかったと思われる
- Deno が運営していた Deno Deploy のような「クラウドサーバ」的なビジネスは、AI エージェントを売る Anthropic 社にはさほど必要でもなかったためか、Deno より Bun を買ったのかと思われる
爆速で動くツールというのは、単に人間の開発者が開発効率を上げたいという話に限らず、昨今の AI エージェントによる自律開発の面でも高速な反復を実現するために重要な要素になってきていると思われる。
Cloudflare は、Workers にデプロイしてもらうまでの垂直統合を図るため、Deno と VoidZero を買収した。Anthropic は、ユーザのマシンローカルでも動作する Claude Code のランタイムとして、軽量高速かつ Node.js 互換の高い Bun を買収した。
両者はアプローチや目指す方向性が別々だが、根幹には「Node.js・npm が拡げたエコシステムをより高速に取り扱いたい」という点が共通している。
結果的に Deno が目指していたセキュリティサンドボックスや package.json 非依存のモジュール解決、といった独特な機能は、開発者ライアン・ダールの狙いどおりには広まらなかったというのが残念ではある。しかし、Deno (2018年~) が Go 言語 (2009年~) や Rust 言語 (2010年~) から取り入れたと思われる「Formatter・Linter などをランタイムに内蔵してしまう」という方式は、VoidZero 社の製品群が引き継いで Node.js 上で実現しているし、現在の「npm パッケージで配信される高速な開発ツール」の多くが、内部的には (Deno でも採用された) Rust 言語を使用している、というところを見ると、ライアン・ダールにはやっぱり先見の明があったんだろうな、と思う次第。
Bun が Zig から Rust に移植したのも AI コーディングがフル活用されたそうだし、「Go 言語は平易な書き方で GC もあってそこそこ高速~」というのがもてはやされた時代が一気に変わり、「言語仕様的に GC がないからこそ爆速にできる Rust 最強!自分で書けなくても AI に書かせればいいじゃん!」な時代になってしまい、まさかそんな流れが Node.js や Web アプリケーション開発の世界で巻き起こるとは、思ってもいなかったよ…。
自分もそろそろ、オレオレコードフォーマットのコダワリ持つのやめて、Vite+ (Oxfmt・Oxlint) に全任せに流れようかしら…。