意義很大，但是你的問題本身認識有偏差。

對于前后端分離，認識上有個誤區，那就是很多人自稱：我們老早就分離了，全AJAX，使用Angular或者什么什么就可以了。

這個說法是不合適的，打個比方，別人問的是“如何解決家禽把蛋生在水草邊的問題？”，但實際上人家養的是鴨子，答題的卻是養雞的，所以回答“不讓去水邊就行了”，這顯然不在點子上。

這兩年業界說的前后端分離，是限于偏展示類的系統(用A代替)，而不是應用、管控類Web項目(用B代替)，在B類項目里，前后端是天然分離的，對此，除了少部分后端開發人員，基本所有人的認識都是一致的。上一段中這樣回答的人一般都是只做B類項目，在B類項目里，前后端分離是共識，不需要討論。

那么，剩下的問題就是討論A類項目的前后端分離了。這個問題的核心在什么地方呢，在于模板的與數據結合的位置，以及，模板的控制權在誰手里。經過這兩年的討論，基本上我們可以達成的共識就是：模板應當由前端人員去控制，主要原因有兩方面：

- 性能優化(尤其是外部資源的管理與發布，請求合并等等)

- 協作的順暢性(已形成模板的界面片段的返工等問題)

那么，模板到底應該在什么地方跟數據結合？

這個問題就比較折騰了，有部分人嘗試像B類項目那樣，使用js模板，然后在瀏覽器端執行，這是存在一些問題的，比如說seo不友好，首屏性能不夠，尤其對于首頁DOM量很大的電商類網站，差距很明顯。

所以我們還是得把主要的模板放在服務端來執行。在這個過程中，阿里作了一些嘗試，那就是引入Node層，在這一層把模板與數據進行合成，然后瀏覽器拿到的就是生成好的HTML了，但也不是所有HTML都是這么生成好的，還是會有一些內容等到了瀏覽器之后，再用js去加載和生成。

所以這一定會是一個混合方案，同一個系統中存在兩種模板，一種在服務端執行，一種在瀏覽器中執行，互為補充。

至于說這個方案中，是否中間層一定要是node，我覺得無所謂，只要是能正常做web項目的東西都可以，這個還是要看所在企業的技術積累方向，當然node做這塊是有一些優勢的，比如對前端人員的語言友好性，前后端模板的通用性等等，但這些都是細節，重點還是整體方案和流程。

這時候回頭看你問題中的這句：

> 前后端分離的意思是，前后端只通過 JSON 來交流，組件化、工程化不需要依賴后端去實現。

我相信你這里對前后端的限定是以瀏覽器為準的，但事實上，A類項目中，前后端的分界一定要延伸到服務器端的模板層，也就是在這一層里，把各種來源的數據整合到模板中，這個數據未必是JSON格式的，會存在有JSON，XML，特定的二進制等等。

組件化這個話題就更復雜了，在剛才組織形式中，很難說出究竟什么才是組件。是某個商品的模板嗎？是數據嗎？是數據和模板的結合體嗎？沒法回答。在此，我說一句自己的看法：像電商這種項目的前端部分，基本不存在組件的概念，甚至不存在組件化的價值，因為這里面可復用的東西太少了，也不易提取，大多數東西都是不帶邏輯的界面模板。

最近因為ReactJS的流行，帶來了一個Isomorphic的概念，這是一種很有意義的探索，但是否能解決這類問題，尚不得而知，根據我的理解，它對B類項目是較好的補充方案，但對A類項目暫時還缺乏可用性，因為A類項目中，運行期的DOM變更并不多，多是整片的改變，用這個方案去解決的話，有些牛刀殺雞的感覺。

關于B類項目的組件化，我之前那個沒寫完的系列是關于它的，但經過最近一年多的思考，我又覺得需要再重新寫一篇東西了。感謝你的問題提醒了我，這就寫。

總結

以上是生活随笔為你收集整理的mysql定位前后端问题_Web 前后端分离的意义大吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。