常见渲染方式
- CSR (Client Side Rendering)：SPA单页应用常用，客户端 异步获取数据渲染页面的方式。
- SSR (Server Side Rendering)：在服务端获取数据生成html返回客户端的方式，html也可包含js文件，加载后获取数据二次渲染。
- SSG (Static Site Generation)：静态网站生成类似于服务器端渲染，不同之处在于您在构建时而不是在请求时渲染页面。
- CSR with Pre-rendering：预渲染原理是：一般在构建阶段的最后，在本地启动一个 Puppeteer 服务，访问配置了预渲染的路由，然后将 Puppeteer 中渲染的页面输出到 HTML 文件中打包，并建立路由对应的目录。
以此， 达到预渲染的目的。
什么是同构渲染
同构渲染是为了解决当下客户端渲染为主的组件式卡法模式下性能，白屏问题而提出的一种解决方案。强调服务端跟客户端公用一套代码。服务端负责渲染，客户端来负责交互。当然服务端渲染挂了，客户端也是可以渲染的。
客户端渲染 还是 同构渲染
可阅读文章： 精读前后端渲染之争
作者通过精读Here’s Why Client-side Rendering Won这篇文章，并收集近10位同仁的意见，对于同构渲染进行了总结并发表了自己的看法。
主要阐述了同构渲染在优化体验的同时也会带来一系列问题，并没有想象中的美好。作者认为还是应该选择客户端渲染的方案为主流，可以通过其他方式优化，或部分同构的方式来解决客户端渲染的性能问题。
同构渲染架构如何实现？
可阅读文章：一文吃透React SSR服务端渲染和同构原理。
作者为我们详细解答了：
- 为什么需要同构渲染？
- 实现同构渲染的核心原理是什么？
- 实现同构渲染有哪些技术难题？如何设计对应的解决方案和具体实现（ 在 React 提供的 SSR 能力的几个API的基础上）。
可行性和是否成熟先不谈，作者解决各种问题的思路值得学习。
我的看法
同构渲染固然是一种非常好的解决问题的思路，但是需要解决的技术难题非常多。推崇同构渲染的同仁可能会说，有问题解决问题便可，比如上述文章基本上给出了各种技术问题的解决方案。我个人也相对保守，崇尚kiss原则，我觉得在形成一套成熟的同构渲染技术方案（非常困难）的情况下，不宜推广全栈同构，可以部分同构。
我认为的成熟的同构方案至少满足以下两点：
- 解决同构渲染的各种技术难题，稳定且不存在很大的性能，兼容性等问题。
- 不能使得普通开发者的开发成本和维护成本大大增加。性能虽然重要，开发质量，可维护性也是相当重要的。
软件开发中遇到的所有问题，都可以通过增加一层抽象而得以解决。