前言
在2024年, TypeScript肯定算不上什么新鲜的技术. 但是经过长时间的使用, 我认为可以使用, 但是要适度.
类型跟不上业务的变化
我们知道TypeScript的类型定义是业务的体现. 但是业务的变化在很多公司都是非常快的. 在产品功能上可能更改了一点点类型定义, 但是你的类型系统可能要大改. 这当中不排除是当初设计的不合理, 但即使设计地再合理, 产品一样有办法让你的合理变得不合理. 因为产品需求永远是'合理'的. 基于此, 你要么花更多的时间去维护类型, 要么就逐渐走向AnyScript.
团队水平跟不上
实际上, 绝大部分团队水平是不具备熟练使用TypeScript的. 当一个新手遇到看不懂的类型的时候, 为了跑通代码, 直接一手可选链操作, 并不是什么罕见的行为. 而可选链可能是最小的灾难. 为了让代码跑通, 你无法预估他们会做什么样的修改, 以及哪些修改是合理的. 此时又考验你们团队的review执行力度了. 一环套一环.
电脑性能压力
这一点我是没什么感觉的, 因为我电脑性能过剩. 64G内存, 怎么折腾都没事. 但是很多人的内存只有16G甚至是8G, TypeScript的类型推导必然需要消耗一些内存. 大家是否经历过等待VSC加载类型系统的时候呢? 过于复杂的类型推导更会加剧这个现象.
拒绝极端
我在这里, 并不是告诉大家不要用TypeScript. 相反, 我是坚定的TypeScript拥护者. 只是根据我的经验, 发现这个东西可能还是中庸更适合. 不使用TypeScript, 会导致维护火葬场. 但是过度使用, 比如各种体操到处窜, 大概率后面维护的人也会很难受. 如何定义过度使用? 这个就看你们团队水平和项目情况了. 就我自己来看, Omit, Pick, 泛型, 这些都算正常使用. 一旦要自己写type去推导, 我建议慎重考虑.
总结
技术上的东西, 往往是没有银弹的. 需要根据你项目的情况和现有资源进行选型. 像一些非常知名的repo的TypeScript确实也用的炉火纯青. 但是他们是他们, 我们是我们. 需要根据自己的情况来定.