🌳 Virtual DOMの真実

🤔 問題提起：Virtual DOMは本当に速いのか？

2013年にReactが登場したとき、「Virtual DOMによって高速なUI更新を実現」という説明が広まりました。 多くのブログや記事が「DOMを直接操作するより、Virtual DOMを経由した方が速い」と主張しました。

では、なぜReactはVirtual DOMを採用したのでしょうか？ 「速いから」ではないとしたら、本当の理由は何なのでしょうか？

🎯 結論から言う

🗺️ 構造図：Virtual DOMとは何か

Virtual DOMは、実際のDOM要素を模したJavaScriptオブジェクトのツリーです。

const element = (
  <div className="container">
    <h1>Hello</h1>
    <p className="text">World</p>
  </div>
);

// React.createElement("div", { className: "container" }, ...)
{
  type: "div",
  props: {
    className: "container",
    children: [
      { type: "h1", props: { children: "Hello" } },
      { type: "p",  props: { className: "text", children: "World" } }
    ]
  },
  key: null,
  ref: null
}

📚 概念説明：Virtual DOMが生まれた背景

2013年当時の問題

React登場前のフロントエンド開発では、JavaScriptフレームワーク（AngularJS、Backbone.jsなど）が 使われていましたが、それぞれに課題がありました。

「全部再描画すればいい」というアイデア

Reactを作ったFacebookのエンジニアたちは大胆な発想を持ちました： 「stateが変わったら、UIを全部描き直せばいい」。

// 概念的なアイデア
function render(state) {
  // stateから完全なUIを計算（毎回全部！）
  return (
    <div>
      <h1>{state.title}</h1>
      <ul>
        {state.items.map(item => <li key={item.id}>{item.name}</li>)}
      </ul>
      <p>Total: {state.items.length}</p>
    </div>
  );
}

// これが「宣言的UI」の核心
// 問題: 毎回DOMを全部破壊して再構築するのは遅すぎる
// 解決: Virtual DOMで「何が変わったか」を計算してから、最小限のDOM操作

💻 コード例：diffアルゴリズムの概要

2つのVirtual DOMツリーを比較して差分を求めることをreconciliation（差分検出）と呼びます。 一般的なdiffアルゴリズムはO(n³)のコストがかかりますが、 ReactはUIの特性を活かしてO(n)まで削減しています。

Reactのdiff戦略

// Before
<div>
  <Counter />
</div>

// After（divからspanに変わった）
<span>
  <Counter />
</span>

// Reactは差分を探さず、divツリー全体を破棄して
// spanツリーを新しく構築する（Counter もアンマウント・再マウント）

// Before
<div className="old" style={{ color: 'red' }}>Hello</div>

// After（classNameだけ変わった）
<div className="new" style={{ color: 'red' }}>Hello</div>

// Reactはdivを再利用して className だけ更新する
// element.className = 'new'; // これだけ実行される

// keyなし（先頭への挿入で全要素が更新される！）
// Before: [A, B, C]
// After:  [Z, A, B, C]
// Reactは A→Z, B→A, C→B, 新規→C と判断 → 非効率

// keyあり（正しく識別される）
// Before: [<li key="a">A</li>, <li key="b">B</li>]
// After:  [<li key="z">Z</li>, <li key="a">A</li>, <li key="b">B</li>]
// Reactは key="z" が新規追加、key="a" key="b" は移動と判断 → 効率的

🔧 仕組み分解：FiberとVirtual DOMの関係

React 16以降、Virtual DOMの実装としてFiberというデータ構造が使われています。 「Virtual DOM」という言葉は概念を指し、「Fiber」はその実装です。

// 処理の流れ
// 1. JSX → React要素（Virtual DOM）が生成される
const element = <Counter count={5} />;
// { type: Counter, props: { count: 5 }, key: null }

// 2. Reactが既存のFiberと新しいReact要素を比較（diff）
// current Fiber: { type: Counter, memoizedProps: { count: 3 }, ... }
// new element:   { type: Counter, props: { count: 5 } }
// → propsが変わった → Fiberを更新する

// 3. 差分をcommit phaseでDOMに反映
// counterElement.setAttribute('data-count', '5') など

Virtual DOMの「速さ」の誤解を整理する

クロスプラットフォームが可能な理由

// 同じJSXが異なるプラットフォームに対応できる理由

// react-dom（ブラウザ）
// Virtual DOM → document.createElement('div') など

// react-native（モバイル）
// Virtual DOM → <View>, <Text> などのネイティブUI

// react-three-fiber（3D）
// Virtual DOM → Three.jsのメッシュ・ジオメトリ

// ink（CLI）
// Virtual DOM → ターミナルへのテキスト出力

// 核心: ReactはVirtual DOMの「差分」を計算するだけ
// 「その差分をどこに反映するか」は renderer が担当
// → 同じコンポーネントコードがどこでも動く

🏁 Virtual DOMを超えて：Compiler時代

近年、「Virtual DOMは本当に必要か？」という議論も起きています。 SvelteやSolidJSのようなフレームワークは、Virtual DOMを使わずに コンパイル時に「どのDOMを変えるか」を解析し、直接DOM操作するコードを生成します。

// Svelte のアプローチ（概念）
// コンパイル時に「countが変わったらp要素を更新」と解析

// コンパイル後（概念的なイメージ）
let count = 0;
const p = document.createElement('p');
p.textContent = count;

function setCount(newValue) {
  count = newValue;
  p.textContent = count; // ← コンパイラが生成した直接操作
  // Virtual DOMのdiffは不要！
}

// React Compiler（React 19）も同様のアプローチで
// 不要な再レンダリングをコンパイル時に削除しようとしている