前端同学，你到现在还没用 typescript 原因是什么？

[Imindzzz]

我认为使用 ts 是只有好处没有坏处的。因为实在没办法的时候也是可以降级到原生 js 的写法的，但是熟悉 ts 后那真是太爽了。

如果你有什么问题可以说出来，看大伙能不能给你一个完美的解决方案。

大家心平气和不要吵架。

[murmur]

学习成本也是坏处啊，我在前端群经常见到因为类型问题饱受折磨的，本来 js 都不是问题，既然这样那 anyscript 不挺好，都 any 了还要 ts 干嘛

不是每个人都在做登月工程，不是每个人都要和别人协作，不是每个人都要维护个 5 年 10 年大项目，没新大项目就不上呗

类型全写完的时间够写好几个模块了

[Shook]

换做 dart 的话我是很愿意的，因为写 dart 心智负担很低，null-safety 让我省了很多问题。
而且配合 api-generator + swagger，我根本不需要自己写 model 和 request 定义，拿到接口文档就生成，剩下的是愉快的 UI 构建时间。

web 的话，因为 vue 本身用 ts 体验就一般，我自己还是更乐意用 js 写。

[Imindzzz]

@murmur 这个可以理解，不过前端其实没多少要花精力去学的，学学 ts 没错的。

你在群里看到的情况，在其他语言的群也能看到同样的情况，毕竟总会有初学者的。多问一些问题，熟练了就好了。

然后项目引入 ts 也是没啥坏处的，哪怕你是只写一个函数，能暴露出一个参数类型 /返回值类型不也挺好的嘛。
关键是引入 ts 你没有任何成本，免费获得 ts 的代码提示。

你调用每一个浏览器内置函数，都能享受到 ts 定义带来的便捷。所以加入 ts 吧！

[Imindzzz]

@murmur "类型全写完的时间够写好几个模块了"

这个我不太认可，这个不是随手就定义了吗，定义类型也算是先规划好再动手写实现吧。

你可不可以举一个“类型要写很久”的例子？

[dqzcwxb]

[murmur]

@xd199153 就是那种跟后端很复杂的交互，你需要啥取啥，少啥加啥，尤其是层嵌套次深的时候定义完整个东西跟写一堆 java 一样爽

问题是这种接口就封装这么一次，封装完可能都不去碰他

先规划好再实现，这就是最大问题，赶工情况下是不可能做到的，都是开发一半发现缺参数，然后东加一个西加一个

ts 配正规的软件工程不错

[otakustay]

@xd199153 写类型要很长时间就属于对 TS 的一个很大的误解，都不知道怎么传出来的

[erlking]

增加新人上手难度，降低自己在公司的可替代性。

[vindurriel]

@xd199153 有没有试过老项目改 ts 很多耍小聪明的地方想加类型约束特别烧脑

[adjusted]

typescript 文件多了确实慢

[hahasong]

写 ts 的同学，现在还没转 java 后端的原因是什么，都强类型了还写什么前端, java 不爽吗

[Imindzzz]

@murmur 哈哈哈，你这个场景我经常遇到，我的解决方法可能不太优雅。
就是直接从 chorme 的 xhr 里面复制返回值 json，直接贴到定义里。
```ts
export interface DoctorInfoInquiry {
amount: 1; // 执行价格
createTime: '2020-06-09 11:22:45';
deptId: '015';
deptName: '五官科'; // 其它这些，不用管它。反正只需要他的代码提示就行了。
doctorId: '2144';
doctorName: null;
hisDoctorId: '2218-2144';
hisId: 2218;
hisName: string;
id: 1531129221808;
isFull: '0' | '1'; // 满员
isOnDuty: '0' | '1'; // 下线
maxInquiry: 50;
price: number; // 这种字段需要参与计算，就认真定义下
remune: number; // 展示价格
type: '1' | '2' | '3' | '4'; // 这种也是，当然最好定义一个枚举
updateTime: '2020-06-09 11:22:45';
}
```

[Imindzzz]

@hahasong

同学，不要带带情绪反问哈，https://www.v2ex.com/help/assertive

认真回答你就是，我是前端。

[h1104350235]

任职过几家公司，都没有使用。

[lemonnTr]

没机会，团队技术栈是 vue 2.x 。

[murmur]

@xd199153 这是个很好的问题，万物基于 js，真的有用么，到头来还不是被 native app 吊锤

微信桌面端基于 h5 开发（当然核心都是 dll 写的），但是不支持 linux，易用性比 native 的 qq 差了一万个米聊都不止，甚至某些基础功能都没有

如果是狭义的前端，就是指浏览器页面，复杂的逻辑意味着复杂的操作，用户体验也不会好，单纯的页面堆砌不等于复杂，一个办公系统可能几十个模块，但是他复杂么，复杂的东西都是流程引擎实现的

所以归根结底，前端是在抢别人的饭碗，为了 js 而 js，还是真的有那么复杂的东西要做？

[Imindzzz]

@vindurriel 这个确实，我们目前的解决方案是不管老代码。新功能用 ts 写，老代码渐进式的重写。

这个就是我开头说到的“是在没法还可以降级到原生 js”，
一个 ts 项目是可以直接编译 js 页面的，甚至用 ts 写的工具函数也可以在 js 写的页面里用

[murmur]

所以我可以猜测说 ts 爽翻的是不是把 node 当 java 用，直接去干后端了

那不好意思，我支持 java，信仰不能丢

[willygeek007]

开源项目或者多人协作用 ts 会好一点, 小项目 js 爽一点

[Imindzzz]

@murmur 刚毕业我确实写过两年 java，现在怎么也是算个“资深前端”吧。
我个观点是，你引入 ts 是一点坏处都没有。哪怕你就写个 demo 项目，也应该用 ts 。

[Imindzzz]

@willygeek007 看上面那句回答你。

@otakustay 应该是初学的多，毕竟前端整天门槛较低，学前端的不一定能熟练使用 ts 。

@erlking 哈哈，逐渐让新人上手嘛，这个对团队整体水平提升也是有帮助的。

@adjusted 这个我到没明显感知，你有测试过吗，具体说说呢。

@h1104350235 这是机会，你如果把工具链什么的都给大伙安排好，他们直接上手舒舒服服的写，那你就是大牛，大伙都的敬礼三分。

[zhaol]

不用 ts 不会写，现在网上找其他库都要有 ts 版本的才行 @types/xxxx，不然不用。没提示真的难受，特别是函数的参数和返回值，真的能省很多事，不需要看文档才知道这是干嘛的了。就算不跟别人合作，自己的代码，久了也忘了是干嘛的了，还是 ts 省事

[Jaosn]

我现在有个问题就是，后端接口返回的字段很多，每个都定义一下好麻烦

[zhangshine]

ts 难度并不高啊，就是有一个熟悉的过程而已。用个 2 个月搬砖效率和 js 没啥区别。以前不用就是懒得学而已，用了之后真香。

[Imindzzz]

@zhaol 哈哈，同感同感。 不过我补充说明一下，免得大家误会。
没有 @types 的库，非要用也可以用，只是没提示而已。

@Jaosn 看一下我回复 murmur 的，直接复制返回的 json 就行。

[Leviathann]

我遇到一个问题，ant design mobile 需要用一个 ref，但是 react useref 和 forwardref 的类型怎么都写不对，给的提示信息又是天书，最后实在是烦躁加了个 //ts-ignore，跑起来完全没问题。。如果是完全追求类型安全就很抓狂了
还有就是泛型函数好像没办法限制 T 是两个类型中的一个，多次尝试后写了两个完全一样但是类型不同的函数。。

[walpurgis]

@Jaosn 可以根据 OpenAPI 文档自动生成对象的 ts interface，不用手写

[Vegetable]

因为 vue2...

[lonelyway]

不要为了 TS 而 TS，有必要就上,我个人觉得弱类型反而是 js 的一大优势

[powerN]

1，什么时候用枚举，什么时候用联合类型

enum Direction {
left = 'left',
right = 'right',
top = 'top',
bottom = 'bottom'
}

type Direction = 'left' | 'right' | 'top' | 'bottom'

2，当我有一个枚举对象或者一个联合类型时，我如何方便快捷地转化成一个 list 对象，提供给 select 组件做后选项

例如上面的 Direction , 我想的到一个这样的结果（当然，现在是手动维护的）：

const list = {
left : 'left',
right : 'right',
top : 'top',
bottom : 'bottom'
}

[dasbn]

webstrom 之类的工具已经让我用上类似 TS 的提示，而我自己用 JS 又不用类型体操（

[limi58]

因为我在 terminal 上用 vim，ts 提示不方便

[leoQaQ]

因为只有我一个前端

[Kmmoonlight]

@lemonnTr vue2 也可以上 TS 的，我们就加了

[HAYWAEL]

之前在 Vue2 时期就试着引入 ts 了，因为没做什么强制，后来被用成了 anyScript，前段时间在一个 taro 项目中用了，结合编辑器的提示功能，写起代码还是很爽的，最近也试着用 Nest 。

[ALVC666]

vue2 js
vue3 + tsx
ts + react
现在几个项目都这样轮轱辘转

[jrtzxh020]

来来去去就那么几个页面，真没必要。。。

[charlie21]

领导没说让用就不用，领导让用就用，还能为什么 ... 当然如果是个人项目是可以用的，用 js 写一版再用 ts 写一版权当提升熟悉度

[Rrrrrr]

牺牲了 js 的灵活，增加学习成本，排错时间成本，不能原生地跑在浏览器等

[muyue08]

@Shook 兄弟，请教怎么用 api-generator + swagger 生成接口，有相关的资料或者文档可以发一下看看吗，谢谢

[jin5354]

@powerN

1. 什么时候用枚举什么时候用联合类型
如果值是弱语意的，比如 status 是 0 1 代表上线 /下线，那么通过枚举 Status.ON 和 Status.OFF 可以补充语意，写的时候就一目了然，这时适合用联合类型；另外如果要修改值只需改 enum 一处就好，其他地方是引用的；联合类型你得改各个地方。强语义的字段我基本都写联合类型，省事儿；如果要重点考虑维护（如前文场景），就用枚举。你这个 Direction 的例子我就用联合了。

2. 枚举 /联合类型转换到对象：用 Record 工具类型，type List = Record<Direction , Direction>，但这里如果按你要求 left 只能对 'left' 的话就不能写 Record 要用底层的 in
type List = {
[key in Direction]: key
};

[ipwx]

可是 webstorm + js + vue.js 的体验很好啊。

甚至可以识别 vuex 的 state，在代码提示里面正确给出属性。

[um1ng]

目前是在用了 项目都是用纯 ts 写的，顶多页面部分用了一些框架...

[jin5354]

TypeScrpit 毋庸置疑是好文明，但目前确实学习路线蛮陡峭的，最适合在工具库里写，结合 React 变难一点，比如你得搞清楚在状态管理时，注入 store 时怎么表述组件 props，挺 hack 的，结合 Vue 更难。

只有付出相当的成本才能做到流畅的写 ts，像我即使重度写了 1 年多也还有很多场景不知咋写比较好，一是因为 ts 文档真的枯燥，只有实际用到才会去找，还有很多小技巧你得去 stackoverflow 才能搜到，二是 ts 自己也不够智能，有的场景它就是推断不出，你只能忍，换个写法。三是我自己也是水货，只想赶紧写完下班。

最近社招时想问几个 ts 的问题，实际情况 90% 没写过 ts，5% 只能写写 interface，能知道泛型、工具类型的都没有，更别提什么 extends，infer 这种了，可见 ts 的普及程度（公司太拉，吸引不到大佬也是一方面原因

[zxCoder]

要我说，ts 纯属脱裤子放屁。。。

[zxCoder]

也就是因为前端那些生态绑定了 js ts，才能火起来

[fanym]

非前端，但是 js，ts 都是恶心货，可以的话真不想碰这些语言。

[silencelixing]

因为没学，JS 又不是不能用，我把这时间用来摸鱼他不香吗？
说白了就是投入产出比不够好，学习也是成本。

[leelz]

写类型的成本就是成本，需求倒排工期哪有时间去写 type，就直接 anyscript 省事

[lemonnTr]

@Kmmoonlight 是装饰器那种写法吗 体验不是很好

[Kmmoonlight]

@lemonnTr 你说 计算属性 watch 之类的么, 感觉也还好, 这种主要看用的人的, 要是不自觉都会变成 AnyScript

[94qihang]

TS 很好用，但终究还是输给了“项目时间紧”，“团队没有规范”（别人 anyscript，你自己写 TS ）等等的现实。

[musi]

“只有好处没有坏处”
团队的技术栈选择不是你一个人说了算，其他人的上手成本也是成本，用不好变成 anyscript 还不如不用
如果你的团队只有你一个人，那你开心就好

[musi]

如果只是为了类型提示的话，那向 webstorm 之类的 IDE 只要写了注释也会有类型提示。这并不能成为用 ts 的理由。说到底软件开发就没有银弹。

[Kaciras]

多少年了对 ESModule 的支持还没搞定，import 不能自动加扩展名，生成的文件也不能自定义 .mjs 扩展名。

DefinitelyTyped 永远落后，不自带类型文件的库没法第一时间升级。

不支持扩展，到现在只有个 JSX 语法，导致一堆自定义模板的库没法兼容，尤雨溪也吐槽过这问题。

TS 的 JavaScript API 一直没有稳定下来，也没有文档。

[ryanlid]

因为同事还不会 JavaScript

[mokevip]

前公司各种新技术各种 high，听说以前 high 过的项目全靠几个老员工撑着，因为新来的压根没听过 Typescript

[iszengmh]

正在写 IE

[nanxiaobei]

写出来的代码太丑了

[Cbdy]

应为我们还在用 Vue2

[Imindzzz]

@Leviathann 有时候是不好搞，用用 ts-ignore 也没啥不好的。
interface A{} interface B{} T exends A|B 这个没问题的吧？

[Imindzzz]

@powerN
1，什么时候用枚举，什么时候用联合类型。我只有一个场景用联合 https://imgtu.com/i/W7gcBF

2，枚举转 list 。
这个我不知道，不过按理说一个是类型，一个是数据，这确实没法转换吧

[chenyu0532]

就像我做小游戏的，一个人就能开发一个一个游戏，当然 js 写起来快了，没 ts 那么多啰嗦的语法。
如果和别人协作，js 需要提前定义一堆约束才能配合好。ts 就不用特意去定义一些约束

[Imindzzz]

@zxCoder 你的想法可能在更高层次了，我只是个前端，我无法反驳。至少我觉得 ts 是前端的最优解决方案了

[Imindzzz]

@fanym
@silencelixing
@leelz
@94qihang
各位都是说写着麻烦~~~ 不是我不信哈~ 我想问问各位使用 ts 多久了。。。
在我看来，写类型就是顺手的事情啊，能花个几分钟？
或者你们说说，写了什么类型花了多少时间。

[Imindzzz]

@musi 刚开始的时候我和你想法一样，我想推又怕同事抵触，后来我们组来了一个比我厉害的同事，把工具链搭好，大家用得舒舒服服的，0 基础也都慢慢入手了。你既然团队成员多，恰恰应该多努力推一下，磨刀不误砍柴工。

注释的提示毕竟没有约束嘛，毕竟不是代码。

[PerFectTime]

ts 到处写 any，烦人

[Imindzzz]

@silencelixing 讲道理，前端真没多少要学的，学 ts 也花不了多少。磨刀不误砍柴工的，试试嘛。

[Imindzzz]

@chenyu0532 什么游戏，能开源大伙看看不。我感觉游戏这种场景 各种分层 /数据传递 最需要 ts 了。

[Imindzzz]

@chenyu0532 不开源，写一个 demo 也行。
实在不行，描述一下需求也可以，如果简单，我空了用 ts 实现一个。

@PerFectTime 对新手要有耐心，多说几次就不会写 any 了，前端总共就没几个应用场景，慢慢熟练嘛。

[libook]

以前 TS 火起来是因为比 JS 早先实现了 ES6 的语法，JS 是等 ES6 正式发布了之后才开始逐渐支持的。

但现在 JS 已经追上 ECMA-262 的所有 proposal 了，所以私以为 TS 的优势没那么大。

唯一比较有优势的是类型声明，然后做编译检查，但这些都是靠工具来完成的，同样靠工具也可以写 JSDoc 、ESDoc 然后用基于 doc 的代码分析工具来检查，效果差不多，我用 JetBrains 家的 IDE，在写的时候自动补全、类型提示、波浪线都很好用，体验就跟 TS 一样。

或许从 C#转技术栈过来的会用着很舒服？都是微软家的东西，思路也会有所相似。

任何一个技术都有好处也有坏处，有其最适合的场景，也有其不适合的场景，所以什么话都不能说死，因为除了会引战以外，过了一段时间回来看自己写的东西会很尬。

JS 是极其灵活的语言，灵活的代价就是对开发者要求很高，没有语法约束来规避各种坑，在水平不足的时候就很容易摔倒，TS 的存在恰好是为了让 JS 没那么灵活，对于 JS 水平较高的人来说，TS 可能会影响发挥。

但你猜怎么着，前端从来都不缺水平低下的人，对于团队协作来说，猪队友是十分致命的存在，那么 TS 的价值就出来了，能提升代码质量的同时提升开发效率。相应的 Go 火起来也是因为这个。

所以做个人项目的话，我通常不会选择 TS，但团队合作最好是 TS 。

[pecopeco]

还没遇到过一个人拿不下来的前端项目，如果有可能会考虑 ts

[Leviathann]

@xd199153 这个是不行的，只能限定 T 的上界是 a|b
比如 type a = {a: 1}; type b = { b: 1 }
如果 <T extends a|b>
那 { a: 1, b: 1, c: 1 } 是一个合法的 T

[nanxiaobei]

@libook #71 觉得 TS 提示「很香」的，基本都是用 VS Code 的，但用 WebStorm 会觉得很奇怪 ... 这些提示不是很多本来就有吗，这有啥特别的

[musi]

@xd199153 #66 有一个推不动的原因是团队使用的是 Vue2，Vue 用 ts 还真不如不用。我个人在写一些底层库或者 SDK 的时候倒是会直接上 ts，对 OOP 的增强写起来很爽。所以我们团队是一直没推，但我个人是一直在学。

[musi]

其实我只是想强调 ts 并不是银弹，不是所有团队或者项目都时候上 ts 。理性看待就好。

[anguiao]

我觉得还蛮舒服的，除了开始写各种 interface 有点麻烦，后面用起来都挺爽。
虽然我才用不久，对各种类型体操还不熟悉，但是用来写业务代码还是够用了。如果是用来写库的话，估计还得更精进一点才行。

[kensoz]

学是肯定要学的，不学面试肯定挂
用的话看情况，领导不让用，团队不会，业务和历史包袱限制等等
如果是只有一个前端，还没有什么限制，那就看心情了

[Imindzzz]

@libook
@nanxiaobei
jsdoc 这个我比较好奇，能做到这种程度吗？怎么做？
https://imgtu.com/i/W45iQK

我知道 document.querySelector 这种都是因为有.ds

[popil1987]

我只是调用封装好的组件当然不需要 ts，但是如果这个组建你负责维护，注释里要写你的名字，过三个月你回来看看源码，接口你想看的，逻辑你是不想看的，ts 的好处就体现出来了。react，只要组件分的足够小，我看也没必要 ts

[yazinnnn]

不是,为什么你们黑 ts 的时候总要嘴一句 java?
难道 ts 不是跟 c# kotlin swift 更像吗?

[mikulch]

@fanym 兄弟话说到点子上了，归根结底 js 是真的垃圾。

[Geo200]

如果浏览器能直接运行 ts 可以考虑下

[xujiahui]

你们不会碰到封装别人已经写好的库的情况吗，那个时候在别人的对象上加属性是真的恶心，比如 AxiosRequestConfig 加点自定义属性，强行搞个文件声明模块和接口

[Imindzzz]

@popil1987 我没理解你这个思路，如果你用的都 ts 的组件，那为啥不顺手让“小组件”也用上 ts 。
所谓的“没必要”本质还是觉的“有成本”，在一个 ts 的大框架下，让小组件也用 ts 需要多少成本？

[lvming6816077]

如果 Node.js 写后端可以考虑用 ts，浏览器端什么时候原生支持了再用，现在就算了

[Imindzzz]

@yazinnnn 哈哈哈。可能他们对一切强类型静态类型的语言言都抵触吧，java 最流行就说 java 了。
我写过几年 java，还是蛮喜欢的。

[Imindzzz]

@mikulch 没太明白你说的“点子上”是什么意思。我们标题已经限定在前端了，要说都是垃圾的话，那前端不干了哦。

我是前端->必须在浏览器里用 js->js 辣鸡->我用 ts 。
如果你能搞出替代 ts 的更好的方案，大伙也不会拒绝的。

[Imindzzz]

@xujiahui 这个情况是极少数的
我们要先达成一个共识“按着他定义的规范写，是更标准的”。
然后如果你实在赶工，直接 as any，先把功能做了，回头再来优化，没啥不可以的。

[leonlu]

不写 ts 是因为在写 dart…

[Imindzzz]

@lvming6816077
@Geo200
@Rrrrrr
浏览器原生支持多半是不可能的，不过你们为什么需要这样呢，可不可以说一个实际引用场景?
现在都是构建工具一把梭，有 sourcemap，调试和 js 完全没差别呀。

[zxCoder]

@xd199153 我个人认为 ts 实际上更适合后端，就是 node.js 那一套，前端的话连浏览器能不能原生支持，算什么前端呢

[murmur]

@xd199153 别提了，chrome 的 sourcemap 跟弱 x 一样，多少年没解决，一打断点整个函数全亮了，必须用 debugger 才能停住，热更的越多 sourcemap 越没法用。。。

更何况我们要做 IE 测试

[ibegyourpardon]

ts 不是只有好处没有坏处的。

一个是很多人提到的场景问题，前端开发中会存在着大量的月抛甚至周抛型任务，但这类任务中又有相当一部分需要从头开始开发，本身也不复杂，使用弱类型语言一把出货，又快又好，这种情况下上 ts 反而是徒增心智负担。

第二个，原因，是我个人感受。不知道有没有人和我持类似的想法，但这个可能没法解决。ts 里有一些优秀的特性我觉得应该是进入 js 里面去的，但 js 既然保证了对历史版本的兼容，意味着基本做不到了。ts 永远只能是一个方言的形式存在。
最后跑起来的还是 js，意味着，ts 是一个从开发层面实现了更友好支持的方言，但最终跑起来的运行时优化，是和 ts 本身没多大关系的。
这很像 python 里现在的类型提示，很大程度上可以借助 IDE 或者某些类库实现友好的提示，帮你写出更好的代码，但跑起来后还是一套动态一起上。
而真正的强类型，编译语言，是可以在运行时上做到针对性的优化的。这事，注定是 ts 的短板。

所以 ts 的场景，我们可以大概认为，它应该是主要面向开发这层做优化，更方便协作，能写出更工程化的东西。
但这样的事，我更觉得，应该让原生 js 增加这些 feature 才对。

ts 应该进入 js 。

但回头看看 js 这边的一些新提案，再看看 python 那边花里胡哨的一些提案……唔，感觉官方们都还集中在语言本身的 feature 改动上，而对工程化的支持，似乎都是社区在自行推进周边的支持。

目前看来最舒服的居然是 go …… 不挑刺，我知道 go 的问题和不爽，但总的来说，在工程化，效率，性能，语法上，我觉得当前阶段是一个蛮舒服的结合点的。

[Imindzzz]

@murmur chrome 这个问题确实，不过 js 也是要 babel 构建的(没啥项目先)，一样调试不好打断点。期待有大牛能把这个问题解决吧。
这个我一般是 能打就打，不能打就 console ebugger 混着用。

[Imindzzz]

@murmur 不过 js 也是要 babel 构建的(没啥项目现在是直接新建个文件夹就开干吧)

[TomatoYuyuko]

独立开发，转 ts 之后做了 2 个项目，没觉得效率提升了，也没觉得 bug 少了，就这样

[Highlights]

成本可不仅仅是学习成本，ts 写完的项目如果后面的人维护，这不懂那不懂，天天拉着你问就恶心人了。

[theprimone]

不用 TS 不会写代码了。。。

[fanym]

@Highlights 维护 js 代码不是更不懂，代码定义在哪使用在哪都不好找。动态类型写起来容易出 bug，代码也不好看懂。