为什么我不会再完全依赖Vue + Element

0x00 开始

这个学期有两个大作业,想着顺便学一下三大框架,之前建站很多都是jQuery一把梭,因为规模小,加了一些比较现代的流程,比如CSS预处理器之类、Gulp之类的,稍微大一些的需要做后台接数据的就用PHP + Bootstrap + jQuery,一直没有接触过三大框架。

就连Fastnote都是jQuery一把梭,现在看来真的是个灾难,应该早点上Vue,现在重构很麻烦……

刚好这两个作业规模算是中等,是一个比较完整的系统,涉及到了CURD呈现,登录注册等等,就想顺便接触一下三大框架,于是花了一些时间去学习、入门、上手。

定下来的方案是Vue + Element,很快就能做一套不错的UI,边做边学。入门难度不高,做一套网站还是比较轻松的,当然为了赶进度没有怎么管自适应这方面的东西,回过头来看粗糙的地方还是很多。

在做的时候发现Vue这个东西确实简单,Vue + Element一把梭也确实好使,但是存在一些问题。

0x01 问题

现在Element的版本看了一眼还是2.13.0,感觉维护这个项目的组对于PR和Issues都不怎么上新,基本上是靠社区来修问题。

开着的PR几百个,官方不到更新的日子是不会理的,如果某个版本出了问题,等官方更新是等不来的,无非就是自己Fork一份然后修改源码,整合一些修正了Issues的PR。

需要深入到源码,用自己Fork的版本才能把站做好,这是我觉得Vue + Element最不友好的地方,快是快,爽是爽,但是质量也得保证。

在2.13.0里,遇到的问题主要有两个:

  • Dialog的半透明黑色背景遮罩匪夷所思地以mouseup作为触发事件,以至于按下鼠标之后把鼠标移动到了Dialog外,触发了遮罩的时间,Dialog关闭。误触发率极高,不知道为什么会存在这样的设计,按照常理应该是mousedown。
  • 新加入的控件popConfirm不响应绑定的确认和取消事件,原因是官方在this.$emit()内填入的是'onConfirm'和'onCancel',而HTML标签绑定东西不认这样的大小写

这两个错误给人的感觉很低级,和Element在外的名声不符,定位到是框架本身的问题之后,按照常规思维Bing、Google、百度查是查不到什么的,只能翻Issues、翻PR,很浪费时间。

自己读源码吧,因为可能不懂Bug出现的机理,可能会浪费更多的时间。好在Issues有人提,可以定位到具体出问题的源码分析Bug,然后Debug,要不然这样的问题真的棘手。

然后就是费时间做自己的分支,然后编译放到项目里用。经历了这样两个问题之后,看到还处于Open状态的那么多Issue,真的会有一些怕。

再者,Element组件预设的一些CSS也不是很讨喜,例如在Dialog的Body内加一个Form,那巨大的内边距看着真的很无语,要么改源码,要么打补丁覆盖这些样式。想到如果以后再用它每个项目都要这么做一遍,就觉得很麻烦,不如换个框架。

0x02 态度

前文提到了,Element的维护团队对于这个项目的态度感觉也有问题,基本上是社区在推进、完善这个项目,官组平日里没有什么作为,PR开了之后只有机器人构建一个预览版本,然后就没有活人来搭理你了。

虽然官组也是开发者,不是客服,但是这种不到发新版基本上不管这个项目的态度让人感觉用这个框架没有安全感。

如果Element维护团队能够积极面对这些社区提出来的问题,尽快地解决这些问题(上面提到的这些致命问题到现在已经过去一两个月了,代码也没合到master上去),那么以后我可能还是愿意用,至少有人在认真、热情、积极地管理和维护这个项目。

0x03 生态

因为Element用的人多,所以生态还不算太差,但是也不算很好。有的问题是框架的锅,有的问题是Vue的锅。

比如说动画,Ant Motion这样的库在Vue里面就找不到很好的替代品,要么用velocity.js,要么用animate.css,但是效果和效率都不是很舒服。

再比如说响应式,Element本身只考虑了PC,没有为响应式设计考虑一星半点,如果你想要做响应式,可,自己动手。作为一个面向PC的框架,其实应该要考虑到PC浏览器的窗口是能随便改大小的,而且PC上分辨率也不止一种,比例也不止一种。

就算是一个只针对PC做的项目,为了保证最好的使用体验也应该就不同的分辨率做优化,这是在我看来好的产品应该要有的,但是Element做响应式这个,在这个框架的生态里没有什么可行的方案。

确实,他们还做了Mint UI,专注于移动端,但是我用了这个框架之后想一站覆盖多端,不想另外开发,我也不是只给移动端的人用,PC也要用。只能说这个框架的设计还是有恼人之处的。

这并不是说Element不是一个好框架,Element仍然是Vue里面用的人最多、最热也确实是有实力的框架,只是Element可以做得更好,可以做得更易用,像动画这样的东西其实也不是不能考虑进来,但是Vue这边的框架很少重视动效,更多还是根据Vue的思路以组件等为主。

0x04 后话

Element感觉是在等Vue 3.0,所以更新的频率放缓了,但是Vue 3.0迟迟不出。起初我入坑Vue也在想等Vue除了3.0再入坑,省得学了的没用上就被淘汰了,但后面发现等不来。

Vue 3.0的变化还是很大的,虽然会向下兼容,但是Vue 3.0才是未来,API以及整个LifeCycle的变化都很重要,很多东西确实要从头学起(至少要改变思路),框架的难度感觉要上一层楼。

改动好不好不好说,对于大型项目来说TS这种类型约束是必须,但是对于中小项目(指前端,后端一律上TS没话说),我更追求自由和灵活,不见得满地的any有什么不太好的地方,特别是自己做开发不考虑协作的话。

再者现在Vue 2这一套感觉还是很舒服的,自己造点轮子效率高的飞起,最近这段时间感觉被React折磨得有点难受,希望Vue 3也一样高效率、低门槛吧。

在Element发新版之前,除非是很急/很重要的东西,求稳优先,否则可能会优先考虑用antd-for-vue或者是vuetify做,如果体验好的话以后可能都不会再用Element,除非它重新活跃起来。

至于React + antd,这个东西目前对我来说用它来转化想法太慢了,不知道是我不熟悉,还是它确实不适合中小项目,这个日后再议吧。

0x05 其他

关于Fastnote的重构,脑子里是有想法但是身体不愿意去做,考虑到会有一个Web版而且Web版用的绝对会是Vue,所以现在的想法是先找个时间吧Nest.js给学了,然后做个项目练手,用Nest.js重铸现在Fastnote的Server,用现在jQuery的版本把云服务的第一步做完。

然后就是Web/PWA等等这些的施工,有了Web版这一份Vue代码,其实重构客户端就会快很多了。时间还是很紧凑的,感觉还是有压力,可能下个学期的重要任务就是这个了。