libook
2017-07-03 16:33:41 +08:00
个人不认为纯前端渲染就一定是只为了高逼格，任何技术的选型都是要综合考虑的，而不是凭借书本上或者老师的一句话。
通常会在以下几个方面考虑：
网站业务特点：网站是更适合纯前端渲染还是更适合非纯前端渲染？
开发成本：使用纯前端渲染技术和非纯前端渲染技术的成本差距有多大？
风险：纯前端渲染和非纯前端渲染在网站可靠性方面的差距有多少？是否有额外的产品设计可以保证在有问题的情况下正常提供核心功能或者引导解决问题？
运营成本：使用纯前端渲染和非前端渲染，在网站的运营成本上有多大差距？
人力资源：目前有限的开发人力资源是适合纯前端渲染还是非纯前端渲染？
技术发展趋势：目前网站技术的发展趋势是纯前端渲染还是非纯前端渲染？趋势是否已经成熟？
我司（不是知乎）选择纯前端渲染架构是因为：
网站业务特点：我们的网站的业务是以内容展示为核心，UI 有大量复杂的交互功能，而且并不是每次操作都需要重新渲染整个页面，只对页面中的特定元素做变化处理，而且也没有很多的敏感业务逻辑必须要隐藏在服务器端，所以我们的网站是更适合纯前端渲染的。
开发成本：有很多现成的纯前端渲染框架可以使用，不需要开发者关心前端渲染本身，只需要关心交互方式、视觉样式和数据流，极大地缩短了开发时间。
风险：我们使用的 React 只兼容 IE9 及以上版本的“旧浏览器”和所有的“现代浏览器”，截止到 2017 年 6 月，IE 整体的占比已经下跌到 9%，而其中 IE9 以下的版本占 IE 总量的 49%，也就是浏览器市场总量的 4.4%，加点余地的话差不多有 5%的网民是排除在 React 之外，假设我们的用户是在网民中均匀分布的，那么就会有 5%的用户不能正常使用我们的网站，但若为这 5%的用户做兼容的话可能要多花费 50%的开发成本，所以即便有 5%的不兼容也算是性价比较高的方案，同时会有辅助方案如页面发现兼容性问题即引导用户安装现代浏览器或使用 PC 版客户端，可以进一步削弱对这 5%用户的影响。React 本身有世界顶级软件公司的支持，技术水平和质量把控要远远超过我司这种小公司，所以在这方面无论是用前端渲染框架还是服务端渲染框架都是差不多的，毕竟服务端渲染出 Bug 也不能保证前端不是空白的，容灾设计无论在前端还是后端都是要有设计的。
运营成本：纯前端渲染的时候，渲染压力被转移到了前端浏览器上，服务端只需要关心核心的业务逻辑，不需要关心 UI，节省了大量服务器计算资源；用 AJAX 等技术可以有效减少数据的传输量，节省昂贵的带宽费用；前端除了 index.html 以外全部托管在 CDN 上，任何地区的任何量级的用户都能流畅加载前端页面，而且 CDN 的流量费用比服务器的流量费用比起来简直就是白菜价。
人力资源：我司所有前端开发都有纯前端渲染架构开发的经验，所以采用纯前端渲染的架构方案是没有问题的，反而服务端渲染架构的话多多少少需要服务端开发人力的介入，两端工作有一定程度相互耦合，项目可能会互相牵制。
技术发展趋势：这个就不多说了吧，看一看纯前端渲染相关技术栈在国内外受到关注的上升速度，就大概了解了。React 已经是第二代真正意义上的前端框架了，此类技术已经完全成熟。而且我前两个月招实习的时候发现绝大多数的投简历的实习生都自学过至少一种前端框架，而像 Ract 这样的前端框架，正是纯前端渲染架构的基础。
综上所述，我司决定使用纯前端渲染的架构设计。
具体情况具体分析，我司的情况并不一定适应于所有其他公司，但思路可以作为参考。
软件工程没有银弹；没有最好的方案，只有最适合的方案。