为本周的前端的框架选择做一个总结
change log:
初次写时,概念表达不太到位,再次翻阅不能起到快速回忆的目的,这里再次进行修改,删去原来的过程部分,增加CSR与SSR的技术内容。
背景
团队的前端同学们想探索一些新的框架,于是就跟他们一起做一些技术选择。
现有的前端框架分成server部分与browser部分,server中是一个node.js服务器,负责页面与路由的映射,根据路由导向不同的页面,渲染的交给了前端来完成,是一个React MPA 前端渲染的框架,设计是用的Material-UI库
发展观
随着这篇文章来梳理一下
-
html时代
http协议最早设计的是从服务器上获取静态的资源,其实也就是静态html
-
模板渲染
后来Java时代,可以通过模板,将数据渲染进模板,从而生成html发送给前端,在后来的CSR出现之间,我觉得可能也没有SSR的概念。
浏览器与服务端数据的交互通过表单来实现,浏览器将表达中的数据一次性通过表单提交,后代进行处理完成后可以再次渲染模板,然后将数据表达出来。
-
CSR(客户端侧渲染)
后来我觉得是ajax与virtual dom技术的出现,使浏览器渲染成为可能,一开始可能只是想做一点改变,感觉很平滑,后来干脆所有的dom都直接渲染,这就成成CSR
这个CSR从过程上看,浏览器先去获取一个空模板,然后再获取js文件进行virtual dom的渲染,这个过程浏览器上会有一瞬的白屏。
浏览器与服务端数据交互很多时候被ajax所替代,好处是比较灵活,不论是数据交互还是页面刷新,不好处容易被滥用,使通信的效率降低,后台服务压力上升。
-
SSR(服务侧渲染)-追加
模板渲染就是一种SSR,这里针对的主要的是React所以略有不同,SSR主要是将render的操作放在了后端来执行,将数据从API Server取来,然后直接通过render函数渲染到页面上,并将页面返回浏览器。这样浏览器也不用再获取js,自己来渲染。
不好处也比较明显,每次获取数据、渲染,对服务器的要求会比CSR高,不过模板时期也是这么玩的。另外响应感觉要比CSR慢一点。
这里要加一下看过next.js之后的感想,next.js是一个SSR的框架,它是一种MPA,提供的prefech与Dynamic Import等功能,在SSR方面做的更突出一些。
-
isomorphic(同构渲染)-修改
Isomorphic既是CSR也是SSR,它是服务器渲染一遍,浏览器也渲染一遍。
在一些实践中服务器渲染完初识界面之后就算完成任务,其余的渲染就靠浏览器来完成。这种同构渲染感觉更偏向CSR
想象中,SSR完成之后,通过AJAX获取数据,然后根据数据做一些render,这样的效果也会不错。这种通过感觉更偏向SSR
CSR与SSR
一些文章中将Isomophic也说成SSR
问题
上次根据研究,已经将一个同构的React同构框架搭建起来,期间跳过了很多的坑,采用create-react-app脚手架、Typescript、express、react-router、stylus等技术。但有还是两个问题其实没有解决:
-
服务端代码运行
原来的框架中,运行时将Ts写的服务端代码也编译成了js之后进行运行,但在这里没有成功,原因是,原来框架中客户端与服务端的代码完全隔离,但在同构渲染时,服务端要渲染,必须要引入React的组件,而这些组件通过webpack打包之后,里边的函数没法再被server侧导入。
处理这个问题时,要么全部将Ts都通过gulp-typescript来编译成js,要么直接使用Ts,而经过确认,定于使用了Ts直接运行的方式
-
stylus问题
这个延伸自上一个问题,由于CSS采用stylus,造成ts直接运行时,没办法转换其中的stylus模块,这个问题目前还没有找到。可能要退回到将Ts全部编译成js,然后用gulp-stylus来处理一下stylus的方式来实现,要是这样,感觉也有些不妥。