2025 年的文章
Nuxt 的 SSR 與 Nitro：方便，但別讓它替你劃架構邊界
Nuxt 的 SSR 跟 Nitro server route 好用，但方便不等於架構，那層很容易把給瀏覽器的聚合跟面向後端的風險混在一起。
Next.js 的 server 邊界：哪些留在框架，哪些丟出去
Next.js 的 SSR、SSG、ISR 管 HTML 何時生成，RSC 管 JS 送不送瀏覽器。替畫面聚合資料的邏輯留在框架 server，跨服務、帶金鑰的風險邏輯丟到獨立 BFF。
Svelte 給前端的一面鏡子，不是一張神主牌
Svelte 同時保留 DOM 直覺、HTML-first 與清楚的 server 邊界，適合當評估前端框架的參考實作。要帶走的是這三條原則，換成別的框架一樣適用。
Framework 的 Server 層不等於 BFF
Next、Nuxt、SvelteKit 的 server 層都能跑 BFF 邏輯，但只有面向瀏覽器的聚合適合放在那裡，服務間認證、信任邊界與風險邏輯該交給獨立的 BFF。
HTML 從哪裡來：用一條路徑看懂 SSR / CSR / SSG / ISR
SSR、CSR、SSG、ISR 都在回答同一個問題：這份 HTML 是在 build 時、每次 request 時，還是在瀏覽器裡生成的。先決定生成位置，再挑框架功能，縮寫就不用背。
BFF 的兩種組合：htmx 回 partial，SvelteKit 才走 JSON
BFF 後面有兩種接法：狀態在 server 的後台表格用 htmx 回 partial HTML，狀態在 client 的高互動頁才讓 SvelteKit 走 JSON。
SvelteKit 預設 SSR 的世界觀，以及它哪裡會卡你
SvelteKit 的 SSR 預設分工合理，但 Vite dev server 吃 I/O，掛在網路磁碟上會慢到無法開發。後台改純 Svelte SPA 加 hash router 有時更務實。