为啥想写这篇文章呢？培养自己一个良好的学习习惯：多总结
再以一个参与者的角度，总结一下我们渲染模板的心酸路程。
使用Vue渲染模板
开发前期，为了快速开发，编辑器和渲染使用同一套代码。所以决定渲染也使用Vue！ SEO问题由后端单独写一个程序。
开发初步完成，测试环境下，主管发现这套方案行不通 原因如下:
- 百度等爬虫会对比爬虫抓到的和用户真实看到的，如果不一致百度就会认为这是在欺骗爬虫，百度会有处罚，不利于seo；
- 一些爬虫不会有指定的UA, 如微信 钉钉他们的爬虫就和正常人访问一样，这个时候就没办法区分爬虫和人了，就会出现微信和爬虫抓取不到数据的情况。
接着进入了渲染模板的第二次革命！
nuxt. js渲染
这个在编辑器开发的代码上 改动的很少，SEO也不需要单独一个程序，感觉没有什么缺点。
但是 当我们产品上线之后发现如下问题
1.nuxt性能问题
当用户做的网站非常复杂（节点上万个），打开时间就很慢，特别是在手机端，未缓存的情况下需要5s左右
性能消耗主要在以下两步骤：
- 执行render函数生成vnode-tree对象；
- 递归遍历vnode-tree将其转化拼接成HTML；
相比传统string-based模板以最直接的方式拼接HTML，逻辑包含了 with、call、对象创建、递归拼接 是制约性能的关键，由于vnode对象是包含了业务数据，不能通过缓存vnode来解决，即便是缓存了vnode，拼接耗时也是瓶颈所在。
2.源码不优雅
站点都是通过动态数据生成出来的，必需放在全局。导致用户（包括开发者我们）觉得数据过多，很不优雅。基于以上原因，我们进行了第三次的模板渲染革命。
nuxt js 性能问题可以查看一下文章：
实测Vue SSR的渲染性能：避开20倍耗时
How to Drastically Reduce Estimated Input Latency and Time to Interactive of SSR Vue.js Applications
基于Vue模板，用Golang，实现字符串拼接方式的渲染
后端使用的是Golang开发，作为一名前端开发者 并不是很了解其优缺点，但是技术主管决定使用Golang来实现服务端方式的渲染，解决nuxt. js的产生问题。作为参与者的我，也非常的期待，这一版的渲染。我主要负责前端js部分的编写。这部分就回到了最开始写静态页面的感觉，什么都是操作dom，没有很大的难点。
是的，由于人员紧张，任务繁重，大部分功能可以使用了。但是还有很多细节及一些组件的修改、搬运还在进行中。期待的小伙伴可以点击这个链接，查看新版本的渲染雏形：http://zhuzi.gray.node.cn.vc/
总结
参与了三次模板渲染的开发，从最开始连前端渲染与服务端渲染这些概念都不知道 到如今 有所了解 。坑也踩了不少，到最后我们实现了一个我们比较满意的渲染方案，还是非常开心的。2020年 希望跟着大佬继续学习，开心的写代码…
Last
如果阅读了该文章的小伙伴，对这个新版本的渲染感兴趣的话，可以去点击下面的链接，查看。
项目地址: https://github.com/bysir-zl/go-vue-ssr
有疑问加站长微信联系（非本文作者）
