1樓：du知道君
意義？怎麼叫意義呢，做一個專案來說，不是特別講究意義所在，更重要的是能否快速準確的實現客戶需求，web專案是否前後端分離並不影響你完成這個專案，只在於影響你這個專案的執行速度等等情況。
web 前後端分離三個最大的優點在於：
1：最大的好處就是前端js可以做很大部分的資料處理工作，對伺服器的壓力減小到最小
2：後臺錯誤不會直接反映到前臺，錯誤接秒較為友好3：由於後臺是很難去探知前臺頁面的分佈情況，而這又是js的強項，而js又是無法獨立和伺服器進行通訊的。
所以單單用後臺去控制整體頁面，又或者只靠js完成效果，都會難度加大，前後臺各盡其職可以最大程度的減少開發難度。
webpack開發傳統前後端不完全分離的website，可行麼
2樓：育知同創教育
先說結論：可以。
首先，我預設你要使用 webpack 的目的是實現模組化管理 js 的依賴關係。那麼我們之前就是這麼做的。
我們的技術路線是：
傳統**（後端模板，每個頁面寫一個 js 檔案）webpack（仍然使用後端模板，js 由gulp+webpack自動打包，每個頁面生成一個 js 檔案）
前後端分離（前端類似於單頁應用，前端模板，前端打包）所以在前後端不完全分離的時候，可以使用我們 2 的這種方式。
當然，更建議直接前後端分離。
純粹的前後端分離是必需的嗎
3樓：匿名使用者
對於前後端分離，認識上有個誤區，那就是很多人自稱：我們老早就分離了，全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類專案的元件化，我之前那個沒寫完的系列是關於它的，但經過最近一年多的思考，我又覺得需要再重新寫一篇東西了。感謝你的問題提醒了我，這就寫。
前後端分離開發是個什麼概念,跟我們用的框架有什麼不同啊
4樓：安徽新華電腦專修學院
就是後端給 api ，客戶端渲染。完全的前後端分離也是一步一步發展過來的。
什麼是前後端，有沒有前後端分離，還有如何區分mvc與前後端分離
5樓：du知道君
1>>前後端分離的意思是，前後端只通過 json 來交流...
同意其他幾位，json 只是一種可選的協專議，而不是唯屬一，也未必是前後端通訊的最佳方案。
2>>元件化、工程化不需要依賴後端去實現...有哪些好處或弊端？
前端的元件化、工程化，js 等**越來越胖，有點類似於過去 c/s 時代的 fat client。所以這個問題相當於，計算是主要放在 client 好，還是 server 好？
fat client 好，還是 thin client 好，取決於所開發應用、產品、系統的型別、規模和特點，其中一些權衡因素主要包括軟體複雜度、人機互動模型、網路頻寬、server 與 client 的處理能力等等。無所謂好壞，適合就好。
client-side mvc 確實是一個趨勢，web 架構設計上的一個創新。
web為什麼要前後端分離？優點是什麼？
6樓：星幣騎士
解耦，降低耦合度，而且前後端分離可以提升一些後端的開發效率。
7樓：騷年阿仔
以前的javaweb專案大多數都是java程式設計師又當爹又當媽，又搞前端，又搞後端。
隨著時代的發展，漸漸的許多大中小公司開始把前後端的界限分的越來越明確，前端工程師只管前端的事情，後端工程師只管後端的事情。正所謂術業有專攻，一個人如果什麼都會，那麼他畢竟什麼都不精。
大中型公司需要專業人才，小公司需要全才，但是對於個人職業發展來說，個人建議是分開。
想要了解具體的分析，請移步到黑馬程式設計師社群，裡面有很多很詳細豐富的內容。
前後端如何做到分離開發，最後再整合部署
8樓：匿名使用者
由於後端提供的介面方式可能多種多樣，同時開發人員在編寫node端**訪問這些介面的方式也有可能多種多樣。如果我們在介面訪問方式及使用上不做統一架構處理，則會帶來以下一些問題：
1. 每一個開發人員使用各自的**風格編寫介面訪問**，造成工程目錄及編碼風格混亂，維護相對困難。
2. 每一個開發人員編寫自己的mock資料方式，開發完畢之後，需要手工修改**移除mock。
3. 每一個開發人員為了實現介面的不同環境切換(日常，預發，線上)，可能各自維護了一些配置檔案。
4. 資料介面呼叫方式無法被各個業務model非常方便地複用。
5. 對於資料介面的描述約定散落在**的各個角落，有可能跟後端人員約定的介面文件不一致。
6. 整個專案分離開發之後，對於介面的聯調或者測試迴歸成本依然很高，需要涉及到每一個介面提供者和使用者。
9樓：齋昌冒堅
搜一下：前後端如何做到分離開發，最後再整合部署
vuespringboot前後端分離如何部署專案
最簡單辦法，vue編譯完後的檔案放到後端容器內 直接上 github vue和node前後端分離後怎麼對接 1.vue非常適合在移動端使用。2.vue當然有很易用的過渡系統過渡效果 vue.js 3.vue可以很方便地直接使用現有的一下元件，這個是最近釋出的vue bootstrap 元件vue s...
如何處理好前後端分離的api問題
對於前後端分離，認識上有個誤區，那就是很多人自稱 老早就分離了，全ajax，使用angular或者什麼什麼就可以了。這個說法是不合適的，打個比方，別人問的是 如何解決家禽把蛋生在水草邊的問題？但實際上人家養的是鴨子，答題的卻是養雞的，所以回答 不讓去水邊就行了 這顯然不在點子上。如何處理好前後端分離...
nodejs前後端分離時怎麼保證跨域
1 前後端分離的意思是，前後端只通過 json 來交流.同意其他幾位，json 只是一種可選的協議，而不是唯一，也未必是前後端通訊的最佳方案。2 元件化 工程化不需要依賴後端去實現.有哪些好處或弊端？前端的元件化 工程化，js 等 越來越胖，有點類似於過去 c s 時代的 fat client。所以...