その上で感想と言うか、思ったことのメモです。
※タイトル内の「SSRアプリでは〜」という表現は、「MPAでのWebアプリでは〜」（MPA=Multi Page Application）とか「従来のサーバーサイドでのWebアプリケーションでは〜」と呼称する方がたぶんが適切ですね。なぜなら「SSRは、SPAを実現するフレームワークにおいて一部をサーバー側に処理を移すためのオプション」と捉えるべきだから。もしくは「サーバーサイドでWeb画面を生成してブラウザに返します（ブラウザ側でWeb画面を変更したりしません、ページ遷移しない限りは）」という手法であって、Webアプリの種別を表現するものではないだろう。ただ、語感的に私が「MAPアプリ」と言うより「SSRアプリ」と言った方がピンと来たので、そのままこの表現で残す（素人なので、一般的ではない可能性大）。
閑話休題。
Webアプリ（Webブラウザアプリ）での話だけど、
サーバーアプリだとMVCが主流で、クライアントアプリだとMVVMが主流のように感じている。「そこの差は何故だろう？」と言うふとした疑問に対して、ふと「理由は、こういうことか？」を思えたのでメモ。
間違っていたらごめんなさい。
前提として、私は以下のように考えている。
- 「UIの実装」ってのは基本的に「データのUIへのマッパー」であるのが望ましい
- 「データをどう処理するか？」はUIとは全く別に考えるのが良い
それを踏まえるとあるべき姿は「MVVM＝Model , View ViewModel」ではないか？と思うのだ。
Viewで「データのUI表現（Mappingの仕方）」を担当して、Modelが「データ処理」を独立して扱う。そして「UI側のアクションとデータへの反映とそれに伴うUIの変化」を担当するVMはFrameworkにお任せして、実装者は触れたくない。そういう分担が分かり易いと思うのだ。
※ここでModelはCRUDを含むが、SPAの場合はその部分だけサーバー側へWeb APIで（多くの場合はREST APIで）渡して処理する、と捉えている。（したがって、Modelはクライアント側と、サーバー側にまたがっての実装、と言える）。
さて、改めて。
SPA（=Single Page App）では、MVVMが主流だと思う。
しかし、SSRではMVVMよりMVC(=Model, View, Controller)が主流に感じている。
この違いは、SPAがViewとVMを同じ言語というか動作プラットフォームであるJavaScriptで実装するからこそなのかな？、と思った。
SSRの場合、Viewの発火をVMが監視する手段、Model変更をリアルタイムでView反映する手段が、たぶん容易ではない。なぜならSSRの場合は、Viewとそれ以外の部分で言語／動作PFが異なるから（ViewはHTMLとJavaScriptであり、それ以外はJavaとかPython、もしくはRubyなど）。
なのでブラウザ側で「Viewが自身の発火をControllerに伝える」ことを起点として、そこに境界をおいて、サーバーサイドのControllerがViewとModelに対して処理を行うMVCが主流となる、、、のかな？（Controllerに制御が移ったときブラウザはサーバーからの応答待ちであって、その応答として返す画面として次のView反映され、その応答が境界となる）、
と思えてきた。
まぁ歴史的には「UIをリッチにしたいんだけど、MVCだと複雑になっていく。MVVMという概念に移行したんだが、SSRだと厳しい。・・・CSR（=Client Side Rendering）だったらMVVMを実現できるんでは？」としてSPAが生まれた、、、とかかも知らん。
さて、実際のところはどうなんだろう？ 教えて、詳しい人？
（前提の「主流」からして誤っている可能性はあるｗ）
※なお、SSR＝Server Side Renderingであって、Super Special Rareの意図では無いですｗ
※あと「マッパー」は「Mapper」「Mappingをするモノ」の意図です。・・・何故かFGOのローランが脳裏に浮かぶけど、だいたい6.5部のせいだ！
