渲染工作应该由谁完成？

时下，前端 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。我认为，模板语言的成功源于它成功地减少了前端工程师的工作量。

后端模板渲染的思路应该是源自“如何管理数以千计的存储于后端的前端页面的版本一致？”这个问题的。通过代码生成代码，本质上是编译，他们基于HTML等基础语言作了更高层次的抽象封装，增强了易用性。各种模板语言大同小异，但大多都有模板中的模板这样的性质来完成继承这样的面向对象特性。

可能，当时工程师们没有考虑前端渲染的一大原因是 以JavaScript为代表的前端技术 尚未崛起。现在H5，CSS3，JS 受到越来越广的普及使得前端的可作为性大大提升，特别是在Node.js出现以后 JS 工程师 维护后端的成本大大降低。

编写本文时 尚不考虑 当时普及度不高的 ES6，尽管它具有更多有用的特性

在一些jQuery用户的角度看来，JS生成前端无非就是这样的

var e = document.createElement('div');
$('#container').append(e);

你需要先把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的存在有一个更深刻的认识。