Web 前後端分離的意義大嗎？
前後端分離的意思是，前後端只通過 JSON 來交流，組件化、工程化不需要依賴後端去實現。 可以通過 Angular 或者 FIS-Pure 等，以實現組件化；通過 FIS 之類的工具去做工程化。 有哪些好處或弊端？現在的發展趨勢是否往這個方面發展？
簡單來說，對於原始的Web開發模式，前後端分離的意義當然是非常大的，但是是不是要具體到：
前後端只通過 JSON 來交流，組件化、工程化不需要依賴後端去實現。
這個有待商榷，具體的實現方式多種多樣，前後端的解耦程度是否越大越好？這個不一定。Web開發是一個很複雜的工程性的問題，前後端分離只是其中一個小問題，採用何種方案進行分離，在什麼層面/維度進行分離？這些都是實踐中要根據具體情況去進行抉擇的事情。
最後回到問題
Web 前後端分離的意義大嗎？
1、該網站前端變化遠比後端變化頻繁，則意義大。
2、該網站尚處於原始開發模式，數據邏輯與表現邏輯混雜不清，則意義大。
3、該網站前端團隊和後端團隊分屬兩個領導班子，技能點差異很大，則意義大。
4、該網站前端效果絢麗/跨設備兼容要求高，則意義大。
沒必要分太細。我們需要 specialist，但是 senior 的人都應該了解整個 E2E (end-to-end) 過程的。
在 Facebook 我們不分前端和後端，只分 product 和 infrastructure。做 product 的通常都是 full stack，不需要對特定的技術非常精通，但要求學習能力和靈活性足夠好，不能只做自己 comfort zone 以內的事情，do whatever it takes to get your product shipped。通常聰明的應屆生都會先進入 product，因為他們學什麼都很快，也不會說浪費了在某個領域的積累。infrastructure 擁有更多各個領域的 specialist，前端只是其中之一。infrastructure 的客戶就是 product，要做的事情就是讓 product 開發實際產品時覺得爽，就這麼簡單。
至於真正 senior 的人，必須了解整個 E2E 過程。這有點像那個「在瀏覽器地址欄按下回車後都發生了什麼」的答案，也就是掌握大局同時了解細節。因為具體的問題可疑扔給 junior 的人去解決，所以 senior 的存在價值就是在眾多問題當中尋找值得解決的問題。學過計算機體系結構的人都應該知道，性能優化只應該在瓶頸上做，因為做在非瓶頸上就是浪費資源。同理技術或產品的優化都應該是做在瓶頸上的，所以 senior 的人應該熟悉整套系統並且能夠有效找到當前的瓶頸。這時候就不存在前端或者後端的概念了，因為 specialist 在特定領域再精通，不了解整個 E2E 的過程就沒辦法再往上提升。
@winter 提到「聯調」，我想說我很久沒聽說過這個詞了，因為這個詞沒有對應的英語版本，美國公司的產品開發過程通常不包括聯調。product 要做什麼，就自己學習對應的技術，學習公司內部的 infrastructure，然後調用公司內部的 API 就可以了。一個產品的邏輯，要分前端和後端兩個團隊的人實現，然後還要協調實現的結果，這我只在中國公司見過。當然這不僅僅要求公司 infrastructure 好，還要求有開放的文化。
我進 Facebook 之前只寫 JS，在 Facebook 要用 PHP 我隨便學學就開始寫，反正寫得不好 code review 時會有人指出。只要保持開放的學習心態，同一個錯誤不要一犯再犯，別人都樂意幫助你進步。現在我的 PHP/Hack 就僅僅是夠用的程度，但這不妨礙我工作。我的工作當然要用到別人的 infrastructure，偶爾用起來有點小不爽，我就會想要改動一下。管它是 Python、Java 還是 C++，反正我不爽就必須親自研究源代碼弄懂了自己該。原本的作者不一定有時間處理我的小需求，我就按照我的理解去改，改好提交 code review，別人都會幫忙看然後提點建議。
所謂聯調，無非就是有些事情你自己做不了非要以來於別人幫你做，然後別人就會成為阻塞你的環節。（通常都是前端依賴後端，很少有說後端因為前端沒完成就必須停下來等的。）這種做不了就停下來等的態度是不對的，不能說那是別人的問題就等別人解決。總之阻塞了產品發布的問題就是你的問題，無論需要你學習什麼新技術，無論需要你編寫和調試什麼不熟悉的代碼，do whatever it takes，just get the product launched。
@齊泰然 那個木工和電工的比喻大致也是對的。在中國公司，這就是木工和電工的分離。在美國公司，有一幫人使用 3D 印表機、激光切割機、數控機床，外加 Arduino 或 Raspberry Pi，迅速把新一代電子產品的原型做出來；還有另外一幫人研究新一代的 3D 印表機，考慮如何讓上述 maker 更快地把頭腦中的產品原型變為現實。在中國公司，木工和電工整天吵架，木工說電工不把線路板面積確定下來他就沒辦法做木盒子，電工說他在電動機大小不確定的情況下線路板沒辦法定稿。意義很大，但是你的問題本身認識有偏差。
對於前後端分離，認識上有個誤區，那就是很多人自稱：我們老早就分離了，全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類項目的組件化，我之前那個沒寫完的系列是關於它的，但經過最近一年多的思考，我又覺得需要再重新寫一篇東西了。感謝你的問題提醒了我，這就寫。
謝邀。
首先，我給 @Cat Chen的答案點了贊，因為本司（百姓網）也採用Cat講的Product/Infrastructure的分法，儘管我們還有許多不完善之處。
但是大家也許知道我非常推崇前後端分離。看上去似乎有點矛盾。
一句話解釋：我推崇前後端分離是在於技術架構上，而不是組織/流程、職位/工種的分離。
我認為最有效率的方式始終是——讓每個人發揮他（她）自己最大的潛能。所有組織/流程、職位/工種的限定，是為了更好的協作，而不應該限制人能力的發揮。
如果人的能力強，當然可以full stack。且小團隊肯定效率更高。反過來，跨部門聯調這種事情，必定非常低效，且多後患，應極力避免。
可是full stack工程師至少目前是可遇不可求，大多數情況還是像 @Cat Chen 講的直接從應屆畢業生培養。但每個團隊最初的核心成員不可能是應屆畢業生，你至少需要有幾個資深工程師作為種子full stack工程師。facebook或許可以招到許多能力超強的人才，但大多數公司招不到，即使是BAT。
市場上有工作經驗的技術人才往往只是熟悉某個特定領域，因為他過去積攢經驗值的地方本來就是這樣分工，從而限制了他成為full stack的可能——這是又一個雞生蛋蛋生雞的案例。
因此，即使我們採用了小團隊協作的方式，團隊內部也難以做到都是full stack，還是有前後端分工。只是這種分工不是基於職位，而是基於能力現狀。
另一個情況是，即使一個工程師在facebook的團隊里可以full stack，但換個團隊很可能就不行。 @Cat Chen 提到了兩個前提：infrastructure 好，開放的文化。兩者缺一不可。小公司常缺前者，大公司常缺後者。本司後者很好，前者還不夠完善但仍算OK。但是我們仍面臨困難，這就是我要補充的第三個前提：合理的人員配比——這點容易理解，你可以不熟前（後）端，但是至少團隊里有人是較為成熟的前（後）端，否則連能review你代碼的人都找不到，成長就更無從談起。我司最近就面臨這樣的情況，業務線發展太快導致新開項目的團隊配不齊人。在這樣的情況下，不得已就得放低要求，採取前後端分離的工作方式——是的，前後端分離的方式對人的要求是更低的。
還有一個問題是 @ZExceed 提到的：「對於個人職業規劃來說，橫向發展的風險往往大於縱深發展」。我個人並不完全認同這點，且我看到至少在前端領域許多由於分工過細導致技能發展受限的悲劇。但是，如果缺乏縱深發展的可能，確實也會是個嚴重問題。
我認為必須給予工程師遵循自己興趣和能力決定自己發展路徑的自由和支持。技術架構若能很好的分層——比如良好的前後端分離，將有助於工程師進行縱深發展。而這反過來也可以促進橫向發展，因為工程師可以更自由的在多個層面上轉換。
以上就是我的想法——Web前後端分離和full stack不是互相矛盾的。相反Web前後端分離的技術架構能更好的幫助我們走向product/infrastructure的組織架構，並且能讓工程師更自由的發展。
前後端要不要分，怎麼分，是由具體業務決定的。
需要搜索引擎帶流量的，必須由伺服器端渲染。
需要用戶登錄且不能由搜索引擎抓取，前後端分離是鼓勵的。
需要App和後端交互，必須分離。
但是分了就表示架構合理？不一定。設計一套合理／可升級／客戶端友好的API也不容易。
要想分離好，前端開發要了解後端架構，後端開發要虛心學習JavaScript，雙方如果互相鄙視，分了也白搭。
&>&>前後端分離的意思是，前後端只通過 JSON 來交流...
同意其他幾位，JSON 只是一種可選的協議，而不是唯一，也未必是前後端通信的最佳方案。
&>&>組件化、工程化不需要依賴後端去實現...有哪些好處或弊端？
前端的組件化、工程化，js 等代碼越來越胖，有點類似於過去 C/S 時代的 fat client。所以這個問題相當於，計算是主要放在 client 好，還是 server 好？
Fat client 好，還是 thin client 好，取決於所開發應用、產品、系統的類型、規模和特點，其中一些權衡因素主要包括軟體複雜度、人機交互模型、網路帶寬、server 與 client 的處理能力等等。無所謂好壞，適合就好。
Client-side MVC 確實是一個趨勢，Web 架構設計上的一個創新。
見 Wikipedia: AngularJS
補記
題主原來想問的其實是一個軟體架構設計的問題。
如果只問「前後端分離的意義大么？」這是廢話，因為從軟體架構的角度 Web 的前後端從一開始不就一直是分離的么，而且 browser、server 可能將永遠分離下去。
前後端分離的意思是，前後端只通過 JSON 來交流，組件化、工程化不需要依賴後端去實現。 可以通過 Angular 或者 FIS-Pure 等，以實現組件化；通過 FIS 之類的工具去做工程化。 有哪些好處或弊端？現在的發展趨勢是否往這個方面發展？
所以，題主特意作出了澄清。這個問題的實質，我理解題主真正想問的是：
基於 JavaScript（如 Angular）的 Client-side MVC 框架、Single-page applications（我說的 fat client）的意義大么，有哪些優缺點，是否是一個趨勢？
怎麼感覺樓下大咖們的回答好像偏題了呢？有點審題不清。
實現一個 end-to-end 的系統功能，Web 前後端的開發工作是實現分離，由不同定位的工程師分別完成？還是開發的角色、任務不分前、後端，全部交由技能全面的一人或多人（如 fullstack 工程師）來完成？
團隊里不分開發與測試，不分前端與後端...這其實是敏捷方法 Scrum 的一個標準實踐。
所以，看來模糊的自然語言「Web 前後端分離」至少有兩層含義：前者是軟體架構的設計問題，後者是項目管理中的角色定位、任務分配問題。這是兩個相關但完全不同的問題。意義很大~
前端就是在前後端分離之後，身份才提上來的。
之前前端就是很少做路由，所有的控制都是交給後端來做的。
調試什麼的很麻煩。
後端專註於提供數據，更重要職責是維護系統架構的穩定，保證數據的安全。
前端人員專註於交互，快速響應UI的變化。
這本身就是兩套不同的訓練模式，而介面文檔在這裡也格式的重要起來了~
在之前沒有前後端分離的時代，很少有介面文檔的說法，只有在Ajax的時候才會有一些，但是大部分都是JSP去提供跳轉數據。
再一個，可以統一給Android和IOS和WEB提供統一的介面了。
之前總是在頭疼，同樣的業務邏輯，可能要寫很多遍，不同的終端可能面向不同的WEB程序。
從分工上來講，變的更明確了~
唯一不好的地方就是SEO，頭疼。
這個之前D2結束的時候有在亂燉上和網友做過一些簡單的討論，縱向來看，無論是樓上提到UED的midway也好還是支付寶做的chair也好，都不是簡單把前後端分化成browser和server，而是進一步的把前端的領域擴大拓展到原本屬於後端的一部分（比如view）。達到讓後端專註於提供數據介面（SOAP/HTTP），而前端掌控所有信息的展現、組織以及架構的目的。
領域擴大了，那麼可供伸縮拳腳的空間也就大了，AJAX/WebSockets的選擇可以自己決定而不需要跨端合作（降低內耗），同時前端對信息、數據交互有了決定權（增強體驗）；又比如語義良好的Restful API本身可以視為一定程度上的文本驅動，其次也能優化SEO（信息架構），這部分前端可以藉server端的url路由控制來實現，而在以前前端能碰的Router只存在於SPA里。另外，前年kenjun在豆瓣的移動化有關的分享上有提到過douban在不同層面上的響應式實現，因為傳統前端能做的responsive其實有限，在面臨一些複雜結構的webapp時，如果可以在server端做分場景的渲染往往可以得到更優的體驗（但同樣會帶來成本開銷）。
換一個層面，一些尚有提升空間的網站，前端可以自主做些按需載入以及combo請求合併，這個張雲龍前輩在他的github上（前端工程與模塊化框架 · Issue #4 · fouber/blog · GitHub）做過一些方案介紹，不做贅述了。
好處有（簡單談一些），缺點自然不能少，但這其中我覺得最難的一點是人。我不喜歡人家說前端容易，但同樣我也認識的到後端的困難（更不提純後端的複雜度了），在做前後分離時，會需要一些複合人才、以及有一線後端工作經驗還熟悉JS的開發者，這一點如何評價淘寶 UED 的 Midway Framework 前後端分離？ - 互聯網這個回答里排名第二的匿名用戶談了很多，比如運維，比如日誌生成與維護，比如安全。前端雖然職責擴大了，但此道浸淫確實不如他者深，如何快速達到平衡也是個問題。
在D2結束後的閑暇時，我偶爾會想想這個問題，考慮到前後端分離很多時候是為了提高開發效率，增強UI/UX，以及降低耦合，讓部門間更好的合作。因此如果是稍小些的公司或者前/後端間流程本就沒有那麼複雜、溝通成本也適中時，那麼推行這樣的前後分離真的是合適的么？再者，前端人的本身的技能儲備、綜合素質是否達到了這樣項目的要求，面對有一定複雜度的項目又是否有橫跨多平台語言的能力（比如Node和C++）？
如果是為了分離而分離，那麼本末倒置的苦果一定不會好吃。
btw，在這個議題上，真心期待更多大廠的踐行與探索。
好了，我真的去看書了........
比較理想的模式是：
RESTAPI ＋ iOS ＋ Android ＋ Web
Web可以用PHP／Python／Node.js 來做，但有伺服器端，部署調試會相對麻煩。
相比 Angular 這種純前端的要好很多。
同時前後端分離後，可以讓各自變得更專註。
目前我們公司的後端會先寫測試數據的，所以不用前端自己來模擬。
按照這種方式Web／iOS／Android 三個前端對於後端來說就無差別了。
前後端分離的意思是，前後端只通過 JSON 來交流，組件化、工程化不需要依賴後端去實現。 可以通過 Angular 或者 FIS-Pure 等，以實現組件化；通過 FIS 之類的工具去做工程化。
前後端分離的最終目的還是為了提高效率，實現途徑有很多，但是一定不是隔離前端崗位和後端崗位。
目前看到比較好的前後端分離案例
1. 後端數據服務化，走統一的介面規範輸出，甚至是統一走一層後端的服務輸出介面，降低前後端介面定義的溝通成本，對前端來說，後端是一個巨大的數據源。而這部分介面的規範是需要前後端在很多方面達成一致才能落地的。
2. 前端頁面組件化，目前已經看到一些業務中，前端編寫組件和調用規範，然後把文檔扔給後端，直接由後端來編寫html，js來接入數據，組合頁面。
實現上，比如一個Node模板模塊
{{include("head.js", data)}}
{{include("foot.js", data)}}
這是一種。
又或者是基於react的。
&
ReactDom.render(React.createElement(Slide,null), document.getElementById("slide"));
})
&
服務端和瀏覽器端都大概可以採用這類的模式。
混著寫和分開寫的項目人事變更之後的維護感受是不一樣的。
提高自己和別人寫碼體驗/代碼質量的事情，何樂而不為。前後端不分開怎麼做單元測試？不做單元測試怎麼做做每日構建？不做每日構建怎麼每周發版本？不每周發新程序怎麼穩住客戶？不穩定住客戶老闆拿什麼發錢？不發錢還要要程序員幹嘛？
意義很大，但不是指工種，而是程序架構。
在公司的角度出發
在公司的角度出發和業務類型有很大關係，如果是大公司，業務線比較深業務比較複雜公司是希望，前後端分離的，原因很簡單：社會分工和協作越來越細化，大公司希望創造流水線式的工作流程。專業的人做專業的事情，我想度過《福特傳》的同學應該會深有體會。通過設計出流水線式的工作模式，大大提高生產力。這樣的好處在與，對於員工依賴性小，只需要短期培訓就能上流水線。公司更希望締造管理者聯盟在管理者之間存在深層次的交互滲透。
對於小公司而言，考慮的是時間成本和人力成本，如果前後端不分離，那麼意味著溝通成本小，在對於細分部分要求不是那麼嚴格，要求快速成型的前提下，一個人能頂多個，公司寧願多付一部分成本來請這樣的人去快速推進產品節奏。對於創業公司，時間也是不小的成本。
在工程師的角度出發工程師團隊有兩種類型工程師：工程師類型和科學家類型
工程師類型，在他們眼中一切皆工具，能快速實現和為工程服務，他們的技能是追求橫向的，一切皆我所用。能快速實現，用可以掌握的技術解決工程問題。這樣的人，無所謂前後端了，全棧或者是爆棧。如果這類人，願意跟隨公司業務一起成長，擅長解決遇到各種技術問題，所以在他們眼裡無所謂前後端。
科學家類型，在他們眼中更像是清教徒，做技術就要做到極致，追求更深入研究和細節。用什麼東西喜歡研究透。這種工程師會在縱向細分領域研究很深入。這些人傾向於做細分領域也就是前後端分離傾向。
科學家類型像學術方向，工程師類型像應用方向，沒有誰絕對好或者不好。
其實我弱弱地說一句，高票答案里說的因為我們product都是full stack所以沒有前後端分離的概念，這個觀點本身是有問題的。前後端分離是從實現上去談，跟你是不是一個人在做開發並沒有必然關係，也沒有衝突。
full stack一樣可以在開發時用前後端分離的方式去構建你的工程，從大的來看，這是一個工程，從小的來看，它是由前端界面與後端數據兩部分組建起來的工程。不管你是什麼構建方式，界面與數據怎麼交互怎麼獲取，這兩部分的開發方式都不可能「差不多」，而我想說的是「差很多」。
所以並不是full stack就沒有前後端分離，前後端分離並不一定就是兩個人或一堆人，關鍵在於你的開發方式，是否有意識地脫離後端數據單獨進行界面開發，以及脫離界面單獨寫後端，你是否思考過先單獨完成兩者中的一個？如果有，那麼你即將要面對前後端分離的問題了。
聯調可能沒有對應的英文翻譯，但是這仍然是開發中經常或者一定會做的事情，即便是前後端沒分離，你總該要輸出數據到頁面吧，你總該看看輸出的內容是否符合預期吧，這就是聯調，打通服務端和客戶端，達到預期，同樣的，這事一個人也可以做。
好吧，回到問題本身，前後端分離的意義大嗎？大部分情況來說，意義是很大的，舉個例子來說，讓你接手一個項目，假如你是一個前端，你希望拿到的是一個命令行里輸入npm run dev就可以開始開發的項目呢，還是一個需要先折騰java開發環境，導入資料庫，啟動tomcat然後跑起來的項目？或者，你希望是你修改html即時生效，還是修改完jsp重啟服務再看效果？
前後端分離的關鍵在於，如何不依賴彼此單獨地進行開發和調試，這樣做在前後端分別由不同人負責的時候優勢更加明顯，大家可以同步進行，縮短開發周期。前端可以做靜態頁面，當然也可以自己mock數據餵給自己；後端只寫輸出json的api。最後將兩者整合，前端用代理後端介面到本地的方式，取代原本mock的方式，對理解有差異的地方進行調整磋商，即聯調。
分離的優點很明顯，那就是更好地分工，對於多人來說，專業的人做專業的事；對於單獨開發者來說，關注點分離，一段時間裡只專註一件事。
缺點也不少，像大家說的，聯調是一大問難題，前後端分別動工之前，是否先過一遍需求，大家先確定一下介面以及介面格式，這些都是預先要花很多時間準備的，再加上前後端的思考問題或者解決問題的方式可能不太一樣，前端希望你能提供這種格式的json，你那樣我用起來太麻煩，但是後端認為你要的那種我操作起來麻煩，而且耗性能，這是由於大家關注點不同。
當然這個缺點是針對多人來說的，如果前後端都是你記幾，那你肯定不能跟自己吵起來。當然你自己埋的坑就自己默默刪了重寫這事就過了。
我總結的不全，只是簡單提一下，其實缺點還挺多的，主要集中在前端，你想想，寫mock api花不花時間？怎麼集成mock server？cookie怎麼造？怎麼proxy一些有限制的api（如防爬蟲、https、域名限制）？等等問題，還有很多，不過都有解決方法，只要你肯耐心折騰。但是一般情況下你的處境也不會出站這麼多限制，所以這些缺點你不一定都會遇到。
贊同徐飛 的回答，對於內容展示型的網站，基於ajax本身並不是很理想的解決方案。
內容展示型網站，就目前來說，目前仍然只有服務端渲染的方案是最優的，即使google現在可以做到動態執行頁面js並索引之，但在可以預見的將來，恐怕服務端渲染仍然是唯一的選項。
徐飛 在他的回答中也提到了，我們首先有一個共識，模板的責任人必須，也只能是前端工程師，他們對最終的視覺效果負責，因此他們也就天然的對模板擁有全權，這裡的矛盾就是，這個模板是在服務端渲染的，後端工程師天然的對模板有更大的控制力，但業務上，如前所述，前端需要足夠的許可權來更好的進行視覺和交互設計。
阿里的midway算是一個不錯的嘗試，同時，我們也有個不錯的嘗試，我在別的回答中詳細的說明過，這裡就不貼spam了，下面給出鏈接，可供參考：
前端開發 與後台開發 如何協作？ - 小豬的回答在校學生，目前實踐過的前後端分離是在今年的一門Web課的期末組隊Project上，和三個室友一起組的隊，寫了一半中間因為另一個人的隊友不幹活加了他，所以總共4.5個人用了四天五夜寫完了一個完整的單頁面Web應用（事實是開發過程中加了一個人讓我們更蛋疼了）。本答案僅僅只是我在自己當前經歷的基礎下，介紹我所認識的前後端分離。
這個項目後端邏輯比較簡單，而前端的界面比較複雜，所以分工是我負責後端，其餘四個寫前端。
前後端的交互通過Ajax發送HTTP請求，後端提供一系列完成特定功能的API，前端通過Ajax發送HTTP請求到對應的Url，數據通過雙方規定好的Json格式傳輸。
第一個晚上學技術＋分需求。後端用的是Spring Boot配置下的Spring + Spring Web MVC+ Hibernate框架，花了一晚上把環境搭好，寫了個簡單的前後端交互的demo，然後組裡面所有人過了一遍。前端組學了一發AngularJS怎麼弄前端的頁面跳轉，第一個晚上確定好技術的選擇以及任務的細分。
隨後的開發流程前端和後端獨立進行，後端根據需求文檔確定API並實現，等待前端完成對應的頁面然後把代碼整合一下測試。
因為後端比較簡單所以我寫的很快，基本上都在督促室友少偷懶多幹活趕快提交代碼測我寫好的API（後端代碼的功能測試我是通過自己發HTTP請求到對應的URL測試，然後再與前端整合測試，所以出了問題首先把鍋往室友頭上甩）。
中間室友有實習第一天一定要過去的，有去考托福的，有熬夜看巴薩踢皇馬的，還有個被爹媽喊去北京看天安門升旗的。就這樣我們還是在deadline之前寫完了Project的所有功能點＋附加分，所以我覺得這就是前後端分離的意義，讓開發效率大大大大大大的提高。
還是放一發github吧，https://github.com/ultra7677/ADWebPJ分離當然是好的，但這僅僅是在源代碼的文件結構上分的。但是對於程序員來講，他需要做的是一個完整的scenario，並不是前端或者後端。一個功能，如果前後端都要改，那就都改。所以前端也是這群人做，後端也是這群人做。當然了，團隊裡面出個前端還是後端的專家給人問問題這是好的，但這並不代表他的工作就是只寫前端或者只寫後端。
項目從一開始就應該具有空的前端和後端程序，但是他們已經互相連接了。千萬不要搞什麼寫完再聯調的事情，這跟幾十萬行代碼打完了才開始編譯調試有什麼區別。
對效率沒意義 全通過rest api本身就是扯淡。
意義僅在於實現動態效果。
高效率的做法不然是以前重後端的做法，不然是未來重前端的做法。
說分工快的根本對web開發沒有概念。
前後端遵循一套脆弱的約定，導致集成測試 / 重構變得無比困難，這也是導致開發人員拒絕更多PM需求，導致產品迭代不暢的重要因素之一。
作為後端開發，不用再去學更新賊快的js了，沒了
推薦閱讀：