この記事を読む前に、まずこのオリジナルが書かれた 2014 年の状況を少しだけ抑える必要があります。
React 登場前夜、 フロントエンド MVC という設計スタイルが破綻を迎えていました。 主に Backbone.js が Rails から MVC を輸入し、 Ember などの後発のフレームワークも同じくその MVC の発想で SPA の状態というものを管理しようとしたのですが、しかしフロントエンド環境では、 Rails や 他のサーバーサイド MVC の暗黙の前提を引きずってしまったことで、その抽象に失敗しました。
サーバーサイド MVC の暗黙の前提は、すなわち、
- ストレージ抽象の Model
- 文字列が一度生成されたら終わりの View
- URL のハンドリング目的の Controller
です。これらが通用しなかった理由は、以下のような理由だと自分は考えています。
- フロントエンドの View は細かいサイクルで変化する
- Controller、というかイベントハンドラにおいて、URL ルーティングは初期イベントに過ぎず、クリックやスクロールのようなイベントが大量に飛び交う
- データベース抽象以外にも、もっと概念的なリソースを扱う必要がある
参考
そのような中で、2013 末に、仮想 DOM を備えた React が登場しました。 React に最初に飛びついたのは、 JavaScript のコミュニティ…ではなく、 Clojure(Script) や、 後に Elm を生み出すことになる Haskell といった、関数型言語のコミュニティだったように記憶しています。
彼らに響いた理由として、 React のイミュータブルオブジェクト、参照透過性、ライフサイクルの概念が、既存のフロントエンドの延長先には存在せず、むしろ関数型言語コミュニティの中で知られた概念だったからです。 React が受け入れられるのに時間が掛かったのは、今では普通になったその革新性を、本当に実用可能か評価する時間が必要だったからです。
というのが、前書きで、ここからは 仮想 DOM そのものを解説していくこととします。