真前言
我发现很多人眼神不太好, 我什么时候说过不该使用TypeScript了? 我全文没有一个字儿说不该用, 而是不该过度使用, 讨论的都是过度的影响, 不是使用了TypeScript的影响. 本文确实是随手一写, 很多观点没写全, 在博客园有个老哥的评论已经完美解释了我想表达的内容我引用一下.
"支持博主说的，确实是这个，特别是业务。使用TypeScript明显是业务系统开发团队被框架开发团队带节奏的情况，强类型对于框架或类库的研发特别有效，不论是生产者还是消费者。但是，到了业务系统开发层面，就变得如同巨蟒了，看上去确实比js强，小业务范围确实比js干净好控，但是，一旦遇到复杂场景，ts就成指数级复杂，一方面是代码量指数增加，另一方面是开发人员的心智负载急剧上升。本来三分钟能交付的开发任务，现在用ts大概得一个小时，再加上测试（没有测试，就不能完全体现出ts优越性了），估计要两三个小时了。一个需求，5分钟不给响应，20分钟不给上线，用户就要投诉了。如果你是某些宗教一样神圣的公司，没有客户敢喷你们，那除外。"
前言
在2024年, TypeScript肯定算不上什么新鲜的技术. 但是经过长时间的使用, 我认为可以使用, 但是要适度.
类型跟不上业务的变化
我们知道TypeScript的类型定义是业务的体现. 但是业务的变化在很多公司都是非常快的. 在产品功能上可能更改了一点点类型定义, 但是你的类型系统可能要大改. 这当中不排除是当初设计的不合理, 但即使设计地再合理, 产品一样有办法让你的合理变得不合理. 因为产品需求永远是'合理'的. 基于此, 你要么花更多的时间去维护类型, 要么就逐渐走向AnyScript.
团队水平跟不上
实际上, 绝大部分团队水平是不具备熟练使用TypeScript的. 当一个新手遇到看不懂的类型的时候, 为了跑通代码, 直接一手可选链操作, 并不是什么罕见的行为. 而可选链可能是最小的灾难. 为了让代码跑通, 你无法预估他们会做什么样的修改, 以及哪些修改是合理的. 此时又考验你们团队的review执行力度了. 一环套一环.
电脑性能压力
这一点我是没什么感觉的, 因为我电脑性能过剩. 64G内存, 怎么折腾都没事. 但是很多人的内存只有16G甚至是8G, TypeScript的类型推导必然需要消耗一些内存. 大家是否经历过等待VSC加载类型系统的时候呢? 过于复杂的类型推导更会加剧这个现象.
拒绝极端
我在这里, 并不是告诉大家不要用TypeScript. 相反, 我是坚定的TypeScript拥护者. 只是根据我的经验, 发现这个东西可能还是中庸更适合. 不使用TypeScript, 会导致维护火葬场. 但是过度使用, 比如各种体操到处窜, 大概率后面维护的人也会很难受. 如何定义过度使用? 这个就看你们团队水平和项目情况了. 就我自己来看, Omit, Pick, 泛型, 这些都算正常使用. 一旦要自己写type去推导, 我建议慎重考虑.
总结
技术上的东西, 往往是没有银弹的. 需要根据你项目的情况和现有资源进行选型. 像一些非常知名的repo的TypeScript确实也用的炉火纯青. 但是他们是他们, 我们是我们. 需要根据自己的情况来定.
