VUE-SSR方案和常规模板简单比较

柏舟   新冠4年 01-08

为什么要用SSR

我前端学习并不是很深入，CSS对于我太复杂了，所以使用element-ui。但是VUE工程打包后，体积达到900多KiB，网络传输500多KiB。再加上买的阿里云服务器很差，首次加载需要6秒，实在太慢。

使用SSR方案，可以加快首次加载的速度，而且可以不需要暴露json接口，提高安全性。此外，SSR可以很方便进行SEO优化，CSR只能返回一个空的html模板。

其它的编程语言SSR方案问题

SSR不一定要使用VUE-SSR，同样可以使用python的Django，Go的template，通过文本替换，完成html的渲染。但是，最大的问题是，html很难进行组件化。组件化的实现需要在组件里面import其它组件的，但这导致进行文本替换的时候很难递归执行。

这些语言的文本替换本质上是定义了一个DSL，或者说，在程序里面运行一个微型解释器，能够解释运行模板，动态加载其它模板。从这个角度思考，最理想的方案是使用ClojureScript。html本质上还是标记语言，无法编写运行逻辑，得益于Lisp强大的表达能力，ClojureScript既能够编写html页面，还能够编写渲染逻辑，抽象组件。

VUE-SSR

归根结底，其它语言编写html的最大问题还是表达能力不够，缺少组件化，只能用蹩脚的函数定义DSL进行文本替换。使用JavaSrcipt的最大优势还是JavaScript是原生的html编程语言，不存在DSL的问题。虽然有些API像Document，浏览器和node不能通用，但是共用的部分能够解决问题。

在调查VUE-SSR时，我发现最大的问题是SSR需要Vite这些工具。因为VUE的模板语法和.vue文件需要使用Vite进行打包才能够使用，这极大的增加了架构的复杂度。这个问题还是JavaScript的表达能力太弱了，导致VUE需要定义模板语法这样的DSL。如果放弃模板语法的写法，就只能选择编写js文件，一是无法使用组合式的方法编写，二是无法使用TypeScript。如果项目有混合SSR和CSR的需求，那么dist的client和server的js文件就比较复杂。像我这种没有打算系统学习前端和前端构建工具的人根本没有学习的欲望，而且只是一个博客，最大的问题也只是首次加载时间慢和没有SEO，也不是什么大的问题。除此之外，使用容器部署还需要使用npm下载依赖，没有500MB根本搞不定。

总的来说，前端还是缺少SSR和CSR通用的解决方案，SSR仍然需要Vite编译Vue文件和ts文件，CSR的SEO问题和首次加载问题很难解决。