網頁應用歷史
90年代末期
MPA（傳統SSR）
Multiple-Page Application
每次點擊連結／傳送表單，伺服器端都會算繪一次HTML
伺服器端主要使用Web MVC框架
Model-View-Controller
View會以「樣板」嵌入內容
整理應用設定的一種概念與思考方式
透過分擔、管理職責，提高程式碼的可讀性與便利性
Model
負責處理、紀錄邏輯
View
負責顯示畫面
Controller
負責Model與View之間的溝通
例如Ruby on Rails、Struts、Spring-Framework…
00年代後期
MPA（傳統SSR + jQuery）
在傳統SSR產生的HTML裡再插入JS
此時認為將內容（HTML）、樣式（CSS）、邏輯（JS）分離是較好的作法
問題點
大量的事件處理器（Sprinkle）、DOM變為默示的全域變數
無法從HTML管理資料資源
伺服器端的樣板和前端的JS會出現功能重複
10年代初期
SPA（CSR）
Single Page Application
以JS算繪畫面遷移時的處理
伺服器只須回傳第一次的HTML頁面
伺服器API因此可運用在如純手機app上
前端MV*框架登場
MVC、MVP、MVVM…
例如Backbone.js、AngularJS、Ember.js…
解決了DOM的全域變數化和Sprinkle 、伺服器端的樣板等問題
問題點
難以從MPA轉移
難以處理SEO問題
OGP
首次顯示緩慢
LCP、FMP
SPA解決了FCP緩慢的問題，卻使LCP變長了
只是把取得資料延後，和伺服器間的多次來回反而拉長時間
10年代後期
SPA（CSR + prerender）
預先算繪好最初會顯示的內容
又稱Isomorphic JavaScript或Universal JS
由伺服器端的JavaScript執行環境（主要為Node.js）處理預先算繪
在伺服器端處理一份先渲染好的初始畫面
顯示之後同樣由CSR繼續更新畫面
後續互動操作部份交由用戶端觸發操作
問題點
INP緩慢
Interaction to next paint，物件反應時間
預先算繪的類型
SSR
Server-Side Rendering
收到HTTP請求時預先算繪
需要伺服器端的runtime（例如Node.js）
SG
Static Generation
靜態網站產生器
也稱作Static Site Generation
SSG
在build時預先算繪
不需要伺服器端的runtime（例如Node.js）
ISR
Incremental Static Regeneration
組合SG 與 SSR
需要伺服器端的runtime（例如Node.js）
Meta Framework
基於如React等再加上如預先算繪、Routing、Data Fetching等功能後的框架
React based
Gatsby、Next.js、Remix(React)…
其他
Nuxt（Vue）、Angular Universal、SvelteKit、SolidStart…
若稱React為library，則常會稱Next.js為框架
若稱React為框架，則會稱Next.js為Meta Framework
或稱為生態系
Streaming SSR & Partial Prerendering