“根本不需要TypeScript，JS+JSDoc够了”，大佬说我想多了
共 8117字，需浏览 17分钟
·
2023-11-11 01:30
本月，Ruby on Rails 作者 DHH 宣布移除其团队开源项目 Turbo 8 中的 TypeScript 代码。
他认为，TypeScript 对他来说只是阻碍。不仅因为它需要显式的编译步骤，还因为它用类型编程污染了代码，很影响开发体验。
无独有偶，不久前，知名前端 UI 框架 Svelte 也宣布从 TypeScript 切换到 JavaScript。负责 Svelte 编译器的开发者说，改用 JSDoc 后，代码不需要编译构建即可进行调试 —— 简化了编译器的开发工作。
Svelte 不是第一个放弃 TypeScript 的前端框架。早在 2020 年，Deno 就迁移了一部分內部 TypeScript 代码到 JavaScript，以减少构建时间。
Deno 团队给出的理由，总结一下就是：减少构建时间、降低发布的代码体积、减少编写的代码量。
加上今年短期内已经有两个项目从 TypeScript 切换到 JavaScript 了，这个状况就很令人迷惑。难道从 TypeScript 切回 JavaScript 已经成了当下的新潮流？在推特和 GitHub 上，讨论也是纷纷扬扬。有人赞同，表示欣赏他们的勇气；有人反对，表示这是开历史倒车。网友觉得，编译速度慢，改进编译器就行了，因噎废食有点想不通。
所以，放弃 TypeScript 回归 JavaScript 是在追求舒适的 partner，还是在开历史的倒车？
对此，开源中国找来了 3 位使用过 TypeScript 和 JavaScript 的前端大佬，听听他们的看法。他们分别是：
刘勇，社区昵称天猪，某大厂 Node.js Infra 负责人，EggJS / CNPM 核心开发者。
刘易成，社区昵称 xcatliu（流浪小猫），《TypeScript 入门教程》作者，来自腾讯文档团队。
李振，社区昵称 tick，来自腾讯文档团队。
一、开历史倒车？谈不上
Q1：TypeScript 是基于 JavaScript 推出的新语言，理论上应该比 JavaScript 完善的，为什么大家还会倒回去用旧的 JavaScript 呢？这算不算开历史的倒车？
刘勇：不算倒车，这只是一个选择，在某些场景下，写 TypeScript 会带来一些额外成本。譬如我看过一些开源库的源码，核心逻辑可能就几十行，但为了实现准确的类型提示，写出来的类型体操反而远远多于核心源码，孰是孰非对于不同的开发者有不同的准绳，需要找到其中的平衡点。当然，就目前的情况，在力所能及的情况下，我个人推荐能用 TypeScript 就用 TypeScript ，但是否要玩类型体操则根据开发者自身情况来决策。
Q2：以上从 TypeScript 切回到 JavaScript 的项目，都是做开发框架的，所以这是不是跟项目类型有关呢？做框架的项目更有可能选择 JavaScript 吗？
李振：是的，项目类型可以是影响选择 JavaScript 还是 TypeScript 的一个因素。在开发框架或库时，特别是前端框架或库，选择使用 JavaScript 的情况较为常见。
一方面，开发框架需要具备广泛的兼容性，以便开发者可以在各种项目中使用。由于 JavaScript 是 Web 开发的基础语言，几乎所有的浏览器和环境都支持 JavaScript。这使得使用 JavaScript 编写的框架更容易被广泛采用和集成。
另一方面，开发框架通常需要提供简单易用的 API 和灵活的扩展机制，以满足各种项目的需求。使用 JavaScript 可以更加直接地表达这些概念，而不需要过多的类型注解和编译步骤。这使得开发者可以更快地理解和使用框架，并且更容易进行自定义和扩展。
Q3：基于 JavaScript 改进的语言却遭到了开发者的嫌弃，这能说是 TypeScript 设计的失败吗？
李振：这并不能被视为 TypeScript 设计的失败。每个项目和开发团队都有自己的需求和偏好。有些开发者可能认为 TypeScript 增加了额外的复杂性和学习曲线，或者觉得它在某些方面不符合他们的开发风格。这并不意味着 TypeScript 设计的失败，而是反映了不同开发者对工具和语言的不同看法和需求。
TypeScript 仍然在许多项目中被广泛使用，并且持续发展和改进。它提供了许多有价值的功能，如类型安全、代码智能感知和重构支持等，这些功能对于大型项目和团队协作非常有益。因此，无论是否有一些项目选择回到 JavaScript，TypeScript 仍然是一个受欢迎和成功的语言。
二、TypeScript 和 JavaScript 并不是简单地互为替身
Q4：有评论认为，TypeScript 编译速度慢，改进编译器就行了，转回 JavaScript 是因噎废食，你怎么看？
刘勇：需要提醒的是，目前社区一些转回 JavaScript 的都是框架和类库，这些作者的决策点并不是只因为 TypeScript 编译速度。
另外，“改进编译器” 这事其实没那么简单，就像 TypeScript-node 在某个版本更新后，动态解析的速度慢了非常多，但也没计划优化。像 esbuild 目前还不支持装饰器。同时应用侧又开始一窝蜂上 monorepo，更加剧了整体耗时。我们只能寄希望于 TypeScript 官方的大神们再出绝招。
刘易成：即使是 JavaScript 项目，也有编译 / 打包 / 构建等过程，绝大部分项目都不会因为加入了 TypeScript 编译就慢很多。是否转回 JavaScript 还是需要综合考虑项目复杂度、团队协作规模等因素。
Q5：我们一开始用 TypeScript 是因为 TypeScript 提供了类型检查，弥补了 JavaScript 只有逻辑没有类型的问题，那如果我们用 JavaScript + JSDoc 来解决类型声明，是不是就不用使用 TypeScript 了？
刘勇：首先，JSDoc 并不能完全解决类型声明问题，它也不能在开发期就帮助开发者发现一些问题。
其次，这两者并不冲突，我个人在写 TypeScript 的时候也会写对应的 JSDoc，因为 TypeScript 的类型没法有更多的注释和描述。我更期望看到后续 TypeScript 团队能优化这块的体验。
刘易成：JSDoc 只能解决一部分类型的问题，而 TypeScript 是一个完整的类型系统。TypeScript 生态更繁荣，对于普通开发者和普通的项目而言，使用 JSDoc 的开发和维护成本可能会比 TypeScript 更高。
李振：理论上也是可行的，但与 TypeScript 相比，它仍然存在一些限制：
-
静态类型检查的完整性：JSDoc 注释是基于注释的方式，而不是直接嵌入到语言中，因此它的类型检查可能不如 TypeScript 的类型系统完整和准确。 -
工具支持的差异：尽管一些工具和编辑器可以利用 JSDoc 注释进行类型检查，但与 TypeScript 相比，它们的功能和智能感知可能有所限制。 生态系统的差异：TypeScript 有一个独立的类型系统和类型声明文件生态系统，这使得与现有的 JavaScript 库和工具更加无缝集成。而使用 JavaScript + JSDoc 可能需要更多的手动工作来编写和维护类型注释。
三、TypeScript 和 JavaScript ，其实各有千秋
Q6：你觉得 TypeScript 有什么特别的长处，对开发者来说是 JavaScript 做不到的？
刘勇：类型的元数据描述能力，这个是 JavaScript 目前还不具备的，除非 TC39 的 「JavaScript 类型标注」（ Types as Comments）等提案能落地。像我们就很重视 “API 元数据”，通过工程化的方式，可以从代码中提取出来接口 API 信息，从而可以在 codegen，mock，前后端协作等很多方面来提升研发体验和研发效能。
Q7：你觉得对普通项目来说，使用 TypeScript 有什么不方便或者不利的地方吗？
刘勇：主要还是工作流的复杂化带来开发成本的提升，我记得之前在 StackOverflow 看过一个关于 TypeScript 的回答是，我开发一个简单的功能，但是解决类型问题就花了一整天的时间，在我们公司内部做日常的技术答疑的时候，也经常发现有不少用户对 TypeScript 问题完全不知道从何下手。举一个 Node.js 项目的例子，很多用户就不理解为什么 tsconfig.json 里的 paths 在代码编译成 JavaScript 后会不生效，因为这些问题，就会容易导致产生计划之外的工作量。
四、TypeScript VS JavaScript ，你 Pick 谁？
Q8：有人认为， TypeScript 的出现是因为一般人驾驭不了 JavaScript ，有人则觉得 “水平越差的人越喜欢自由”，你怎么看？这两个语言的选择跟程序员的水平有关吗？
李振：拿爱好来判断个人水平是挺无聊的事情。写 JavaScript 和写 TypeScript 都有大牛。
刘勇：笑～ 平时可没少见有同学吐槽，好好的 TypeScript 项目，被人提交了一堆 Any。也见过很多吐槽接手了一个 TypeScript 仓库，要硬着头皮看一大堆类型定义，搞清楚这些奇奇怪怪的类型是如何工作的。我觉得语言的选择主要看团队的工程化和规范化程度，过犹不及。如果一个 TypeScript 类库写了一大堆类型，但却连一个单测都没有，那我觉得它是不合格的。
刘易成：TypeScript 的出现确实有一部分原因是 JavaScript 比较难 “驾驭”，JavaScript 太灵活了，缺少类型的约束，很容易写出 bug 代码，TypeScript 一定程度上解决了这个问题，使得代码的可维护性更高了。
Q9：你认为这两个语言是不是分别有不同的适用项目？什么时候该用 TypeScript 什么时候该用 JavaScript 呢？对个人和企业开发者来说，应该怎么选？
刘易成：对于大型项目、多人协作和需要高可靠性的项目来说，使用 TypeScript 更好；对于小型项目、个人项目，可以使用 JavaScript 更快迭代，当然也建议使用 TypeScript 保持更高的可维护性。
另外企业也需要根据员工技术能力和项目历史包袱来灵活选择技术栈。
Q10：你如何看待 TypeScript 的未来发展？你觉得它是一时流行还是会终将取代 JavaScript ？你认为谁的技术生态更好一点呢？
刘勇：TypeScript 的定位是 JavaScript 的一个超集，它的能力是以 TC39 制定的 ECMAScript 规范为基准（即 JavaScript ）。我觉得它也谈不上会取代 JavaScript ，毕竟它并不是官方规范，而且 JavaScript 的存量生态实在是太庞大了。
当然，TypeScript 现在已经某种程度上成为事实的标准，尤其是因为 Node.js 官方对 ESM 和 CJS 何去何从的犹豫，导致社区开发者长时间的割裂，越来越多的人被迫选择用 TypeScript 来写类库，然后同时编译为 ESM 和 CJS。目前 TypeScript 的生态已经成规模，所以它不会像 CoffeeScript 那样昙花一现。
刘易成：我个人认为 TypeScript 会持续流行并得到更广泛的应用。但并不会 “取代” JavaScript 。TypeScript 的目标一直都不是 “取代” JavaScript ，而是基于 JavaScript 提供类型系统，作为 JavaScript 的一个补充，在不同的项目和场景中发挥各自的优势。
JavaScript 和 TypeScript 的技术生态早已融合在一起了吧，几乎所有库都会有 TypeScript 类型文件。
李振：我认为 TypeScript 不太可能完全取代 JavaScript，而是作为 JavaScript 的一个补充和增强。两者暂时不会出现零和博弈，也希望这两种语言都可以有更好的发展。目前来看 JavaScript 的生态更庞大一些，但是 TypeScript 的地位和影响力不断增长。作为普通开发者，在两者并不冲突的当下，最好都能关注其发展。
对此，你怎么看？你手上用着的是 JavaScript 还是 TypeScript 呢？哪个更顺手？
最后
如果你觉得这篇内容对你挺有启发，我想邀请你帮我个小忙：
点个「喜欢」或「在看」，让更多的人也能看到这篇内容
我组建了个氛围非常好的前端群，里面有很多前端小伙伴，欢迎加我微信「sherlocked_93」拉你加群，一起交流和学习
关注公众号「前端下午茶」，持续为你推送精选好文，也可以加我为好友，随时聊骚。
