>_Minimal
Contact

React・Svelte・SolidJSから学ぶ「仮想DOM」の現在地

2026-05-31 6 min read IT
  • Home
  • IT
  • React・Svelte・SolidJSから学ぶ「仮想DOM」の現在地
目次
6 min read

フロントエンド開発の世界では長らく「仮想DOM（Virtual DOM）」が高速なUI更新を実現する重要な技術として語られてきた。

しかし近年では、SvelteやSolidJSといった新しいフレームワークの登場により、「そもそも仮想DOMは本当に必要なのか？」という議論も活発になっている。

この記事では、React・Svelte・SolidJSを比較しながら、仮想DOMの役割と現代的なUIフレームワークの設計思想について解説する。

仮想DOMとは何か

まずは仮想DOMについて整理しよう。

通常、Webブラウザの画面はDOM（Document Object Model）によって表現されている。

例えば次のようなHTMLがあるとする。<div> <h1>Hello</h1> <p>World</p> </div>

ブラウザ内部ではツリー構造として管理されている。

DOM操作は比較的コストが高い。element.textContent = "Updated";

のような単純な更新でも、ブラウザは再描画やレイアウト計算を行う可能性がある。

そこで登場したのが仮想DOMである。

仮想DOMはJavaScriptオブジェクトとしてUI状態を表現し、

  1. 新しい仮想DOMを生成
  2. 前回との差分を比較
  3. 必要な箇所だけ実DOMへ反映

という流れで更新を行う。

これにより大量のDOM操作を効率化できるようになった。

Reactと仮想DOM

Reactは仮想DOMを普及させた代表的なフレームワークである。

例えば状態が変化すると、function Counter() { const [count, setCount] = useState(0); return ( <button onClick={() => setCount(count + 1)}> {count} </button> ); }

Reactはコンポーネント関数を再実行し、新しい仮想DOMツリーを生成する。

その後、

  • 前回の仮想DOM
  • 今回の仮想DOM

を比較（Diffing）して変更箇所を特定する。

開発者は「画面がどう変わるか」を意識せず、

現在の状態から見たUI

だけを記述できる。

これがReactの大きな成功要因だった。

Reactのメリット

  • 宣言的UIが書ける
  • 状態管理との相性が良い
  • エコシステムが巨大
  • 学習リソースが豊富

Reactのデメリット

  • 仮想DOM生成コストがある
  • Diff処理が発生する
  • 再レンダリングの最適化が必要になる場合がある

Svelteのアプローチ

Svelteは「ランタイムでDiffする必要はない」という考え方を採用した。

Reactでは実行時にState変更 ↓ Virtual DOM生成 ↓ Diff ↓ DOM更新

が行われる。

一方Svelteではコンパイル時に、<script> let count = 0; </script> <button on:click={() => count++}> {count} </button>

を解析し、button.textContent = count;

のような最適化された更新コードを生成する。

つまり、

どこが更新されるかを事前に知っている

ため、仮想DOMそのものが不要になる。

Svelteのメリット

  • ランタイムが小さい
  • 仮想DOM不要
  • パフォーマンスが高い
  • 記述量が少ない

Svelteのデメリット

  • コンパイル前提
  • Reactほどエコシステムが大きくない
  • 大規模開発での実績はReactに及ばない

SolidJSのアプローチ

SolidJSはさらに興味深い。

SolidJSはJSXを使うため見た目はReactに近い。const [count, setCount] = createSignal(0); <button onClick={() => setCount(count() + 1)}> {count()} </button>

しかし内部は大きく異なる。

SolidJSは「Fine-Grained Reactivity（細粒度リアクティビティ）」を採用している。

状態変更時、countが変化 ↓ countを参照している箇所だけ更新

を実行する。

Reactのようにコンポーネント全体を再実行しない。

仮想DOMも使わない。

更新対象が最初から分かっているため、直接DOMへ反映できる。

SolidJSのメリット

  • 非常に高速
  • 仮想DOM不要
  • Reactライクな構文
  • メモリ効率が良い

SolidJSのデメリット

  • Reactほど普及していない
  • エコシステムが小さい
  • 学習資料が比較的少ない

なぜ仮想DOMが不要になりつつあるのか

2013年頃のブラウザ環境では、

  • DOM操作が高価
  • フレームワークの設計が未成熟

という事情があった。

そのため、

一旦仮想DOM上で差分計算する

という設計は非常に合理的だった。

しかし現在は状況が変わった。

コンパイラ技術の進化

Svelteのように

  • 更新箇所を事前解析
  • 最適コード生成

が可能になった。

リアクティブシステムの進化

SolidJSのように

  • 状態依存関係を追跡
  • 必要箇所だけ更新

できるようになった。

JavaScriptエンジンの進化

V8やSpiderMonkeyなどの性能向上により、

状態追跡や最適化のコストが大幅に低下した。

それでもReactが強い理由

仮想DOM不要論が語られることは多いが、Reactの人気は依然として高い。

理由は単純である。

フレームワーク選定では、性能 ＜ 開発体験 ＜ エコシステム

となるケースが多いからだ。

Reactには

  • 巨大なコミュニティ
  • 豊富なライブラリ
  • 企業採用実績
  • TypeScript対応
  • Next.jsとの連携

といった強力な武器がある。

多くの業務システムでは、数ミリ秒の描画差よりも保守性や人材確保の方が重要である。

まとめ

React・Svelte・SolidJSはそれぞれ異なる方法でUI更新問題を解決している。 フレームワーク 更新方式 仮想DOM React Diff方式 使用する Svelte コンパイル最適化 使用しない SolidJS Fine-Grained Reactivity 使用しない

仮想DOMはWebフロントエンドの進化に大きく貢献した技術であり、現在でも十分有効である。

一方で、SvelteやSolidJSが示したように、

「UI更新を効率化する方法は仮想DOMだけではない」

ということも明らかになった。

今後のフロントエンド開発では、

  • 仮想DOM
  • コンパイル最適化
  • 細粒度リアクティビティ

といった複数のアプローチが共存しながら進化していくだろう。

重要なのは「どの技術が最強か」ではなく、「どの課題をどのように解決しているか」を理解することである。