前后端渲染之争
在16年甚至更早时期，所有的网站都是使用ASP、JSP、PHP等这种后端做渲染，后来随着JQuery、Angular、React、Vue等JS框架的崛起，开始转向了前端渲染，以及中间增加了同构渲染
后端渲染：传统的ASP、JSP、PHP的渲染机制
同构渲染：前后端共用JS，首次渲染时使用Node.js来渲染出HTML。一般来说同构渲染是介于前后端中的共有部分
前端渲染: 使用 JS 来渲染页面大部分内容，代表作是现在流行的SPA单页面应用
前后端渲染比较
同构渲染的优点
- 有助于SEO 首先确定你的应用是否都要做 SEO，如果是一个后台应用，那么只要首页做一些静态内容宣导就可以了。如果是内容型的网站，那么可以考虑专门做一些页面给搜索引擎
- 共用前端代码 其实同构并没有节省前端的开发量，只是把一部分前端代码拿到服务端执行。而且为了同构还要处处兼容 Node.js 不同的执行环境。有额外成本
- 提高首屏性能
同构渲染的缺点
性能
- 把原来放在几百万浏览器端的工作拿过来给你几台服务器做，这还是花挺多计算力的。尤其是涉及到图表类需要大量计算的场景
- 浏览器是一个天生的分布式缓存系统，
不容忽视的服务器端和浏览器环境差异
前端代码在编写时并没有过多的考虑后端渲染的情景，因此各种 BOM 对象和 DOM API 都是拿来即用。这从客观层面也增加了同构渲染的难度。会遇到以下几个问题
- document等对象找不到的问题
- DOM计算报错的问题
- 前端渲染和服务端渲染内容不一致的问题
内存溢出
前端代码由于浏览器环境刷新一遍内存重置的天然优势，对内存溢出的风险并没有考虑充分
异步操作
前端可以做非常复杂的请求合并和延迟处理，但为了同构，所有这些请求都在预先拿到结果才会渲染。而往往这些请求是有很多依赖条件的，很难调和