這個說法是不合適的，打個比方，別人問的是“如何解決家禽把蛋生在水草邊的問題？”，但實際上人家養的是鴨子，答題的卻是養雞的，所以回答“不讓去水邊就行了”，這顯然不在點子上。
這
兩年業界說的前後端分離，是限於偏展示類的系統（用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類項目的組件化，我之前那個沒寫完的系列是關於它的，但經過最近壹年多的思考，我又覺得需要再重新寫壹篇東西了。感謝妳的問題提醒了我，這就寫。