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