尤其是过了这么久还能看到这些营销号，然后评论区大家都在集火喷 TypeScript 。
实在是不懂为啥静态类型会惹来这么多人厌恶，更不用提这个 PR 还有个更严重的问题 - 在多人协作的项目里直接 force push 了。
本来还想写点啥吐槽一下，然后感觉累觉不爱，只能说这位社区领袖直接把 Ruby 这个语言对我的吸引力拉到近乎于 0 的状态。
顺便引用一下一个算得上是爆典的修改：
68 | async function gotoPageWithFormMode(page: Page, formMode: "on" | "off" | "optin") {
68 | async function gotoPageWithFormMode(page, formMode) {

用户获得了在formMode里传入 null 、undefined 、114 、5.14 、"1919"和new Date()的自由。

你对营销号很无奈，我对你因为营销号而迁怒 Ruby 也很无奈。一方面我理解很多人不爱讲道理，喜欢让情绪胡乱蔓延，比如报喜讯的信使获得奖赏，报坏消息的信使被砍头，但人家信使是无辜的啊；同时欲加之罪何患无辞，你也可能本来就讨厌 Ruby ，或者人家移除 TypeScript 的时候你就已经生气了，现在说什么“营销号刷屏”导致你讨厌 Ruby ，搞得好像“营销号刷屏”是主要原因似的，但这也可能只是借口而已。这些我都理解，但我也很无奈，为什么不能理性一点讲逻辑讲道理呢。

three.js 移除官方 ts 支持时候很多人也觉得挺无奈的

静态类型没问题，厌恶的不是静态类型，而是不友好的语法带来的开发成本、理解成本、心智压力，TypeScript 这种语法我感觉有点怪异，乍一看不是很直观。比如 let name:string = ''，如果是更符合常规静态语言习惯的 string name = '' 就好了。不过可能作者考虑到 js/ts 混编、迁移等场景，let 开头这样更方便吧。刚看了眼苹果 swift 语法，发现居然引入了 js 的 var/let 这种动态类型，说明这种便捷的方式接受度高。从 objctive-c 到 swift 实际上也变成了强制静态类型到可选动态类型。对比近日 vue3.4 会取消实验性特性语法糖$ref ，看了原因解释我也很理解，在看原因之前我觉得语法糖真方便，看了取消的原因发现确实很有道理。

那完蛋了。现在类型在后就是趋势，你可以去查查这种方式的好处在哪儿，相关资料已经很多了。

我主要做前端和 PHP ，动态类型用得多，静态接触少一些哈哈。没怎么关注。

变量定义只是举例，除了这个整个 TS 的语法我都不是很喜欢。

他可能只需要 TS 的一个很小的子集，不喜欢类型体操那些东西JS 好像有提案要原生支持类型注解，到时候 TS 的位置一定很尴尬。如果是为了长远考虑去除 TS 其实是能够理解的不仅仅是他，Svelte 的作者 Rich Harris 在重构 Svelte 代码库的过程中也用 JSDoc 取代了 TS

js 原生支持类型就好了，支持。

静态型其实是一种倒退。你写逻辑为什么要关心机器底层的实现细节？就像你使用 ChatGPT ，你还必须整理清楚 每句话说的东西的变量？这些细节都应该被抽象层屏蔽掉之所以这种东西反复摇摆，静态型只对机器有利，大量使用对于机器优化的 feature ，说明机器又比人贵了。

静态类型确实有价值但 typescript 其实一直我都用不太好，因为有一些诡异的类型错误，你就不容易 debug

真 tm 神论，那你变量也随便 abcd 得了，没必要想个意义出来

静态类型好点

＃3 Swift 的 var/let 跟 JavaScript 的完全不是一个意思。而且 Swift 是非常强静态类型的语言。

let/var 就动态类型了那说明你没理解什么是动态类型。那只是自动类型推断。

前端程序员的至暗时刻：10 ， 别人发布的 npm 包没有 d.ts9 ，给自己发布的 npm 包写 d.ts楼下补充

DHH 对前端社区的抨击可远不止静态类型这一个：反对微服务、反对上云、反对 SPA 、反对 WebPack 、反对前端渲染，推 Turbolinks 、推 Stimulus 、推 HTML over WebSocket. 以前 Rails 社区普遍对 EmberJS 有好感，这个框架一大卖点就是纯 JavaScript.这里是他在今年 Rails World 大会上的演讲： 不针对 TypeScript 这件事情，只能说 DHH 这个人虽然有些偏执，但他的这套解决方案对某些开发者的确比目前所谓的「主流」方案更合适。另外 Ruby 社区对整个 Web 开发领域的贡献可能比人们想象的大。Sass 的最初版本是 Ruby 写的，各种 env 管理工具的始祖就是 rbenv ，没记错的话主流语言包管理器里最早有 lockfile 概念的也是 Ruby 的 Bundler ，Rails 对 REST 和 12-factor apps 的贯彻到现在很多框架都没做到，而引入前端编译工具是在 2011 年。GitHub （至今也是一个 Rails 应用）最早就是 Rails 圈子出来的，所以很长时间里 GitHub 项目最多的语言是 JavaScript 、Ruby 、Objective-C （那会要做 iOS 和 Web ，全栈三语言）。DHH 最早给 Rails 做的演示视频用的是 Mac ，那会还在 PowerPC 时代，苹果甚至找 DHH 拍过商务宣传片（ twitter.com/dhh/status/1329062154151063552 ），那会只有很少的开发者用 Mac ，这对后来 Mac 的流行多少有点影响

尴尬什么，js 的类型提案就是做 ts 的人提的😅

ts 出来之前，ts 出来之间，大家不写程序么。 TS 只是加个 type 而已。TS 出现之前，很多类型注释工具都可以更好的，无入侵解决这个问题。

没有类型定义是很可怕的，就像 java 里用 map 传参一样，你根本不知道里面可能有哪些键，只能看文档，自动提示也没了

因为写 typescript 确实烦人

DHH 本质上他是半个 business guy ，他的第一要务是把好产品做出来，成本是最需要去考虑的事情。我觉得 Rails 的 turbo 真的是太好用了，用过一次就知道，如果只是小团队，小而美的产品，前后端分离就是累赘，turbo 把很多事情都变得非常简单。我曾经把一个 2 前端+3 后端前后端分离的 react 项目，用了 turbo 之后，只需要 1 前端+1 后端就基本替代了，并且达到了类似 SPA 的效果。对于他这样的 business guy 来说，简单，易用，方便，节省人力才是第一要务。我不是说前后端分离是错的，而是对于某些产品来说，前后端分离可能真的不是一个最优解，现在的有些人逢项目必前后端分离真的有点像是邪教。

对于类型，我一直不觉得这东西有多好，如果在一个程度上我可以减少代码，但是 bug 并没有增加，那为什么需要这个类型系统？大量的代码维护，心智负担，我不觉得我需要去承担这些。DHH 早年也说过，去查过 github 很多静态类型语言的项目，他们的 bug 数量并不会因此减少，所以引入了大量成本，但是 bug 并没有因此减少，这个成本带来的价值在哪里？只是某些类型 fans 的自我满足吗？我自己用也是这样的感觉，就像 ruby 的类型系统，看到都不想用，引入的成本实在是太高了，这东西可能对一些超大型项目有一些价值，但是并不是每个人都能碰到这类型的项目，1w 行都对我来说都是大项目了，所以我也感受不到类型有什么用。

确实很反智，python php 不都在推 type hint 吗，动态语言静态化是个趋势要是说 typescript 的设计方案有问题，写起来麻烦确实是一个合理观点，但有些人上升到反对静态化就没有讨论必要了

ts 对于 lib dev 和 app dev 完全是两种难度。对于 app dev 来说，ts 基本是直接用就行了，文档都不怎么要看，直接大幅提升 dx(developer experience)。但如果是 lib dev ，ts 根本就是魔鬼难度。dhh 和 svelte 虽然都删掉了 ts ，但完全不是一个性质。svelte 是用 jsdoc 取代了 ts ，类型还是有的，用 ide 的时候 dx 还是一级棒，目的是降低 svelte 本身的开发维护成本。dhh 直接删掉了类型。。。绝对是损害了 dx 。

这年头不都这样吗，相似观点的人抱团，很明显这种话题下就是反 ts 的抱团

新一点的语言不都是这个设计，rust 的 let a:Vec，go 的 var a string

这哥们很有意思啊

看了一眼 DHH, 脑子里不禁问了句 ROR 作者就这?

至少他言行一致啊，他反对的东西和推崇的东西，都在他的商业产品力得到了实践，并且能拿出统计数据，有理有据的表明他的这些决定都是有价值的。详见 ＃16 楼的视频。比如从云上搬下来，每年节省了 150 万美刀服务器费用。参考： shiftmag.dev/leaving-the-cloud-314/ world.hey.com/dhh/why-we-re-leaving-the-cloud-654b47e0在技术圈逐渐饭圈化的今天，很多人只会无脑的跟着混圈子，仿佛加入了这个圈子就掌握了未来，对不愿意加入圈子的人无脑诋毁。技术是为产品服务的，产品需要考虑的是效率、成本和质量。DHH 是一个典型务实型的技术人员，他的一切技术选型都是围绕产品出发，而不是为了技术人的自嗨。PS：DHH 从来没有反对语言静态化，只是他个人不喜欢 TypeScript ，更喜欢 JavaScript ，他也没反对你们用 TypeScript ，被他移除 TypeScript 的项目 turbo 是他们公司主导的开源项目，他们作为项目的主导方，应该有权选择自己的技术实现细节吧。如果某天微软在 TypeScript 上使用了一个你不喜欢的技术实现，你也要组织人是去网暴吗？

汽车出来之前，大家不出行么。汽车只是代个步而已。汽车出现之前，很多坐骑都可以更好的，无加油解决这个问题。

高级语言是给人类看的，引入新的语言要能降低项目生命周期内人的心智负担，不然就是扯蛋

＃3 Swift 的 let/var 只是类型推断，本质还是静态类型

＃7 原生支持类型注解 都是微软提的，TS 尴尬什么

DHH 或者 ruby 社区也好意思抨击 webpack ，我觉得他们圈子整的 node-sass 才是前端最大的毒瘤。前些年跑 npm 踩的坑，至少一半以上都是 node-sass 闹的。

讲个笑话，连 TS 都不愿写的人（大神除外），说自己愿意写更啰嗦的 JSDoc 。

反智而已，小丑

说实话我并不讨厌 Ruby ，甚至以前还有一些兴趣（可能因为是比较早就流行函数式写法的原因），只是说现在会觉得没太多兴趣了。 看了一下 three.js ，说法并不是移除 ts ，而是把 ts 支持转交给专门的团队来做，这和一个 force push 直接覆盖掉整个主线有本质上区别吧。 类型是和数据建模直接相关的，这难道不是逻辑的一部分吗？静态型才能够提供类型推断，TypeScript 之所以有时候还需要写类型标注恰恰是因为 JavaScript 太灵活。 所以更不懂关于 TypeScript 的争论了，再不济写 any 也好过吧 对于 lib 来说删掉 TS 算是一种选择，但是按理来说删掉 lib 应该引入单元测试和文档来覆盖掉类型本应起到的作用，然后一堆人在那里抨击 TS 却对文档和测试闭口不谈…… +1

不会 swift,就看了下语法，我想表达的是它这样写代码不用显式申明类型。

再见啦，Ruby on Rails blog.wildcat.io/2023/09/goodbye_rails_zh/

node-sass 关 DHH 的 p 事？反智过头了

关 ruby 社区的事

看完这个帖子，我对一些用 js 的人真的大开眼界

灵活不是缺点，瓶颈的问题在于人，以及人的设计。想通过类型想要消灭 BUG 是不可能的，也是徒劳。动态语言一开始便不提供这种幻想。现在之所以回到静态型无非就是业务开始固定，人力便宜，机器昂贵。这是老板降本增效的方向，并不是程序应该发展的方向。

你好像搞错了Sass 是 Ruby 社区发明创造的。Node-sass 是 Node 社区重新造轮子。Node 轮子造的不好，不能怪 Ruby 社区。Ruby 带来的先进理念，现在还被其他语言学习和模仿。

如果拿汽车发动机比喻，动态性是自动挡，静态型是手动挡。你的比喻弄反了。动态语言抽象等级更高。程序的发展方向是抽象化。

虽然写纯 js 的大神很多，但是身边统计学，嘴上排斥静态类型，手上整活儿出不可维护代码的，大部分是为了坑人稳定自己地位的...

node-sass 是 sass 官方 libSass 的封装，libSass 是用 C++写的。如果 node 社区真要重复造轮子，肯定会选择用 js/ts 来重新实现。比如 less 、stylus ，这两家都是 js/node 背景，安装体验也比 sass 好。后来 sass 官方自己倒是重新实现了 sass 编译器，但居然是用 dart 来重做。所以，联想这个社区还曾经鼓捣过 coffeeScript ，我无端猜测，这个社区别说是对 TS 了，对 JS 都鄙夷。那些只写 JS 的开发者最好别跟风起哄，说不定他下次要移除的就是 JS 。

是的，也就这而已，一个用 ruby 发家致富，然后把开发拿到的钱拿去开赛车比赛的男人，不会开赛车的男人不是好程序员

3202 年还有人认为静态类型描述的是底层实现？看你头像应该是个学过函数式编程的人，为什么会发表这样的爆论

let name:string = ''这种写法是很少有的，统计过我的代码，20 个变量声明里，只有一个用写类型，其他都是自动推断。唯一需要写类型的原因，还是是 File[]这种复合类型。string name = ''这种写法，就不适合自动推断了。你可能会说 auto name = ''也可以自动推断。但是，跟 const 连用就成了 const auto name ，中间这个 auto 要不要留就又是一个争论。

我做外包，坚持使用 JS ，而不是 TS ，显然用人成本低很多，，周边做外包用 Java 、TS 的团队基本都死光了。

有时候显式类型标注可以起到文档和契约的作用，当然一般来说不是 string 这种简单类型而是复杂的 model 或者联合类型。静态类型的意义是这种写法是完全可选的，哪怕没有注解，也可以根据上下文尽可能推断出变量的类型（ File[]算是少数反例了，但至少静态类型能推出个 any[]来）。动态类型里面完全没有这种契约关系，所以真的要把类型约束推出来的时候，还得四处添加 userland 的 type hint ，而这就是 Turbo 的用户将要面对的情况（或者完全不考虑这些写面条代码）

www.zhihu.com/question/623259697/answer/3223957909本来就不是给正经 web 前端用的框架，所以也不应该因这些项目的技术路线去评价 web 技术栈

所以那些只写 JS 的程序员借这个话题抨击 TS ，还以为找到大神为自己站队似的，很可笑。

用的太久了，有一种类似“审美疲劳”的错觉吧。就像陈坤那些“音乐人”一样，在巅峰太久了，反而感觉大众化的内容太“俗”，“土里土气”反而是一种异样的美，就像现在的 “低代码平台” 比 visual basic 6.0 一样。

我的理解如果 type 在一些语言里是和底层硬件绑定的硬件细节。我觉得我们不需要关心。底层应该被抽象层屏蔽。如果 type 是抽象层的接口描述，那么其实没必要大动干戈，以前有注释工具还能生成文档。现在用一个语言来分裂整个生态，是很差的选择。一些语言提供辅助的类型注解。如果你觉得 type 可以消除 bug ，你会失望，这只是一个幻想。动态语言一开始就不提供这样的幻想。无论哪个层次，type 都没那么重要。

不加类型，重构的时候咋办？当然如果都是用完即弃的代码，当我没说。

vscode 不支持 3.7 了，公众号大多都报道未不支持 3.x 了。因此，我取消了几个公众号的关注。我现在将我的方法推荐给你。

TypeScript 是 JavaScript 的超集，首先就要保证 JS 能在 TS 的系统里面跑起来。另外 String name = '' 也不一定就是最好的设计，都已经给出初始值了，let name = ''，TS 也能推断出类型了