- 服務器渲染：服務器生成整個的 HTML 頁面（數據部分），CSS 和 JS 的部分是在瀏覽器端執行的。
- 前後端分離：後端偏向於提供單純的API接口，前端就是調用API接口進行展示和業務調用。
在以前傳統的網站開發中，前端一般扮演的只是切圖的工作，只是簡單地將 UI 設計師提供的原型圖實現成靜態的 HTML 頁面，而具體的頁面交互邏輯，比如與後臺的數據交互工作等，可能都是由後臺的開發人員來實現的，或者是前端是緊緊的耦合後臺。比如，以前淘寶的 Web 基本上都是基於 MVC 框架 webx，架構決定了前端只能依賴後端。所以他們的開發模式依然是，前端寫好靜態 demo，後端翻譯成 VM 模版。
而且更有可能後臺人員直接兼顧前端的工作，一邊實現 API 接口，一邊開發頁面，兩者互相切換着做，而且根據不同的 URL 動態拼接頁面，這也導致後臺的開發壓力大大增加。前後端工作分配不均。不僅僅開發效率慢，而且代碼難以維護。而前後端分離的話，則可以很好的解決前後端分工不均的問題，將更多的交互邏輯分配給前端來處理，而後端則可以專注於其本職工作。而前端開發人員則可以利用 NodejJS 來搭建自己的本地服務器，直接在本地開發，然後通過一些插件來將 API 請求轉發到後臺，這樣就可以完全模擬線上的場景，並且與後臺解耦。前端可以獨立完成與用戶交互的整一個過程，兩者都可以同時開工，不互相依賴，開發效率更快，而且分工比較均衡。
但是我們怎麼才能知道，是不是需要這樣的架構呢：頁面交互是否複雜 ？是簡單的提供頁面給用戶瀏覽？或者想要支持複雜的用戶操作？是否需要搜索引擎優化？如果需要的話，那麼從一開始我們就需要考慮後端渲染。能提升開發效率嗎？如果不能有效的提升開發效率，爲什麼要作死呢？是否會提供 API 給 APP？如果我們已經有一個 API 提供給 APP，那麼要做這件事就很容易了。如果未來會有的話，那麼我們更應該嘗試去分離。前端的修改是不是非常頻繁？如果不需要經常修改的話，那麼這種優化便沒有優勢。
當我們決定需要前後端分離時，我們仍然還需要面對一系列的問題： 是否足夠的安全？如果我們設計出來的架構不夠安全，那麼這一系列的操作都是白搭。我們怎麼去存儲用戶數據，使用 LocalStorage 的話，還要考慮加密。採用哪種認證方式來讓用戶登錄，並保存相應的狀態？是否有足夠的技術來支撐前後端分離？有沒有能力創建出符合 RESTful 風格的 API？是否有能力維護 API 接口？當前端或者後臺需要修改接口時，是否能輕鬆地修改。前後端協作的成本高不高？前端和後臺兩個團隊是不是很容易合作？是不是可以輕鬆地進行聯調？前後端職責是否能明確？即：後臺提供數據，前端負責顯示。是否建立了前端的錯誤追蹤機制？能否幫助我們快速地定位出問題。
參考文獻
[1] 淺談WEB前後端分離
[2] 前後端分離掃盲