我的看法是，如果前端只是單純的吐些後端提供的資料，javascript 不會做太多的頁面變化，那麼不做前後端分離是正確的，確實沒那個必要。

但隨著前端的應用互動 (交互？) 越做越複雜，像是一些主流的社交平臺，會提供即時顯示回覆的功能，也就是說使用者第一次點開頁面的時候，後端會需要渲染一次所有的回覆，這時候後端需要一個顯示回覆用的樣板，當有新增的回覆時，資料吐到前端，前端在渲染的回覆時，也需要用到一次同樣的樣版，這樣的場景你是要後端寫一份樣版，再寫一份樣版給前端用嗎？這樣會增加開發維護上的負擔，還是前端直接跟後端請求渲染完的 html? 這樣需要多一個 endpoint 去吐回覆的局部樣板 (Partials)，這兩種作法其實都不如使用像是 react 提供的 ssr 來得方便，一個 component 就能統一搞定前後端的渲染，在實現 lazy load 時也有同樣的問題，第一批貼文是在後端渲染，當使用者捲到底時，要顯示更多的貼文則是前端處理，再舉一個場景，動態表單的實現，像是表單會根據使用者選擇男性或女性產生許多不同的子選項，當使用者下次再回到這個頁面，表單會根據之前選擇的不同，渲染出不同的子選項，這樣的場景其實用 react state 同時管理前後端渲染其實輕鬆很多

面對越來越豐富的 web 應用，前端的框架也日益成熟，我會比較傾向將多數的邏輯歸到前端做處理，而後端只需要對資料做所需的 authentication 和 authorization 或是些只能在後端處理的部分即可，簡單的說，後端只需要管理資料能不能讓該使用者讀取或甚至新增修改刪除，怎麼呈現則是前端的職責，至於前後端是不是該由不同的人或是不同的團隊分工，我想這是另外一個問題，再看有沒有時間跟大家討論，基本上我先說我是支持前後端分離的分工方式

P.S. 抱歉我對這裡的用詞不太熟悉，避免誤用我還是盡量使用台灣的用語