Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

自己紹介

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Vapor Mode

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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' }

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

Vue3で 改善: Compiler-Informed VDOM

これ 静的なテキストです。

これも静的です。

{{ message }}

import { ref } from 'vue'; export default { setup() { const message = ref('これ 動的なメッセージです。 '); return { message }; } } 静的ホイスティング( 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 */) ])) } コンポーネント ソースコード コンパイル後 コード 「どうせ変わらない部分 、毎回作り直したりチェックしたりする をやめて、  最初に作ったも を使い回そう」という効率的な仕組み

Slide 13

Slide 13 text

「ど 部分が変更されるか」というパッチフラグを付与し、実行時にこ フラグに  基づいて必要な更新 みを行い、不要な比較処理を完全にスキップする仕組み パッチフラグ( Patch Flag) Vue3で 改善: Compiler-Informed VDOM

これ 静的なテキストです。

{{ message }}

クラスが動的です。
IDとdisabledが 動的 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 }; } } 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 */) ])) } コンポーネント ソースコード コンパイル後 コード

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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と構文を使用していること ※ 既存 Options APIコンポーネントをVapor Modeで利用するに リファクタリングが必要

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

{ "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 Package.jsonを書き換え 1 2 3 npm run installでv3.6.0をインストール

Slide 19

Slide 19 text

// VaporTest.vue // 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(左と同じ)

Slide 20

Slide 20 text

コード分析 (1):サンプルコンポーネント シンプルな Vueコンポーネントが Vapor ModeとVDOM Modeでど ようにコンパイルされるかを比較 // App.vue import { ref } from 'vue' const msg = ref('Hello World!') const id = ref('my-element')

{{ msg }}

コンポーネント 説明 2つ リアクティブな値(msg と id)を持つ、最もシンプルな Vueコンポーネント。h1要素 id属性とテキストコンテンツを 動的にバインドしている。 使用している機能 ref リアクティブな値 作成 :id 動的な属性バインディング {{ msg }} テキスト補間(マスタッシュ構文) コンパイル前 Vueコンポーネント例

Slide 21

Slide 21 text

コード分析 (2):コンパイル出力 直接比較 import { template, renderEffect, setDynamicProp, setText } from 'vue/vapor' const t0 = template('

')(); 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 import { ref } from 'vue' const msg = ref('Hello World!') const id = ref('my-element')

{{ msg }}

コンパイル前 Vueコンポーネント

Slide 22

Slide 22 text

コード分析 (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("

", 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にグルーピングする方向で最適化が進められている。

Slide 23

Slide 23 text

コード分析 (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("
Static Element Above
") // v-ifブロック テンプレート :

...

構 const t1 = _template("

") 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] } 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);
Static Element Above

{{ textContent }}

Vapor Modeコンポーネント (コンパイル前 コード ) Vapor Mode (3.6.0-alpha.2 実際 コード ) 上記 例で 、 v-if 動的コンテンツ 更新部分が、構 管理 エフェクトと 別に 独立した_renderEffectに分離されていることがわかります。

Slide 24

Slide 24 text

alien-signals

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

設計思想 収束

Slide 35

Slide 35 text

思想 収束: 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 変更があった箇所 みをピンポイントで 更新する仕組みを採用。 コンポーネント関数全体を再実行する で なく、最小限 更新を実現。

Slide 36

Slide 36 text

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行を更新する

Slide 37

Slide 37 text

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