整理 | 屠敏
出品 | CSDN（ID：CSDNnews）
作为 JavaScript 的一个超集，TypeScript 在微软内部沉淀两年后，带着弥补 JavaScript 在开发大型应用中遇到的种种问题的使命，于 2012 年 10 月正式面世。
然而，近几年来，曾经如日中天的 TypeScript，接连受挫，遭到各个社区与应用的摒弃。前有 Svelte 创建者 Rich Harris 选择从 TypeScript 转向 JavaScript 和 JSDoc，今有 Ruby on Rails 的创建 DHH 在多平台发布声明，宣布「再见了，TypeScript！」
这也让众人深感好奇，TypeScript 怎么就成为了开发者眼中“不值得”的技术之一？
DHH 发布声明：Turbo 8 正在放弃 TypeScript！
首先，简单介绍一下，DHH 是谁。
在开发圈，也许不少人对 DAVID HEINEMEIER HANSSON（简称 DHH）并不陌生。他被人们视为软件天才，以开发了开源项目 Ruby on Rails 而被众人熟知，Hulu、GitHub、早期的 Twitter 都使用了这种框架。同时，DHH 也带来了一款软件即服务的产品 Basecamp，担任 37signals 的 CTO，是一位长期活跃的社交媒体用户和畅销书籍的作者。
他官宣弃用 TypeScript 后，这一决定首先会应用在 JavaScript 库 Turbo 8 身上。
Turbo，是一种用于传递 HTML 页面的框架，指集成了几种技术以创建快速的、现代的、渐进式增强的 Web 应用而不需要使用太多的 JavaScript。借助 Turbo，你让服务端直接发布 HTML。
对此，DHH 表示，“从各方面来看，TypeScript 对微软来说都是一个巨大的成功。我看到很多人因为 JavaScript 中加入了可由编译器检查的显式类型而欢欣鼓舞。但我从来都不是它的粉丝。五分钟后不会喜欢，五年之后也不会喜欢。因此，我非常高兴地宣布，我们将在 Turbo 8 的下一个大版本中删除 TypeScript。”
TypeScript 替代不了 JavaScript
相较之下，DHH 坦言，他其实更喜欢 JavaScript。
「我甚至可以说它是继 Ruby 之后我第二喜欢的语言。不过，更早之前并非如此，但自从 JavaScript 中有了适当的类，以及 ES6 之后的所有其他改进之后，编写 JavaScript 就成了一种真正的乐趣」，DHH 写道。
JavaScript 虽然不适合在网络应用程序的服务器端所做的大部分工作，但现在拥有如此强大的 JavaScript，浏览器无需编译器就能解释它，这是让 DHH 感到非常幸运的地方。
现如今之所以放弃 TypeScript，和过往很多人一样，DHH 透露主要是因为 TypeScript 的「类型」。他的博客中写道：
对我来说，TypeScript 就是个障碍。不仅因为它需要一个显式的编译步骤，还因为它用类型污染了代码，给我的开发体验带来的快乐少之又少，而且经常会带来相当大的痛苦。本应简单的事情变得困难，而困难的事情变得”无处不在”。
不过，这并不是要让任何人改变什么。正如我在《编程类型与思维方式》一文中所讨论的，通常很少有程序员有兴趣改变他们对类型的看法。大多数程序员都会在职业生涯的早期就发现自己强烈地倾向于或不倾向于 TypeScript，然后在余下的时间里向自己和他人解释 “正确的选择”。
这就是 JavaScript 与 TypeScript 二分法的魅力所在，TypeScript 的支持者意识到完全替代 JavaScript 是不可能的，所以从一开始就必须实现完全兼容，这一点值得称赞。Turbo 8 弃用 TypeScript 并不意味着你不能用它编写客户端代码，或使用任何其他采用它的库。我们可以混搭使用，这很好。
这也是必要的。因为 JavaScript 与 Ruby 等语言不同，后者是服务器端的首选语言，而 JavaScript 则是客户端的必需语言。虽然你可以将方言编译到 JavaScript 中，但你仍然必须接受这样一个事实：在浏览器中运行代码就意味着运行 JavaScript。因此，在这种情况下，能够不使用任何工具、不使用任何强类型来编写 JavaScript 是一件幸事。
所以，再见了，TypeScript。愿你为你的部落带来更多严谨和满足，同时让我们其他人享受 JavaScript 最初设计时的光荣精神：没有强类型。
因为”类型“，越来越多的人加入了放弃 TypeScript 的队伍
事实上，DHH 并非是第一个宣布不想再用 TypeScript 的开发者。
早在 2020 年，Deno 宣布弃用 TypeScript，还给出了五个理由：
-
当更改文件时，TypeScript 的编译需要几分钟，这使得项目文件的连续编译非常缓慢。
-
在创建实际的 Deno 可执行文件和面向用户的 API 文件时，使用的 TypeScript 结构会造成项目运行的性能问题。
-
事实证明，TypeScript 本身对 Deno 代码管理没有帮助，并且 Deno 团队正经受着相反的效果。在项目的议题列表中就提到一个问题：在两个不同的位置产生了相同的独立主体类。
-
必须手动保持内部代码和运行时 TypeScript 声明的同步，因为 TypeScript 编译器对生成 d.ts 文件没有帮助。
-
Deno 团队需要去维护两台 TS 编译器主机：一个用于内部代码，另一个用于外部用户代码，尽管两者的目标相似。
除此之外，也正如文章伊始所提及的，Svelte 创建者 Rich Harris 认为 TypeScript 对开发库来说“不值得”，所以让团队选择从 TypeScript 转向 JavaScript 和 JSDoc。
在他看来，“类型确实很棒，但 TypeScript 有点麻烦……一旦用上了.ts 文件，就必须同时使用支持它的工具……所以我逐渐觉得，使用 TypeScript 这样的非标语言并不值得。于是，我们开始将所有类型都放入 JSDoc 注释，这样既保证了类型安全，又回避了缺点。毕竟这只是 JavaScript，所有内容都在注释当中，只要运行代码就行。我们在 Sveltekit 代码中就是这么做的，效果非常好。所以对于 Svelte 4.0，我们也将采取同样的思路、借此加快开发速度。”
不久之前，redux-saga 的工程师 Eric Bower 发布了一篇《Typescript 对于库开发人员来说很糟糕》的文章，其中他从 TypeScript 的说明文档、调试、复杂性、测试等多个维度分享了对 TypeScript 的不满。
Eric Bower 表示，”类型会给库添加大量代码……我发现相较于编写库代码，我花在类型调整上的时间要多得多。我精通 TypeScript，但我不是专家。令人沮丧的是，在花了多年时间编写 TypeScript 代码之后，我仍然不具备作为库开发人员使用 TypeScript 所需的知识。精通似乎是一个上手 TypeScript 的门槛。这里的万恶之源就是类型，它让 js 库维护变得困难重重，断绝了后续开发者的贡献参与通道。“
不过，并非所有开发者都对 TypeScript 的类型避而不见，在 HN 上，也有很多程序员展开了激烈的讨论。
其中，一位名为 waterluvian 的用户表示：
多年来，我一直对 “会拖慢我速度的额外复杂层 “有抵触情绪，后来我采用了 TS，现在我已经离不开它了。
因此，作为一个粉丝，当我读到这样的事情时，我会尽力去换位思考，试着从他们的角度去理解。但在这种情况下，我真的很难做到。
我知道它增加了一些复杂性。但如果没有它，你又能得到什么呢？这并不是说类型会消失。它们不会消失。它们只是变得隐蔽了。它把计算机擅长的东西塞进了你的大脑。正如很多人指出的：类型更多的是一种文档。
但除了这些（我觉得这是最重要的一课）：当支持率达到 100:1，你可能就错了。但有时你最多只能说：”我根本不了解你们这些人，但你们是绝大多数，所以不管我喜不喜欢，我都必须保持现状”。
对于 DHH 此次弃用 TypeScript，在 GitHub pull request 板块，也有用户评论道：“我不确定删除 TypeScript 是否是最好的方法。对我来说，TypeScript 对我的贡献确实很大，而且我觉得在库级代码中使用它仍然很有意义。你从中获得的 DX 真的很有价值，实际上有助于捕捉 bug。但我也明白，在某些情况下，它很快就会变得很烦人。但完全删除类型（即使没有 JSDocs 和/或 .d.ts 文件）对于库用户和贡献者来说都是一种退步。”
对此，你是否使用过 TypeScript，你如何看待它的类型？
本文文字及图片出自 CSDN
你的反应是：