现在的服务端渲染和过去的服务端渲染完全是两码事。什么叫“又流行”?说明看问题太浅薄。
以前的服务器渲染,是以“文档”为核心思想。服务器端的逻辑是把HTML, CSS, Javascript当作一个静态文件,对“文档”而言不存在“指令”和“数据”的区别,一切都是数据。所以我们可以看到服务器渲染,GET就是请求一个文件,而web 1.0时代的诸多服务端框架最基础的组件之一就是文档模版,比如asp, JSP之类,核心设计理念就是HTML文件里放占位符然后由服务端逻辑替换成实际数据后一股脑返回。
现在划重点:Web 2.0时代最大的思想革命本质不是前后端分离,而是把网页当作独立的应用程序(app)。前后端分离只是实现这一新架构的必然结果。对程序而言指令和数据是分离的。HTTP GET拿到的不是渲染后的网页,而是一个由html和Javascript组成的app, 这个app以浏览器为虚拟机。装载和显示数据是app启动之后的运行逻辑。传统上app叫什么?叫Client,也就是前端。于是前后端就这么分离了,浏览器变成了app的运行环境,后端蜕化成了单纯的业务逻辑和数据接口。写Javascript不再是给网页添特效的小伎俩,而是正经的和写桌面应用程序一样的工程。于是我们看到了前端工程化,编译(转译),各种MVC/MVVM框架,依赖工具,等等。很新鲜吗?不新鲜,都是传统桌面开发玩剩下的。我很早就说过,前端NodeJS的那堆东西,什么npm,Babel,Webpack,gulp,各个框架的cli... 本质上就是开源社区东拼西凑做一个Visual Studio。
那么现在怎么叫“又流行”服务端渲染了?走老路吗?当然不可能,模版式的服务端编程早就进了垃圾堆。我们公司的后端实现甚至都不加载HTML模版引擎,进出的数据都是JSON(HTML/Javascript内容怎么办?单独编译,然后部署到S3上)现在的服务器渲染的目的只是为了加速和搜索引擎优化(准确的说是非Google引擎优化,因为Google可以解析Javascript动态网页)。而实现也很简单:拿个浏览器核心跑一下app然后把生成的html存起来给搜索爬虫就行了。与其说是渲染,不如说是“快照”,就像给app截图一样。
历史是螺旋上升的,有相似性但更重要的是进步。
技术不一样了,以前是用server语言拼字符串,局限性其实是很大的,比如说一不小心就会有XSS漏洞,比如说复杂的、反复层叠的结构实现起来会很不清晰。现在是用DOM生成,而且复用了前端的逻辑,实现了服务器端渲染的组件化。
但其实目标都是一样的,单页结构对SEO很不友好,这从发明出来第一天就是已经知道了的。所以其实服务器端渲染一直都是和客户端渲染并重的,现在只是多了一种服务器端渲染的技术而已。
其实倒不是说客户端渲染的问题,现在的搜索引擎大部分已经可以抓取(一部分)JS动态生成的内容了,只是单页结构就只能抓一页,通过交互操作显示出来的更多内容抓不到。
Javascript不是一门好语言,没有类,全局变量泛滥,变量作用域奇葩,很难做稳定的大型应用.这还不是最严重的,我学过C/C++PHPPYTHONRUBYOBJC,JS和其中任何一门都不像,函数回调大括号摞小括号让人心烦,不是不得已我避免写JS。最严重的前后端分离把开发效率减慢了。不差钱的大厂可以扑腾。小项目很致命。而且技术栈深,随便安装个东西塞几千个库进目录,一堆warn,看着心情极为不爽。依赖多,可定制差,写起代码很痛苦。这是我研究一个月vue react的感受。说实在的我没有直观感受到前后分离有啥明显的优势。明明后台一个模板替换解决的问题,搞复杂了。用material或者antd这些组件化的UI,想定制自己的东西难。你在meterial里面引入了一个alert,然后就报hook错误什么鬼。然后就要花一个晚上就研究如何解决这个问题。然后你安装gulp一大推警告,最后报错,你又得花一个晚上去研究如何解决这个问题。还有webpack如何配置?恐怕两个晚上也搞不定。你费尽头发研究明白了这些玩意你得到了什么?除了UI更动态酷炫之外,好像并没有得到什么特别的东西。我自己动手实现类型类似react之类的玩意,以明白其设计意图,就发现这个东西必须一个页面加载完毕,因为一刷新什么都没了,所以必须单页应用,在启动的时候把整个程序框架都塞给你,几个兆,不管你用到用不到。所以很多react之类的web app第一次启动就慢。你打开知乎看源代码,里面塞了一堆JSON文本,里面应有尽有。这样做好吗?不安全,还浪费用户流量啊。反正现在已经这么流行了,然后发现塞给客户端的东西太多了,客户端也受不了了,塞回给服务器,美名其曰服务端渲染,我x你大也的,本来你不就是鄙视服务端渲染吗?你补丁上打补丁,搞了一圈就返回原点。这种流程我只能用丑陋来形容,比丑陋更丑陋的是,这一切还都是用丑陋的Javascript实现的,没有比这更糟心的事情了。ugly piece of shit ! Javascript is a horrible language. 如何你说你喜欢用js写程序,我建议你看看心理医生,是不是有那个啥倾向。什么样的语言随便安装个东西就导入几千个依赖?恕我直言,nodojs的很多包纯粹就是一坨shit。而这些个光鲜的框架,其实就是建在屎山上的。也难怪稍微动动就一身翔。
所以,局部更新AJAX,turbolink就好了。从明天开始回归,不折腾了。这玩意不合适咱。小项目小团队没有人,也没有时间折腾。
现在大厂垄断严重,人家人多钱多,不怕。没法比。如果你想在一个人一个月做一个项目,我想前后端分离这个东西不适合你。
说到安全问题,那就是客户端渲染安全问题没法解决,因为一切都是透明的,客户端想怎么改就怎么改,你解决不了。永远不能信任客户端。
这要从大概八年前说起,事情是这样的
1 一开始,html 就是后端渲染的。不过后端发现页面中的 js 好麻烦(虽然简单,但是坑多),于是让公司招聘专门写 js 的人,也就是前端
2 前端名义上是程序员,实际上就是在切图(CSS)和做特效(JS),所以所有程序员中前端工资最低,职位也最低。所以前后端的鄙视链就出现了。
3 nodejs 和前端 mvc 的兴起让前端变得复杂起来,前端发现翻身的机会,于是全力支持这两种技术,造成本不该做成 spa 的网站也成了 spa。慢慢地前后端分离运动从大公司开始兴起,目的就是前端脱离后端的指指点点,独立发展。(表面上是为了「代码分离」,实际上是为了「人员分离」,也就是「前后端分家」,前端不再附属于后端团队)
4 spa 之后发现 seo 问题很大,而且首屏渲染速度贼慢,但是自己选的路再难走也要走下去,于是用 nodejs 在服务端渲染这一条路被看成是一条出路
5 其实这是第二个翻身的机会,如果 nodejs 服务器渲染成为主流,其实就相当于前端把后端的大部分工作给抢了,工资压过普通后端指日可待
6 然而结果是 nodejs 服务端渲染始终是小众,因为后端也没那么脆弱,java php rails 十多年沉淀的技术岂是你说推翻就推翻的,已经运行多年的项目又岂是容你随便用 nodejs 重写的,另一方面 golang 等技术的兴起也给 nodejs 不少压力。最终只有少部分前端特别强势的团队成功用上了 Node.js 做渲染(比如阿里的一些团队),大部分公司依然是用 PHP 渲染 HTML。
7 于是 nodejs 退一步说好好好我不抢你们的工作,我只做中间层(大部分工作就是渲染页面和调用后台接口),绝不越雷池。后端说算你识相。现在 nodejs 主要搞什么微服务,也是为了抢后端还没注意的市场。
你要看一门技术的发展主要应该看背后的人是谁,应用场景是哪些,最后才是技术细节。
nodejs 的火在中国早就烧过了,以后估计不会大火了,作为前端了解一下还是不错的,但是如果你是后端的话,看不看都无所谓,nodejs 跟其他后端开发框架差异并不大,单线程异步既是优点也是缺点,你就把它当做一种范式研究就好。
我是一个坚定的『前后端分家』反对者,前后代码可以分离,但是人员绝对不应该分离。前后端撕逼的事情在大公司天天都在发生,全都是因为前后是两个团队,利益不同。实际上前端推 nodejs 渲染就是在试图重新让前后端合成一体。
但是前端不能明说这件事,因为如果要把前后端部门合并,拆掉的肯定是前端部门。
合,则相当于自断前程。
不合,则永远没法解决seo和首屏加载慢的问题。
所以前端真的挺矛盾的。
JS 也有一个矛盾的地方,凡是浏览器上的框架(Vue React)都说自己能适应「复杂」场景,凡是 Node.js 上的框架(express fastify koa)都说自己是「轻量级」框架。
为啥?因为浏览器是 JS 的主战场,而且无敌手。而服务器上,JS 的经验积累还是太少了,搞企业级服务,Node.js 是敌不过 Java、PHP 的,没办法,发展得太晚了。所以目前只能搞「轻量级」咯。egg.js 号称是企业级 Node.js 框架,用过的人来评我就不评了。
有些大佬提出「大前端」的概念,意思是前端也要会后端,但是我们心还是前端的。
这不就是把以前的『前后端一个人做』换了个说法嘛。
反正你现在让后端去学前端,后端肯定是不愿意躺这浑水的。只能前端自己想办法咯。
想来想去就只有 Node.js 中间层做 HTML 渲染了。
当初是你要分开,分开就分开。
现在又要用kpi,把我唤回来。
但是后端kpi跟你前端kpi是不同的呀,所以没戏。
这些话也就我这种脱离了大厂约束的人敢说,在大厂的人根本不敢说,毕竟跟后端低头不见抬头见的。
最后告诉你一个小秘密。由于阿里 nodejs 用得还算多,却招不到人,所以从功利的角度出发,也许你学 nodejs 比学 java 更容易进阿里,毕竟阿里的 java 大神多如云,nodejs 大神却不多。
你说是吧。
但是从另外一个角度考虑,SEO 不友好的页面我是支持的。
如果你的页面是对 SEO 不友好的,那么百度的重要性就会被削弱。现在是移动互联网时代,大家在手机上几乎不用百度,都是直接点 App 点微信公众号的,SEO 不友好问题不大。首屏速度随着 5G 网络的普及也不会是问题了。
只要能让百度利益受损,我觉得 SPA 这事还是值得做的。服务端渲染还是直接免了吧,大家都不做 SEO 让百度倒闭就最好咯~(只是我的幻想而已,不要当真,我是百度的脑残黑,黑百度从来不需要理由)
感谢你看我说了这么多,不过说到最后,我也没给出啥结论,只是把我观察到的告诉你了。
你要不要学、要不要用服务器渲染HTML,都是需要你自己思考的事情。
还是那句话,我不喜欢说中庸的观点,我喜欢跟你说一个极端的观点,然后会有人用另一个极端的观点反驳我,他说服不了我,我也说服不了他,但是最终,你会得出自己的观点。
手机打字,大小写错误请海涵。