为什么你们要选择 TypeScript？

[BoringTu]

我只是不明白为啥这么多人会选择 ts ？理由是啥啊？ ts 出来的那年我就关注了，但所有的理由在我看来都是莫名其妙的观点，但这些年怎么还用的人越来越多了？
咱就说脑回路很神奇的把本身弱类型为优势的 JavaScript，套了一层强类型的壳的这步操作我就看不懂了，这是图啥呢？这样代码写着不难受么？那你直接用 Java 写然后编译成 JavaScript 不好么？
网上有很多人说，用 ts 可以减少因类型导致的错误。大哥，你是个程序员，你连自己写的代码是怎么跑的都不知道的话，转行好吗？我十一年的程序员了，js 写了 11 年，js 的其他高级语言我也都研究过，包括 ts，但现在只用 es6 和 coffee2，我怎么就一次都没碰到过我连变量背后的值类型导致的 bug 呢？

[tobeyouth]

@BoringTu 对，就我个人而言，如果明明是 int，但是文档里写成是 string，这个几乎是无法容忍的错误；
如果是合作的同事觉得这个甚至不算什么问题，那我肯定是非常难受，甚至难受到回去帮他修正文档 or 离职；

还有一点，如果前后端都用 ts，可以省掉很多对接口的工作，大家直接甩 interface 就好了；对于后端非 node 环境，其实也有解决方法，如果后端工程师会使用类 marshal 的工具来序列化输出的话（比如用 Python ），直接看 schema 写 interface 也不是什么难事，如果你喜欢，也可以把 schema 走一遍 ast 直接生成 interface ；

总之，我个人感觉如果前后端的合作者都对输入 /输出有明确定义，很多时候其实不用文档，这样也能减少很多沟通成本。

[BoringTu]

@Kasumi20 github 光秃秃是因为绝大部分项目都是非开源的，不是在 gitee 上就是在工蜂上，而且还都是私有的
博客打不开是因为一开始 https 的证书过期了，再之后 vps ip 被墙了，我就再没去管
然后反问一句，有什么关系么？能说明啥？我现在都成天忙成狗，哪来的时间折腾别的？人的精力都是有限的，总要有个取舍，而博客对于我来说，就是个记录程序员生涯里的各种需要特意记下来的东西而已，我并不需要吸粉，既然这样，我记在本地以我能看懂的方式，有什么问题么？话反过来说，网上真是是人是狗都能发个文章，大部分都是 copy 别人现成的文章，还有一部分人自己都没弄明白就在上面胡写一气，你如果有幸看到这种文章中招了，估计你骂的更欢。我只想管好自己，并没有打算改变国内互联网环境，而且也没这个能力。

@TonyG 我平时也不咋写 js 啊，要写一堆的括号烦都烦死了，除非是维护别人的代码，coffee 不香么？看来你就没注意听讲啊，乖，去好好翻翻我们都说了什么在来抬杠~

@merpyzf IDE 这么累赘的东西，我很久很久没碰过了，我就是你所谓的脱离 IDE 编程的人，而且不妨跟你说，我常用的开发工具是 vim，不过也会用 vscode，，但也并没有装什么代码提示的插件，因为累赘也完全没有必要，而且这么一过就是这么多年
说到这里其实一直想问一下这里的那些杠精，没有 ts 没有代码提示就活不下去？如果真是的话，除了能证明能力不行，还能说明啥？

@tobeyouth 我也很烦接口文档不注重字段类型的，但话反过来说，你不能因为你的个人原因去强制后端人员全都来迁就你啊，后端那么多人，他们出的文档都是一个德行，然后你跟他们说你难受，让他们把现有文档都犁一遍把字段类型改过来？别说我没权力管他们，就算有权力我也不能这么干啊，除非项目还没启动还在规划中，我们可以把这一条当做规范列出来。

[KuroNekoFan]

typescript 写起来比 js 约束多一点，比 java 少很多，是刚刚好，令人舒服的约束

[lanten]

理性的争论是好事，帖子本身是有价值的。
看了各位的观点收货颇丰，我总结一下我所认同的观点：

## 优点
- 类型推导, 一切可溯源
- ide 代码补全增强, 降低心智负担
- 第三方库不看文档直接打点就用
- 映射后端接口, 确保字段的准确性
- 依然可以保持 JS 动态类型特性, 可以通过 as, any 逃课。
- 类型即文档 (且与代码深度集成)，大家都不喜欢写文档。类型定义了，文档就有了
- 易于维护, 随便翻一个函数，不用看上下文，就知道参数类型，返回值类型
- 规范化约束整个团队
- 易于修改 (变量使用 F2 重命名)

## 缺点
- 开发成本 +
- 学习成本 ++
- 用人成本 +++

[jiyinyiyong]

@hronro Nim 社区人手太少了, 来不及的

[tobeyouth]

@BoringTu 我认为这不是个人原因，更不是有没有「权力」管后端的问题；
恰好是因为人员流动大，所以更应该把文档和类型补充清晰，毕竟「今天流的汗，是前人脑子里进的水」；
还有所谓要求的问题，有些事情对的就是对，错就是错，如果觉得有用，当然可以提出要求，如果别人不改，你可以自己上手改；老项目可以慢慢改，但我觉得不需要因为所谓的「以前就是这样」，所以要一错再错下去；
再换个思路，其实现在很多工具已经支持直接从 api 导出文档了（比如 swagger ），试试新工具，说不定可以更好的提高效率；

[tonytonychopper]

确实很多项目没有必要上 ts，但是涉及到大型的复杂项目，有 ts 加持还是挺重要的，毕竟不是每个人都像楼主这么优秀，有 bug 出现在所难免

[TonyG]

@BoringTu 看来你也没看懂我的表达，其实没有别的意思，只是单纯的看不起或者鄙视，coffee/es6 只是在垃圾的基础上给垃圾上了点颜色，看看 Anders Hejlsberg 在 ts 最初发布对 js 缺失 nullable 的言辞充满鄙视和不懈。其实对这些语言大师来说，或者对 Java, C#这类传统 developer 来说，他们要的不是增加几个 keyword，人家要的是 service container, 构造器依赖注入, lifecircle, 高度抽象的 even listener/emitter, 5 层以上的 extends 和满天的 interface，积累的大量设计模式实践代码的照搬。而不是还要研究什么怎么用原型、闭包 oop，等你去确定 module 方案，为了出来个私有变量、setter, getter 而欣喜。说实话，人家没这闲情逸致哄小孩，你认为如果没有 ts，Erich Gamma, Benjamin Pasero 这票 eclipse 的 Java 大佬能把 vscode 搞出什么名堂么，恐怕只是另一个 atom

透过现象看本质，js 纯粹是个“文盲”成了“富翁”了，但拥有众多的开发者不代表它就该被认可有文化，好好把 es 补课到高阶才是该有的态度。

[DiamondYuan]

https://dropbox.tech/frontend/the-great-coffeescript-to-typescript-migration-of-2017

可以看这篇，dropbox 在 17 年把全部代码从 coffee 迁移到了 ts

[adoal]

看下来感觉楼主应该是一个比较聪明，个人能力比较强的程序员，并且习惯于跟类似水平的人合作。

但是现实中因为各行各业信息化的需求太大，高水平程序员根本不够用，导致大量低水平的人经过各种泛滥的商业培训班速成甚至没经过培训进入这个行业。而且高水平程序员通常不太愿意去垒技术含量不高的 CRUD 代码。所以 IT 行业看起来这么热闹，但必须面对的一个现实问题就是怎么把低水平的程序员管好，能在可控的资源消耗下以可控的时间做出质量未必很高但按项目标的通过验收的系统。

这种控制，有两方面的努力。一是来自于管理学。在软件开发领域的实践就是软件工程，通过开发过程的管理来控制质量和保证效率。这一点大家回帖里已经讲得很多了。另一个是来自编程语言理论，通过编程语言本身的方法论变革，一方面约束程序员，另一方面又提供便利，把很多因为人的脆弱性而导致的问题消灭在源码阶段，又尽可能提升生产力。比如近些年来函数式语言的复兴，很多较新的语言都或多或少引入了函数式的特征。其实类型系统也属于 PLT 的范围。很多人厌恶 Java 、C#之类“开发业务系统的场景下最常用”的静态类型语言，有一个因素是所有地方都要自己明确写变量类型……但是在近几年的新静态类型语言里，包括一些传统静态类型语言的演化里，通过类型推导极大减少了这种繁琐劳动。再比如通过对 union type 的 pattern matching 处理，也很大程度上让有可能多种不同类型的数据在运行时出现在同一上下位的情况有了较为优雅的容错解决办法。

建议楼主有空的时候了解一下对类型系统依赖性更大的语言，比如 Haskell 、Rust，并尝试用来在工作中完成一些相对独立不影响全局的小任务。看看静态类型的语言是如何也可以拥用很高生产效率的。尤其是 Rust，它在不引入 GC 的情况下实现自动内存管理，就是把资源的生存周期作为类型的一部分，通过强大的类型推导来让编译器发现分配的资源要在什么地方释放。

静态类型并没有那么讨厌。在很多场合下，它是程序员的好朋友。

[BoringTu]

@TonyG 我看懂了所以那么回的你啊，咱这么说吧，按你的说法，如今站在 web 前端顶层的人物应该全都看不起 js 而全都用 ts 来代替 js，但实际上你稍微动脑想想，你觉得这种情况是成立的么？如果真是这样，ts 应该在很多年前就出现了，而且也不会出现 coffee 、Clojure 这些就不会出现。既然你都聊到这了，你可以去研究一下 coffee 的设计理念，在我看来是恰到好处的，扬长避短。但因为缩进语法给很多人劝退了。

@adoal 感谢用心回复~ 我现在的态度也偏向多人团队管理尤其是能力差距较大的情况下用 ts，但我个人的项目应该还是不会考虑用 ts 的，还是感觉太繁琐太累赘了

[Pythoner666666]

> 你连自己写的代码是怎么跑的都不知道的话，转行好吗？
别的先不说了 仅这个观点实在是不敢苟同。敢问你呆的团队是多少人啊，代码都是你一个人写的吗？没有历史代码吗？诚然，不写类型，我花个 10 分钟读下代码也能知道函数的参数是什么类型，但是加了类型之后我可以秒懂。这种效率上的提升 你难道没有想过吗？ 还自称 11 年程序员，我也是服气。

[ericgui]

@hfpp2012 确实，能把 ts 学明白的，都不是工具人了

[BoringTu]

@Pythoner666666 那你用 coffee 试试呢？

[zbinlin]

在 TypeScript 3.0 出来之前，我也是跟楼主类似的想法，不过我是直接用 JS，编辑器也是用 vim，那时可是可以手打
API 呀。

后来全面转到了 TypeScript 。

[zbinlin]

@zbinlin 接楼上，TypeScript 对比 JavsScript 对我来说，主要的一个区别是一个把类型定义写出来，一个定义在心中。

[TonyG]

@BoringTu 别着急，让子弹飞一会

vue3 ( js --> ts ) Egret ( actionscript<flash> --> ts ) Dropbox ( coffee --> ts )
ng2+ (js --> ts) vscode( js --> ts ) Redux( ts ) yarn ( ts ) playwright (ts) 钉钉( ts ) ant design( tsx )
typeorm ( ts )

除了开始较早(基本都 2014 年前就开始了)，又用户众多的 react, babel, webpack 没放弃 js, 但你仔细读他们源码，其实都是有 type check system 的，而且写法和配置比 ts 更麻烦

还有鹅厂，菊花厂也是大一票 ts 拥趸

不知道你说顶层，这些够不够顶。

ts 没出现的早原因其实挺简单的，初期根本没人拿前端当成个职业，也根本没有前端这个说法。早期都是写 Java, asp, php, py 的兼着写，google map 出来那年才有的 ajax 概念，jQuery 也是前后脚出来的，那时也是后台渲染，没什么前后分离。iPhone 两三代出来之后我在这个 v 站见到了中国最早一批做移动端开发的人。3G 普及微信、4G 普及抖音，淘宝 90%销量来自 app 后中国彻底侧重移动端了，自然前后分离更现实了。

这个过程 javascript developer 越来越多，而且持续稳定增长，国外什么最值钱？ Ballmer: "developer, developer, developer", 所以基于 v8 给这大群人给 runtime 跑跑后台的 node.js 应运而生太正常了

也是因为要争这批开发人头，微软才肯让 Anders Hejlsberg, Erich Gamma 这票大神出手，但你得清楚，这些不是“前端顶层人物”，而是人类顶层人物，这个领域的神。

[DeWjjj]

我也自己愿意写 js，但是团队合作时候有的时候还是 ts 吧。也省的 JSON 拿数据都调半天。

[kwrush]

1. 编辑器提示和补全，类型推导
2. 在编译阶段就发现错误，重构时有效避免 bug
3. 和后端合作，事先定义好类型接口，提高效率

[CleverCirno]

主要作用配合 tsx，写页面模板不要太舒适
以及隔了三个月再回去维护时，看一眼类型就知道他用来干啥的了