什么是前端的同构渲染？

同构渲染是 15 年左右 React 火了一段时间后提出的概念（也差不多是《三体》那个时候），原文是 Isomorphic rendering，但是很快就有人驳斥不应该用 Isomorphic 这个词，而应该用 Universal Rendering。

可以看看四年前的讨论：https://medium.com/@ghengeveld/isomorphism-vs-universal-javascript-4b47fb481beb

不过 Universal 在中文中没有足够陌生化的对应词（普遍渲染？万能渲染？），而同构这个来源于群论的形容动词在中文语境中足够陌生，「同构渲染」也就一直在中文里沿用了下来。

所以我们现在讨论的其实是 Universal Rendering，Universal 指的就是到处都运行 JS，后端在 NodeJS 上运行一遍 JS 然后把运行结果「脱水休眠 dehydrate」，前端也运行一遍 JS 把后端传来的状态「浸泡复苏 hydrate 」。

除了中文语境中使用同构一词以外，当年的 Isomorphic-Universal 之争还留下了很多别的遗迹，比如 isomorphic-fetch 等库，至今仍保持着百万的周下载量，影响着无数的人。

Q. 前端的同构渲染指的是什么？

同构渲染简单来说就是一份代码，服务端先通过服务端渲染(server-side rendering，下称ssr)，生成html以及初始化数据，客户端拿到代码和初始化数据后，通过对html的dom进行patch和事件绑定对dom进行客户端激活(client-side hydration，下称csh)，这个整体的过程叫同构渲染。其实就是满足三个条件：1. 同一份代码 2. ssr 3. csh

Q. 这个和node.js作为bff中间件做接口的聚合什么区别？

bff中间件做的实际上是绞杀者模式，对接口进行对不同客户端的胶水层，实际上偏向于客户端数据处理。而不处理视图，bff作为后端的前端，跟ssr作为前端的后端还是有区别的，实际上你可以在同一个服务里边开展bff和ssr，但最好明确划分好代码

Q. 同构渲染和php,jsp的渲染有什么不同，同构渲染称得上ssr吗？

既然同构渲染就是一份代码ssr加csh，那么ssr部分本质上跟php，jsp也是一样，也就是模版引擎出来html字符串，但是同构要求能通过一份代码实现ssr，csh，同时服务端需要提供一份初始化数据以便csh，而且传统php，jsp不关注csh过程。这三点就是与传统ssr的区别

Q. 同构渲染也是node.js实现的吗？

同构渲染只能node实现了，因为同构需要同一份代码，且客户端局限性只能用js，那么服务端也只能js了。当然，这只是暂时的情况。暂时对于其他语言的方案一般就是调用node或者v8进行处理

Q. 那什么又是异构渲染？

很少这样说，但传统的jsp，php 加jq这种模式可以理解为异构渲染吧

Q. 同构渲染能解决首屏加载和seo的问题吗？

其实解决这两个问题，是ssr来解决的，csh解决的只是交互问题。既然文件已经交由服务端渲染完，展示的速度肯定是提升的(因为不需要等待客户端渲染)，同样seo蜘蛛一般是分析服务端出来的html的，那么没有ssr的spa客户端等同于无法seo(当然一些蜘蛛也会提供spa的方案)，同构包括ssr，当然可以解决seo的问题

但解决归解决，不一定能很好解决。毕竟这几个其实不是同样的问题。就像我个人觉得ssr来实现seo本身就是个伪需求，同理首屏加载问题也是。

seo其实还能通过预渲染或者通过ua判断让蜘蛛走headless chrome渲染来解决。另外首屏加载速度问题的解决方案就更多了。

比较前后端还是属于不同环境，同构考验开发人员对大局观的考虑，约束了特定环境的一些开发灵活性，同时也影响代码解耦。ssr抛开这两点好处，甚至没有找到任何优点。所以这是当前前后端同构不温不火的重要原因