(cache)本当に倒すべきだったのは jQuery ではなくテンプレートエンジンだった

fsubal
本当に倒すべきだったのは jQuery ではなくテンプレートエンジンだった
「他人の書いた 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 の人の内輪の問題」になってしまった。サーバーサイドの人にとっては他人事。残念でしたね。

ところで現状任意の n 回目のレンダリングを担当できる言語は JavaScript ぐらいしかなく、みんな観念してビューは常に Node.js を使ったほうが良いという事になっていったが、これに変化の日は来るだろうか（ C# の Blazor とか一応あるけど ）。そっちはそっちで来てほしい気もするが、あんまり未来が見えないなー。

#フロントエンド