MS_SPAAndMPA - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki
ASP.NET SPAなど、対応したフレームワークを使用して開発する。
- レンダリングはブラウザ側の JS で行うやり方
- 初回リクエスト以降の通信は Ajax での JSON のやり取りのみとなる。
SPA の登場に合わせて登場した従来型の Web アプリを表す対義語
- HTTP GET が来たら、リクエストに応じた HTML を組み上げてブラウザに返す。
- Rails 等のサーバサイドフレームワークで何も考えずに作るとこうなる。
補足（最新化：二項対立ではなくなった）: 執筆時点では
「SPA か MPA か」という二択だったが、現在はその中間が主流である。
方式 内容 代表例 MPA サーバーで HTML を組んで返す ASP.NET Core MVC / Razor Pages SSR + ハイドレーション サーバーで初期 HTML を返し、クライアントで JS を有効化 Next.js / Nuxt ストリーミング SSR / 部分ハイドレーション 必要な部分だけ JS を動かす React Server Components / Astro SPA 初回に JS を落として全部クライアントで描く React / Vue の SPA .NET でも Blazor の
「Blazor Web App（SSR / Interactive Auto）」がこの流れにあたる。「SPA は初期表示が遅く SEO に弱い」という弱点への対処が SSR であり、
現在の議論は「どこまでクライアントで描くか」の程度問題になっている。
- 業務系に向いているが、
- レガシー臭が漂い始めている（.NET Core への移行パスが未定）。
補足: 「移行パスが未定」は、その後
「移植しない」で確定した（ASP.NET Web Formsを参照）。
- よりデザイン重視の案件に適合。
- しかし、SPA に比べるとレガシーではある。
業務系ではなくユーザー・エンゲージメントが必要
と、されているようなシーンで活用すると良さそう。
- モバイル向け
- PV 数の多い B2C 向け
ASP.NET SPAは、全く流行らず、
JavaScript 系のモノ（VS系コンテンツ）が流行ったので、その対抗。
画面全体更新（MPA）か画面部分更新（SPA）か。
-
画面全体更新（MPA）の方式は、
- 業務系に適合する。
- 参照系にも適合する。
-
画面部分更新（SPA）の方式は、
- 業務系以外（管理画面）に適合する。
- 純粋な参照系やエントリ系にも適合しない。
- リッチでインタラクティブな UI を開発したい場合など。
- その他、SPAの適合 / 不適合をご参照下さい。
-
画面全体更新（MPA）の方式は、従来の IDE を使用した開発
-
画面部分更新（SPA）の方式は、
- npm 系の開発ツールとフレームワーク、テキスト・エディタを使用した開発
- npm 系の開発ツールとフレームワークは、MPA 開発環境と比べると、
全体的に不安定
補足（現在の状況）: 「npm 系は不安定」という評価は、
2016 年前後（Grunt / Gulp / Bower / webpack 乱立期）の実感としては妥当だった。現在は Vite がほぼ標準となり、ビルド設定の複雑さは大きく下がっている。
一方で、依存パッケージ数の多さに起因するリスクは残っている。
- サプライ チェーン攻撃（
event-stream、node-ipcなど実例多数）npm auditの脆弱性報告が常時大量に出る- Lock ファイル管理とバージョン固定の運用が必須
「不安定」の中身がツールの安定性から
依存関係の管理コストへ移った、と捉えるのが正確である。
手数が増え、開発の生産性が落ちる
（Single-page applicationを参照）。
- SPAとMPAって何が違うの？SPAにしたほうがいい？ - やわらかVue.js
https://scrapbox.io/vue-yawaraka/
- フロントエンドと単位画面あたりの単価的な話
https://www.osscons.jp/joicpdhoq-537/ - SPAに対する2つの見解。と言うかハマるところにハメれば良い。みたいな話
https://www.osscons.jp/jodlnmgck-537/ - 結局、WebAPIのフロントエンドUIの使いドコロってさぁ。
https://www.osscons.jp/jorwrrjui-537/
Tags: 移行, .NET開発, ASP.NET, ASP.NET Web Forms