1樓：匿名使用者
>>前後端分離的意思是，前後端只通過 json 來交流...
同意其他幾位，json 只是一種可選的協議，而不是唯一，也未必是前後端通訊的最佳方案。
>>元件化、工程化不需要依賴後端去實現...有哪些好處或弊端？
前端的元件化、工程化，js 等**越來越胖，有點類似於過去 c/s 時代的 fat client。所以這個問題相當於，計算是主要放在 client 好，還是 server 好？
fat client 好，還是 thin client 好，取決於所開發應用、產品、系統的型別、規模和特點，其中一些權衡因素主要包括軟體複雜度、人機互動模型、網路頻寬、server 與 client 的處理能力等等。無所謂好壞，適合就好。
client-side mvc 確實是一個趨勢，web 架構設計上的一個創新。
web 前後端分離的意義大嗎
2樓：匿名使用者
這個說法是不合適的，打個比方，別人問的是「如何解決家禽把蛋生在水草邊的問題？」，但實際上人家養的是鴨子，答題的卻是養雞的，所以回答「不讓去水邊就行了」，這顯然不在點子上。
這兩年業界說的前後端分離，是限於偏展示類的系統（用a代替），而不是應用、管控類web專案（用b代替），在b類專案裡，前後端是天然分離的，對此，除了
少部分後端開發人員，基本所有人的認識都是一致的。上一段中這樣回答的人一般都是隻做b類專案，在b類專案裡，前後端分離是共識，不需要討論。
那麼，剩下的問題就是討論a類專案的前後端分離了。這個問題的核心在什麼地方呢，在於模板的與資料結合的位置，以及，模板的控制權在誰手裡。經過這兩年的討論，基本上我們可以達成的共識就是：
模板應當由前端人員去控制，主要原因有兩方面：
- 效能優化（尤其是外部資源的管理與釋出，請求合併等等）
- 協作的順暢性（已形成模板的介面片段的返工等問題）
那麼，模板到底應該在什麼地方跟資料結合？
這個問題就比較折騰了，有部分人嘗試像b類專案那樣，使用js模板，然後在瀏覽器端執行，這是存在一些問題的，比如說seo不友好，首屏效能不夠，尤其對於首頁dom量很大的電商類**，差距很明顯。
所以我們還是得把主要的模板放在服務端來執行。在這個過程中，阿里作了一些嘗試，那就是引入node層，在這一層把模板與資料進行合成，然後瀏覽器拿到的就
是生成好的html了，但也不是所有html都是這麼生成好的，還是會有一些內容等到了瀏覽器之後，再用js去載入和生成。
所以這一定會是一個混合方案，同一個系統中存在兩種模板，一種在服務端執行，一種在瀏覽器中執行，互為補充。
web 前後端分離的意義大嗎
3樓：黑馬程式設計師
什麼是前後端分離？前後端分離說白了就是把前端和後端分成兩個工程，由不同的團隊負責開發，這樣從工程和職責的角度上都有分開，這樣，後端偏向於提供單純的api介面，前端就是呼叫api介面進行展示和業務呼叫。
這樣不僅將頁面渲染和業務邏輯從server剝離開來，將頁面渲染放給前端，甚至放給瀏覽器；將業務邏輯放給後臺專心搞業務，降低了他們之間的耦合性，而且從職責上進行了分明，更適合大專案和大團隊管理和開發。
web 前後端分離的意義大嗎
web前後端分離的意義大嗎 web前端開發好學嗎
4樓：嘩啦啦的三爺
前端還是比較好學的，一些標籤類的語言，js可能會涉及到一些邏輯方面的問題，其他都是頁面佈局排版方面的，個人推薦學習後端，發展更廣一點。
前後端不分離spa的意義大不大
web 前段和後端是什麼意思
web 前後端分離的意義大嗎
5樓：硪丨曖戀
簡單來說，對於原始的web開發模式，前後端分離的意義當然是非常大的，但是是不是要具體到：
前後端只通過 json 來交流，元件化、工程化不需要依賴後端去實現。
這個有待商榷，具體的實現方式多種多樣，前後端的解耦程度是否越大越好？這個不一定。web開發是一個很複雜的工程性的問題，前後端分離只是其中一個小問題，採用何種方案進行分離，在什麼層面/維度進行分離？
這些都是實踐中要根據具體情況去進行抉擇的事情。
最後回到問題
web 前後端分離的意義大嗎？1、該**前端變化遠比後端變化頻繁，則意義大。
2、該**尚處於原始開發模式，資料邏輯與表現邏輯混雜不清，則意義大。
3、該**前端團隊和後端團隊分屬兩個領導班子，技能點差異很大，則意義大。
4、該**前端效果絢麗/跨裝置相容要求高，則意義大。
web 前後端分離的意義大嗎
6樓：匿名使用者
對於前後端分離，認識上有個誤區，那就是很多人自稱：我們老早就分離了，全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類專案的元件化，我之前那個沒寫完的系列是關於它的，但經過最近一年多的思考，我又覺得需要再重新寫一篇東西了。感謝你的問題提醒了我，這就寫。
聯想中的安全晶片意義大嗎
tpm安全晶片 晶片級安全技術是目前最安全的系統保護措施之一。tpm truste platform.mokules,受信平臺模組 作為可信計算平臺的核心,實際上是一塊安裝在主機板上的含有密碼運算部件和儲存部件的系統晶片。它起到的作用則相當於一個 保險櫃 可以將安全 加密和密碼管理等重要的資訊,比如...
去非洲參加義工旅行,它的意義大嗎
義工旅行不光可以看景物 瞭解風俗 瞭解當地人的各種文化,更重要的是能通過公益服務,幫助到別人,站在不同人的角度去審視生活和世界。國內的這種機構偏旅遊的多,國際上的偏義工的多,你可以去找找看projects abroad的這型別專案,非洲的迦納 肯亞都有,都是義工類,不過週末不工作的時候可以自己去旅行...
組織微商團體旅遊的意義大嗎什麼旅行公司做得好
隨著時代的飛速發展,跨界融合已成為大趨勢,企業與旅遊產品 已融為一體,專業的 精專細的旅屬遊產品不僅讓微商團隊產生巨大愉悅感 集體榮譽感和歸屬感,同時給團隊巨大激勵和感召力,成為企業文化的重要載體和手段。而無限風光微商團體旅遊直銷會獎旅遊打破傳統旅遊的固定模式,將傳統意義上的旅行轉型提升到與微商 團...