🙅 为什么 2024 年了还讨厌 TypeScript 是没有意义的

最近我发现了这种趋势：越来越多的开发者开始抨击 TypeScript。抱怨的内容五花八门，从“太复杂”到“拖慢开发速度”。

虽然并非所有担忧都是毫无根据的，但在 2024 年讨厌 TypeScript 是说不通的。

让我们来分解一下。🔍

TypeScript 不是你的敌人，而是你的安全网

我明白——JavaScript 灵活、动态，可以让你快速交付代码。但同样的灵活性也会导致一些 bug，这些 bug 很难发现，直到为时已晚。TypeScript 的严格性并非为了拖慢你的速度；而是为了让你免于花费数小时来调试那些本可以及早发现的问题。

以下是一个例子：

let id;
getUserByID(id);

理论上，id可以是数字、UUID、随机字符串或结构化字符串。但根据其类型，如果您尝试递增它或将其传递给需要特定结构和类型的 API，则可能会出现错误。

你可以通过观察它的用法来判断它的类型。但你知道为什么这不成问题吗？

let id: number;
function getUserByID(id: string) {...}
// and that's the most basic thing you could do
getUserByID(id); // boink, error!

将 TypeScript 添加到项目中，就相当于增加了一层安全保障。这就像系上安全带一样。当然，开车时可以不系，但既然一个简单的预防措施就能让你免于撞车，何必冒险呢？🚗💥 在软件质量比以往任何时候都更加重要的时代，TypeScript 的类型检查无疑是一项至关重要的保障措施。

这并不像你想象的那么复杂

我经常听到的另一个抱怨是 TypeScript “太复杂”。但说实话，JavaScript 可能很乱。函数签名可以接受任何输入，对象可以变形，代码只要一个拼写错误就会在生产环境中崩溃。TypeScript 并没有增加复杂性，而是将其形式化或标准化。

请这样思考：

你正在开发一个功能的前端，其他人可能有一些工作与你重叠。你还需要整合一些后端 API，但这些 API 尚未准备好。无论如何，你都被要求开始 UI 的工作。

如何确保你现在编写的代码与你从 API 获取的数据一致？并且，如果 API 发生变更，各方是否都能遵循一个可靠的数据来源？

没错，
通过定义类型。

在开始实施之前定义类型，就不会对 UI 和 API 之间共享的数据契约产生混淆，如果确实存在差异，那么需要做的就是遵守之前定义的契约。

如果你能学习 React、精通 Webpack 或处理 async/await，那么你就能学习 TypeScript。关键在于——这是一项能带来回报的技能。学习过程值得你付出努力，因为它迫使你更批判性地思考你的代码。你不再只是拼凑一个快速解决方案，而是在思考架构、类型和长期可维护性。🛠️

发展更快，而不是更慢

有一种说法是 TypeScript 会拖慢开发速度。但事实往往相反。TypeScript 通过在编译时而不是运行时捕获错误，从长远来看可以帮助你加快开发速度。你不用再整天泡在浏览器控制台里，苦苦追查未定义的变量或奇怪的类型强制转换了。🚀

TypeScript 的工具也同样一流。
自动补全、重构工具和内联文档等功能让开发体验更加流畅。你不仅仅是在编写代码，而是在一条路灯明亮、标识清晰的道路上前行，而不是在黑暗中摸索前行。🌟

这是我的一个小故事。
在我完全接受 TypeScript 之前，我经常陷入代码库考古的泥潭。我遇到一个函数，却不知道它应该接受什么参数。它是字符串吗？还是对象？这个对象需要哪些参数？哪些是可选的？那些看起来可选的东西，在调用栈的某个地方，是否真的需要？

因为开发人员并不完美，糟糕的变量名、不一致的命名约定和编码偏好总是会造成阻碍……

所以，我只能照着步骤来：回滚到函数声明处，仔细研究实现，试图拼凑出应该放在哪里的代码。如果自动完成功能能救我一命？那就算了，它根本没用。代码编辑器跟我一样一无所知。😅

当然，你可能会说 JSDoc 注释可能会有帮助。但是，如果你要费尽心思手动记录类型和函数签名，那又何必呢？你基本上是在做 TypeScript 的工作，却得不到任何实际的好处。TypeScript 消除了所有这些猜测，让你能够自信而快速地编写代码。

TypeScript 是未来（也是现在）

TypeScript 现已发布至第五版。它在GitHub上拥有10 万颗星，在 NPM 上每周下载量超过 5500 万次。越来越多的大型项目和公司正在采用它。这是有原因的：TypeScript 为代码库带来了稳定性、可扩展性和信心。它不仅仅关乎当今的项目，更关乎构建一个能够不断发展和演进，而不会因自身负担而崩溃的项目。它意味着无需一直单独编写文档和测试（当然，它不会完全取代它们）。

所以，让我们抛开这些噪音。TypeScript 在 2024 年遭受的攻击在很大程度上是没有根据的。当然，它并不完美——没有哪个工具是完美的。但它的好处远远大于坏处。是时候停止将 TypeScript 视为障碍，而开始将其视为必不可少的工具了。

拥抱它，学习它，你会发现自己可以更快地编写出更好的代码。💪

TypeScript 并不完美，但不要让完美成为优秀的敌人！

当然，TypeScript 并非完美无缺。一个合理的抱怨是，在一个并非基于 TypeScript 构建的项目中安装 TypeScript 会带来巨大的开销。将遗留代码库转换为 TypeScript 可能是一个耗时的过程，而且对于时间紧迫的团队来说，这并不总是可行的。⏳

此外，有时 TypeScript 的严格类型系统会让您感觉像是在与你作对而不是在帮助你，尤其是当您处理复杂类型或未正确输入的第三方库时。

TypeScript 的好坏取决于开发人员的配置。
我参与过多个 TypeScript 项目，其中一些项目的配置相对宽松，允许人们使用any类型或规避严格或严格的null检查。如果将无类型或松散类型的代码混入有类型的代码库中，情况可能会非常糟糕。

我们接下来要去哪里？

话虽如此，这些都是短期的痛苦，但是为了长期的利益。没错，它一开始可能会减慢你的速度，但你获得的稳定性和可维护性足以弥补这一点。

这些问题几年前曾经更加严重，但现在可以说已经好多了。

我认为，应该努力学习 TS。TS可以让你将其部分引入到现有的代码库中——试试看。或者，你也可以创建一些小型的、利用 TypeScript 的宠物项目。

此外，根据最新的StackOverflow 调查， TS 开发人员的收入比 JS 开发人员高一点。

说到更好的代码……

如果您对 TypeScript 如何提升实际项目水平感到好奇：

⚡️ 查看中间件仓库 ⚡️

这是 TypeScript 实际应用的一个很好的例子，说不定你能从中汲取一些灵感，用于你自己的项目！🚀

更好的是，告诉我们我们的代码为什么不是最好的！
如果你有什么切实可行的建议，我会修改帖子，把它们作为示例添加到文章中！