Ruby on Rails 作者 DHH 移除了他们开源项目 turbo 中的 TypeScript 代码，大家怎么看

[byj66]

DHH 移除了他们开源项目 Turbo 中的 TypeScript 代码，这在推特上引起了很多的讨论，有人赞同，表示欣赏他们的勇气；有人反对，表示这是开历史倒车。我不明白这造成的影响，请问大家怎么看？

推特链接： https://twitter.com/dhh/status/1699427078586716327

文章链接：Turbo 8 is dropping TypeScript

[agagega]

@keithwhisper
这个好理解。在我看来所谓的开源项目的开放程度本来就分几个级别：

- 只开源给你看，带个开源协议，但不让你交任何代码，比如某些国内 KPI 项目
- 按照协议开源了，但只接受修 bug 这样的补丁，不接受任何 feature ，比如苹果 darwin 开源那堆东西
- 社区可以加 feature ，但整个项目是由某个公司主导的，公司要加的 feature 社区很难反对，比如苹果的 swift ，微软.net
- 社区有足够大的影响力，但整个项目只有一个人有最终裁决权，比如以前的 python
- 项目由基金会产生的核心团队管理，核心团队成员有 term ，重要变更经过社区讨论后由核心团队表决

[YuJianrong]

其实这没啥。
一两个项目宣布不用 TS 恰好说明 TS 是更广泛的选择。
等哪天什么著名项目不用 TS 也不成新闻了，那 TS 就真的危险了。

[dayeye2006199]

DHH 是个非主流，很喜欢反潮流搞事情。
他们公司著名的下云行动（从 AWS 挪到自己的裸机上）
为了配合下云行动，直接把 k8s 也扔了（自己开发了个类 k8s 的编排系统）

但是这货的 coding 能力是真的强，写东西太快了。

[WildCat]

再见了，Ruby on Rails

https://blog.wildcat.io/2023/09/goodbye_rails_zh/

[SolidZORO]

不要听风就是雨，ts 该用用。不用低级错误会淹死你，以及类型没提示也很难受的。

侧面说明 DHH 是个狠角色，那么香的 ts 说 drop 就 drop 。

[geelaw]

@keithwhisper #19 建议不要重新定义 open source ，开源并不代表应该、需要接受社区的意见、帮助。你所引用的评论也混淆了开源准确定义和“包容开放社区”的想象。

[xieyuheng]

我知道第一个这么做的是 deno ，最近这么做的是 svelte 。

jsdoc 的体验，作为 library 的作者，比 typescript 要好的多，可以直接运行你写的代码本身就是应该的事，ts 也不是很在乎优化开发者在这方面的体验。

只要用了 ts ，不光要有一个 build 步骤，还必须要有 bundle 步骤，你的代码才能被别人用。

而且 ts 团队明确说了不会改进这方面的体验，真的太横了，你爱用不用，人家不在乎。

[dif]

经常写 Java 的，对于弱类型语言很是不适应，但 js 也好，TS 也罢，能实现就行了。

[acthtml]

大仙可以赤手空拳，我们还是拿上个兵器吧。

[maocat]

AnyScript 诚不欺我

[ruoxie]

想不通，用得舒不舒服自己不知道？被人用了才能用？什么卵风气

[justdoit123]

写写小脚本、小应用，倾向于不用。

但是，项目一大，你怎么知道 item 、data 、form 等等这些对象有什么属性？靠 JS + VSCode 是不靠谱的，补全不精准，重命名也是个大硬伤，动不动把很古老的文件里的同名属性也给我改了，这怎么能忍？

经常看到有人吐槽 AnyScript 。说到底要嘛学得不深，要嘛由钻研得太深。该用 any 、as 、!的时候，你就大胆的使用。然后尽量不要类型转换超过 3 次，这种类型体操做起来累，看起来也是很累！ TS 已经是可以渐进式的使用了，别一上来自缚手脚，搞个火箭发射台。

[justdoit123]

还有，凡事多先自己体会下，技术圈有点娱乐化了，尤其是前端。这种现象感觉也开始蔓延到后端。天天要用新技术重写一个世界。最近感觉吐槽 Go 的文章开始多起来了，然后开始吹 Rust 。估计再过个一两年，今天的小甜甜，也要变成牛夫人。

你管他大佬不大佬，大佬还能帮你写 CRUD ，还能帮你写基础建设吗？大佬，也会犯错误。

[Justin13]

小项目能不用就不用，短平快最好
大项目想不用都不行，别给自己挖坑

[vsitebon]

这件事情影响的是已经开了的 PR ，意味着这些 PR 都要重构代码（如果有引用类型的话），而且看评论这件事情并没有通知对应的 PR 作者

[zjsxwc]

@mistkafka
JSDoc 可以类型推导的。

[zjsxwc]

DHH 移除 ts 的理由
https://world.hey.com/dhh/turbo-8-is-dropping-typescript-70165c01
```
TypeScript 对我来说只是阻碍。 不仅因为它需要显式的编译步骤，还因为它用类型体操污染了代码，这给我的开发体验增添了很少的乐趣，而且常常带来相当大的悲伤。 应该容易的事情变得困难，困难的事情变得“任何”。 不，谢谢！
```

Svelte 为什么要移除 ts 的理由：
```
它增加了主要的进入壁垒。 这意味着——

在开发应用程序时对库进行基本调试期间查找库的源代码非常复杂。

人们一开始会偷工减料或砍伐，直到得到有用的东西。 这最终会导致一个毫无意义的过于复杂的配置，引入大量未使用或配置错误的依赖项，然后人们犹豫是否要继续接触它，因为他们不理解它。

只有设置它的开发人员才能理解它。 留下单点故障。

多年来没有人接触过它，甚至开发人员也忘记了它是如何工作的。

没有人会更新导致错误和安全问题的依赖项。

最终，依赖关系被打破（新的操作系统版本需要新的节点版本需要新的构建工具版本，现在默认启用新的 lint 规则，删除不推荐使用的功能等），并且所有内容都会被破坏多天，而实际上所有内容都必须更新。 更糟糕的是，当人们绝望地禁用整个文件等上的 linter 并且永远不会返回并清理它时。

更糟糕的是，当共享构建服务器场、内部 npm 代理等发生重大版本更改时，开发人员都必须同时升级他们的环境。
```

[ChrisFreeMan]

看了很多评论，那些讨厌 TS 的主要是一些底层库的开发者，应用层的几乎没啥抱怨。底层库的开发者清一色抱怨“类型体操”的问题。

[zjsxwc]

总结下理由就是：
1. ts 对于老 ts 代码与包有各种 breaking issues （见各个 ts 版本发布说明里的 Breaking Changes ），每次要维护 n 年前写的老 ts 代码，就要各种兼容性配置行为，来让老代码运行，这些被认为是“无意义”、“不值得”的，
2. js 使用 jsdoc 、import map 已经有不错的强类型体验，
3. ts 对于复杂问题仍旧得用 anytype ，如果一直在基于复杂问题的项目里就各种 anytype ，那还不如用 js ，
4. ts 教徒对于 dhh 的人身公鸡。。

[justdoit123]

@ChrisFreeMan 我认为底层库的最低要求是，声明好接口的参数与返回值类型，保证用的人能清晰的知道怎么调用即可。至于实现部分，如果掌握不住体操，那就 any 吧。