在所有程式都混在一起的年代，前後端是怎麼分家的？
先講結論
前後端分離不是某天有人拍桌子說「我們分開吧」，而是隨著 MVC 架構的普及，自然而然把「寫 View 的人」從「寫 Model + Controller 的人」裡面拆出來。本質上是一個成本問題——要後端工程師同時精通 HTML/CSS/JS 的成本太高，壓縮到他們開發核心功能的時間。
怎麼分家的？
故事是這樣的。後端程式基於 Model 2（就是 MVC）建構專案之後，跟前端有關的東西理論上都集中在 View 層的資料夾裡。
早期大家都會後端語言，但要額外花時間搞懂 HTML/CSS/JS？成本太高了。寫 CSS 寫到懷疑人生的不是只有你——那個年代的後端工程師也一樣。於是後來就分出一批人專門寫前端程式。
分法很直覺：MC（Model + Controller）交給後端，V（View）交給前端。
這個分法影響深遠。直到現在，如果你想在一個後端框架（比如 Laravel、Rails）裡引入前端框架，你會在 View 層的公版進入點上掛前端程式——通常包含兩個東西：一個 real DOM 的掛載點、前端打包完的 JS/CSS 檔案。
為什麼沒有 HTML？因為後來 HTML 全部寫在 JS 裡面了（JSX、template）。這造成了另一個問題：HTML 語意化跟初始前端架構設計有沒有對齊，到現在還是一個很少人認真處理的議題。
混在一起的架構怎麼做分離？
如果你現在面對的是一個前後端全部混在一起的 legacy 系統，想要做前後端分離，工作方法很重要：
- 先盤點：整理出哪些頁面要分離，排優先順序
- 準備退路：做好 feature toggle，隨時可以切回舊版。別跟我說「不需要退版機制」——你一定需要
- 漸進式替換：用 proxy 控管，依照需求做階段性的 router release。前端 router 一條一條暴露，最終取代後端 router
- 備好新架構：前後端各自的 MVP 專案架構要先準備好，不要邊分離邊決定新架構怎麼長
這不是一個可以「某個週末加班搞定」的事情。我看過有人想一次全部重寫，結果兩個月後新版還沒上線、舊版也開始出 bug，兩頭燒到最後是三頭燒。
漸進式比較無聊，但它讓你每一步都有退路。在真實的商業環境裡，有退路的方案永遠比沒退路的酷方案好。
前後端分離不是技術演進的終點，而是工程分工的必然結果。