2024年10月19日、東京・大手町プレイス ホール＆カンファレンスで開催された「Vue Fes Japan 2024」は、日本のVue.jsコミュニティにおける最大級のイベントとして大きな成功を収めた。昨年の約600人を上回る750人規模へと拡大し、Vueの変わらぬ勢いを感じさせるものとなった。

この年のカンファレンスは、Vue.jsの創始者であるEvan You氏をはじめ、Vueエコシステムの主要な開発者やコミュニティメンバーが一堂に会し、最新の技術動向や将来のビジョンについて議論した。単なるVueの新機能紹介にとどまらず、Vueの創造主であるEvan You氏によるキーノートを筆頭に、JavaScriptエコシステム全体の未来を再定義しようとする壮大なビジョンが提示された。その中心にあったのは、tooling、toolchainの再構築である。

Keynote (Evan You氏)

基調講演はVueおよびViteの作者であるEvan You氏が務めた。Vueの10年間の歩みを振り返ることから始まり、JavaScript開発の根幹を成すツールチェインの未来像へと展開した。

Vue.js⁠：10年の軌跡と現在地

2014年2月に正式アナウンスされたVue.jsは、この10年で大きな進化を遂げた。Evan氏はその変遷を次のように振り返った。

• Vue 1.0：DOMベースのテンプレート構文を特徴としていた。
• Vue 2.0：仮想DOM（VDOM）を導入し、サーバーサイドレンダリング（SSR）に対応。SEO要件など、より高度な要求に応えられるようになった（2.0は2023年12月にEOLを迎えた⁠）⁠。
• Vue 3.0：もっとも大きな変更としてComposition APIを導入。ES2015やTypeScriptへの本格的な対応により、当初の小規模プロジェクト向けという位置づけから、大規模で野心的なアプリケーション開発にも耐えうるフレームワークへと進化した。

Vueは成熟期に入ったかに見えるが、その成長は続いており、各種データがその健全性を示している。

• コミュニティ活動：9,000以上のコミット、500以上のリリース、200万人以上のユーザー、25万以上のGitHubスター。
• 利用状況：npmでの週間ダウンロード数は約530万回、jsDelivr経由のCDNリクエストは月間10億回に達している。
• 成長率：過去1年間で37%の成長を記録しており、市場の飽和を考慮すると驚異的な数値である。
• Vue 3への移行：npmダウンロード数全体の66%をVue 3が占め、新規プロジェクトにおいては98.4%がVue 3を選択している。

Vueの進化は続く⁠：Vue 3.4から3.6へ

Evan氏は、今後のVueの進化についても具体的なロードマップを示した。

Vue 3.4

パフォーマンス改善を目的としたパーサーのリライト、Reactivityシステムのリファクタリング、そしてdefineModelの導入による開発者体験の向上が行われた。

Vue 3.5 (コードネーム: "Tengen Toppa Gurren Lagann")

大幅な改善が実施されている。

• Reactivityの刷新: メモリ使用量を削減し、大規模なリアクティブ配列への対応を強化した。

• SSRの向上: 必要なコンポーネントのハイドレーションを遅延させるLazy Hydrationや、サーバーとクライアント間のID不整合を防ぐuseIdを導入した。

• 開発者体験の向上: useTemplateRefにより型サポートを強化し、defineCustomElementの改善により、Vueコンポーネントから作成したカスタム要素を他のフレームワークでより容易に利用できるようになった。

Vapor Mode

長期的に取り組まれてきたVDOMを使用しない新しいレンダリングモード。パフォーマンスが非常に重要な場面での利用を想定しており、Vue 3.6でVueコアの実験的機能として導入する予定。

Viteの課題と⁠、次世代ツールチェインへの道

Viteは「State of JavaScript 2024」の調査で「もっとも採用されている」「⁠もっとも維持率が高い」「⁠もっとも愛されている」ツールとしてNo.1の評価を受けるなど、大きな成功を収めている。しかしEvan氏は、Viteが抱える根深い課題を指摘した。

依存関係の複雑さ

開発時にはesbuild、本番ビルド時にはRollupを使用するなど、複数のツールに依存している。これにより、パーサーの非互換性や、開発と本番での挙動の差異といった問題が生じている。

パイプラインの非効率性

複数のツールを組み合わせることで、ソースコードのパース、変換、コード生成といった処理が重複して行われ、無駄が生じている。

VoidZeroのチャレンジ

この課題を解決するため、Evan氏は新会社「VoidZero」を設立し、JavaScriptのための次世代統一ツールチェインを構築するプロジェクトを開始したことを発表した。

VoidZeroはVite、Vitest、Rolldown、Oxcの開発者とコアコントリビューターからなるチームで構成されている。これらのプロジェクトを統一されたビジョンのもとに統合し、次世代のJavaScript統一ツールチェーンを構築することを目指している。なおVoidZeroは、Accel主導で460万ドルのシード資金を調達した。

その中核をなすのが、Rustで書かれたツール群である。composableなパッケージとRust crateを提供する「Oxc⁠」⁠、そしてOxcに依存するバンドラー「Rolldown」だ。

• Oxc（The Oxidation Compiler⁠）⁠：パフォーマンスを最優先に設計した、パーサー、リンター、トランスフォーマーなどを提供するツールキット。
• Rolldown：Oxcを基盤とする次世代バンドラー。RollupのAPIとの互換性を持ち、Viteの新たなエンジンとなることを目指している。

RolldownはViteを支え、ソースコードをブラウザだけでなくCloudflare Workersなどでも動作させることができる。

Rolldownのパフォーマンスは圧倒的だ。巨大なベンチマークプロジェクト（19,000モジュール）のビルドを0.63秒で完了し、esbuildさえも上回る速度を記録した。Vue自身のビルドプロセスに適用した例では、その効果はさらに劇的であった。

この数値は、ツールチェインの刷新が開発者の生産性にどれほど大きなインパクトを与えるかを明確に示している。

今回のEvan氏の基調講演では、Vueの未来、そしてVueにとどまらないtoolingによるJavaScript世界全体の未来への貢献が語られた。

Oxc - The JavaScript Oxidation Compiler (Boshen Chen氏)

キーノートで紹介された「Oxc」のクリエーター、Boshen Chen氏が登壇し、その設計思想と技術的な詳細を解説した（発表スライド⁠）⁠。

パフォーマンス哲学⁠：「すべてのパフォーマンス問題はバグである」

Boshen氏は、従来のツール開発では機能実装が優先され、パフォーマンスは後回しにされがちだったと指摘した。Oxcでは、開発初期からパフォーマンスを最優先事項とし、「⁠パフォーマンスの問題はバグである」という哲学に基づき設計を進めた。

その設計思想の根幹には、Data-Oriented Design（DOD）がある。「⁠CPUは速く、メモリは遅い。CPUでより多くを処理し、メモリでの処理をより少なくする」という原則に基づき、徹底的な最適化が行われている。

Oxcの高速化技術

OxcがSWCの3倍から5倍高速であると語られる背景には、数々の緻密なエンジニアリングが存在する。

メモリ効率の追求

Parser

JavaScriptのAST（抽象構文木）でもっとも多く確保されるTokenオブジェクトのメモリレイアウトを最適化。また、ソースコードの位置情報を示す数値をu64からu32に変更することでメモリ使用量を削減している。

String Handling

ヒープアロケーションはパフォーマンス低下の大きな要因となるため、小さな文字列をスタック上に直接確保できるcompact_strライブラリを多用し、メモリアロケーションを回避している。

Memory Arena

ASTの各ノードを個別にヒープに確保するのではなく、bumpaloというライブラリを用いて連続したメモリ領域に確保することで、CPUキャッシュの効率を劇的に向上している。

並列処理とアルゴリズム

SIMD

一つの命令で複数のデータを同時に処理するSIMDを活用し、マルチラインコメントの探索などを高速化する。

Oxlint

設定不要でESLint互換のリンター。Rustの並列処理機能を活用し、複数のCPUコアで同時にファイルを解析することで、ESLint比で50倍から100倍の高速化を実現する。

Transformer

BabelやSWCが複数のパスでASTを変換するのに対し、Oxcはシングルパスで処理を行うアーキテクチャを採用し、オーバーヘッドを削減している。

信頼性へのコミット

Oxcは速さだけでなく、正確性と信頼性も重視している。ECMAScriptの公式テストスイートであるtest262に合格しているほか、BabelやTypeScriptの膨大なテストケースもパス。さらにFuzzingテストや、トップ3000のnpmパッケージに対するEnd-to-Endテストを実施することで、エコシステムにおける互換性を担保している。

UnJS: The Missing Tools for the Modern Web (Pooya Parsa氏)

Nuxtチームのメンバーであり、UnJSとNitroのクリエーターであるPooya Parsa (pi0)氏が、現代のサーバーサイド開発における課題と、その解決策について語った（発表スライド⁠）⁠。

Nitro誕生の経緯⁠：多様化する実行環境への挑戦

Nitroは、元々Nuxt 3のために開発されたサーバーエンジンだが、その背景にはサーバーレスやエッジコンピューティングといった実行環境の多様化があった。

Serverless Era

Vercelのようなサーバーレス環境では、デプロイされるLambdaのサイズが重要になる。そこで、Nuxtのコアランタイムを最小限の依存関係で動作させるnuxt-vercel-builderを開発した。この取り組みはVercelとの協業に発展し、特定のフレームワークに依存しないオープンな標準へと繋がった。

Edge and Workers Era

Cloudflare Workersのような環境は、Node.jsのAPIに完全には対応していない。この課題を解決するため、様々な環境の差異を吸収するPolyfillライブラリunjs/unenvが開発された。

APIの互換性

従来のNode.jsサーバー（Expressなど）と、Web標準のFetch APIとではAPIの様式が異なる。このギャップを埋め、両方の環境でシームレスに動作する軽量なサーバーフレームワークとしてunjs/h3が生まれた。

UnJS⁠：課題解決から生まれたユーティリティ群

これらの課題解決の過程で生まれた汎用的なライブラリ群が「UnJS」というエコシステムを形成している。

• unjs/consola：開発者体験の良いコンソール出力
• unjs/ufo：高速なURLパーシングライブラリ
• unjs/jiti：TypeScriptとESMをオンザフライで解決するランタイム

これらのユーティリティは、累計5億回以上ダウンロードされており、Nuxtのエコシステムを越えて広く利用されている。

Nitroの現在と未来

現在、NitroはNuxtから独立し、AngularのメタフレームワークであるAnalog.jsや、SolidStart、TanStack Startといった他のフレームワークにも採用されている。

ゼロコンフィグでのデプロイ対応、柔軟なキャッシュルール、シンプルなサーバーサイドストレージ機能などを提供し、モダンなWebアプリケーションのバックエンドを支える強力な基盤となっている。

pi0氏はまた、新拡張機能「CrossWS」も発表した。Unified WebSocket Serversとして、ライブエディタやチャットのための機能を提供し、幅広い実行環境に対応する。デモでは、サーバーなしでの同時編集（YJSベース）を披露した。

Next Generation Frontend Cross Talk

イベントのハイライトの一つが、Tooling分野で活躍する開発者が集ったクロストークセッションであった（敬称略⁠）⁠。

• Evan You (creator of Vue), VoidZero
• Boshen Chen (Oxc and Rolldown)
• Yosuke Ohta (ota-meshi) (eslint-plugin-vue (-svelte)), ESLint
• Sosuke Suzuki (Prettier, WebKit committer)
• unvalley (Biome core member)
• Kia King Ishii (Vue core)

なぜ統一ツールチェインが必要なのか

JavaScriptは当初、ブラウザのための小規模なスクリプト言語として誕生した。しかし時代とともに、開発者たちはそれぞれ異なるツールを作り、異なるソリューションを採用してきた。この多様性は創造性を生んだ一方で、大きな課題も残した。

パーサーの非互換性、AST（抽象構文木）の不統一、ツール間の設定の違い—⁠—これらは開発者に大きなフラストレーションをもたらしてきた。特に、フレームワークレベルでの分断が深刻だ。各フレームワークは独自の設定スタイルを持ち、互換性がない。多くの開発者はフレームワークから開発に入るため、本来隠れているべきツーリングの詳細にまで悩まされることになった。

また、こういった背景からビルド工程そのもの、そのための設定が複雑化を重ねていった。パネリストのohtameshi氏は「webpack config職人」という言葉で、この問題を端的に表現した。

Viteが切り開いた道

過去4年間、Svelte、Solidといった新しいフレームワークが登場し、Next.js、Nuxt、Remixのようなメタフレームワークも生まれた。これらのメタフレームワークは「車輪の再発明を避ける」ことを意識し、既存のツールをうまく活用しようとしている。

そして興味深いことに、AngularのAnalog.jsやRemix、Redwood、Qwikなど、多くのフレームワークがViteを選択している。Viteは、メタフレームワークの共有レイヤーとなりつつある。Vueが広く使われ、Viteはさらに広く使われた。これによって、大統一JavaScriptツーリングへの道が開けた。

Sosuke氏は、Unified Toolchainのメリットをこう語る。「⁠Next.jsの前は、webpackやbabelの設定を直接書いていた。いい思い出はない。Next.jsがその層を隠蔽してくれたことは、アプリケーション開発の上で非常に重要だった。エンドユーザーに価値を届けたいのであって、設定を書きたいわけではない⁠」⁠。

なぜRustなのか

近年、JavaScript toolingのRust化が急速に進んでいる。OxcやBiome、SWCなど、多くのツールがRustで書き直されている。よく言われるのは「Rustが速い」という点だが、背景にはより深い理由がある。

Oxcの開発者であるboshen氏は、率直にこう語った。「⁠ツーリングやインフラストラクチャにおいて、JavaScriptは間違いだった⁠」⁠。15年前、JavaScriptはブラウザのためだけの小規模な言語だった。Node.jsの登場でサーバーサイドも書くようになったが、本来小規模だったものが膨大なコードベースへと成長した。CIの完了に20分かかるような状況になってしまったのだ。

さらにAIの登場が状況を変えた。AIは大量のコードを一瞬で生成できる。だが、AIの生成したコードはJavaScriptを速くするのか？ 答えは否だ。1万人の開発者がいれば、1分の削減でも大きなコスト削減になる。パフォーマンスの重要性は増すばかりだ。

一方、Evan氏は慎重な立場を示した。「⁠JavaScriptで書いたこと自体が間違いとは思わない。タイミングの問題だ。当時、他の言語でJavaScriptツールチェインを書こうと思わなかった。JavaScriptの人はJavaScriptで書くしかなかった⁠」⁠。JavaScriptで書くことで、柔軟に高速に試行錯誤でき、多くの人が協力して開発できた。Prettierは長い議論を重ねてきた。BiomeやOxcは、そうした過去の議論の上に構築できた。新しいツールは、JavaScriptの柔軟性やそれがもたらした膨大な知識の蓄積の上に成り立っている。

Rustエンジニアのunvalley氏は、言語自体の魅力を強調する。「⁠Rustは単純に良い言語と言われている。過去の言語の悪い点を直し、良いところを取り入れ、エッセンスも加えて、そして速い。この言語が選ばれるのは自然ではないか⁠」⁠。

プラガビリティとパフォーマンスのトレードオフ

しかし、Rust化には課題もある。ESLintに造詣の深いothameshi氏は重要な懸念を示した。「⁠ESLintが好きな僕としては、Rustで書かれているlinterでは、ESLintのプラガブルなところは今のところ実現できないのではないか懸念がある。JavaScriptエコシステムのlinterは昔はプラグインがなかった。ESLintはそこが嫌でプラグインシステムを作った⁠」⁠。

これは難しいトレードオフだ。Evan氏は、rolldownにおける戦略を説明した。rolldownは、RollupのJavaScriptプラグインの多くをカバーする。だがトレードオフがある。遅くなる。JavaScriptの速度の問題もあるし、RustとJavaScriptのやりとりにはオーバーヘッドがある。解決のアイデアはいくつかある。まず、100%の互換性を維持する。rolldownでそのまま動くようにする。これだけでも、JavaScript版より速くなるだろう。次に、プラグインの動作範囲を指定し、パフォーマンスを向上させる。有名なものは自分たちで書いてコアに入れる。strict subsetを設計し、オーバーヘッドを最小化する。さらに先進的なアイデアとして、zero-cost AST変換によるASTの共通化がある。RustでASTを読み、それを使うことでJavaScriptフレームワークも共通のAPIでアクセスできるようにする。

Rust化は貢献のハードルを上げるのか

言語が変われば、貢献のしやすさも変わるのではないか。この懸念に対して、sosuke氏は楽観的だった。「⁠SWCに貢献したこともある。WebKitはC++。個人的には言語が違っても大丈夫。コミットしてくれるようなOSSエンジニアなら、Rustぐらい学ぶでしょ。コミット数減少などの大きな影響はない気がするけど⁠」⁠。

むしろ、新しい可能性も見えてくる。unvalley氏は指摘した。「⁠Rustで書かれたツールがあることで、JavaScriptに貢献したいというRustの人が増えてきている。Rustをやりたいからフロントエンドツールに貢献という人もいるだろう⁠」⁠。

未来への展望

boshen氏は、Rust化の流れは続くと予測する。「⁠JavaScript（ECMAScript）のProposalを見ても、プロセス間のshared objectなど、Rustっぽいものが増えている⁠」⁠。

Evan氏は、JavaScriptの本質を守りながら進化することの重要性を語った。「⁠JavaScriptはこれまでどおり学びやすい言語であってほしい。そしてさらに高い天井を目指せる言語であってほしい。統一ツールチェインが、それを可能にするものであってほしい⁠」⁠。

統一ツールチェイン構想は、単なる技術的な最適化ではない。開発者がツールの設定に悩まされることなく、本来の目的—⁠—ユーザーに価値を届けること—⁠—に集中できる環境を作ることだ。ViteやOxc、そしてVoidZeroは、その未来への重要な一歩となるだろう。

Vue Vapor: Reinvention (Kevin Deng (a.k.a sxzz)氏)

Vue.jsの新しいレンダリングエンジン「Vue Vapor」について、コントリビューターのsxzz氏から発表があった（発表スライド⁠）⁠。会場には使ったことのある人やコントリビューターも多く見られた。

Vaporは「より速く、より軽く」という願いを込めて開発されている。Solid.jsから発想を得た新しいアプローチで、Virtual DOMを使わずネイティブDOMを直接操作する。これにより、オーバーヘッド削減やメモリ使用量の削減を実現し、バンドルサイズは53.3%削減された。きめ細かいリアクティビティも可能となる。

パフォーマンスは、バニラJSを100とした場合、Solid.jsが93.4、Svelteが90、VaporもSvelte同等の90となっている。Virtual DOMを使うVueやReactよりも高速だ。

Breaking Changesはなく、Vueのサブセットを目指している。現状はComposition APIのみ対応で、<script setup>のみをサポート。ビルドが必要でブラウザ単体では実行できない制限がある。

互換性は高く、ほとんどのVueUseが利用可能で、Vue RouterやPiniaとも互換性がある。APIを共有しているため、Vue 2から3への移行ほど大変ではないはずだ。

技術的には、ui = fn(state)というアプローチで、レンダリング関数は一度だけ実行され、必要な箇所だけを自動更新する。アーキテクチャは中間表現（IR）を採用し、Vue、Svelte、JSXなど異なる構文を同じ出力に変換できる。

また、すべてをVaporにする必要はなく、Virtual DOMとの互換性があるため、スムーズな移行や共存が可能だ。この機能は「Fusion」と呼ばれている。

Anthony's Road to Open Source（Yak Shaving (Anthony Fu)氏）

最近日本語を本気で勉強し始めたというAnthony Fu氏は、OSSにおける「Yak Shaving」（⁠ヤクの毛を剃る＝本来の目的からそれた作業）について語った（発表スライド⁠）⁠。

Yak Shavingは通常否定的な意味で使われるが、Fu氏はこれをポジティブなプロセスに変えていくことを提案した。「⁠自分のニーズに直面し、モチベーションを得て、検証し、イテレーションを重ねてコミュニティを助ける。このアプローチははるかに実用的だろう⁠」⁠。

ShopifyがECプラットフォームになったように、Epic GamesがUnreal Engineをライセンス化したように、AWSやSlackが生まれたように、OSS開発における副産物が大きな価値を生むことがある。

Fu氏自身の経験として、国際化アプリの開発からi18n Allyが生まれ、Vue 3のComposition API実験からVueUseやVue Reactivityが誕生し、それがSlidev、UnoCSS、Vitest、Nuxt、unplugin、vite-node、birpcといった一連のプロジェクトにつながった経緯を紹介した。

「私の経験がみなさんのインスピレーションになればいい」とFu氏は締めくくった。

カンファレンスの雰囲気

カンファレンスでは技術セッションだけでなく、エンターテイメント要素も充実していた。サイリウム配布、Creative Wall、ストア、アフターパーティーなど、まさに「お祭り」のような明るい雰囲気だった。

キーノート、23の通常セッション、8つのライトニングトーク、3つの特別イベントに加え、ハンズオンコーナーも設けられた。Anthony Fu氏も参加したハンズオンでは、Nuxtが公式に作成中のチュートリアル（learn.nuxt.com）の日本語版が本家より先に公開され、約40名が参加した。

パーティーには約500人が参加したという。スポンサー企業や個人スポンサーも多数参加し、コミュニティの熱量の高さを示していた。

おわりに

Vue Fes Japan 2024は、Vueコミュニティの結束と熱量を示すと同時に、JavaScriptエコシステム全体が大きな転換点を迎えていることを明確に示したイベントだった。