こちらもまとまってない考えをモニョモニョ書きます。
サーバーとクライアントどっちがいらない？
前提として、俺個人としては、Webアプリ作成の省力化のターゲットは1人〜数人程度のエンジニアで作れるもの。大規模になったら簡単に作るというより、スケールしやすさと信頼性が大事だから別の話。
サーバーサイドの人は「なるべくサーバーでやりたい。クライアント最小限」
クライアントサイドの人は「なるべくクライアントでやりたい。サーバーは最小限」
Hotwireは前者。サーバレスとかは後者。 俺がハマってるSuperbase + Nextみたいなのは後者。
どっちが楽かって観点だと、ある程度頑張れば両者とも同じぐらい楽になるんじゃないかと思う。 それよりも、パフォーマンスの観点、コストの観点が重要視されてると思う。
ユーザーのアプリ体験のリッチさって面では現状クライアント重視派に軍配。
また、CO2排出量的にエコかどうかって観点も今後ありそう。 同じ処理をするのに共通部分をなるべくサーバーで処理して、クライアントに配信した方がエコではありそう。
俺みたいなとにかく楽したい野郎にとっては本質的なところよりも、どんだけ便利なSaaSがあるかに依存してるからこれはもうどうなるかわからない。
現状の面倒なところ1 - Web API
下記にも書いたけど、まずAPIを作るのはめんどい。
Web APIを手作りする時代は終わった | FJORD BOOT CAMP（フィヨルドブートキャンプ）
ライブラリとかで、APIの定義を書けばクライアントとテストが自動化できますよってみた時にまず、
「APIの実装は書かなきゃいけないんかい。」
って思ったよね。
アプリの提供する中心的な価値とは関係ないDBのラッパーごときに面倒すぎる。データの定義だってDBのDDLで１回書いてるのになんでまた別の言語で書くの。
それを解消するソリューションはいろいろあるけど、要はアクセス制限をどんな言語で書くかって部分がまだこれは良いってのが見つかってない感じ。
Firebaseのセキュリティールールは複雑でキツい。RLSはみんなが大喜びするほど書きやすくはない。あとMySQLが対応してない。 Punditみたいにアプリの言語で書くってのも独自っぽくてちょっと嫌。ただrubyで書けてものすごく書き味が良いのがあれば良いかも。
現状の面倒なところ2 - 通知
Web APIを書かないとすると、プロジェクのコードの中で地味に大きいのが通知。
Facebookみたいなサイト内の通知やメール通知やアプリ通知。
送る対象と中身の文章、未読・既読程度管理ぐらいしかやってないのにコード量とか手間がかかりすぎてると思う。アプリの提供する中心的な価値とは関係ないのにこれはだるい。 （アプリの提供する中心的な価値の部分は独自のコードたくさん書いても良い）
定番のSaaSとかgemが欲しい。もしくは作りたい。