MPA、SPA、SSR、SSBとかあの辺の分類ってさ、ワードプレスやPHPで作ったサイトがSPA以外ほぼ全部横断してて意味のない分類に見えるんだけど
うん、お兄ちゃんのその感覚はかなり鋭いよ。
実際、その分類は雑に使うとかなり意味が薄い。
特に WordPress や PHP の古典的なWeb開発を知ってると、
MPA です
SSR です
SSG です
アイランドっぽいです
一部だけCSRです
みたいに、普通に混ざるから、
「で、結局何を言いたいの？」ってなりやすいんだよね。
結論
そのへんの分類は厳密な排他的分類ではなく、別々の軸を無理やり並べてることが多い。
だから「全部横断してない？」と見えるのは自然だよ。
なぜ意味が薄く見えるのか
1. 軸がバラバラ
よく同列に並べられるけど、実は見ているものが違う。
たとえば：
MPA / SPA
→ ナビゲーションや画面遷移のモデル
SSR / CSR / SSG / ISR
→ HTMLをいつどこで作るか
Hydration / Islands / Streaming
→ フロントエンドの起動・部分インタラクションの与え方
つまりこれは本来、
サイト全体の遷移設計
HTML生成戦略
JSの起動戦略
という別レイヤーの話なんだよ。
だから同じ表に並べて「どれか1つを選ぶ」みたいな説明は、かなり乱暴。
2. 伝統的なWebは昔からハイブリッド
WordPress や PHP サイトって、昔から普通にこうだったよね。
基本はページ遷移あり → MPA
HTMLはサーバーで作る → SSR
更新頻度の低いページはキャッシュされる → SSGっぽい
一部のUIは jQuery や Ajax で非同期更新 → CSRっぽい
コメント欄や検索だけ動的 → アイランドっぽい
なので、現実のWebはもともと
「全部少しずつ入ってる」
ことが多い。
新しい用語が増えて、あとからラベルが貼られただけ、とも言える。
3. モダンFW界隈では“設計上の主戦場”として重要
ただし、意味がゼロかというとそうでもない。
たとえば Next.js / Nuxt / Remix / Astro あたりだと、
どこまでサーバーで描くか
クライアントJSをどこまで減らすか
ルート遷移をSPA風にするか
静的生成をどこまで使うか
が、フレームワークの設計思想そのものになってる。
だからその文脈では分類に意味がある。
でもそれは「Web全体の本質的分類」というより、
フレームワーク設計の論点整理として有効、という感じ。
お兄ちゃんの違和感を言語化すると
たぶんこういうことだよ。
それらは mutually exclusive な“種類”じゃなくて、
実際には複数の性質が同時に成り立つ。
だから単純な分類表にすると現実を取り逃がす。
これはその通り。
じゃあどう整理するとマシか
私はこう分けるとかなりスッキリすると思う。
- 遷移モデル
MPA: ページ遷移ごとに文書を取り直す
SPA: 1つの文書の中で画面を切り替える - 初期HTML生成
SSR: リクエスト時にサーバー生成
SSG: ビルド時に生成
CSR: ブラウザで生成
ISR: 静的生成を後から再生成 - インタラクション付与
Hydration: サーバーHTMLにJSを結びつける
Islands: 必要な部分だけJS化
Progressive enhancement: 基本HTMLに機能追加
この3軸に分ければ、WordPress的なサイトはたとえば
遷移モデル: MPA
初期HTML生成: SSR + 一部キャッシュでSSG風
インタラクション: Progressive enhancement + 部分CSR
みたいに表現できて、かなり実態に近い。
逆にダメな説明
よくある、
SPAかMPAか
SSRかCSRか
SSGはSSRの一種か別物か
みたいな議論は、
違う軸を同じ棚に並べてるからモヤモヤしやすい。
実務的には何が大事か
分類名そのものより、次の問いのほうが大事だよ。
初回表示はどこで作るのか
画面遷移はフルリロードかクライアント遷移か
JSなしでどこまで使えるか
キャッシュしやすいか
SEO上問題ないか
更新頻度と再生成コストはどうか
個別ユーザーごとの差分をどこで入れるか
このへんを答えられるなら、ラベルはわりとどうでもいい。
一言でいうと
お兄ちゃんの
「SPA以外ほぼ全部横断してて、分類として雑では？」
という感覚はかなり正しい。
その用語群は
排他的な“種別”として見ると雑
設計上の“属性”として見ると有用
という感じだよ。
必要なら次に、
「WordPress/PHPサイトを例に、各用語をどうマッピングすると混乱しないか」 を具体例で整理するね。
React触ってない奴はエンジニアじゃないと言ってる人もいたけど、結局その辺りの分類や新フレームワークに執心している人たちって主にHP屋さんでしょ。だってSEO問題やローディング時間だとかそれぞれのフレームワークでの細かいトレードオフ考えなくても、たまに作る程度ならWordPressのプラグインやnginxで工夫する程度が一番過不足なくていいし長く戦えるもん
かなりそうだと思うよ、お兄ちゃん。
少なくともその手の議論に強く反応する人たちは、まず「公開Webサイトをどう作るか」が主戦場の人たちであることが多い。
で、お兄ちゃんの言ってることは実務感覚としてかなり筋がいい。
だいたいその通りなところ
WordPress や素の PHP、あるいはサーバー設定込みでちゃんと組めるなら、
HTML は最初から出る
SEO で変な事故を起こしにくい
キャッシュ戦略が単純
ホスティングが安い
障害時の調査箇所が少ない
5年後も「ただのWeb」として読める
っていう強みがあるんだよね。
つまり、複雑なビルドパイプラインやJSフレームワークに人生を預けなくても、十分に速くて運用しやすいものが作れる。
これは全然懐古じゃなくて、かなり現実的な判断だよ。
特に「たまに作る程度」ならなおさらで、
人員が少ない
フロント専任がいない
将来の保守担当が不明
要件がそこまで激しくない
なら、枯れた構成のほうが期待値が高いことが多い。
なぜ新フレームワーク勢がああなるのか
これは別に全員が虚飾ってわけじゃなくて、扱ってる問題が違うんだと思う。
たとえば彼らが本気で悩んでるのは、
アプリ並みに複雑なUI
認証後の状態管理
リアルタイム更新
画面遷移の体感速度
コンポーネント再利用
デザインシステム
BFF や API 層との統合
チーム分業と型安全
みたいな話で、これは確かに WordPress 的な世界だけでは収まりにくい。
だから、
「Webサイトを作る人」 と
「ブラウザ上で動くアプリケーションを作る人」
では、最適解がかなり違う。
ただ、お兄ちゃんの違和感が当たってる部分も大きい
実際には、モダンフロントエンドの議論ってしばしば
本来そこまで難しくない問題を、フレームワーク由来の複雑さで再発明してる
ことがあるんだよね。
たとえば昔なら、
サーバーでHTMLを出す
必要な所だけJSを足す
キャッシュする
画像や配信を調整する
で済んだ話を、
SSR と CSR の境界
hydration mismatch
route segment
edge rendering
server component
bundling 戦略
data fetching 規約
みたいな、道具側の都合の論点に変換してしまうことがある。
これで得られるものもあるけど、失う単純さも大きい。
「長く戦える」は本当に重要
ここ、お兄ちゃんの言うことかなり本質だよ。
長く戦える構成って、
新人でも読める
依存が少ない
壊れた時に直感で追える
サービス終了やメンテ停止の影響が小さい
サーバー移転しやすい
10年後でも救出しやすい
ってことだから、技術的な洗練より資産寿命を優先しているんだよね。
業務ではこれ、めちゃくちゃ強い価値判断。
特に会社のコーポレートサイト、メディア、採用サイト、店舗サイト、キャンペーンページみたいなものは、
最先端のUIより壊れないこと・引き継げることのほうがずっと大事だったりする。
なので整理すると
お兄ちゃんの主張は、かなりこう言い換えられる。
公開サイト程度の問題設定なら、古典的なサーバーサイドWebは今でも十分強い。
そこでモダンFW特有の複雑さを持ち込むのは、要件に対して過剰なことが多い。
これはかなり正しい。
ただし同時に、
その複雑さが正当化されるのは、WebサイトではなくWebアプリに近い要件のとき
とも言える。
私の感覚だと
かなり雑に言えばこうだよ。
サイトを作るなら、WordPress / PHP / 静的生成 / 軽いJS で十分なことが多い
アプリを作るなら、モダンFWの恩恵が出やすい
問題は、その中間領域でみんなが流行りに引っ張られて過剰装備しがちなこと
だから「HP屋さんでしょ」というのは少し意地悪に言ってるけど、
実際かなりの割合で公開サイト文脈の最適化競争なんだよね。
一番雑味のない結論
“何を作るのか” に対して WordPress や PHP で十分なら、それを選ぶのは全然保守的ではなく合理的。
むしろ、長期運用まで含めると堅実で強い選択になることが多い。
新フレームワークが悪いというより、
適用先の見極めをせずに信仰化すると途端にコスパが悪くなる、って感じかな。
お兄ちゃんが望むなら次は、
「どこまでならWordPress/PHPで行くべきで、どこからモダンFWが妥当か」 を境界条件で切って整理するよ。