現在大部分前端新人只寫「前後端分離的代碼」，所以很難理解前後端分離的邊界在哪裡。
其實判定很簡單：如果前端和後端只通過簡單的 API 文檔就能進行數據交流，就說明他們的邏輯是分離的。我們可以稱之為「前後端代碼分離」。
如果除了 API 文檔之外還需要各種其他的數據交流方式，比如後端把數據藏在一個 div 的屬性裡，那麼就不是前後端分離的（因為這根本就不算是一個 API，只能算是一種「私下約定」，但是在實際工程中，總是會保留一兩個這樣的約定）。
這看起來是一句廢話，但是很早之前的 Web 開發確實沒有這個意識。導致頁面代碼雜亂，PHP 中有 JS，JSP 中有 JS，ASP 中有 JS，JS 中有 HTML，HTML 中有 CSS，HTML 中還有 JS，JS 中還有 CSS，CSS 中還有 JS（比如 IE 這個死瀏覽器）。
代碼一點也不「分離」。這種代碼結構根本就沒有 API 的概念，只有數據在各處流竄，極難維護。為了鄙視這種代碼，才有了前後端分離運動。
但是要注意：前後端分離不代表前後端代碼是兩個人寫的，如果代碼是兩個人寫的，那麼就是前後端「分家」。如果代碼是一個人寫的，這個人也不叫做「全棧開發者」，應該叫做 「Web 開發者」，流行的叫法叫做「大前端」。
前後端人員「分家」必然導致前後端代碼「分離」。前後端分離的初衷是用「單一職責」原則把代碼質量提上去，很難想象為什麼之前的開發者連這麼基本的原則都不知道吧，其實是因為以前沒有 AJAX 這項技術，而且前端代碼太少了，不值得花時間分離。後來突然 Web 大爆發，JS 代碼和 CSS 代碼從幾百行躍升到幾千行甚至幾萬行，不分一下就說不過去了。
前後端分離的一個不好的後果是讓前後端人員分家（矯枉過正）。分家的問題我已經吐槽好幾年了，不過之所以大公司喜歡讓前後端人員分家，也是有一些客觀原因的（康威定理）。（其實我很想說前後端分家就是錯的，但是好像大家不喜歡聽，那我就中庸一下吧）為了防止有人擴大概念，我舉一個明確的例子。
某大型 Web 應用，後端服務全部都是 Java 提供的 service（如數據服務）（並不是 HTTP service），業務部門的開發者需要使用 groovy 調用 Java 服務使用 groovy 響應前端的 AJAX 和 HTML 請求使用 JavaScript 做前端界面這三件事都是一個開發者完成的，這就是一個 Web 開發者要做的事情。
他不需要自己去寫 SQL 語句，也不需要自己去連接 Redis。上面的 groovy 可以換成任何你喜歡的語言，比如 Python、Ruby 或者 JS，都一樣。這個時候如果你要問前後端分離在哪裡，其實沒有什麼意義。因為既然前後端都是同一個人，其實不寫文檔也沒事（當然還是寫文檔更好），如果你一定要他寫文檔，也是很簡單事情，因為代碼都是他寫的嘛。而且他自己在前端調用 HTTP 服務的時候用的就是 AJAX + JSON 的方式，這很分離。
這麼做的最大好處就是節省人力和減少溝通時的信息損失。另一個好處就是讓你多學一門語言（我知道有些人認為多學一門語言是壞處），還有一個好處就是沒有什麼蛋疼的「前後端聯調」了。
總之：前後端代碼分離是百分百正確，而且是現在的主流，但是要不要分家（分成兩個團隊，一個前端，一個後端）則是值得商榷的。因為每次前後端撕逼和聯調都是效率的瓶頸請區別對待前後端代碼「分離」，和前後端人員「分家」。
如果你司已經把前後端「分家」了，那麼基本上前後端代碼也是「分離」的。但是如果你司沒有讓前後端「分家」，那麼前後端代碼可能是「分離」的，也可能是「不分離」的，如何判定前文已經說了。前後端分家的對立面並不是全棧，而是 Web 開發。未來的趨勢是大前端，也就是我上面說到的 groovy 的例子。
閱讀更多 前端小學生 的文章
