为什么你们要选择 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，后端改字段不合开发沟通是后端问题

[FreeEx]

前端的深度低，3 年，5 年，10 年工作内容都差不多，那如何体现出来自己的水平呢，既然深度不行那就横向扩展呗，只有写写 ts 才能维持的了生活这样子。

[jeffwcx]

@FreeEx 前端深度低吗？只是重客户端的应用少，office365，figma，notion 都是重前端的

[nexo]

@wunonglin 我知道 但是层主说 ts 可以暴露这个问题 没懂怎么暴露 不一样也是 出了 bug 才知道吗

[BoringTu]

@d873139022 这个没啥推荐不推荐的，这个得看你想转的信念有多坚定，如果不坚定的话就建议不要转
前端是程序员的一个分支，跟后端一样，虽然前端的门槛是真的低，说句不好听的，现在是人是狗都好意思说自己是前端工程师，结果一面试问啥啥不会，就觉得自己会个 vue 会个 elementUI 就敢自称前端工程师了~ 我们这帖子里估计也有一部分人在此行列，尤其是那些叫的欢的。emmmm，话题歪了，咱继续说转行的事儿
其实测试的水也是蛮深的，而且薪资水平也不低，为啥打算转行嘞？
如果要转前端的话，你需要做好的准备是，关于程序员的基础你需要很长一段时间来学习（因为是转行从零开始，以前没有接触过程序员相关知识，所以这里我用的是“很长一段时间”
比如软件工程思维啦，比如数据结构和常用算法啦，比如 js 的各种基础和常识啦，哦当然也还有 HTML 和 css 等等。就像前面说的，不是说会用个 vue 之类的框架就能叫做前端工程师的。
所以基于以上，你结合自身考虑一下呗~

[james122333]

@BoringTu
必须得说实话搂 语言特性与可维护性本来就没有必然关联 惯不惯而已 都有长处和短处
有政治因素或利益考量照样难以维护
也觉得 oop 有点走火入魔 而弱类型能实现强类型本身就归功于弱类型特性 弱类型加上"简单"数据结构个人觉得还是可以的

[BoringTu]

@abcbuzhiming 哟西，说的好~

[BoringTu]

@wwwap 哈哈哈哈，我也是服了，你看那些叫得欢的人，我都怀疑是不是只会个 ts
前面我还试着回几个，后面实在是懒得回，不值得浪费这个时间。。不过网络嘛，啥人都有~

[wunonglin]

@nexo #223 你换成任意一种后端强类型语言，不做错误处理的话一样会出现这样的错误。这和 ts 没关系，再说 ts 只是静态类型，不是强类型，而且 ts 只做于开发期间使用，而不是生产时。如果你写过任意一种强类型的后端语言你自身应该能知道类型带来的好处，如果没写过那你应该是尝试接触下后端，或者当我没说

[penll]

js 的 any 特性已经给许多人带来灾难性不可维护的后果。
ts 强类型的好处，楼上都说很清楚了。约束、规范带来各种便捷，可维护性、写代码时的提示。
还有，限制一个对象传递过程被多个人一起开发时，挂上各种不可预知的子字段造成内存溢出

[ychost]

ts 写 angular 很舒服，写 vue 或者 node 就没 js 那么爽了

[nexo]

@wunonglin 我写过 c++、java 、 也用过 ts 我问的是这个人的回复是怎么运行前暴露后端问题的 怎么做到的 你看了他的描述吗...

[lbp0200]

我去年准备自学 coffeescript，最后被 vue 、recact 、angularjs 这些框架很难与 coffee 兼容劝退，大佬这些问题怎么解决的呢？

[james122333]

@wunonglin
类型有带来好处也有坏处 坏处大于好处的时候就是不可维护性 弱类型同理 说到底还是看人如何使用

[BoringTu]

@FreeEx #221 是谁跟你说前端深度低的。。前端门槛低倒是真的，深度咋就低了？
数据结构和算法，一样是前端工程师的基础，尾调用尾递归你要会，除非你一辈子不会写复杂逻辑（根本不可能吧，比如后台系统，你连菜单树都不渲染的么。。）比如各种棋牌游戏，你不得重新把初高中数学捡起来？什么斐波那契数列，什么阶乘，什么交集并集，什么排列组合都是要的。比如动画类游戏，你还得折腾 canvas，甚至也许需要 cocos2d 、ThreeJS 。虽然这些是广度，但每个广度背后都是需要基础这个深度支撑的，你不会以为没啥基础的人随便找个框架看着文档就能撸代码吧。。

[BoringTu]

@lbp0200 #232 coffee 跟 vue 可以完美结合啊，没啥问题啊。。我用 vue 跟 coffee1 一直用到现在的 coffee2，不能再舒服~
而且我看上面有人说，如果用 ts 的话需要上下游环境都是支持 ts 的（未验证），但 coffee 不会，可以跟 js 完美融合在一起。比如我现在的这个项目，我和几个同事用 coffee 写，另外有同事因为赶进度没时间学 coffee，那就用 js 写，配合没有任何问题

[Austaras]

> 尾调用尾递归

笑死，报菜名都报不利索

[bsg1992]

楼主的思维方式和性格 和当年 20 岁一样，有一种莫名的优越。太局限于技术上的思考。

[wunonglin]

@nexo #231 他那是压根不知道 ts 能拿来干嘛

[wunonglin]

@james122333 #233 原本 js 的定义就是个脚本语言而已。只是发展到现在慢慢变得大型化，工程化，弱类型已经不能满足发展需求了，所以 ts 诞生了。十几年前哪个鬼知道 js 能有今天的地位

[BoringTu]

@Austaras 说话呢，就说全了，说出个论点就要有论据支撑，否则只能证明你跟那些人一样是个 sd~


@bsg1992 优越谈不上，自信是有的，你什么时候能一样做到在每家公司里都是 bug 率最低，你也可以
但你所谓的局限，我并不敢苟同，我自己啥样我还是知道的。我这篇帖子抛出来就是问 ts 火的原因，然后你也看到了，还是有相当一部分人跟我一样的看法的，那你是不是顺便也挨个 @一下来指导一下我们？

[Austaras]

我看起来像在和你辩论吗？我只是在嘲笑你

[nexo]

@BoringTu 看了下 github 没什么营养阿..... github 有个简历 都是些国网之类的国企项目? 然后写的代码足够少 或者项目简单 就可以保证 bug 率足够低呢

[james122333]

@wunonglin
语言会进化 脚本也可以做很多事情
并不是有类型才能做工程 语言特性发挥的好以及不複杂化问题及解方才是工程顺利因素
能达成这个目的做工程有何不可

[BoringTu]

@Austaras 那你确实是个 sd 啊。。

@nexo ？？？项目简单？你脑子呢？你的手还行，还会扒点东西，但可惜没有脑子支撑啊。。你这结论都是手拍膝盖得出来的么？

[nexo]

@BoringTu 好家伙 直接急了急了

[Austaras]

不是，我有什么必要跟你这种自我感觉良好得不行实际上只做过一点点简单项目而且还把自己比同事做得好（谁知道你同事是什么牛鬼蛇神）这种事情拿出来说事的人讲道理？你看你简单报一点菜名都没几个报对了的，就算讲了你听得懂吗

coffee 之所以凉了就是因为只能吸引到你这种人

[tobeyouth]

就我个人而言，现在基本上所有的项目都转向 ts 了，主要是以下几点考虑：
- 比较偏向业务层面的，用 interface or type 很方便跟 api response 同步
- 比较偏向 lib 层面的，因为大家都用 vscode，参数 /返回 都严格定义了描述，即使文档比较简陋，其他人也可以很快上手

[jiyinyiyong]

用 ts 也有个原因.. 你希望某个写代码的程序员 A, 他写的代码是会要你接手的, 可能用到几个接口, 可能接手整个项目. 然后就就会很希望 A 做事规矩一点可靠一点, 就算有点类型麻烦一点, 反正要的效果是自己接手的时候省事, 至少有 ts 做类型检查的时候, 你可以防着 A 做很多无语的事情. 你知道他写了类型的几个地方, 至少不容易出现低级的或者很难找到的错误.

另外, 那个 A 很多时候其实是半年前的自己...

要说语言的话, Rust 设计上比 js 好多了, 而且也不像 ts 这样带着各种历史问题, 而且现在 Rust 也能越来越多写网页了.. 真希望 Rust 这些东西快点成熟起来.

最后要说喜欢不喜欢什么语言的话, 哼, 我为什么要喜欢一个别人设计的语言, 要就是自己设计语言自己用!

[james122333]

@jiyinyiyong
然而除了类型他还是可以做很多其它无语的事情 全都限定的话一下子就被需求考倒
不过有志气 的确没完美语言就是 自建起码很舒畅

[BoringTu]

@Austaras 你好像有那个大病，快去治治吧好吗，我给你出钱？就当做善事了
没有必要你为什么要回我的贴呢？说你有病你还喘上了
光知道满嘴喷 f，然后字里行间一点营养都没有，这种话是人就会说，别说人了，狗都会
你说没几个报对的，哪里有问题你倒是说出来让我们看看啊？
会说话就老老实实的说，不会说话就多看书少说话，家教这么差么，没人教？能别在这现眼了好么？你这种人我是真不想回，别把我帖子搞的乌烟瘴气的 ok ？

[Austaras]

那你别发这种弱智帖子把 V2EX 搞得乌烟瘴气的 ok ？

[BoringTu]

@jiyinyiyong 哈哈哈 这么傲娇的嘛

@tobeyouth 大佬，我现在有个问题，比如举个栗子，我现在的这个项目，后端出的接口文档，只会注重字段名，并不重视这个字段的类型，基本都是 string，但实际上是 int 是 boolean 等等，如果是基于这种前提，ts 好像就会很难受吧？然后就只能让后端把现有的所有接口文档都过一遍，把字段类型改成正确的，ts 才能玩的转，是这样吧？

[BoringTu]

@Austaras 你自己看一下我这昨天下午发的帖子，现在有多少收藏好么？
你再挨个层看看有多少人跟我有同样的看法行么？
有争议，就代表有相当一部分人是持有不同看法的，这个道理你不懂？
还是那句话，你既然觉得弱智，为什么还要来这里被我喷呢？受虐倾向？
把嘴闭上吧，我都不好意思骂你了。还有，送你句话，做事之前先学会做人

[Austaras]

v 站就没有和你傻逼到一块去的人了？这什么迷之自信，何况收藏的人里面还不知道有多少是来文明观猴的

> 为什么还要来这里被我喷呢

我是来喷你的啊

[Austaras]

另外也送你一句话：想让我教你东西，可以，先打钱

[Imindzzz]

@nexo 他说的 接口 可能是 ts 的 interface 关键字 ,不是 “后端接口请求”。

[fengerzh]

我只是为了能让 PropTypes 少写几行

[james122333]

@Austaras
这是地图炮吗？
不过果然就是政治问题

[BoringTu]

@Austaras 你先把怎样做人学会吧，真可怜。。你现在过的应该不太如意吧。。不过我又不是你父亲，没义务教育你

BLOCK 了，自己玩儿吧~

[BoringTu]

@james122333 哈哈，这人是站在自己意淫出来的制高点在教育我们呢，让他自己玩儿吧，我已经把这位神人屏蔽了

[walpurgis]

后端接口字段类型不固定都能忍的吗

[BoringTu]

@walpurgis 不能忍啊，不过这是有历史原因的。。
一开始接口文档是我出的，但在出了 120 个接口的时候休陪产假了，出接口文档的任务就移交给后端了，等我回来之后就发现，卧槽，每个接口的字段几乎都特么 string 。。但那阵已经出了几百个接口了，而且上面还催的急，我不能忍也只能忍了，因为没时间去改文档。。

[Austaras]

我就不懂了，你这种混了十来年还在各种野鸡小公司里滚来滚去的是怎么有底气嘲讽别人过的不好的

[Imindzzz]

1 、上下游都需要 TS 支持
不需要。在 tsconfig 中配置 allowJs:true, 你就可以直接 import 一个 js 文件。

2 、接口字段类型不固定
这个两个方案，实际例子来说有个 age 字段
一是定义成 any 类型，这样就降级到 js，你原来 js 怎么做就怎么做。比较年龄时编译器不会报错，但运行时可能就报错了(出现字符串比较 '2' 大于 '11'这种情况)。
二是定义成 unknown,这样在你比较年龄时编译器会报错，需要你先写判断 if(typeof a.age ==='number'){//TODO 比较年龄}，才能编译通过
-------
这个帖子的风向已经是人生攻击了，你作为题主很有必要拉回来。
-------
在我的理解中，js 换到 ts 不会有任何成本。除了一个领域到另一个领域的“几天学习成本”。
你可以提出你遇到问题，我们很乐意为你提供解决方案。

[BoringTu]

@xd199153 感谢大佬认真答疑~ 了解了~
-------
咋，我屏蔽的那货又回我了？
我争取拉回来。。不过因为话题争议确实挺大，再加上网上是人是狗啥都有，比如我屏蔽的这位，上来就喷我，我跟人家讲理，但人家不讲理啊，我就只能屏蔽了，但也只是我看不到，你们能看到吧。。
-------
好嘞，感谢大佬支持，我正在入坑中~

[liuhan907]

@BoringTu #262 你看这个不就是静态类型的优点么？

[cereschen]

我给你们总结一下
此楼主首先看现在 ts 大行其道,而自己却不会,心里有点焦虑,但是又不能偷偷的去学,这样不符合自己的性格(爱好哗众取宠)
那么思来想去,不如上 v 站开贴喷一下 ts,好处有不少:
1. ts 目前热度高 喷它可以造热点
2. 自己对 ts 一点不懂 发帖自然会有人来科普 顺便也学习了知识
3. 自己声称写 js 不出 bug 为了好找工作才学习 ts 营造一个技术大神的形象(大伙看看笑话就行)

可谓是一石三鸟 如此睿智 三个诸葛亮也抵不上楼主呀

好了 下面我来预测一下楼主接下来的行动
楼主会对指责他的人猛烈回击 甚至捏造事实
楼主会不断从好言相劝的回帖中找台阶下

大伙也得文明一点 不管观的是什么都得文明点 有些事儿 犯不上

[BoringTu]

@cereschen 哦豁，又来个心理学家，服了。。
你能说出这句话，只能证明没认真听讲，好好翻翻我都说了什么再来回我的贴吧好吗，乖~

顺便针对性的回复一下：
1. 我需要热点？？？我是网红？我能获得什么？也没人跟我分流量钱啊，何况流量也不高，你是咋说出这句话的。。
2. 一点不懂？核心观念跟 js 背道而驰，我本意聊的就是这件事，只不过在你看来这是优点，而在我看来这有点莫名其妙。有一说一，我这帖子有不少大佬心平气和的跟我聊技术，我在思路上确实学到了不少。但你是不是跟谁都是习惯性恶意揣测他人想法啊？厚黑学看多了还是犯罪心理学看多了？这习惯可不好，建议改正
3. 这点跟 1 一样，我需要热点？客观事实也不能说出来？我是不是再给你个调查表啊让我历届公司同事给我 bug 率一个评价整理好了给你看？你平时都是这么看人的话，那你活着是不是有点累啊。。我就是个程序员，只不过在这程序员的水里，我自认代码质量还是不错的而已

想问您还有什么想说的？

[FreeEx]

@BoringTu 我指的是 web 前端深度低，不要混淆概念。另外你举得这几个"斐波那契数列，什么阶乘，什么交集并集，什么排列组合都是要的" 这些就算得上深度了？建议刷刷 leetcode
@jeffwcx 又有几个这样的产品呢。

[nameyukan]

哈哈，有种当年在论坛里吼一嗓子「 PHP 是世界上最好的语言」的既视感了。

能干活，写啥不是写，不过确实也有点好处，也有点坏处；

好处：
1. 减少点低级错误，之前看到一些开源库里把变量名都给写错了
2. 写 ts 在用一些 API 的时候确实省脑子，vscode 会给你提示可用的 API，并且 tsdoc 也能显示出来

坏处：
1. 一层层泛型能把你看秃，还不能调试，纯看

[jeffwcx]

@FreeEx 所以说嘛，前端深度是有的，只不过现在的产品大多数都是大路货

[FreeEx]

@jeffwcx yes，前端写 ts，后端搞微服务，都是一样的套路。

[BoringTu]

@FreeEx 抱歉，我刷 codefights，但估计你没听过，而且现在也改名叫 codesignal 了
至于深度，我从两个方向来说
1. 关于我说的这几点只是举个栗子，但换句话说，你觉得前端这个锅里，有百分之多少的人会？我给你一个我的答案，我面了大概 500+的人（肯定又要有人喷了），就这些人里，有去了解数据结构和算法的，不超过 20 人，我招的岗都是中高级岗
2. 前端和后端的区别，确实是后端要深度，前端要广度，从这个角度来说，前端的深度确实没后端深。但你这是在偷换概念，这里的深度，不是知识储备深度


@nameyukan 是哒，能干活写啥不是写~

[Kasumi20]

你技术这么六，代码这么好。
怎么 Github 光秃秃的，博客也打不开？

[hronro]

@jiyinyiyong #248
与其期待 Rust 写网页的东西成熟起来，还不如期待 Nim 呢。

[TonyG]

不如直接跟你说一个你可能很难接受的理由吧，因为终于可以不用写 JavaScript 了，不管你写了多久的 js，有一点你得承认，在很长一段时间以来，js 都受到了浏览器端唯一语言的垄断保护，要是浏览器能写 Java, C#, PHP，你以为还能有 js 的事么

[10bravoman24]

java 程序员估计没有谁喜欢愿意去写 js 吧，这可能也是 ts 存在的意义。
个人观点：
1. 有利于前端生态的完善
2. 增强可维护性（主要原因）
3. 客户端代码依赖于浏览器去编译执行，使用 ts, 减少不必要的编译开销

[merpyzf]

就想问有多少人可以脱离 IDE 编程，弱类型 IDE 的代码提示太弱，经常写着写着就要去翻 api，很影响编程时的连贯性。上份工作有幸从 Android 转向前端开发写了一年的 TS，由于无法忍受同事写的 any 满天飞的代码，索性离职。对于维护性这一点，完全取决于人。

[merpyzf]

偷偷问一句，题主用 js 都是在写面向过程的代码么？

[lqfxz520]

工作以来，我都没接触过 typescript 。我没想那么多，我水平不高。我只想面向工资开发，什么技术能够给我带来竞争力我就学习她……

[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，写页面模板不要太舒适
以及隔了三个月再回去维护时，看一眼类型就知道他用来干啥的了