为什么你们要选择 TypeScript？

[BoringTu]

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

[d873139022]

哇，我想默默问下楼主...我想从测试转到前端，推荐嘛，因为现在很纠结。还有楼主你觉得从后端跑到前端，现在看来后悔当初的选择嘛，以及前后端的薪水同级是同价嘛，还是要比后端低 or 高。
我自己纠结的原因在于，我现在从测试转到前端，避免不了的就是薪水大幅下降，毕竟没有经验。而又往后看，感觉测试和前端可能只是领域不同，薪水可能也就比前端稍低点。 也有可能未来前端薪水大幅度超过测试，毕竟我才刚工作 1 年，所以不了解将来的路。想让楼主说说对于前后端，测试的一些看法
希望楼主过来人能给我解惑了~十分感谢

[wednesdayco]

理解你作为一个 11 年的 JSer 不喜欢 TS,毕竟每个人都有爱憎的权利.

不过你喜欢不喜欢跟我有啥关系呢?我自己爱用就完事了,TS 真香.

[FallenMax]

补充一个角度。除了提示和补全这类便利特性外，类型系统对于解决软件工程一个重要问题--可维护性，是一个性价比极高的工具。

为什么可维护性是最重要的问题之一？关于这一点可以去看《代码大全》《 clean architecture 》之类经典著作。但从实际观察，对于这么重要的问题，反而没什么「很容易推而广之」并且「行之有效」的解决方案：懂设计 /架构 /具备好的品味的人很少（也很难遴选），设计的好坏很难像性能 /代码体积一样随时度量（圈复杂度这种真没什么用），deadline 和不负责任每天都在导致代码腐坏，堆成屎山。

对于这个问题，类型系统提供的帮助是：（强制要求用户）把更多必要信息（类型，调用，关联，一致性约束）嵌入到代码本身，从而可以被外部工具利用，也被人阅读。且不说一致性约束能被工具自动检查和维护，仅仅信息不丢失本身，就很大的提升了代码的可理解性。

至于架构，现在即便我们一开始无法为手头的问题设计一个好的「架构」，也不必特别担心。只要把足够的信息内嵌到代码中（少用 any/as ），后面从「坏架构」重构为「好架构」，从「架构 A 」重构为「架构 B 」，成本都比动态语言显著降低。

这种重构成本的降低还带来一个额外的好处：我们可以在开始时放心地使用「比较专门」的「不符合开闭原则」的设计，在实际需要时再通过重构来扩展为「比较通用」的设计。这种做法的好处有两个：1. 专门的设计针对眼前的问题，往往更简单实际 2. 没有足够的用例，就试图设计地通用，往往有「过度优化」的负面作用。

最后谈谈性价比，提升可维护性不是没有其他方式：大量的单元测试，注释，代码审查等方式我们都在用，但这些方法是否容易推行，效果是否好，相信大家各有感触。

[Lemeng]

哈哈，这楼好热闹，围观一下

[magichacker]

内卷嘛。得学会了装装逼。哈哈哈

[shunia]

本来喷完打算认真回复一下，结果发现楼上的朋友基本把优点都聊过了：
1.静态类型使现代 IDE 可以轻松的进行精确的智能提示，降低个人脑力消耗，提升开发效率。
2.团队合作更有信心，可以更轻松的提供规范和约束，提高团队输出。
3.类型系统完善，可以完美的表达 lodash 库中的方法，可以降低阅读源码的必要性，还是提升开发效率。
4.语法更先进更激进，可以认为它引导 JavaScript 快速进入了 es6 时代。

有缺点：
1.必须转译才可以运行，迄今没有真正的 TypeScript 运行时（ deno 是代替 nodejs，不是网页环境的替代品）。
2.开发成本变高:
a.一旦启用，上下游都需要 TS 支持（最好）
b.对开发者素质要求变高，能正确的使用类型系统编写和表达语意
c.需要更多的工具支持（至少需要 SourceMap ）

[abcbuzhiming]

@BoringTu
TS 本质是一种约束，作为约束，它其实约束的还不够狠，any 仍然能满天飞。

但是约束本质是软件工程的一个大方向，这个前提是不会变的。

高手永远太少，所以需要大量的工具人来写代码，这是软件工程存在的意义。这是历史的车轮，TS 也只是车轮上的一个零件而已。

资本希望把软件行业打造成不需要高手，填充机器零件就能完成的流水线的野心不是一天两天了，这也是个历史趋势，悲观的说，程序员其实在实践这个趋势。

抱怨没有天赋的选手没有意义，让没有天赋的选手也能写代码本身就是历史趋势的一部分。搞技术的本身要能跳出技术的局限性，仅仅自己写代码是没有前途的，你一个人再牛逼一天也就 24 小时啊

[zhuweiyou]

不站队 ts, 但 coffee 早就没落了...

[usw]

说白了就是为了让编辑器更快乐的弹出提示，一百个类一万个方法，也不见得我都能记住函数签名。写个 d.ts 交出去别人也更容易理解更容易直接用了。就这么简单。人也不能什么都明白，都明白了就活不明白了，对吧。

[wwwap]

看了这么多评论，有人竟然因为用了一门语言（ TS ）就攻击使用其他语言（ JS ）的人，真的 nb

[hfpp2012]

ts 给水平差的程序员用的，但是水平差的程序员又用不好，很矛盾

[aloxaf]

我觉得动态类型是好的，但是弱得像 JS 这样的弱类型……
想问问 LZ 会用 JS 写判断奇数的函数吗（笑

[ALVC666]

小项目想快速梭哈上线的时候我就不用 ts
其他能用还是用
约束和提示有成本，
带来的可维护性和提示补全便利是获利
权衡利弊自己就知道要不要用了

[lujjjh]

> 直接用 Java 写然后编译成 JavaScript 不好么

同样可以说，用 CoffeeScript 为什么不直接写 Python 然后转义成 JavaScript ？

只能说，有很大一部分人确实有类型系统的需求，主要原因当然还是前端工程化的发展。简单来说就是确实需要一种类似 Java / C# 的前端工程化语言，但又不那么 Java / C#。

事实上，近几年来人们对创造新语言越来越克制了，会考虑这个特性是不是值得造一门语言通过语法层面解决（除了 CoffeeScript，再想想 pug 、sass 、less ）？同样，随着 ECMAScript 本身的发展，CoffeeScript 在语法层面的优势是不是依旧得以超过引入一门新语言可能带来的生态问题──比如 CoffeeScript 2 还是有一些 breaking changes 的，但是如果不升级是不是就没法用 async functions 和 JSX ？

相比而言，TypeScript 的定位是 JavaScript 的超集，语法上没有那么激进，解决的问题也足够实际。我觉得这是 TypeScript 更容易被接受的原因。

我的观点是，如果没有遇到需要使用 TypeScript 的场景，确实也没必要强上，但是在 TypeScript 有明显优势的场景，不用白不用。更重要的是对新技术有包容的态度，即便我写了十几年 JavaScript，不理解新技术有什么用，但也不排斥，相反我会充满好奇上手试一下。

不管是 JavaScript 、CoffeeScript 、TypeScript，甚至 ClojureScript，只要场景合适我都用──JavaScript 写一些小 demo 很快，不需要任何构建系统； CoffeeScript 写 parser prototype，可以充分利用语法上的优势，而且本身就是一个比较 geek 的场景； TypeScript 写工程化的项目和服务端应用。

[abersheeran]

@aloxaf 别骂了别骂了，孩子都要傻了。

[richardwong]

说明你这 11 年相当于 1 年经验重复了 11 年

[nexo]

@yyfearth 请问下后端改了字段类型 ts 中 interface 编译后的 js 里是没有 interface 类型判断部分的 是怎么知道的错误

[colatin]

@richardwong 不能同意更多

[dfkjgklfdjg]

1. 有没有看到过这个报错 "`Uncaught TypeError: Cannot read property 'foo' of undefined.`"
2. 前端圈喜新厌旧，比如以前 jQ 一把梭，现在一个个都嫌弃 jQ 🤡
3. 跟风大厂, 大厂多人协作没办法，然后参看 第二条
4. 如果没有类型和接口声明鬼知道其他人怎么弄的，有几个人写注释。
5. 类型推导，这个我不知道 coffee 有没有了。

[wunonglin]

@nexo #217 自行修改前端工程的 interface，后端改字段不合开发沟通是后端问题