仮想 DOM フレームワークの暗黙の仮定と 「jQuery 禁止」
ここまで仮想 DOM の 良い点ばかり喋ってきましたが、しかし仮想 DOM が機能するためには ２つの暗黙の仮定があります。すなわち、
- 仮想 DOM アルゴリズムがその差分検出 / 適用操作を導出できる
- 仮想的な木構造と、本物の木構造が、構造として一致している
仮想 DOM の基本アプローチは仮想 DOM 上の操作 -> 生の DOM への適用であり、この手続きに依存する限り生 DOM を触ることは推奨されません。副作用を起こすと仮想 DOM と生 DOM の対応関係がずれます。触ってしまった箇所に適用処理が走ると、何が起こるかわかりません。しかも内部のアルゴリズムに依存するので非常にデバッグ困難です。
つまり、仮想 DOM アルゴリズムのフレームワークを使ってしまうと、その仮定を壊す可能性がある、手続き的な生の DOM API を行うライブラリ、つまり jQuery や生の DOM API と併用できなくなります。
複数の DOM 操作を行うフレームワークを併用しない、というのは 2020 年現在では普通の事と思われるかもしれませんが、2014 年当時は激しい抵抗にあったように記憶しています。
その理由として、 Web 開発者といえば、その共通言語として、(習熟度の差はあれど) jQuery を使えるのが当然、という状況でした。 jQuery は JavaScript がメインではない開発者が、片手間で少ない時間で学習できる点が好まれていました。
そんな中で jQuery の仕様を禁止を言い渡される事は、「なんか高尚な設計思想を持った連中が俺たちの共通言語を潰しに来ている!!!!」というふうに捉えられたわけです。
仮想 DOM がどのように受け入れられたか
そのような状況はどう解決されたのでしょうか。全部は解決していませんが、次のような変化があったように思います。
単なるテンプレートエンジンとして需要
フロントエンドの習熟度が低くても、React の JSX, Vue の SFC が、単にテンプレートエンジンとして受容されたように思います。それ以前からも jsp, slim, jade などが流行っていたので、その派生の一つのような扱いです。その上で、ロジックを書けば動く、という長所も(たぶん)伝わっているはずです。
これは仮想 DOM アルゴリズムの詳細を知らなくても仮想 DOM フレームワークを使える、という点が効いたと考えられます。ただし、状態管理の複雑な層をさわれる、構築できる人は本職の人だけ、みたいな扱いです。
本格的なフロントエンドエンジニアという職域の成立
2010 年頃からフロントエンドという領域自体はありましたが、開発リソースに比較的余裕がある大企業に一人か二人いる「贅沢品」扱いだったように思います。しかも、アプリケーション層ではなく、画像の最適化や CDN 周りを担当することがメインだったような気がしています。SPA は Google の職人芸であって、まともな企業が自力で作る対象ではありませんでした。
React, Vue, Angular, そして ES2015 と それに続く TypeScript, それらを扱うための node.js ツールチェーンが洗練されるにつれ、フロントエンド自体が一つの独立された職域として認められるようになりました。また node.js/V8 か高速化されたことで、アプリケーションドメインを記述するまともな言語として認識されたように思います。
コンテナ技術によるモノリスの解体
サーバーサイド側では、コンテナ技術によってモノリシックなアーキテクチャから単機能なものへと分解しやすくなり、 API サーバーとそれ以外を分離することが、比較的容易になりました。これによって、アプリケーションサーバーの一部だったフロントエンドが、独立したものになりやすくなりました。
CDN の普及による分解点の成立
また、AWS Cloudfront や Fastly などの CDN のコモディティ化により、js/css などの静的コンテンツは
アプリケーションサーバーが配信するものから、専用のネットワークで配信するものになり、これもまたフロントエンドとサーバーサイドの分解点として機能しました。