为什么有人说React和Vue可能是最后的前端框架了？

这么看来，jquery还是yyds，笑到最后。

web前端，只要浏览器标准不变，那就永远是三大件，html，css，js。

你整再多的框架，封装再多的特性，什么虚拟DOM，什么webpack，最终还是要回归到这三大件，没有这三大件，用户压根看不到最终呈现的内容。你webpack整再复杂，各种插件，组件，node_modules，最终还是要编译成浏览器能解读的js，css，html。编译过程咱就不说了，如果你遇到过一个js十几MB的话（没错，pixiv说的就是你），你就应该吐槽，为啥不把这一个js文件拆成几个？毕竟浏览器可以多线程加载资源，一次下5个怎么也比卡着这一个下载快啊！尤其还是外网环境，网络质量很差的场合，多线程的优势自然就发挥出来了。而现在，脚本加载不完，就不能渲染页面，其他的图片资源也加载不了，都在这堵着，也就是白屏显示很久才出内容。

虚拟DOM整再多复杂的结构，再怎么优化性能，最终你都要呈现到真实DOM，性能该啥样还是啥样，然后再加上封装产生的debuff，实际性能比直接操作DOM还是下降了。只不过封装了各种利好开发者的特性，你以为是让程序猿们少掉点儿头发，然而实际上是各种框架学习学到头发掉光光，不同框架业务逻辑大相经庭，不同业务不同框架，一个程序猿要掌握一堆框架技术，学的多了还有可能记混，写出奇怪的bug。比如你学了React，jsx以为天下无敌，突然让你换到vue，Angular就一脸懵逼，很容易就写错。好在vue现在也引入jsx了，但这玩意儿又是另一个毒瘤。

以前我们前后端不分离时，在jsp，php里混写html，各种业务逻辑和html混杂在一起，各种字符串拼接，让代码像一坨屎。现在jsx承接了这项工作，继续在html里写逻辑。比如你写一个ul、li的列表，vue只需要在li里写v-for，里面是标准的for...in，作者还很贴心地加上了for...of迭代数组的语法，react你得array.map，箭头函数，一堆大括号。条件渲染？vue写个v-if，里面是标准的if语法，简洁明了又好读，react：又是一堆大括号，丫还不支持if、for循环！得用各种魔法表达式！你想绑定点attribute，双向绑定，OMG！光看代码就能烦死你！更不用提这玩意丫根本就不是js的标准语法，是要编译的！编译出来就是React.createElement。还有啊！最令html爱好者深恶痛绝的一件事，那就是attribute引用变量不写引号！不然它就是普通字符串！！！！比如：let name=123; return <div name={name} id="{name}"></div>，渲染出来就是<div name="123" id="{name}"></div>。你丫name的引号呢？？？？如果你在vue里这么写，妥妥的报错。还有啊，class写成clasaName这种打破html常规的写法，会让一个写了十几年html，面对jsx里class警告而一脸懵逼。出于0 Errors, 0 Warnings强迫症，就得老老实实把class换成className。还有<label for="item">，你得给换成htmlFor。

如果你们在那些性能很差的电脑上跑这些基于框架实现的页面，尤其是那些复杂度很高的，都会有同样的体验，那就是卡！本来简简单单的一个表单，填东西时硬是卡出翔来。本来一个很简单的展示页面，滑动卡，划到底部慢慢等加载，图片慢悠悠懒加载出来，然后页面越来越长，流畅度肉眼可见地下降，一点点地磨灭你的耐心。我们在用ElementUI就深有体会，一张表格展示数百甚至上千条的数据，点开这个页面就要卡半天，是完全不能动的那种卡。最终只能老老实实做分页，每页显示10条，要看你就慢慢翻吧。后面数据越来越多，领导们翻页很累，要求优化，然而他们的老爷机……只好老老实实用jquery组装数据生成整块儿html放进去，这下子就非常流畅了，虽然还是会卡那么两三秒，但好歹不用让头头们等那么久了。

由于这些框架并没有一个统一的标准，那API的实现还有兼容性就看框架的开发人员了，升一个大版本API全都不通用又不是没发生过，还不向下兼容，这一波属实是把ActionScript2.0～3.0的天翻地覆学得清晰透彻。

那jquery呢？它是啥？你可以认为，它的出现，为当时奇葩的js提供了一套兼容各大浏览器的语法糖，让很多网页特性的开发不再那么艰深晦涩，并且可以适配不同浏览器，尤其是IE。现在虽然浏览器内核几近大一统，js原生的DOM操作API还是没有多少改进，啰哩啰嗦的像老奶奶的裹脚布，又臭又长。我就举个栗子，document.getElementById('id')和$('#id')哪个好写好记又好看。还有增删改查元素的方式，jquery提供的方法一应俱全，还不损失性能。因为它用的是最纯朴的方法去直接操作DOM，性能跟原生方法几乎是一样的。比如在某div后面插入div，原生js你得写一大堆，又是createElement，又是写各种attribute，innerHTML，最终还得appendChild。jquery？$('div').append('<div blabla>blabla</div>')就完事儿了！你甚至不需要去折腾webpack，不用纠结node_modules这个巨大的黑洞，只需要把脚本下下来，html里引入，然后做你想做的事。快速地实现需求，剩下的时间喝喝茶，摸摸鱼，再刷刷知乎，不香吗？

动画，这是框架玩家们心里的痛。如果你用的不是ElementUI，antd这种为你写好的UI框架，那么网页的动画能折磨到你怀疑人生。比如一个类似Vista的弹窗动画，有类3D的立体效果，在框架里你就要考虑它的生命周期，在各个阶段为它配上相应的css，再用transition过渡，听起来好像很好对不对？那遇到不同元素，不同动画，就都得去一个个写，一个个调，写不完还得加班，头发掉光光。jquery呢？$('#id').animate()就搞定了，而且还能连着写一堆.animate()，按顺序播放！压根不需要考虑啥生命周期，想动就动，还有各种缓动曲线，回调函数，这不比css那一坨好写？如果你对默认的animate不满意，还可以用Transit插件，效果更多。你还可以将animate封装成Promise，用await，async去控制。比如一个列表，里面的元素按顺序一个个从下面滑动到自己的位置，到位了碰一下上一个元素，还有opacity透明度变化，诶这就能用for循环，配合await，等动画播完了元素就位了再放下一个。如果你不想等上一个动画播完，而是想要一个延时，那也可以把setTimeout封装成Promise，同样用await来控制。当然，你也可以用框架生成内容，再用jquery调效果，但不得不考虑动态DOM和jquery之间的冲突。

web前端开发就应该这样简单、纯朴、高效，自由，不需要跟各种配置、框架、node_modules勾心斗角。你的web开发目录下，就应该只有html，css，js和各种网页用到的资源，而不是各种node_modules黑洞，package.json，各种你看懂看不懂的脚本、配置文件、编译产物。而将你的项目部署到生产环境时，它应该是能够被web服务器，如nginx，apache直接读取，而不是反代各种由node跑起来的各种端口！node在这里做的事，就是把webpack，框架代码，根据配置编译成浏览器能识别的三大件，node本来是后端，却干了前端的活儿，然后多此一举把本应该在前端渲染的东西放在服务端渲染（SSR），用一个成语比喻就是「牝鸡司晨」。node就应该干服务端该干的事，为前端提供各种接口和API，而不应该掺和前端。

当然，对于js动态生成html会不利于SEO这样的问题，用node在服务端渲染html是没有问题的，它还能提高网站的加载性能。然而js本来就性能有限，还去搞那么多虚拟DOM，框架，这反而会影响网页的呈现速度。毕竟这玩意是单线程异步，工作量大了该卡还是会卡的。当然你有钱，能买到高性能的服务器这都不是事。