前端渲染和後端渲染，要說的都在這裡？
時下，前端 UI 設計越來越複雜，可謂“XX與XX齊飛，XX共XX一色”。
越來越複雜的 UI 意味著越來越重的 渲染工作。
目前通常有兩種選擇：伺服器渲染 與 客戶端渲染
筆者是支援客戶端渲染的（沒錯就是欽點的）
以 Jade, YAML 為代表的 模板渲染引擎 一般作用於 伺服器 作為 後端 的 檢視部分。
而使用 JavaScript 直接 處理 HTML DOM 則是 作用於前端，性質是客戶端執行渲染。
兩者在終端使用者看到的效果是一致的。
Web App 最終都還是要落實到HTML，CSS，JavaScript上才能體現到使用者介面上。
歸根結底，後端渲染是將一些模板規範語言翻譯成如上三種語言回傳給前端；而前端渲染則是將整個生成邏輯程式碼全部回傳前端，再由客戶端生成使用者介面。
為什麼會有伺服器渲染與客戶端渲染？
一開始，Web App 直接由若干 HTML，CSS， JS 組成，每一個頁面需要特殊的邏輯，因此隨著App規模的擴大，後端網站目錄下的程式碼檔案就越來越多，而且，彼此之間是沒有同步的，比如你改了站點的佈局風格。那麼你很可能需要改動成百上千的HTML檔案，這誰能忍?
聰明的工程師們想到，既然如此多的HTML具有一定的邏輯聯絡，何不使用程式碼生成程式碼？於是後端模板語言誕生了，這可是前端狗的一大痛點啊，於是人們開始廣泛使用模板語言代替手寫HTML。我認為，模板語言的成功源於它成功地減少了前端工程師的工作量。
後端模板渲染的思路應該是源自“如何管理數以千計的儲存於後端的前端頁面的版本一致？”
可能，當時工程師們沒有考慮前端渲染的一大原因是 以JavaScript為代表的前端技術 尚未崛起。現在H5，CSS3，JS 受到越來越廣的普及使得前端的可作為性大大提升，特別是在Node.js出現以後 JS 工程師 維護後端的成本大大降低。
編寫本文時 尚不考慮 當時普及度不高的 ES6，儘管它具有更多有用的特性
在一些jQuery使用者的角度看來，JS生成前端無非就是這樣的
var e = document.createElement('div' - 1
- 2
- 1
- 2
你需要先把DOM生成，然後再插入到其他的DOM裡去。
純JS處理DOM確實是一件麻煩事，這可能也是客戶端渲染遲遲沒有發展起來的原因之一。
考慮一下為什麼後端模板語言方便簡潔？ 因為它用了與HTML類似的語法。
在PHP，JSP頁面裡面你可以使用大量的HTML語法，只使用少量的變數注入與迭代注入。
使用HTML進行設計明顯比純JS更方便快捷並且直觀。
那麼可以借鑑地，解決客戶端渲染問題的最後一個錦囊就是引入模板，在這裡我們稱之為元件(Component)
。
對待模板，新興的Angular，React，Vue 意見不一，甚至他們對自己在Web App 的定位也不一樣。
具體情況可以自己去了解，這並不是本文的重點。
隨著前端也支援了模板語言，那麼以前的程式碼管理問題也解決了，以往的後端渲染引擎也大多有了基於JS的前端版本。
前後端真正解耦，前端將專注於UI，後端將專注於資料處理，兩端通過設計好的API進行互動，這會是一個趨勢，不管你信不信，反正我是這樣認為的。
從 後端渲染 到 前端渲染，發生了什麼變化？
-
計算任務轉移
原本由伺服器執行的渲染任務轉移給了客戶端，這在大量使用者訪問的時候大大減輕後端的壓力。讓後端專注做後端應該做的事情，效能將大大提高，因為伺服器做的事情確實減小了，而現在隨著客戶端軟硬體的發展，也能處理好大多數的渲染工作了。 -
放棄前端許可權
將整個UI邏輯交給客戶端以後，一些有經驗有能力的使用者可能會劫持UI，使得他們能夠看到一些不該看到的介面。這似乎違反了安全的原則。但是“一切在前端談安全1都是耍流氓”，後端不能輕信一切從前端傳來的資料，切記一定要做好過濾與驗證。只要使用SSL、遮蔽XSS、後端不出漏洞，想偽造身份劫持App還是難以做到的。
結語
比起後端渲染，前端渲染既能提升效能，又沒有無解的安全問題，何樂不為？
By the way, 安利一發React2，瞭解了很多React特性，會對UI的存在有一個更深刻的認識。
文章轉自http://blog.csdn.net/github_34219513/article/details/50831443
- 在前端存在一種名為XSS的攻擊，一般通過在頁面中插入script標籤來遠端執行程式碼。過濾script標籤等轉義可破被動XSS，另外可以通過提示使用者不在console使用未知程式碼來預防主動XSS攻擊。XSS攻擊是非常危險的，必須做好防範。 ↩