1樓：
國內的前後端分工是有歷史原因的，早期有一批前端就是寫html，切圖，頂多來點jquery，這些後端選手做不來，做了也不符合設計師或產品要求，來來回回很麻煩，所以還不如專職找乙個專注於介面展示這一塊的，後來前端發展越來越深，就脫離了這個概念成為了純的工程師，現在各類ui庫也很盛行，對設計的要求就沒那麼高了。
2樓：驀然不回首
1. 有利於服務化和被整合。沒有前後端分離的情況下，系統的能力是比較難於被其他系統整合和使用的，或者需要額外的開發去暴露api介面。
前後端分離之後，幾乎所有頁面操作能夠完成的功能，都天然可以被其他系統通過呼叫api的方式來完成，這一點對於平台化非常重要
2. 有利於自動化整合測試。前後端分離，對於寫自動化測試指令碼的測試工程師非常友好和高效，而且更容易覆蓋所有的業務
3. 有利於專業的人做專業的事。前端工程師終於不用去關心jsp，velocity等後端技術了，跟後端工程師的互動也只需要專注於介面和資料結構
4. 不要混淆前後端分離和動靜分離
5. 不要混淆前後端分離和前後端人員分離
3樓：AlexanderChiuMungZit
你學程式設計的時候，天天掛嘴邊的是什麼來著？
沒錯，就是團戰可以輸，提莫……打錯了。低耦合，高內聚。
前後端分離就是低耦合，高內聚。
4樓：
不是分工的意義大，是架構的意義大。
伺服器端只要準備資料，不需要再把資料組合進模板形成html，少一步則快一點。
反回的是json比html內容少很多，網路傳輸過程中少傳一點也就快一點。
伺服器端也不用維護那麼多使用者的登入資訊啥的，只要通過jwt之類的把好關就夠了，省資源。
所以這樣的架構能有效降低伺服器的負荷，提高伺服器的效能。
這種架構已不算是BS架構了，應當算CS。
5樓：個人資料已顯示
淺薄如我覺得，大。好吧，前面的dalao們都說大了，我要是說小豈不是鋼筋了。
哈哈哈，我個人看法就是，且不只單說前後端分離，能夠降低軟體或者系統功能的耦合度的開發模式都是應該支援的。牽一髮而動全身可是很恐怖的。
6樓：陽叔
未使用前後端分離的開發流程：
使用前後端分離的整個開發流程：
應用前後端分離後的一些感想：
前後端邏輯不一樣前端是ui ux 後端是服務在約定好資料結構之後前端可以通過做mock資料進行get post等一系列操作提高效率。不管是不是SPA都可以應用前後端分離、
能節省一點除錯介面時間，之前用react 的UI框架antd 資料結構不對除錯的時候還能取到值真是坑死
前端：負責View和Controller層。後端：負責Model層，業務處理/資料等
如果前端掌握了Controller，完全是需求決定使用方式：
可以做url design，
根據場景決定在服務端同步渲染，
還是根據view層資料輸出json資料，
根據表現層需求很容易的做Bigpipe,Comet,Socket等等；
7樓：劉穎
隨著各種終端的出現，傳統的web開發模式也帶來了一些問題，比如如何提高使用者的體驗、優化頁面載入速度，這些問題帶來的結果就是實現「前後端分離」，通常會針對不同的終端定製不同的版本，所以我認為前後端分離的意義很大。
前後端分離，使得前後端能夠各司其職，後端更注重於服務的提供，而前端更注重服務的使用，前端通過JS可以做非常多的資料處理工作，所以一定程度上也能夠降低伺服器的壓力；後端的處理異常也不用直接反映到前端，通常分離可將異常處理變得更友好，比如以炫麗的頁面效果展示錯誤訊息。
隨著技術的發展，前後端技術的差異性也日異明顯，如果仍然以傳統web開發模式來實現，短時間也不能確保公司員工都能精通全棧開發，進行前後端分離，後端更注重的是服務提供，而不用考慮前端的終端情況，至於如何布局，如何實現資料渲染展示交由前端完成，分工更明確，減少了前後端的耦合，降低了合作難度。
因為前後端技術及性質的差異性，所以我們要做分離，但分離後如何實現前後端的互動，如何才能使互動更加簡單，這是分離後需要考慮的問題。
前後端分離後，通常前端通過AJAX技術非同步請求後端資源，後端通過JSON返回響應資料交由前端處理資料邏輯。原來我們使用XML來實現前後端資料互動，但XML解析比較繁瑣，資料傳輸冗餘較大，所以採用了更方便的JSON格式，其實不管是XML還是JSON，都僅僅是資料儲存和傳輸的一種格式，作用上是一致的，用以保證能實現互動。
傳統web開發，有各種工程化構建工具可以使用，現在對於前端來說，也有非常多優秀的構建工具，Grunt、Gulp、Webpack、Fis3等，前後端分離後，各端可更專注自己端的業務，利用工程化構建工具優化開發也更方便。
所以，我認為前後端分離實際意義重大，通過現在前端的發展也可以看出，和使用者天天見面的介面內容就交由前端去處理吧，業務資料服務功能就交由後端去完成，大家各司其職又相互協作。
8樓：站長魏星
大家都提到了許多，其實有一點是因為，前端檔案對接好後端以後，修改更新起來就不是太方便了。而且因為大公司的策略，一般更新的話前端是沒有後端檔案的svn許可權的。
你可能只是加個span，就得去後端那兜一圈。
所以索性資料全靠ajax來更新，
這樣你後端資料寫好以後，前端檔案更新再也不用麻煩後端了
9樓：伊撒爾
樓上已經說的很明確了……其實估計他們的長篇大論你也不會看……可以看看我寫的這篇直白的文章：
其實總結起來就是，前端以前不分離的話，前端幹得活少，薪資漲不上去不說，還沒發裝逼……
然後前端人員都不是傻子……為了裝逼（或者漲薪）也要多幹點活呀2333以上……不接受反駁
10樓：啊波
分離的意義，在於重用性和可維護性的提高。
反過來說，只有帶著高重用和提高可維護的思想去分離，才有意義
什麼?你只想快?php,jsp出門不送
11樓：
應該意義挺大吧，至少各做各的，前端不會把後端架構搞得亂糟糟，後端不會把前端做的醜醜的。
但是這樣帶來的是對前端人員要求的提高，整體架構的複雜度。從長遠來看前期付出的複雜度其實並不大，但後期帶來的好處顯而易見。
這種模式生活中挺常見不是麼。
發現現在的軟體架構其實在生活中都能找到影子。而且從小做到大，同一類事情的架構都會發展成必然的樣子，只是各家叫法概念不同罷了。
12樓：墨明棋妙
分業務場景比如後台管理系統不需要seo 分離是最好的如果是電商比如某寶的商品頁需要seo 這種場景是一定要用後台模板引擎渲染的所以就不應該前後端分離
13樓：前端老夫子
這個問題需要分開了看；在某些專案類別上，適合使用前後分離的模式，有些專案就不能使用前後分離；
第一類專案是前後分離，前端無法把握業務流程的；
第二類專案是以前沒有做分離，後來改成分離，剝離成本高的；
這兩類專案是不建議做前後分離。
第一類專案，是因為分離後，前端的體驗有點差，例如：某電商系統中的本地資料和後端的資料，無法做到一致，需要極其精準的校驗，依賴後台的加密，不傳輸原始資料；
第二類專案，是因為，以前的東西邏輯侵雜嚴重；大部分業務邏輯放在前端，使用純前端無法實現的複雜邏輯；
14樓：JiangNan
前後端分離的實現方式多種多樣。對於中小型公司而言，通過前端工程化的形式去做前後端分離既提高了運維成本，也帶來了更多的風險，個人感覺對於小公司而言是沒有必要去這麼做的。
採用開發模式上的前後端分離開發，提供工具(mock,sdk等)支援前端開發解除對後端的強依賴性，上線前將前後端整合發布。無論你是spa、mpa，不管你是前端模板、還是後端模板，只要和後端約定好，都不會有什麼大的影響。
15樓：SaveeeSaveee
如果回頭看看，Web是在螺旋形的發展，從一開始的純伺服器端生成頁面，前端只負責展示和簡單的表單互動。 到後來的前後端分離，後端只負責提供資料，前端負責路由/互動/渲染。再到現在的全端渲染（初始頁面在伺服器端生成，後續頁面在前端生成）。
Web的每一次發展實際上都是在解決當時的網頁應用難題，
16樓：lu sidney
還是那句老話，天下大勢，合久必分，分久必合，都是給AugurJs害的，反正我用過2次就沒用了，我不是前端，也不靠這個吃飯，我的需求只是做很簡單的頁面，所以jquery + php足以，最簡單的前端就是最簡單的包，或者自己寫就好了，當然前端JS寫多分一些模組還是需要的，你要說意義嘛，js 分乙個nodejs出來我倒覺得合理，語言發展，擴充套件的必然，augurjs的出現和被應用真的毫無合理的地方，曾經也迷過google，現在發現不過如此。。。。。。
17樓：墨斗
意義很大。
從經濟價值層面考慮，套用亞當斯密的話：
前後端分工能提高勞動的熟練程度；
前後端分工使每個人專門從事某項作業，可以節省與其生產沒有直接關係的時間；
前後端分工有利於發明創造和改進工具
從架構層面考慮：前後端分離也有助於控制系統的複雜度。注意是控制而不是降低！
也就是說即便可能因為這個控制行為、導致了整體複雜度的公升高、但系統的每乙個模組都變的更清晰、更利於理解了。我認為這個投入值得的！
從技術層面考慮：前端後端事實上就是兩個技術領域，無論他們應用的語言、框架還是他們關注和處理的問題基本上也都完全不同。硬是讓乙個程式設計師關心所有問題、證明架構師沒能力。
當然 @Cat Chen 說facebook 這種情況是乙個特別的例子。人家早就過了談前後端分離這種問題的階段。 product + infrastructure 是乙個更高階的架構方式，做infrastructure也必然有專注前端Team、專注後端的Team。
這就好比工廠裡小工發明了新工具、但完善工具的人卻是物理學家。但如果你的工廠裡連專注某個領域的專業工人都沒有，就去學人家有物理學家的團隊不是很搞笑的麼？
18樓：暗滅
意義很大~
前端就是在前後端分離之後，身份才提上來的。
之前前端就是很少做路由，所有的控制都是交給後端來做的。
除錯什麼的很麻煩。
後端專注於提供資料，更重要職責是維護系統架構的穩定，保證資料的安全。
前端人員專注於互動，快速響應UI的變化。
這本身就是兩套不同的訓練模式，而介面文件在這裡也格式的重要起來了~在之前沒有前後端分離的時代，很少有介面文件的說法，只有在Ajax的時候才會有一些，但是大部分都是JSP去提供跳轉資料。
再乙個，可以統一給Android和IOS和WEB提供統一的介面了。
之前總是在頭疼，同樣的業務邏輯，可能要寫很多遍，不同的終端可能面向不同的WEB程式。
從分工上來講，變的更明確了~
唯一不好的地方就是SEO，頭疼。
web前後端分離的web專案如何灰度發布？
網易數帆 先針對幾個疑問，發表一下自己的觀點，web專案的灰度應該是各種專案灰度裡面比較容易實現的，按照你的例子，可以根據使用者的id按照一定演算法將部分使用者跳轉到新頁面上，而實現這個功能最簡單的技術就是nginx或者現在比較流行的envoy。這樣不僅可以選擇灰度的人群，也可以控制灰度的比例。這裡...
前後端分離就必須 SPA 嗎？
Exception.neko 你不清楚什麼叫前後端分離 前後端分離是指後端暴露資料介面，前端用ajax獲取後端的資料，然後經過js一系列的操作，展示給頁面 這跟SPA沒什麼關係，前端想怎麼搞都行 七分甘願 話說天下大勢，分久必合，合久必分。前後端分離這麼些年，現在微軟要借razor推blazor利用...
現在前後端分離趨勢下，後端還要學習前端嗎
小小虎 肯定得了解呀，不然後臺就不知道要給前端返什麼型別的資料，我之前就遇到過乙個後台，一點都不懂前端，什麼東西都讓前端做，返給前端的資料都不規範，本身很簡單的json資料，硬是給了一組4維，操作起來太tm麻煩了 已登出 不學client side沒關係，但是http你得學，cookie怎麼用你得知...