後端渲染html、前端模板渲染html,jquery的html,各有什麼區別?

後端渲染html

前端angular、backbone模板引擎渲染

直接使用jquery的html,append等方法

在實現過程和效率上各有何區別?


瀉藥……

好大的題……

偶懶的說怎麼辦……

湊合叨逼幾句得了。

1、後端渲染

實現:後端拼字元串唄…… (理論上後端模板也是字元串)

好處:模板統一在後端。前端(相對)省事,不佔用客戶端運算資源(解析模板),只要不大改結構,文字啥的小修改後端改了就好了。

壞處:佔用(部分、少部分)伺服器運算資源、,response 出的數據量會(稍)大點,模板改了前端的交互和樣式什麼的一樣得跟著聯動修改。

2、前端模板

實現:看這個吧……關於模板引擎的工作方式和性能? - 前端開發 但不僅限於正則替換這一招,掃token 生成語法樹,再根據語法樹拼接也行,或者使用 DOM 模板,藉助 DOM API 處理也行,反正招兒多了去了。

好處:不佔用服務端運算資源(解析模板),模板在前端(很有可能僅部分在前端),改結構變交互都前端自己來了,改完自己調就行。不用麻煩後端再聯調神馬的。

壞處:佔用(一部分、少部分)客戶端運算資源(解析模板)。前端代碼多點,畢竟包含模板代碼了么。腳本是不是首次下就慢點了(看你在意不在意這個畢竟能304和CDN啥的)。可能造成前後兩份模板的情況,總歸要後端吐出個首屏啥的先讓用戶看見吧。那這部分頁面模板不就是後端拼好了吐出來的么。

3、jquery的html,append等方法(包括瀏覽器原生相關DOM API)

實現:……這就不說了吧,不就是直接插內容或者DOM節點么。除非後端是直接吐出拼好的頁面,否則不關後端是通過介面吐的html字元串還是模板數據,怎麼著不都得是通過這些玩意整頁面里去么。

好處:(興許是)靈活…… 還有因為一竿子捅到底了,直接使用(前端可控的)最終API,所以除了是後端直接吐的頁面外,這種方式是(相對)執行效率最高的……

壞處:各種字元串和DOM節點拼來拼去真的很煩……


區別在於以下幾點

1.前端渲染是在客戶端完成字元串替換,後端渲染當然在伺服器完成,這並不說明前端渲染下載的資源就一定比後端渲染要少,有時候需要下載的東西更多,比如多了模板語法,多了某一種模板js文件,你知道,一個頁面的性能的絕大部分還是取決於你下載的內容重量。

2.大部分人說前端渲染可以在客戶端生成代碼而無需下載,但是生成代碼也是非常耗時間的操作,同樣生成代碼也需要根據伺服器返回的數據,還是需要等待數據下載完成才能著手生成代碼。

3.單頁面應用可以使用前端渲染,在性能不差的條件下能給伺服器減少一點壓力,而且體驗也要好一點,但是除此之外,就要放棄一些東西,比如搜索引擎優化,關鍵字優化。

4.後台渲染還有一個非常明顯的優點,就是可能生成緩存片段,生成靜態化文件,這也可以減少資料庫查詢的性能,甚至減少渲染頁面的開銷,這對相對數據變化不大的頁面非常高效。這些如果在配合一款內存資料庫,真的可以非常高效的解決大部分問題

5.從可維護或者工程化來講,前端渲染更好維護,後端也省了很多工作,但是後端省的工作並不是不需要做,只是轉給了前端而已,前端這個時候可能需要維護倆套代碼,最後你會發現,本來應該相同的代碼最後不同了,這是因為某一天你偷個懶,直接更新了模板而沒有更新你的靜態文件。。。

還有很多,自己權衡,不說了


我覺得題主提到的這些技術可以分為兩類,分類的依據在於瀏覽器到底做了什麼事情

後端渲染HTML的情況下,瀏覽器會直接接收到經過伺服器計算之後的呈現給用戶的最終的HTML字元串,這裡的計算就是伺服器經過解析存放在伺服器端的模板文件來完成的,在這種情況下,瀏覽器只進行了HTML的解析,以及通過操作系統提供的操縱顯示器顯示內容的系統調用在顯示器上把HTML所代表的圖像顯示給用戶。

前端渲染就是指瀏覽器會從後端得到一些信息,這些信息或許是適用於題主所說的angularjs的模板文件,亦或是JSON等各種數據交換格式所包裝的數據,甚至是直接的合法的HTML字元串。這些形式都不重要,重要的是,將這些信息組織排列形成最終可讀的HTML字元串是由瀏覽器來完成的,在形成了HTML字元串之後,再進行顯示。

題主所提到的幾個技術,我認為模板這個詞語並不能用來區分這些技術的本質,模板只是一種提供給程序來解析的一種語法,換句話說,模板是用於從數據(變數)到實際的視覺表現(HTML代碼)這項工作的一種實現手段,而這種手段不論在前端還是後端都有應用。

以下為本人自己的想法:

在性能上,我認為後端渲染最終會被前端渲染,因為後端渲染將所有的HTML生成集中在了一個伺服器上,而前端渲染將這部分工作分發到各個終端上。

另外,對於開發而言,這樣能夠避免後端開發人員過多的編寫HTML代碼,後端開發人員只需和前端開發事先商定好數據格式,後端就只需將數據生成,用數據交換格式包裝,再發送出去就可以了,這樣能夠使開發人員之間的分工更加明確。


這個問題可以理解為伺服器端渲染和瀏覽器端渲染的區別。

本質

渲染的本質都是字元串的拼接,將數據渲染進一些固定格式的html代碼中形成最終的html展示在用戶頁面上。

性能

字元串的拼接必然會損耗一些性能資源。

如果在server端渲染,那麼消耗的就是server端的性能。所以用戶量達到一定程度後,後端會考慮緩存部分數據,避免消耗過多資源重複渲染一些對及時性要求並不高的地方以節約資源。例如常見的排行榜,可以將渲染後的模塊緩存起來,十分鐘更新一次。

如果是在客戶端(瀏覽器)渲染,常見的一些渲染手段比如使用mustache.js這類模板庫,以及Vue這類MV*庫/框架的模板功能。他們初次渲染的原理大多是將原html中的數據標記(例如{{text}})替換。當然像Vue這樣還提供了指令功能,這其中不可避免的會涉及到一些編譯原理的知識,path字元串的解析使用了狀態機等等。而原生DOM API更有點原始的味道,庫/框架渲染的實現也會用到這些API。一般來說只要不作死無腦用了document.write,瀏覽器端初次渲染的性能消耗都是可以接受的。

瀏覽器端渲染的難點在於數據變更後,頁面響應式變更時如何節省資源?要知道DOM直接讀寫的速度是很慢的,而且不小心還會觸發重繪,在複雜的SPA下直接讀寫DOM帶來的影響會很明顯。再拿Vue來舉例子,在數據變更後,Vue會幫你diff,沒有改變可以復用的部分是不會重新渲染一遍的。

SEO

browser端渲染是對搜索引擎不太友好的,雖然SPA怎麼做SEO已經有過無數討論和實踐,但是browser端很大程度是不如server端渲染容易做SEO。

維護

server端渲染很多時候前後端是一起完成的。有的團隊是前端開發人員直接寫模板文件,但是也有的團隊是前端寫了靜態html文件,後端改為模板。後一種團隊在維護時是比較蛋疼的,改個css都要前後端在一起搞定(不要笑,時至今日依然很多團隊在干著這種事)。

如何選擇

關於在server端還是在browser端渲染的選擇,更多的是要看業務場景。

例如一個注重SEO的新聞站點,非強交互的頁面,做成SPA意義並不大,還是建議server端渲染。

像後台管理頁面,或者是QQ空間這類強交互的網頁應用,可以嘗試瀏覽器端渲染。後端開發人員也能更加專註於介面服務的提供,不用去考慮頁面的渲染問題,分工合作更加愉快。

在瀏覽器端渲染時,如果數據量並不大,也沒有什麼大的改變,那麼自己用原生的DOM API去操作綽綽有餘了,即使有時候有些操作會浪費一些性能資源,影響也不會太大,反而引入了框架和庫卻只用了一部分功能是一種浪費。但是如果做一個複雜的頁面應用,我還是建議使用Vue這類庫/框架來幫你完成。一方面來說,他們會幫你把業務邏輯抽象,不讓你去關注渲染這些操作,可以提升開發效率;另一方面,恐怕大多數人自己實現渲染以及數據變更後的DOM變更未必會比庫/框架做得好。如果他能做的更好,一定要請他為主流框架/庫去提PR或者issues來幫助庫/框架做的更好;或者激進點,他自己寫一個框架造福大家吧。


其實我覺得題主的意思分成具體的情景可能是兩種:

① 頁面是PHP文件,是由&和&標籤混合嵌套而成,比如WordPress模板,這類情況是前端資源的載入在伺服器端就解析完成,這種方式就是後端承受的壓力大;

② 頁面沒有任何後端代碼嵌套,數據用ajax或者websocket請求,這種情況就是實現了前後端的完全分離。至於html結構,也分為用模板和動態操作DOM兩種情況,模板的原理主要是靠正則匹配替換,假設整個交互過程中,html結構沒有太大變化,那麼模板效率相對好些,如果需要頻繁動態地更新的html結構,必然要操作DOM,例如append()、html()、remove()、empty(),這種方法很靈活,但是DOM查找是件代價比較高的事,尤其如果在移動端性能就會下降。


簡單來說

後端渲染html 叫或者噴,機器人可以看到完整的呈現源碼

前端模板渲染html叫填,機器人看不到完整的呈現源碼


如果後端人員能力不強或對前端了解不夠,盡量少用後端渲染;

如果前端人員能力不強或者前端數據交互不是很複雜,盡量少用前端模版;

如果項目不是很大,想快速實現,用jquery;


1:後端渲染html

- 最原始傳統的方式,代表:Wordpress、Thinkphp、DedeCms、Discuz!(很多PHP應用)

2:前端渲染Html

- 較流行和現代化的方式,代表:Lumen/Express... 任何前後端分離的方式

區別:

前後端分離可以大大將服務端的壓力分散給客戶端,而客戶端的計算性能損耗幾乎是微乎其微,並且在開發流程上,效率也極大提升,也可以適應敏捷開發;至於SEO,服務端完全可以有針對搜索引擎的渲染解決方案,如Prerender - AngularJS SEO, BackboneJS SEO, or EmberJS SEO ,或者針對Spider UA再做渲染處理。

總之:

既然走在朝前的路上,就別再頻頻往後看。


都沒有人提到SEO么


題目太大,仔細講能講很多。而且題主你說的後兩種歸根結底其實是一個東西。

先說特點

後端渲染:相對模塊化,非常適用於偏向展示性的頁面,利於SEO。而且由於是在後端就已經渲染好,所以載入體驗相對好,在網速差的時候表現明顯。

前端渲染:比較靈活,適用於dom操作比較頻繁或者交互比較複雜的業務場景。可以很好地維護一份model,而不用反覆請求。理論上更符合前後端分離。

一點對比

有的答主說比前端渲染response的數據量要大,這個看你使用場景了,像有些很重的前端框架,載入其實並不比後台渲染輕鬆,移動端這個問題比較明顯。

事實上,絕大多數情況下,兩者同時用。。。。


題太大,回答一點兒.

所有的渲染最終瀏覽都是一個html頁面+js,差別就是在於後端渲染的很多都是會生成些冗餘的垃圾代碼(目前很對都是),前端比較好控制


推薦閱讀:

TAG:前端開發 | HTML | HTML5 | jQuery | AngularJS |