TypeScript被放弃！又一知名前端利器决意转回JS，社区不满：这在开倒车！
撰稿丨千山
日前，Ruby on Rails的创建者David Heinemeier Hansson（DHH）宣布，将从前端工具链Turbo的8.0版本开始删除TypeScript，这一决定引起了开发社区极大的震惊与不满。
TypeScript作为广受欢迎的语言，以其强大的类型系统和优秀的可维护性而出名。所以Turbo 8的决定受到了很多人的质疑。很多Turbo用户表示，这个决定不仅仓促，而且是“不受欢迎的”。
但如果你有留意过前端工具的发展动态，也许会记得，数月前，前端框架Svelte曾宣布将在4.0版本从 TypeScript 迁移到 JavaScript JSDoc。如今，又一个前端工具选择放弃TypeScript，这到底意味着什么？是技术的倒退，还是TypeScript的某种“不合时宜”，或者另有隐情？
图源：X（推特）@DHH
TypeScript污染代码，只是障碍？
Turbo本身并不是最受欢迎的框架之一，但近年来，在Rails世界中，它和Hotwire还是受到了不少关注。
Hotwire 作为一种Web开发的新方法，旨在编写全栈式Web应用时尽可能简化Web开发过程，减少对JavaScript的使用依赖，其中Turbo是Hotwire 的核心组件之一。
借助 Turbo，可以让服务端直接发布 HTML，这意味着所有业务逻辑都能或多或少地只用你所喜欢的编程语言即可实现。所有的逻辑都位于服务端，而浏览器只处理最终的 HTML。
关于为什么要放弃TypeScript？
DHH直接发文表示：“TypeScript 对我来说只是阻碍。不仅因为它需要显式的编译步骤，还因为它用类型体操（Type Gymnastics）污染了代码。“这让他的开发体验苦多乐少，且常常会化简为繁，徒增困扰。
简言之，对Trobo而言，TypeScript有些“麻烦”。
首先，使用TypeScript需要进行额外的编译步骤，而且需要配置设置，这会增加不必要的复杂性。弃用TypeScript将使Turbo 8的编译过程更加迅速，开发流程更为简洁。这将释放出更多宝贵的时间和资源，用来进行其他创新和改进。
其次，类型系统很棒，但类型的引入也可能导致代码变得繁复而冗长，让代码体积变过于庞大。而且有时候，某些简单的事情反而会因为类型相关的限制变得事倍功半。
再者，TypeScript 团队早就意识到无法完全替代 JavaScript，因此他们努力实现了两者的完全兼容。这意味着即使不使用TypeScript，仍然可以使用 JavaScript 编写代码，并且能够使用用TypeScript编写的库。
最后，放弃TypeScript并不意味着Turbo 8放弃了类型安全和可维护性的重要性。相反，Turbo 8承诺将加大对JavaScript生态系统的支持，通过引入新的功能和工具，来提高代码质量和开发速度。更加聚焦于JavaScript生态系统的发展可以让Turbo 8能够更专注于提供出色的开发体验。
矛盾的激化：
不满不仅在于更改，还在于更改的方式
微软的Anders Hejlsberg发明了TypeScript，因为他相信用强类型语言编写复杂的应用程序会更健壮，更容易维护。TypeScript也的确取得了巨大的成功，这一语言在编程社区中的流行表明，许多人都赞成这一点。
但在DHH看来，TypeScript最引以为豪的“强类型”恰恰是障碍。JavaScript 是客户端的必不可少的语言。虽然可以将其他语言编译成JavaScript来在浏览器中运行，但最终还是需要用JavaScript来实际执行代码。因此，在这种情况下，“能够自由、无需任何工具和强类型约束地编写JavaScript代码是一件幸事”。
不过，就社区的反馈来看，多数用户都在不同程度上感到困惑和失望，而且不仅仅是因为这个决定本身，还因为决定的方式。
一位用户表示：“切换回JS意味着许多Hotwire生态系统包将被破坏。目前所有开放的PR现在都已完全过时。IDE将不再像以前那样提供自动完成功能。”
另一位抱怨道，“仓促做出这一重要改变，忽略了所有（我指的是所有）公开评论……开创了一个先例。Ruby on Rails也会这样开发吗？这是一个人的心血来潮吗？”
还有人直言：“大卫单方面且未经讨论就淘汰了多个贡献者的工作。这与TS无关，这关乎对社区和生态系统的尊重。”
对于反对声，DHH早有预见。他在官宣放弃TypeScript时就曾提到，“很少有程序员有兴趣改变他们对类型的看法。大多数程序员发现自己在职业生涯的早期就受到了TypeScript的强烈吸引，然后把剩下的时间花在为自己和他人合理化这一选择之上。”
有网友“翻译”了一下DHH的这段话并开了一波嘲讽：“这段话基本上就是在说，1、程序员不会改变主意。2、因为他们不会改变主意，所以关于这个决定的争论是徒劳的。3、因为争论是徒劳的，所以我拒绝解决人们对这个武断决定的担忧。老实说，如果他只是说‘我正在做一个武断的决定’，而不是用冗长、半生不熟的辩解来表达它，我会更能接受。”
图源：Reddit
随着矛盾的激化，针对少数TypeScript的激进支持者，DHH也“硬刚”了回去，再度发文称之为“绝对精神错乱的开源流氓行为”。
他依然坚持己见：“所有的爱和赞赏都献给那些喜欢TypeScript的贡献者。这是一场争论，争论不太可能改变任何人的基本立场，所以我不会试图这样做。”
一切只是选择：
放弃TypeScript，放过自己
争论尚未休止。除了反对声外，也有人觉得这个决定只是面向未来版本的战略调整，尽管会给开发者们带来一些困扰，但Turbo团队的决策还是很有勇气的。
就像当初Svelte 团队决定放弃TypeScript，转而使用JavaScript和JSDoc注释来实现类型安全。这种方法提供了所有类型安全的好处，而没有与 TypeScript 相关的缺点。
如今Turbo团队的决策到底是刚愎自用还是富有远见？尚需要时间的检验。不过，可以肯定的是，TypeScript终究只是工具，到底要不要用，好不好用，还是取决于开发团队或开发人员的特定需求和偏好。
很多开发人员之所以选择 TypeScript，是因为强类型可以减少错误，如果你追求代码的严谨可靠，并乐于在开发过程里获得更多的工具支持和类型检查，那么TypeScript会很趁手。但如果你和DHH一样，对类型限制感到痛苦，希望能更加无拘束地编写代码，那么放弃TypeScript也是放过你自己。
就像React核心开发Dan Abramov所表达的，“如果你增加TypeScript，我会为你鼓掌。如果你移除TypeScript，我（同样）会为你鼓掌。关键在于是你在更改代码，而不是那些代码在改变你。改变意味着生活，你正生活在其中。”
图源：X（推特）@dan_abramov
参考链接：
https://world.hey.com/dhh/turbo-8-is-dropping-typescript-70165c01
https://www.reddit.com/r/programming/comments/16bufc7/turbo_8_is_dropping_typescript/
https://devclass.com/2023/09/07/ruby-on-rails-creator-removes-typescript-from-turbo-framework-upsets-community