https://scrapbox.io/fsubal そうはっきり言ったほうが良かった。いや言わなくても伝わる現場は良かったんだけど、伝わらないままごく一部だけをコンポーネントに移行、それ以外はただ生 DOM API に変えて終わり（あるいは他は jQuery のまま）みたいな「モダン化」で済ます余地を与えたのは発信の失敗だった……という10年代の振り返り。 テンプレートエンジンはなぜ倒された方が（…といって悪ければ、変わったほうが）良いのかは端的に指摘できて、それは初回レンダリングしか考慮してないからだということになる。 Web の UI には状態変化がつきもの（になったのは実は最近の話）だが、テンプレートエンジンは1回目のレンダリングだけを担当し、変化した後の2回目以降の見え方は JavaScript が担当するというパラダイムを構成する。 これは、1回目のレンダリングと2回目以降のレンダリングに技術的境界を設けるということである。
同じ一つの画面を、1回目の描画は PHP や Ruby や Java が担当し、2回目以降は JavaScript が担当することに何の合理性があるだろう？？関心の分離もへったくれもないではないか。 かくして、同じ一つの画面は任意の n 回目のレンダリングについて JavaScript が担当するというパラダイムに移行した。これが React や Vue のことを言っているのは皆さんお察しの通り。 一方、現場の人々がいざ React を導入するという話になったとき、なぜかテンプレートエンジンからの移行ではなく、jQuery からの移行という語り口を採用してしまった。これは不幸の始まりだった。 よく「jQuery と React は対立してない」という（ごく当たり前の）指摘がなされるが、じゃぁ本当に対立していて倒すべきだったのは何かはあまり言われなかった。 本当に倒すべきだったのは Slim や ERB や Twig や Blade だったのだ。そうはっきり言ったほうが（より論争にはなっただろうが）おそらくサーバーサイドのメンバーを巻き込んだ改善ができただろうに、jQuery を対立候補にしてしまったせいで「JavaScript の人の内輪の問題」になったり、ゴールの不明瞭な「モダン化」を目指させがちになってしまった。アプリ向けAPIがないようなプロダクトでは特に、サーバーサイドの人にとって他人事感を与えてしまっていたと思う。残念。 ところで現状任意の n 回目のレンダリングを担当できる言語は JavaScript ぐらいしかなく、みんな観念してビューは常に Node.js を使ったほうが良いという事になっていったが、これに変化の日は来るだろうか（ C# の Blazor とか一応あるけど ）。そっちはそっちで来てほしい気もするが、あんまり未来が見えないなー。