「管理画面はシンプルなフロントエンドが良い」は本当か？
TL;DR
「管理画面」と一言で呼ぶのが悪い
本当は同じでないものを同じ技術で作ろうとするのが悪い
------
だいたい世の中で「管理画面」と言った場合2つの要素がある
主に toC のサービスを想定
ここではユーザー向けではなく、社内の運営メンバー向けのページ
典型的には /admin のような URL にまとめられがちなやつ
1. 開発者向けの画面（コンソール、ダッシュボード…）
あるいは ↑ をもう少し社内のメンバー向けに使いやすくしたもの
画像が見れるように、とかね
漠然と「管理者」が特権的な操作をする（ユーザーデータを見るとか）のに使う
2. カスタマーサポートやマーケター向けの画面（問い合わせ対応、チケット管理、審査…）
ユーザーにメッセージを送る（ときには一斉送信をしたり）
サイト上にお知らせを出す（なんなら CMS みたいに記事を書いたり）
ユーザーの作成したデータに対するトラブルを解決する
開発者以外の人が社内で触る「業務システム」である
世の中で「管理画面はサーバーサイドの技術者にも扱いやすいスタックが良い」と言われる
が、これが成り立つのは 1 に対してだけだと思う
2 はどうせリッチになるんだから最初から #React とか使った方がいいと思っている 2 はたまにユーザーと同じ見た目の UI コンポーネントを使うことが重要になったりもする
ユーザーの編集画面を管理者が見られるようにしたい、とか
前提として、ユーザー向けの画面はまぁどうせ React とかでしょうし
これを理由にモノレポをやりたくなるケースもしばしばあるぐらい
小さめのアプリケーションでは 1 と 2 の境界は曖昧である
ユーザートラブルの解決のため開発者がデータを操作するとかがある
そして正にこれのせいで、「管理画面」の技術的負債は 2 に近い分野から表出しやすい（経験上）
「お問い合わせでユーザーの商品情報見れたほうが便利なんで1ページにいろいろ詰め込んだりしたい」とか
まぁこれはそのまま実装するんじゃなく要件削ったほうが賢明だけど、極論そういうの
オペレーションが速いことが重視されるのでページ遷移を減らすインセンティブが発生する
Hotwire は 1 と 2 の区別をちゃんとやる必要がない状況では選択肢になるのかもしれない
が、そもそも 1 と 2 はちゃんと区別した方がいい（経験上）
サービスの立ち上げがモノリスからスタートするのはしょうがない
が、「/admin ってどうせ後から開発者用のコンソールと業務システムに分離するよね」ってところに合意が取れてるに越したことはない
なんなら最初から /dev と /customer_support とかに分けてはどうか
2 の分野にテンプレートエンジン使っても最悪良いけど、せめて 1 と 2 を同じ場所に置かないとかを徹底すると良いのではないか
後でサポート業務が大規模化したときに、2 だけ作り直すとかができると良い感じ
このときはまともに UI をつくれる人を入れたほうが良い
モノリスだけどモジュラに作る、はこういうところでも成り立つ教訓のはず
最初は 1 しか作らない、という割り切りもある
が、経験上 1 の画面に 2 の機能を求める人が現れてだんだん境界がグダグダになるのでこれを上手く行かせるのは難しいと思っている
ではどうすれば良いのか
1 の画面は（サーバーサイドの人がやるなら）そもそも CSS を書くべきではない
決まった見た目のパーツしか存在すべきではない
なんなら classless CSS framework とかで良い
1 の画面に対して「ここちょっと見た目を変えたい」と言われた場合は「諦めろ」と返すのが正しい
Bootstrap についてくるユーティリティクラスとか使ってもいいっちゃ良いが
そもそもあーいうクラスの種類が多いフレームワークを 1 に使うこと自体微妙だと思う
管理画面の CSS フレームワークはアップデートが放置されやすい（経験上）
ので、便利クラス自体があまりない方が良い
万が一 CSS を自分で書くときは、再利用可能な最低限のクラスを作る方が良い
.row とか .primary-button クラスを注意深く設計して再利用とかした方がいい
.admin-item-page > .wrapper { display: flex; } のような個別的なスタイルを書いたら負け。やめろ。
が、その設計ができる人はそもそもフロントエンドちゃんとできる人なので、想定してる状況がおかしい
要するに自分で CSS フレームワークを作れと言ってるようなもの
そういう人がいないから 1. の技術選定をそうしたんじゃなかったんですか？？
JS についてもできるだけミニマルが良い
個人的に HTML Centric 系（Stimulus、htmx など）はあまり気が進まない
あーいうの使うぐらいなら単に Custom Elements（Shadow DOM 抜き）を書けば良いじゃんと思ってしまう
ビルドもしなくていいし、要素のカプセル化とか増減を意識しないでかける仕組みが必要十分にあるので
petite-vue や Alpine.js には多少期待してた時期もあったけど……どうかな正直
2 については前述の通り
最初から React とか使う方が良い
CSS もできるだけ柔軟に変えられるものが良い
ふつうにサービスのフロントエンドを作るときの気持ちで選定すれば良い
上書きをあまり想定しないフレームワーク（Bootstrap とか）は避ける
Bootstrap も Utilities API 以降はアリになったのか……？
Material UI の sx みたいなものと考えればまぁ…？
shadcn-ui とかはいい選択肢
React を使うからと言って 1 とコードベースを分離する必要は必ずしもない
してもいいが
前述のように「ユーザーの編集画面を管理者が見られる」とかを叶えようと思ったらそっちと共通のコードベースのほうがうれしいはず
私は Rails のビューとして React + JSX を書くのがふつうに生産性高い選択肢だろと思ってるので感覚がバグっている可能性はある
どうしても 2 のためにリッチな UI を作れないなら SaaS に任せた方がいい
お問い合わせやカスタマーサポートのタスク管理も Zendesk とかでやる