在2025年的前端圈,说自己不喜欢TypeScript,几乎是一种“政治不正确”。现在你去面试,如果说自己的项目没用TS,面试官看你的眼神都会有点奇怪。
坦白说,我曾经是TS最忠实的拥护者。大概五六年前,我几乎是在团队里力排众议,强力推行TS,把好几个旧的JS项目都重构了一遍。我享受过它带来的所有好处:智能的类型提示、重构时的安全感、以及那种把代码写得像诗一样严谨的快感。
但最近,尤其是在做一些需要快速迭代、频繁试错的小项目时,我发现,我好像开始“讨厌”它了。
这种“讨厌”,不是因为它不好,恰恰相反,可能是因为它“太好”、“太重”了。
我们为“类型安全”的付出
没有什么东西是只有好处没有代价的,TypeScript也一样。我们享受了它的类型安全,但我们也在不知不觉中,为它付出了三种代价。
1. 还没开始写代码,就先配置tsconfig.json
每个新项目,tsconfig.json
都是第一道坎。target
是ES5
还是ES2020
?module
用CommonJS
还是ESNext
?moduleResolution
选node
还是bundler
?strict
模式要不要开?paths
路径别名怎么和Vite或者Webpack对齐?
这些配置,每一个背后都代表着一堆需要去理解的概念。有时候,光是让TS和构建工具、测试框架、ESLint和谐共处,就得花上半天甚至一天的时间。
我只是想写个简单的业务逻辑,却要先成为一个“配置专家”,这个过程真的很消耗耐心。
2. 我的类型,比我的逻辑还复杂
给简单的变量和函数加类型,很愉快。但一旦你的逻辑变得复杂,比如处理一个泛型工具函数,或者一个嵌套很深的数据结构,类型体操就开始了。
我遇到过好几次,一个函数的实现逻辑可能只有20行,但我为了让它的类型完美无缺,写的type
、interface
、extends
、infer
这些东西,加起来超过了50行。
这个时候我总会问自己:我到底是在写业务代码,还是在“取悦”TypeScript的编译器?
这种为了类型而类型,在追求完美的同时,也实实在在地拖慢了我的开发速度。代码的可读性,有时甚至不升反降。
3. 总有那么几个拖后腿的第三方库
TS的生态很好,但不是完美的。你总会遇到那么一两个你想用的库:
- 它本身是JS写的,官方没有提供类型定义。
- 社区的
@types/xxx
包,要么没人维护了,要么类型写得有错误。
然后,你就陷入了窘境。你要么花大量时间去给它手写一个.d.ts
声明文件,要么就只能忍气吞声地使用any
或者// @ts-ignore
。
每当这个时候,TS带来的安全感就荡然无存,只剩下被一个第三方库的类型问题卡住的挫败感。
我们真的需要它吗?
上面说的这些,在一个大型、长期、多人协作的项目里,我认为是值得付出的。这种项目,稳定性和可维护性压倒一切。TS倒是保证了规范。
但我开始“讨厌”TS,是在那些小规模、需要快速试错的场景里。
比如,我要快速搭一个原型去验证一个想法,或者做一个生命周期可能只有三个月的营销活动页面。在这种场景下, “快”是第一位的。
这时候,TS就变得很重。API的结构可能一天变三次,数据字段天天都在增删,我大部分的时间,都花在了和各种类型定义作斗争上,而不是快速地实现功能、收集反馈。
使用场景用错了,它反而变得碍手碍脚。
我的优雅解决方案:回归JSDoc
在感到疲惫之后,我开始尝试一种“中间路线”:在.js
文件里,用JSDoc来做类型注解。
// 以前的TS写法
function getUser(userId: string): Promise<User> {
// ...
}
// 现在的JSDoc写法
/**
* 获取用户信息
* @param {string} userId - 用户ID
* @returns {Promise<import('./types').User>}
*/
function getUser(userId) {
// ...
}
我发现,在VSCode强大的支持下,这种方式几乎能提供TS 80%的好处:
1.有智能提示:函数的参数、返回值类型,一清二楚。
2.有类型检查:开启// @ts-check
后,简单的类型错误也能被发现。
3.没有编译时:它就是纯粹的JS,不需要TS的编译过程,启动和构建都更快。
4.它是“可选的” :我可以只在我认为最关键的地方(比如API边界、复杂函数)加上JSDoc,而在一些简单的内部逻辑里,享受纯JS的灵活性。
所以,我现在“讨厌”TypeScript吗?
我想,我讨厌的,不是TS本身,而是那种“所有项目都必须上TS”的“技术正确”。
我厌倦的,是无处不在的配置、是日益复杂的类型体操、是在项目初期就被类型束缚住手脚的感觉。
技术不是信仰,它只是工具箱里的工具。我们应该根据要解决的问题,来选择最合适的工具。
也许,最好的开发者,不是掌握了最“好”的工具的人,而是最清楚在什么场景下,选用“最合适”的工具的人。
你们觉得呢?😀