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

Things that should be easy become hard, and things that are hard become `any`

从我自己实际的开发体验来看，原生 JS 最舒服，VSCode 里配合 JSDoc 有着不输 Typescript 的开发体验

不了解 Turbo ，但一般我倾向于用 ts 。让类型系统在编译期捕捉问题很美妙。

因为 any

不慌 [Types As Comments Proposal]( https://tc39.es/proposal-type-annotations/)已经在路上了 这是大势所趋

对于没有专职测试的项目，TS 帮我避了不少坑

没有 typescript === 闭眼写代码

@enchilada2020 才 stage1

赞同为动态语言提供类型注解和推断工具，但不赞成强制使用……

@putaozhenhaochi stage3 了就不用吵了

@enchilada2020 #10 没多少人会去 push 吧，不是痛点也不咋重要

如果一群大佬写东西确实 TS 没那么重要了，Native power

让写 ruby 的人写 类型 估计比杀了他还难受

楼上说的有道理

https://github.com/JuliaDebug/Cthulhu.jl/pull/469 像 julia 这样默认可以不写类型，但提供显示推断出类型的工具就很好

我感到惋惜，类型一个是个伟大的概念，有着远超编程语言的涵义

也不是社区第一个了，前端热门框架 Svelte 也弃用 TS 了，虽然反对的也不少

人可是 ruby 哥

其实这个点比 `是否移除 TypeScript` 更重要

> This PR, created 3h ago and merged 1h ago, seems very rushed.

> This PR fundamentally changes the library. It changes the library's main language. I don't see the need to rush this? Why was this rushed?

> Was there any prior discussion on this change?

> This is an open-source library, not just source available.
> There are many other open-source libraries using this library directly or indirectly.

这个行为导致这个项目只是 public, 而不是 open source

Ref: https://github.com/hotwired/turbo/pull/971#pullrequestreview-1613489798

开始我也不太想用 TypeScript ，但从头开始写新项目的时候强制使用时有点不习惯，但是过 2 天再看自己写的 TS 代码和 JS 代码，理解起来 TS 的容易很多。

慢慢的习惯了 TS ，越用越觉得好用。

JS 是开始写的时候快速方便，但是 JS 的代码可维护性远不如 TS 的。

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

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

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

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

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

再见了，Ruby on Rails

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

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

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

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

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

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

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

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

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

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

AnyScript 诚不欺我

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

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

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

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

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

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

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

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

@mistkafka
JSDoc 可以类型推导的。

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

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

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

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

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

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

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

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

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

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

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

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

先说下我的开发背景, 大概有五年左右的 TS 使用经历, 在两个大型项目中使用过 TS 的严格模式开发.

结论: 从 TS 迁移回 JS 将会是一件常见的事情

TS 对于库开发者来说是很重的心智负担, 我的库开发选型是 vite + vite-plugin-dts

1. 经常出现只生成了 .d.ts, 或者只生成 .js 的情况

2. 在测试时, 经常出现 LSP 没有更新的情况, 导致测试代码时提示语法错误, 必须要手动重启 TS 服务

3. 为了编写复杂类型导致开发本末倒置

以及诸多小问题, 这些小问题合在一起就变成了很影响心态的大问题

TS 对社区的贡献是不可否认的, 但是我想我下一次开发库会选择 Vanilla JS + .d.ts(or jsdoc)

我的工作会用强类型的.net 和 Java ，也用弱类型的 Python ，所以我觉得这和个人开发经验背景有关，习惯了强类型开发平台，会预期所有变量都是确定类型的，在思考代码逻辑时有确定类型会比较顺畅，没有类型就有心智负担得时刻记着变量的实际类型和结构，若没有充分的注释说明，可能不久后重看代码时就会忘记为什么这么写，如果有较好的辅助工具或框架可以解决这个心智负担，弱类型开发平台也会很方便。我认为关键在于一个解决方案可以让开发者将编码重心放在处理逻辑上，而不是分心解决类型可能引发的各种问题，大佬可能不需要借助工具什么的就能做到，但大多数还是需要有效的工具或框架，哪个方案好就会有越来越多的开发者选择。

https://github.com/hotwired/turbo/pull/972
😂

@leeg810312 虽然但是，python 也是强类型

我估计你想说的是动态静态

一个坐吃山空的人管他作甚。。。

咱们一般的开发者还是要冷暖自知，小马过河的故事听过没有

他能坐吃山空，一般人有那个山可供坐吃吗

@tairan2006 经常一堆人分不清强弱、静态动态的啦

纯个人偏好而已，团队代码管理好就可以不用，管理不好就别试图打破常规了。

刚看了下推特，有人说这是作者在推广... 在此之前确实不太了解 turbo... 现在知道了

如果你不是大牛，如果你的团队中不都是大牛，那么就选择 typescript 吧

开源项目也难拜托一言堂

可能他写不出屎山代码
也可能未来 turbo 变成屎山之后又会发一篇文章：《 TypeScript is back!》

ts 感觉是内卷下的产物..但凡说会 ts 的.工资喊出来都翻倍..前端最明显的..
对于快速开发的产品.根本就不合适做业务
说白了.业务..不可能说增加一个字段..就全链路都要改.都要去定义..

TypeScript 大法好

大佬就是任性，乐趣驱动。

对是否使用 ts 不做评价。但很明显这个项目就是一言堂，对这种项目最好不要做任何贡献。

对于精通开发，逻辑清晰的人来说，TS 是降低效率的罪魁祸首之一。

TS 还没有普及之前就已经很成熟使用 JSDoc/ESDoc 来让 IDE 自动检测潜在问题了，再配合 Linter ，能避免不少问题。

我个人认为，因为 JS 实在太灵活了，所以对开发者要求很高，开发者要从众多可行方案中选择一个最佳的，同时利用经验规避各种问题。
TS 解决问题的核心思路其实就是降低灵活性，增加各种限制和强制做一些工作来避免问题，这对用 JS 很 6 的人来说可能会有些不爽。

但归根结底 TS 只是一个面向企业生产的工具产品，如果根据实际项目和团队情况来评估 TS 可以提升效率，那它就是有价值的。

我只知道 Ruby on Rails ，没听说过 Turbo 8 。
简单看了看这个项目的文档，似乎用起来几乎不需要写 JavaScript ，只是写一些 HTML 标签。对使用者应该没什么影响，给这个项目贡献代码的人可能比较难受。

@tairan2006 并不是，我知道 Python 是动态类型，不过我没有看到 python 官方说自己是强类型语言，我看到过的都是社区自己讨论的结果，如果官方有说过请指出。我不认为 python 是强类型，因为它可以进行超出隐式转换的类型转换，动态类型是在运行时决定类型，但我认为一旦确定类型，就不能能随意变更，如果变量在作用域内最多只能做隐式转换，我就认可它是强类型

贴个经常要处理的 python 问题。

TypeError: unsupported operand type(s) for -: 'int' and 'NoneType'

不是针对 python ，只是刚好又要修个这种 bug 。js 也是一样，经常有 undefined 问题。

写代码的时候，脑袋里还要记忆某个属性存在不存在是真 tm 的累。然后，这种 NoneType Error 、undefined 问题还是数据相关的，可能你开发的时候压根不会碰到。

@leeg810312 自由心证是吧，要不你问问 chatgpt……

@tairan2006 原来 chatgpt 是圣经啊，说什么都是对的

@leeg810312 毕竟你是自由心证，“我不认为 XXX”，我也没法反驳你啊。GPT 是大模型训练的结果，反映了大多数人的认知，我觉得你跟他聊聊挺好。

@tairan2006 官方都没有说过的话，你说的就是对的，别人说的就是不对，原来学术问题可以多数服从少数是吧

@mywaiting #2 歪一下，老哥你的 keptab 突然从谷歌消失了，啥时候能上架？我重新安装后数据是否还在啊

@Rendex 商店介绍图片右上角有个 NEW 字样，说违反商店规则给下架了~~

我已经准备好新版本了，增加了 tabGroups 的处理，这几天重新上架吧

重新安装，建议先导出数据，以保证数据的绝对安全