前端的技术、工具链实在太多,发展又快,简直有些疯狂。这里简要说一下项目中用到技术的一些评估和感受。

个人对某些技术的熟悉程度、理解程度不一样,所以我的感受跟他人的可能并不匹配,这个很正常。

TypeScript – 简称TS

如果你的项目使用的技术栈比较复杂,而你对TS熟悉程度不够,那么TS在早期将起到巨大的阻碍作用。尤其是开启了TS的严格模式之后。

在项目中后期,TS将对项目的质量起到巨大的提升作用,算是对前期各种头痛的一种补偿。

这里绝不是说使用TS不好,恰恰相反,TS非常的不错。但是TS带来的复杂性,特别是与各种框架混用带来的复杂性叠加,用户没遇到就很难预期。

最典型的就是各种泛型“满屏飞舞”,时不时的冒出来新的类型定义让人茫然无措 – 只有语言手册里面才能查的到。各种事件回调究竟应该怎么定义才能编译过去,如何让该死的lint程序闭嘴,都是让你十分恼火的事情。很多代码库都是javascript写的,并不是原生TS编写,让它们恰当的兼容并且正确运行,好多时候,并不简单。

光是这些玩意儿排雷,就够你忙活好多天的了,你啥也产出不了,整天困在TS这里。TS在这个时候,就是巨大的障碍。如果确实时间紧急,个人建议先别用TS了。或者,使用折中的办法:先关掉TS的”strict模式”,按手册修改tsconfig.json配置文件即可。”strict模式”下,TS把弱类型的js变成了强类型的js,完全没有弱类型语言编写的那些隐患,当然也就没有了弱类型语言的各种便利。

延伸,可以看看这位老兄的吐槽:https://www.zhihu.com/question/273619114

……跟着文档撸了几百行Demo级别代码,确实感觉无缝接入,然而,你写东西得依赖框架吧?这个时候才是大坑,注意 TS没坑,框架没坑,TS+框架会有很多坑

你必须学习框架+全家桶的各种暴露出来的d.ts(还好用的是React,生态良好,生态差的在下一条出现),重新配置webpack,并解决各种冲突,比如在webpack中设置了src为@方便我们引入文件,然而Typescript不识别会报错,你需要解决这种冲突,此类冲突很多,还有如果TS彻底替代babel会出问题,比如不能享受babel-plugin-import这种按需引入的Babel插件了,最好的方法是TS+Babel,这又是额外的复杂度,再比如prettier美化插件,虽然支持了TS但是会出现各种各样的花式美化,还有各种各样的坑爹的地方就不提了,需要有一段很恶心的过程去一点点踩坑,我对那段的记忆反正是痛苦的……

感同身受。

Material-UI

简称:mui,UI框架库。它与React框架是很好的搭配。初次接触mui的用户,或者有过其它UI框架 – 特别是bootstrap框架使用经验的人,会觉得很不适应。它让人觉得莫名其妙,为什么一个个简单的HTML控件、标签,都包装成一个个的组件?Bootstrap框架就没这个问题,直接在HTML标签上,加一个“class”定义就解决问题了,简直没有比这个更容易的了。

mui使用起来跟React组件一个样,这有优点也有缺点。

优点是:控制力强大,几乎每个标签、控件都可以通过程序控制。它可以做成一致性非常好的应用,比如你可以把应用需要的UI元素做成重用的组件,反复使用就可以达到目标。而Bootstrap要做到这样,经常得反复复制粘贴代码,稍微改下就会造成UI体验的不一致。

缺点是:它太麻烦了!编写、调试这样的UI,时间耗费是Bootstrap的10倍以上。

这种组件式写法让人觉得非常的麻烦,连个按钮都要自己编程一番,本质又跟业务逻辑没什么关系,纯粹UI的活。另外,React组件中CSS的写法没有规范,弄的五花八门,各种理念、说法都有,乱七八糟,mui也面临一样的困扰,你得找出适合自己的方式。

它在项目早期,也是巨大的成本消耗,你也得理解那一套套的组件控制逻辑。Bootstrap是不用这样的。实际上,Vue + Bootstrap开发难度比React + Material-UI容易的多。

只有等到项目的中后期,你把所需的UI抽成必要的重用组件,调试开发成熟,它就会带来开发效率和质量的提升。

React

对React的总体感受,一图抵千言。

这个事儿,不要看网上鼓吹的那些内容,自己上手做一个一样需求的稍微大一点的程序,就能体验出不同和各自的优劣了。

Vue

未完待续。。。

Apple公司的M1芯片和开源的RISC-V芯片给了我们什么启示?