为什么很多人对 TypeScript 的作用存在误解？

JS

TS 的主要意义在于为库的使用者提供更智能的提示功能。即便你只用 JS，也能享受到大量由库开发者提供的基于 TS 的智能提示。比如，为什么在输入 document. 后会自动补全出 getElementById？这是因为 TS 内置了一套 DOM 类型定义。如果你觉得 native 对象的补全不足为奇，那再看 lodash，当你输入 _. 时，后边的一系列函数是如何实现补全的？这背后同样得益于 TS 提供的支持。即使是用 Vue，ref 对象在纯 JS 环境下不写 .value 也不会报错，但智能提示依然能够帮你补全 .value，这一切都源于开发者为它编写了 TS 类型定义。这些补全并不是理所当然的，而是得益于 TS 所带来的类型支持和智能体验。

也有人举 Svelte 的例子，说写库可以不使用 TS——但 JSDoc 的类型检查本质上还是依赖 TS。没有 TS，JSDoc 只是普通的文档说明。他们的理由是希望写出的代码无需编译，直接使用，从而保持轻量化和简洁性。这并不能算放弃 TS，只是用了一种更复杂的 TS 实现方式而已。当然，别人怎么选择是别人的自由，没人会去干涉。即使在项目开发中，如果你认为 typescript 增加了过多复杂性，让代码灵活性降低，至少可以借助 JSDoc 为函数参数标注类型，从而在函数体内获得参数的智能提示。如果觉得写 /* @typedef {...} */ 太繁琐，哪怕只为简单的 string、number 类型的参数添加注解，也能显著提升开发体验。这种方式几乎没有任何成本，却能带来很大的便利。当然，如果你觉得省去这两行 JSDoc 比享受函数内的智能提示更重要，那是你的选择，但无疑你会错过一个高效的优化机会。很多人其实早已在不知不觉中享受了多年 TS 带来的优势，却对 TS 的贡献毫无察觉，反而指责 TS 太复杂、不够灵活，这种现象令人感到十分讽刺。

TS 无疑为库的声明提供了一套统一规范，让不只是被编辑器特别支持的库也能实现完整且安全的提示。这极大地促进了 JS 生态的繁荣，吸引更多人尝试新技术。试想，当你上次使用一个没有 TS 支持的 JS SDK 时，那种缺乏智能提示的体验是多么令人困扰。