作者:趙魏璇
鏈接:https://www.zhihu.com/question/28725977/answer/116177149
來源:知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權,非商業轉載請注明出處。
鏈接:https://www.zhihu.com/question/28725977/answer/116177149
來源:知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權,非商業轉載請注明出處。
作者:貘吃饃香
鏈接:https://www.zhihu.com/question/28725977/answer/41877597
區別在於以下幾點
實現:……這就不說了吧,不就是直接插內容或者DOM節點么。除非后端是直接吐出拼好的頁面,否則不關后端是通過接口吐的html字符串還是模板數據,怎么着不都得是通過這些玩意整頁面里去么。
好處:(興許是)靈活…… 還有因為一竿子捅到底了,直接使用(前端可控的)最終API,所以除了是后端直接吐的頁面外,這種方式是(相對)執行效率最高的……
壞處:各種字符串和DOM節點拼來拼去真的很煩……
鏈接:https://www.zhihu.com/question/28725977/answer/41877597
區別在於以下幾點
1、后端渲染
實現:后端拼字符串唄…… (理論上后端模板也是字符串)
好處:模板統一在后端。前端(相對)省事,不占用客戶端運算資源(解析模板),只要不大改結構,文字啥的小修改后端改了就好了。
壞處:占用(部分、少部分)服務器運算資源、,response 出的數據量會(稍)大點,模板改了前端的交互和樣式什么的一樣得跟着聯動修改。
2、前端模板
實現:看這個吧……關於模板引擎的工作方式和性能? - 前端開發 但不僅限於正則替換這一招,掃token 生成語法樹,再根據語法樹拼接也行,或者使用 DOM 模板,借助 DOM API 處理也行,反正招兒多了去了。
好處:不占用服務端運算資源(解析模板),模板在前端(很有可能僅部分在前端),改結構變交互都前端自己來了,改完自己調就行。不用麻煩后端再聯調神馬的。
壞處:占用(一部分、少部分)客戶端運算資源(解析模板)。前端代碼多點,畢竟包含模板代碼了么。腳本是不是首次下就慢點了(看你在意不在意這個畢竟能304和CDN啥的)。可能造成前后兩份模板的情況,總歸要后端吐出個首屏啥的先讓用戶看見吧。那這部分頁面模板不就是后端拼好了吐出來的么。
實現:……這就不說了吧,不就是直接插內容或者DOM節點么。除非后端是直接吐出拼好的頁面,否則不關后端是通過接口吐的html字符串還是模板數據,怎么着不都得是通過這些玩意整頁面里去么。
好處:(興許是)靈活…… 還有因為一竿子捅到底了,直接使用(前端可控的)最終API,所以除了是后端直接吐的頁面外,這種方式是(相對)執行效率最高的……
壞處:各種字符串和DOM節點拼來拼去真的很煩……
1.前端渲染是在客戶端完成字符串替換,后端渲染當然在服務器完成,這並不說明前端渲染下載的資源就一定比后端渲染要少,有時候需要下載的東西更多,比如多了模板語法,多了某一種模板js文件,你知道,一個頁面的性能的絕大部分還是取決於你下載的內容重量。
2.大部分人說前端渲染可以在客戶端生成代碼而無需下載,但是生成代碼也是非常耗時間的操作,同樣生成代碼也需要根據服務器返回的數據,還是需要等待數據下載完成才能着手生成代碼。
3.單頁面應用可以使用前端渲染,在性能不差的條件下能給服務器減少一點壓力,而且體驗也要好一點,但是除此之外,就要放棄一些東西,比如搜索引擎優化,關鍵字優化。
4.后台渲染還有一個非常明顯的優點,就是可能生成緩存片段,生成靜態化文件,這也可以減少數據庫查詢的性能,甚至減少渲染頁面的開銷,這對相對數據變化不大的頁面非常高效。這些如果在配合一款內存數據庫,真的可以非常高效的解決大部分問題
5.從可維護或者工程化來講,前端渲染更好維護,后端也省了很多工作,但是后端省的工作並不是不需要做,只是轉給了前端而已,前端這個時候可能需要維護倆套代碼,最后你會發現,本來應該相同的代碼最后不同了,這是因為某一天你偷個懶,直接更新了模板而沒有更新你的靜態文件。。。