Vue 3.6 時代のリアクティビティ最前線〜Vapor/alien-signals の実践とパフォーマンス最適化〜

Vue 3.6時代リアクティビティ最前線〜Vapor/alien-signals 実践とパフォーマンス最適化〜平沼真吾株式会社GENEROSITY CTO 2025年10月25日

自己紹介

じめに - Vue 3.6がもたらす「 2つ進化」 Vue 3.6 単なるアップデートでなく、コアアーキテクチャにおける根本的な進化
を遂げている alien-signals Vapor Mode 本講演で、こ 2つ進化が、Vueをどう改善しているかをお話します

Vapor Mode

純粋にVaporモードを適用したアプリケーションで、 VDOMランタイム全体をバンドルから削除できるため、軽量なアプリケーションが実現されます。直接的なDOM操作コード生成ファイングレインなリアクティビティ（必要な時に必要な操作だけ行う仕組み） Vapor (ヴェイパー ) =
蒸気こ名称、Virtual DOMランタイムオーバーヘッドを「蒸発させる」という核心的なコンセプトを象徴しています。 Vapor Mode 特徴 VDOMを完全に排除 Vapor Modeと？ 1 2 3

Vueパフォーマンス進化軌跡 Vue 1 DOMベーステンプレート実際 DOMノードを直接操作シンプルで直接的な操作効率性
課題が存在 Vue 2 純粋なVirtual DOM サーバーサイドレンダリング(SSR)可能メモリ使用量オーバーヘッド差分検出(diﬃng) 計算コスト Vue 3 Compiler-Informed VDOM 静的ホイスティングで VNode再利用パッチフラグによる不要な比較スキップ根本的なVNode オブジェクト生成コスト Vue 3.6 Vapor Mode / alien-signals VDOMレス直接DOM操作アプローチファイングレインなリアクティビティ軽量化とパフォーマンス向上

◦ ユーザーが A1 値を 10 から 20 に変更して確定する ◦ A1
10 ◦ B1 A1をWach（A1に依存） ◦ 数式結果として 20 と表示されているリアクティビティ（ Reactivity）と？表計算例で考えると ◦ ユーザーが B1 を直接操作していないにも関わらず、B1 値即座に 40 に自動更新される 2. A1 変更 1. 初期状態 3. B1 自動更新（リアクション）データ（状態）が変更された際に、そデータに依存している他要素が自動的、かつ、即座に更新される仕組みや性質リアクティビティ

const oldNode = document.querySelector('p') const newNode = document.createElement('div') newNode.textContent =
'Hello' oldNode.parentNode.replaceChild(newNode, oldNode) Vue1 DOMを直接操作する仕組みを採用 Watchしている DOM 更新を検知したら、リアクティビティにより、即座に直接 DOM操作処理を実行不要な更新が何度も行われる問題あり • DOMを操作するたびに、ブラウザがスタイル再計算やレイアウト再計算（ reflow）、再描画（repaint）を発生させる • 複数要素が同時に変更される場合、それぞれ更新が逐次的に走るため、ブラウザ都度再計算と描画を行い、非常に重い処理になる更新前 DOM 更新後 DOM

Vue2で導入された Virtual DOM（VDOM）仕組み実際 DOM 軽量なコピーをメモリ上に保持 Initial Virtual DOM
Updated Virtual DOM 更新後実際 DOM 差分があれ patch関数内でまとめて更新更新前実際 DOM DOM コピーを作成コンポーネント状態が更新されたら、新しく Virtual DOMが作られる { tag: 'p', text: 'Hello' } { tag: 'div', text: 'Hello' }

Virtual DOM メリットと問題点 VDOMにも問題点あり • メモリオーバーヘッド実際 DOM コピーを常にメモリ上に保持するため、アプリ
規模が大きくなるにつれメモリ使用量が増加する。 • 計算コスト状態が変更されるたびに新しい VDOMツリーを生成し、差分比較処理自体に CPU計算コストがかかる。 • バンドルサイズ増加 VDOM ランタイムコードがアプリケーションバンドルに含まれるため、初期ロード時バンドルサイズが増加するメリット VDOM 変更された差分を全て算出してから、まとめて実際 DOMに適用することで、スタイルやレイアウト再計算（reflow）、再描画（repaint）を削減し、ブラウザ負荷を軽減する効率的なDOM更新例え v-for 途中で要素を追加する場合など、どデータ変更が処理が重たいかを意識する必要がなくなり、開発者が手動で行っていたパフォーマンス最適化一部を自動化してくれる開発で注意する箇所削減

Vue3で改善: Compiler-Informed VDOM Vue 3で、Virtual DOM 持つオーバーヘッドを削減するために「Compiler-Informed
VDOM」というアプローチを採用。コンパイラがランタイムに「ヒント」を与えることで、 VDOM 効率を大幅に向上させる。 Vue 3で採用された VDOM最適化仕組み静的ホイスティング（ Static Hoisting）パッチフラグ（ Patch Flag）

Vue3で改善: Compiler-Informed VDOM <template> <div>  <p
class="static-class">これ静的なテキストです。 </p> <p>これも静的です。</p>  <p>{{ message }}</p> </div> </template> <script> import { ref } from 'vue'; export default { setup() { const message = ref('これ動的なメッセージです。 '); return { message }; } } </script> 静的ホイスティング（ Static Hoisting） import { openBlock, createElementBlock, createElementVNode, 　　　　　　　　　　　　　　　　　　　　　　　　 toDisplayString } from "vue" // ========================================================== // 静的ホイスティング: // 静的なノードがレンダリング関数外で定数として一度だけ生成される。 // ========================================================== const _hoisted_1 = /*#__PURE__*/createElementVNode("p", { class: "static-class" }, 　　　　　　　　　　　　　　　　　　　　　　　　　 "これ静的なテキストです。 ", -1 /* HOISTED */) const _hoisted_2 = /*#__PURE__*/createElementVNode("p", null, 　　　　　　　　　　　　　　　　　　　　　　　　　 "これも静的です。", -1 /* HOISTED */) // レンダリング関数 export function render(_ctx, _cache, $props, $setup, $data, $options) { return (openBlock(), createElementBlock("div", null, [ // 再レンダリング時も、毎回生成するでなく定数を再利用する _hoisted_1, _hoisted_2, // 動的なノード毎回新しく生成される createElementVNode("p", null, toDisplayString(_ctx.message), 1 /* TEXT */) ])) } コンポーネントソースコードコンパイル後コード「どうせ変わらない部分、毎回作り直したりチェックしたりするをやめて、　最初に作ったもを使い回そう」という効率的な仕組み

「ど部分が変更されるか」というパッチフラグを付与し、実行時にこフラグに　基づいて必要な更新みを行い、不要な比較処理を完全にスキップする仕組みパッチフラグ（ Patch Flag） Vue3で改善:
Compiler-Informed VDOM <template>  <p class="static">これ静的なテキストです。</p>  <p>{{ message }}</p>  <div :class="{ active: isActive }">クラスが動的です。</div>  <button :id="dynamicId" :disabled="isDisabled">IDとdisabledが動的</button>  <input :id="dynamicId" :class="{ active: isActive }" :value="message"> </template> <script> import { ref } from 'vue' export default { setup() { const message = ref('こんにち '); const isActive = ref(true); const dynamicId = ref('my-id'); const isDisabled = ref(false); return { message, isActive, dynamicId, isDisabled }; } } </script> import { openBlock, createElementBlock, createElementVNode, 　　　　　　　　　　　　　　　　　　　　　　　　　toDisplayString, normalizeClass } from "vue" // 1. 静的な要素 Static Hoistingされる (Patch Flag: -1) const _hoisted_1 = /*#__PURE__*/createElementVNode("p", { class: "static" }, "これ静的なテキストです。", -1 /* HOISTED */) export function render(_ctx, _cache, $props, $setup, $data, $options) { return (openBlock(), createElementBlock("div", null, [ _hoisted_1, // 2. テキストだけが動的 -> Patch Flag: 1 (TEXT) createElementVNode("p", null, toDisplayString(_ctx.message), 1 /* TEXT */), // 3. classだけが動的 -> Patch Flag: 2 (CLASS) createElementVNode("div", { class: normalizeClass({ active: _ctx.isActive }) }, "クラスが動的です。", 2 /* CLASS */), // 4. class/style以外属性が動的 -> Patch Flag: 8 (PROPS) // 第5引数で、動的な属性名を具体的に指定 ["id", "disabled"] createElementVNode("button", { id: _ctx.dynamicId, disabled: _ctx.isDisabled }, "IDとdisabledが動的", 8 /* PROPS */, ["id", "disabled"]), // 5. 複数動的バインディング -> Patch Flag ビット演算で結合される // 16 (FULL_PROPS) が使われることが多い createElementVNode("input", { id: _ctx.dynamicId, class: normalizeClass({ active: _ctx.isActive }), value: _ctx.message }, null, 16 /* FULL_PROPS */) ])) } コンポーネントソースコードコンパイル後コード

Compiler-Informed VDOM 限界 Compiler-Informed VDOMだけで限界も存在根本的なコストが残存 Compiler-Informed VDOM あくまでVDOM
枠組み内で「緩和策」であり、根本的なコスト依然として残存していた。結論：Compiler-Informed VDOM Vue 3 パフォーマンスを大幅に向上させたが、 VDOM 基本構自体オーバーヘッドを完全に排除するために、根本的なアーキテクチャ革新が必要だった。 • メモリオーバーヘッド実際 DOM コピーを常にメモリ上に保持するため、アプリ規模が大きくなるにつれメモリ使用量が増加する。 • 計算コスト状態が変更されるたびに新しい VDOMツリーを生成し、差分比較処理自体に CPU計算コストがかかる。 • バンドルサイズ増加 VDOM ランタイムコードがアプリケーションバンドルに含まれるため、初期ロード時バンドルサイズが増加する。

VDOM 仕組みから改善するために Vue 3.6で採用された Vapor Mode

Vapor Mode 導入方法 Vapor Modeを利用するため条件 v3.6.0-alpha.2 　2025/07/18 公開（Pre-release） v3.6.0-alpha.1
　2025/07/12 公開（Pre-release） Vue3.6 リリース状況 ※ 2025年10月25日現在で、まだ機能的に実装されていない部分が多い段階 • Vue バージョンが 3.6以上であること • Composition APIと<script setup>構文を使用していること ※ 既存 Options APIコンポーネントをVapor Modeで利用するにリファクタリングが必要

Solid.jsから着想と Vue独自解釈 Solid.jsと共通哲学 VDOMを排除し、直接 DOMを操作する必要なも
だけを、必要な時に更新する Vue独自進化 Vapor Mode オプトイン機能として提供され、段階的に導入可能。既存 VDOMベースアプリとで共存できる。オプトイン設計開発者体験維持 refやcomputedなど既存 SFC構文（Single File Component）をそまま使え、開発者新しい書き方を学ぶ必要がない。コンパイラが直接DOMを操作するコードを生成してくれる「シグナル」を使い、変更があった DOMだけをピンポイントで更新

{ "name": "pj-name", 　… "scripts": { "dev": "vite", "build": "vite
build", "preview": "vite preview" }, "dependencies": { "vue": "^3.5.22" // → "^3.6.0-alpha.2" に変更 }, "devDependencies": { "@vitejs/plugin-vue": "^6.0.1", "vite": "^7.1.7", "vite-plugin-vue-devtools": "^8.0.2" } } Vue3.6利用方法（2025/10/25時点で、v3.6.0-alpha.2が最新）新規プロジェクト場合 npm create vue@latest <pj-name> Package.jsonを書き換え 1 2 3 npm run installでv3.6.0をインストール

// VaporTest.vue <script setup vapor> // vapor 属性を追加 import {
ref } from 'vue' // ... Vapor Modeへ移行方法（現在 2パターン） Vapor Mode 導入方法 2 アプリ全体に適用したい場合 1. createVaporAppを使ってAppを作る 2. Vaporを適用したいコンポーネントに <script setup vapor> を追加 1 VDOMとハイブリッドで部分的に適用したい場合 1. vaporInteropPluginでVaporコンポーネントをAppにインストール 2. Vaporを適用したいコンポーネントに <script setup vapor> を追加 AppをVapor Modeで作成すると、VDOM ランタイムコードを利用しないで、バンドルサイズが軽減できる // main.js import './assets/main.css'; import { createVaporApp } from 'vue'; import App from "./App.vue"; createVaporApp(App).mount("#app"); // main.js import './assets/main.css'; import { createApp, vaporInteropPlugin } from 'vue'; import App from "./App.vue"; createApp(App).use(vaporInteropPlugin).mount("#app"); // VaporTest.vue（左と同じ）

コード分析 (1)：サンプルコンポーネントシンプルな Vueコンポーネントが Vapor ModeとVDOM Modeでどようにコンパイルされるかを比較 // App.vue
<script setup> import { ref } from 'vue' const msg = ref('Hello World!') const id = ref('my-element') </script> <template> <h1 :id="id">{{ msg }}</h1> </template> コンポーネント説明 2つリアクティブな値（msg と id）を持つ、最もシンプルな Vueコンポーネント。h1要素 id属性とテキストコンテンツを動的にバインドしている。使用している機能 ref リアクティブな値作成 :id 動的な属性バインディング {{ msg }} テキスト補間（マスタッシュ構文）コンパイル前 Vueコンポーネント例

コード分析 (2)：コンパイル出力直接比較 import { template, renderEffect, setDynamicProp, setText }
from 'vue/vapor' const t0 = template('<h1></h1>')(); renderEffect(() => { setDynamicProp(t0, 'id', id.value); }); renderEffect(() => { setText(t0, msg.value); }); import { openBlock, createElementBlock, toDisplayString } from 'vue' export function render(_ctx, ...) { return ( _openBlock(), _createElementBlock("h1", { id: _ctx.id }, _toDisplayString(_ctx.msg), 9) ) } VDOM (実際コードでなく概念的な出力 ) Vapor Mode (実際コードでなく概念的な出力 ) idとmsg更新独立した renderEffectで管理。コンポーネント全体再評価されない。状態が変わると render関数全体が再実行され、新しいVNodeが生成される。 // VaporTest.vue <script setup> import { ref } from 'vue' const msg = ref('Hello World!') const id = ref('my-element') </script> <template> <h1 :id="id">{{ msg }}</h1> </template> コンパイル前 Vueコンポーネント

コード分析 (2)：コンパイル出力直接比較 import { child as _child, setProp as
_setProp, toDisplayString as _toDisplayString, setText as _setText, renderEffect as _renderEffect, template as _template } from "/node_modules/.vite/deps/vue.js?v=09619d40"; const t0 = _template("<h1 data-v-inspector=\"src/components/VaporTest.vue:9:3\"> </h1>", true) // こ例で h1タグ自体変わらないため、 DOM構を一度だけ生成 function _sfc_render(_ctx, $props, $emit, $attrs, $slots) { const n0 = t0() // テンプレートから DOMノードを作成 const x0 = _child(n0) // 子ノードへ参照を取得 _renderEffect(() => { // レンダリングエフェクトを登録 _setProp(n0, "id", _ctx.id) // 変更する部分プロパティを直接設定 _setText(x0, _toDisplayString(_ctx.msg)) // 変更する部分テキストを直接設定 }) return n0 } import { createElementBlock as __createElementBlock } from "/node_modules/.vite/deps/vue.js?v=09619d40" function _interopVNode(vnode) { if (vnode && vnode.props && 'data-v-inspector' in vnode.props) { const data = vnode.props['data-v-inspector'] delete vnode.props['data-v-inspector'] Object.defineProperty(vnode.props, '__v_inspector', 　　　　　　　　　　　　　 { value: data, enumerable: false }) } return vnode } // ... function _sfc_render(_ctx, _cache, $props, $setup, $data, $options) { return (_openBlock(), _createElementBlock("h1", { id: $setup.id, "data-v-inspector": "src/components/VaporTest.vapor.vue:9:3" }, _toDisplayString($setup.msg), 9 /* TEXT, PROPS */, _hoisted_1)) } VDOM (3.6.0-alpha.2 実際コード ) Vapor Mode (3.6.0-alpha.2 実際コード ) 3.6.0-alpha.2時点で、実際、 idとmsg 独立した renderEffectでなく、同じrenderEffectで更新する作りになっている。極端なケースを除き、コンポーネント内すべて動的バインディングを一つ _renderEffectにグルーピングする方向で最適化が進められている。

コード分析 (2)：コンパイル出力直接比較 import {child as _child, toDisplayString as _toDisplayString,
setText as _setText, renderEffect as _renderEffect, createIf as _createIf, template as _template} from "/node_modules/.vite/deps/vue.js?v=09619d40"; const t0 = _template("<div data-v-inspector=\"src/components/VaporTest.vue:17:3\">Static Element Above</div>") // v-ifブロックテンプレート : <div><p>...</p></div> 構 const t1 = _template("<div data-v-inspector=\"src/components/VaporTest.vue:19:3\"><p data-v-inspector=\"src/components/VaporTest.vue:20:5\"> </p></div>") function _sfc_render(_ctx, $props, $emit, $attrs, $slots) { const n0 = t0() // 静的要素作成 // こ関数が _ctx.showMessage 変更を追跡する【独立したエフェクト】として機能 const n1 = _createIf( () => (_ctx.showMessage), () => { const n4 = t1() const n3 = _child(n4) const x3 = _child(n3) // _ctx.textContent 変更みを追跡する【独立した _renderEffect】を登録 // showMessageがtrueで構が存在するときみ、こエフェクトがテキスト更新を行う _renderEffect( () => _setText(x3, _toDisplayString(_ctx.textContent))) return n4 } ) return [n0, n1] } <script setup vapor> import { ref } from "vue"; const showMessage = ref(true); const textContent = ref("Initial Message"); setInterval(() => { showMessage.value = !showMessage.value; }, 2000); setInterval(() => { textContent.value = `Updated: ${new Date().toLocaleTimeString()}`; }, 500); </script> <template> <div>Static Element Above</div> <div v-if="showMessage"> <p>{{ textContent }}</p> </div> </template> Vapor Modeコンポーネント (コンパイル前コード ) Vapor Mode (3.6.0-alpha.2 実際コード ) 上記例で、 v-if 動的コンテンツ更新部分が、構管理エフェクトと別に独立した_renderEffectに分離されていることがわかります。

alien-signals

alien-signals (エイリアン・シグナルズ ) = 異質シグナル alien-signalsと？従来 ref
や reactive 代替として設計された、 Vue 3.6 新しいコアリアクティビティシステム Vapor Mode 採用有無にかかわらず、すべて Vue 3.6アプリケーションに恩恵をもたらす設計

alien-signals (エイリアン・シグナルズ ) = 異質シグナル外部から来た異質な（ Alien）概念従来 Vue
リアクティビティ（ Pullモデル、refとreactive）限界を克服するために、 Solid.jsなど他フレームワークで確立された Pushモデル Signals 哲学を、 Vue エコシステムに「持ち込んだ」ことを象徴している alien-signalsと？当初プロジェクト性質と、そ技術が Vue エコシステム内で位置づけを表す、やや非公式で遊び心ある名前として alienと付けられた

alien-signals = Vue3.6 新しいコアリアクティビティシステム項目メリット詳細メモリ使用量効率化によるメモリ削減
大量 ref、computed、effect などリアクティブインスタンスを生成する際メモリ消費を約13%削減。（例: 2.3MB → 2.0MB）パフォーマンス特定シナリオで劇的な高化従来「Pullモデル」課題である、一つ ref 変更後に、大量 computed が読み込まれるシナリオにおいて、最大30倍以上パフォーマンス向上（スケールに比例）を達成。全体的な性能テスト結果も改善。コード抽象化クリーンな設計と保守性向上従来スケジューリングロジックにあった、依存関係クリーンアップやデバッグイベントなど外部実装と密結合を解消。これにより、システムコア抽象度が高まり、コード保守性が向上。主な改善点

なぜいか？徹底した実装レベル最適化アルゴリズムによるも Push-Pullアルゴリズム値が変更されたときに「dirty」通知をプッシュするだけ、実際値が必要になったときに初めて再計算を実行（遅延評価）。軽量データ構
コア部分でSetやMap ような高コストなデータ構や再帰呼び出しを避け、リンクリストようなより軽量で高な構を採用。再帰排除リアクティビティ伝播を効率的に管理し、循環参照を防ぐため最適化。

なぜいか？：「 Push-Pull」アルゴリズム Pushフェーズ値が変更されると、依存先に「値が古くなった」通知をdirtyな値としてPush 再計算行わないため、非常に高通知
軽量で、大量データを扱える Pullフェーズ `dirty`な値が実際に必要になった時点で初めて値を Pull 遅延評価による計算コスト最適化一度計算したらキャッシュされるため、 2回目以降アクセス高 A1 dirty dirty 通知 B1が必要なタイミングで A1を読み込んで計算 2回目以降キャッシュを読み込んで高にアクセス A1 dirty

Vueにおいて、開発者に優しい後方互換性 alien-signals 導入方法利用するため条件 • Vue バージョンが 3.6以上であること
• Composition APIと<script setup>構文推奨 ※ 既存 Options API コード内からsingal()を使うこと技術的にできるが、非推奨何もコードを変更せずに、vue バージョンを3.6以降にアップデートするだけで完了 ref、computed、watch、effectScope など API や、.valueアクセスをそまま使える導入方法

Vapor Mode導入時注意点とベストプラクティス

注意点：Vapor Mode 制限カテゴリ制限される機能説明互換性 Options API 非サポート
Composition API み動作。既存 Options APIコンポーネントを Vapor Modeで利用するにリファクタリングが必要となる。コアAPI getCurrentInstance() 非推奨 Vaporコンポーネント内で `null`を返すため、VDOM に依存したコンポーネントインスタンスアクセス非推奨また制限される。動的要素多用 <component :is="...">や動的なタグ名多用 v-bind:[dynamicArg] やカスタムディレクティブ複雑な値など、 VDOM 柔軟なコンパイルに依存した一部機能に制限がある。カスタムレンダーカスタムレンダー関数や JSXを多用しているレンダー関数（Render Functions）やJSXをサポートしないため、これら機能で構築されたコンポーネント、Vapor Mode で機能しない。エコシステム VDOMライブラリ VDOM を使用しないため、VDOM 依存外部ライブラリやテストツールが動作しない場合がある。

VDOMとVapor modeを共存できる利点を活かし、段階的に適用段階的な移行をすることで、リスク低減が可能 Vapor Mode ベストプラクティスライブラリ互換性確認をしてから導入する

設計思想収束

思想収束： VDOMレスアーキテクチャ潮流近年、フロントエンドフレームワーク分野で、 Virtual DOM (VDOM)
を排除するアーキテクチャへ関心が高まり、Vue Vapor、Solid.js、Svelte.js フレームワーク、共通思想に基づいて進化を遂げています。 Vue Vapor VDOMを排除し、コンパイラが直接DOMを操作するコードを生成 Solid.js 「シグナル」を用いたリアクティビティ、直接的なDOM操作 Svelte.js 「Runes」と呼れるシグナルに近いモデルへ移行共通アーキテクチャ思想コンパイラ主導ビルド時に処理を完了させ、ランタイムオーバーヘッドを削減する「コンパイラ主導」アプローチを採用。VDOM 生成と比較をコンパイル時に解決。 VDOM 中間層を排除し、状態変更から直接的なDOM操作を行うことで、パフォーマンス向上とレンダリング複雑さを削減。 VDOM 排除 Fine-Grained Reactivity 変更があった箇所みをピンポイントで更新する仕組みを採用。コンポーネント関数全体を再実行するでなく、最小限更新を実現。

Solid.js Svelte Vue Vapor Vue VDOM 平均 3.4ms 平均 3.5ms
平均 6.3ms 平均 17.1ms パフォーマンスベンチマーク比較 (レンダリング ) Vapor Mode 登場により、 Vue 最クラスフレームワーク群と肩を並べる存在に。初回レンダリング (1万行) 部分更新 (1000行) 注意: ベンチマークあくまで指標一つです。実際アプリケーションパフォーマンス、具体的な使用状況やデータ構によります。 Solid.js Svelte Vue Vapor Vue VDOM 平均 21ms 平均 16.4ms 平均 11.4ms 平均 16ms ＜計測方法＞時間計測 : performance.now() を使用して、処理開始と終了タイムスタンプ差をコンソールに出力するデータ　 : 1万行リストデータを生成し、ボタン操作で1000行を更新する

ご清聴ありがとうございました Vue 未来単に高であるだけでなく、軽量で、柔軟性に富んだもとなる Vue 3.6 単なるアップデートでなく、コアアーキテクチャにおける
根本的な進化を遂げている alien-signals コアリアクティビティシステムを刷新すべて Vue 3.6アプリが恩恵を受ける Vue 3.5と比較して軽量、かつ、パフォーマンス向上メモリ使用量約13%削減（2.3MB -> 2.0MB） Vapor Mode VDOMを排除する新しいコンパイル戦略パフォーマンスが重視される特定シナリオ向けオーバーヘッドを「蒸発」させる革新的設計適用させたい箇所を選べて、既存アプリと共存が可能

Vue 3.6 時代のリアクティビティ最前線 〜Vapor/alien-signals の実践...

Vue 3.6 時代のリアクティビティ最前線 〜Vapor/alien-signals の実践とパフォーマンス最適化〜

Other Decks in Programming

Featured

Transcript

Vue 3.6 時代のリアクティビティ最前線〜Vapor/alien-signals の実践...

Vue 3.6 時代のリアクティビティ最前線〜Vapor/alien-signals の実践とパフォーマンス最適化〜