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

[Imindzzz]

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

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

大家心平气和不要吵架。

[shik1]

ts 真的太香了！现在真不想碰 js 项目

[Highlights]

@fanym 团队项目基本都是用框架开发的，但问题基本所有的前端都学过 js，学过 ts 的并不多，没有静态类型概念的连 interface 都理解不了，真不是所有人两下子就能上手的。

[Imindzzz]

@ibegyourpardon
一：把你的月抛周抛项目开源出来大伙看看，我倒要看看用 ts 能增加多少心智负担。
恰恰是这种项目，这个月抛了，明年这个月又要叫你改改再上线一次，有 ts 不是更好改？

[Imindzzz]

@Highlights 不是我看不起你哈，如果你的视野范围内是“学过 ts 的并不多”，那我劝你早点换个圈子，换个团队。
或者你学好 ts，带着大伙一起用，提升整体的工作效率，年终奖就有着落了。
(前面我也说到了，我想推推不动，来了个比我厉害的把各种事情安排好，大伙用得舒舒服服的。

[Highlights]

@xd199153 去年推过，遭到全组的反对，算了，多谢您的指教，生活也可以这么轻松就好了，搬砖去了。

[libook]

@xd199153 #75 你这个例子不需要写 JSDoc，编辑器、IDE 能自己判断出有哪些属性或方法。https://imgtu.com/i/WH1KZF
任何编辑器、IDE 在没有 TS 插件的时候也都做不到 TS 的提示功能，相应的 JSDoc 带来的提示功能也是由插件实现的，和 TS 一样，很多编辑器和 IDE 自带了 JSDoc 的插件，甚至在 TS 出现之前就已经存在了。

其实更多区别还是在于类型声明上，这两张图就是个简单的对比，图一是 ESDoc 实现的，图二是 TS 实现的：
https://imgtu.com/i/WH3Ulq
https://imgtu.com/i/WH3Npn
你猜怎么着，ESDoc 还能给参数加描述。

建议看一下 JSDoc 和 ESDoc 的文档，在自己的编辑器或 IDE 上试试，花不了几分钟。

我觉得 TS 也就那样，没必要神化，项目适合就用，不适合就不用，TS 再怎么🐂🍺也不敢脱离 ES 的基本范畴，因为它就指着 ES 生态来维持用户群；除非某一天浏览器集体支持 TS 原生引擎，但只要 TS 还是微软主导的，就基本没可能。

[rongchuan]

想用就用，不想用就不用，这东西有用，但没那么大用，写起来成本也不低。我用 JS 十分钟能写完，换成 TS 要 20 分钟，何必呢。况且 VUE+TS 写起来一股异味，自己给自己造 bug,如果用 angular 的话写 TS 倒是无可厚非。至于说维护，你自己写的代码，要是你维护，那用不用 TS 没多大区别。要是维护别人的代码，别人用 TS 写的，你看起来会清楚一点，但也就清楚一点，不懂业务，你也看不懂他代码为啥这么写。
要是 leader 要求大家写 TS，就老实写。leader 没发话，就别自我发挥了，浪费时间...这真不是啥高深的东西，写不写 TS 也没啥优越

[HAYWAEL]

@Highlights 这玩意还有反对的 ，做技术的，如果对新技术都不好奇，。

[Imindzzz]

@rongchuan 把你“10 分钟”写完的项目开源出来看看，我看我用 ts 要不要 20 分钟。
你要是真有什么“必须不用”的理由，那我没啥好说的。
但是整个 js 生态(前端 /后端)都在推的东西，你是“可以可不用，所以我不用”，那我觉得你不是一个合格的工程师。

[Imindzzz]

@libook 大伙至少都还是觉得“有提示更好”。看来自动推断也挺不错的，但不可否认还是 ts 更精确，重构也更方便。
用 ts 都觉得麻烦(“有成本”)的话，用 jsdoc 不觉得更麻烦吗。。

“项目适合就用，不适合就不用”这话倒是没错啦，不过我也是一直强调“用 ts 没有坏处”嘛
就比如你这个 jsdoc 提示的场景，用 ts 就能免费得到这个功能(甚至更好)，为啥不用呢~

[kingwl]

@libook 你猜你这三个截图的功能在 VSCode 里面是谁做的。。。

[Imindzzz]

@rongchuan 不好意思，“不是一个合格的工程师”说的有点激动了，抱歉。

我主要想表达的就是，你可以有各种理由暂时不能使用 ts，但是你不能否认 ts 对 前端(和 node 后端) 现代化 /工程化 /专业化... 的贡献。

“尽快用上 ts，加入到这个生态圈里来” 应该是每个工程师的梦想吧？

[libook]

@kingwl #111 你的意思是说，在 TS 出现之前没有任何工具可以做到这个事情吗？ VSCode 使用的方案同时是其他所有编辑器和 IDE 使用的方案吗？讨论的问题是 JSDoc 、ESDoc 能否帮助达到 TS 一样的效果，这几张图不足以说明吗？


@xd199153 #110 仔细看我的图，用 doc 的方式除了能满足类型提示和检查以外还能加更多描述，很多时候团队协作为了写描述横竖都要写 doc，顺手写类型声明和 TS 的成本是一样的，也就只是写的位置不一样。

我前面的回复已经说明了，代码提示和类型检查都是工具带来的，TS 离了工具也没法出提示（用纯净的 Vim 试试看），面向 JS 的相关工具也都有，精确不精确取决于工具水平怎么样，WebStorm 上的高水平工具不写 JSDoc 靠推论也能做精准的类型提示。

工具链+语言，至少工具链方面 TS 并没有比 JS 多少优势，语言方面看你要约束还是要灵活，对于要灵活的情况来说，TS 的约束就是缺点。

技术栈选型从来都不是选一个最好的，而是选一个最合适的，任何技术都有优点和缺点，没有完美的。

[Imindzzz]

@libook 我说更精确，是下面这种。JSDoc 只能作为文档，不能限制工程师随手写错。
重构的时候，jsdoc 还是需要改注释和代码两个地方，调用方也不会报错(CI 测试照样会 pass)。
https://imgtu.com/i/WHqCgU
https://imgtu.com/i/WHqPvF

我觉得不需要争论 jsdoc 的类型好还是 ts 的类型，他们各司其职比较好。ts 提供精确的类型定义，jsdoc 提供详细的注释描述。
路图一，其实我一直都在写这种规范的注释，只是我不知道它叫“jsdoc”

[Imindzzz]

@libook 随便问一下，ts 我定义的对象参数，用 jsdoc 应该怎么定义？ 我不会，所以图二写成了多个参数。

[libook]

@xd199153 #114 TS 重构的时候也是一样要改两个地方，一处类型声明、另一处代码声明，只不过这两个地方和 JS 的两个地方位置不一样而已。
工具都是有好用和不好用之分的，VSCode 的代码分析和提示功能跟一些商业 IDE 比起来还是很弱，在 WebStorm 里，JS 即便不写 doc 做类型声明也会通过代码分析来推断类型，然后给画波浪线，提交的时候还会提示代码可能存在问题建议去修改（也可以忽略），花的钱其实也值在这里。
无非是 TS 工具默认不忽略问题（你也可以 @ts-nocheck 忽略问题）；这个对于 JS 工具来说也可以配置不忽略潜在问题，让 CI 直接失败。在这个问题上，不得不说 TS 技术栈给出的是一站式方案，包装成了现成的产品，开箱即用，而 JS 技术栈则依然十分灵活，按配置来实现需求。

对象参数用 doc 来定义的话有多种方式，一种思路是直接在 saveUser 声明参数的时候写个对象结构声明：
/**
* Save a user.
* @param {{nickname: string, age :number}} userObject
* @returns
*/
function saveUser(userObject) {
return true;
}

另一种思路可以先声明对象类型，然后在 saveUser 声明参数的时候直接引用这个类型，同样这种方式可以给每个属性写描述：
/**
* @typedef {Object} User
* @property {string} nickname
* @property {number} age
*/

/**
* Save a user.
* @param {User} userObject
* @returns
*/
function saveUser(userObject) {
return true;
}
// 效果如此： https://imgtu.com/i/Wb9wY4


JSDoc 和 ESDoc 是两种 doc 标准，前者主要针对原型写法，后者主要针对 class 写法（这么说也比较笼统），不过很多工具都是会同时集成两者，都可以直接用，也确实有很多人不知道有这个东西，在 TS 出现之前 JSDoc 是解决文档和辅助语法检查问题的主要方式之一。

[leelz]

@xd199153 断断续续写了两年，光说后端反的一个大几十个字段的 json 去挨个定义类型就要花一会时间了。

[mxT52CRuqR6o5]

@libook webstorm 里用重构工具能直接一次改好类型声明和代码声明

[libook]

@mxT52CRuqR6o5 #118 是，TS 和 JS+doc 都能自动改。

[kingwl]

@libook

是，但不完全是。例如：

```ts

/**
* @template {string} T
* @param {T} x
* @return {T}
*/
function strindId(x) {
return x;
}

const a = strindId(1); // Argument of type 'number' is not assignable to parameter of type 'string'.
const b = strindId("");

```

除非有人 /公司另外实现了一个 TS typechecker, 否则最后还是交给了 TS 。。。

[Imindzzz]

@leelz
两个方案，一个就是我前面说的，直接从返回数据里复制 json，不太优雅。
一个是用接口文档生成代码，楼上也有说。

[Imindzzz]

@kingwl 我觉得这个可以不用争了，我同意 @libook， 要实现大伙都能实现。

只是我觉得现在圈子里大部分都用 ts，那就用 ts 更好吧，融入到 ts 打圈子里来。
要迁移有成本的话，这个可以理解，

[94qihang]

@xd199153 我寻思我也没说 TS 类型写着麻烦啊。
我说的场景是：一个项目那么多接口，每个接口返回的数据结构都需要写类型定义；项目要求快速上线，这个时候还一定要用 TS 吗？虽然好多 API 文档工具都已经支持生成 TS 声明文件了，但是后端不配合你你怎么搞？
我 18 年才开始用 TS，理解还不够深入，希望一块探讨吧。

[Imindzzz]

@94qihang 你看一下我 12 楼 25 楼 121 楼，说的是不是你这个场景。

写个 interface，然后 copy 一下接口的 json，这个花不了一分钟吧？
要更详细的定义一下，也花不了几分钟吧？