Hello，诸位前端工程师，今天由我来从一个 CRUD 开发工程师的角度聊一聊这个 "敏感" 的话题。

有一个现象

就是你不难发现，大多数能力比你强的前端工程师，要么在鼓励大家用 TS，要么就是自己的开源项目采用了 TS。

而这种现象通常会在技术领域会传播下来，普及给所有程序员。就像 Vue/React 等框架都有大厂开始大量使用后，再慢慢普及到小厂，最后几乎所有程序员都被普及到了（毕竟你不会就找不到工作了）。

而大厂尝试使用一门技术，并且成功落地之后并没有抛弃它，而是在更多的项目中使用，这种时候基本上就可以说这门技术的优点是比较明显的，被普及的概率也就非常大了。

正好，TS 就符合这个现象和普及规律。

也就是说，按照这个规律我们其实可以得出一个简单的结论：前端项目中使用 TS 是优大于弊的，并且以后 TS 会被普及

有一个误区

这种评论见多了，起初我真的很想回复一些什么来反驳反驳，后来想一想，其实就是他们当前太菜了...

因为我实在是想不明白 TS 降低开发效率是怎么得出来的？

如果你说你玩上了类型体操，开发效率降低了，那我想说的是，能力不够是可以不玩类型体操的，能够玩上类型体操的也不会吐出这么低级的槽，CRUD 也完全不需要类型体操
如果你说你初始化一个项目，进行各种 TS 配置和导包，出现大量报错不知所措，那说明你还不具备从零搭建一个TS 项目的能力，本质上还是你 TS 以及生态不熟悉，那你可以选择去开源社区找一个模板，等使用熟悉后再试着自己搭建，不要一开始就磨灭了自己的兴致
如果你觉得你定义一个 const a = 1，也要写成 const a: number = 1 是降低了开发效率，那其实是你还不习惯罢了，毕竟我刚学 TS 的第一天也有这种心理

或者这样，假设你们说的都是事实，就是 TS 降低了开发效率。但是 TS 没有优点吗？TS 的优点就没有一个能打赢 "降低开发效率" 这个假设吗？

我觉得应该是有的吧，说几个 CRUD 时就能体会到的：

一个变量原本是 string 类型，但是在某一处给这个变量赋值的时候，赋值成了 number 类型，你开发时发现程序无论如何都跑不对，定位半天发现原来是类型错误
还是这个变量，你赋值错了，但是由于对应功能不常用，上线前没有测试出来，导致出现了严重生产环境问题，你即将被追责
后期维护时，不用再到处翻找上下文就能立即知道变量类型
几乎不会再出现 ReferenceError： "x" is not defined

就这三个比较常见的点，哪一个带来的问题不能打赢 "降低开发效率"？就难道 ReferenceError： "x" is not defined 时你不需要花费时间定位问题吗？更别说出现生成环境问题了

有需求就有市场

随意截取了其他 TS 文章下的两则评论，类似的不支持 TS 的评论还有很多，几乎每一篇相关文章下面都会见到。

但是事实是，从 TS 出现，到现在的高热度和高采用，足以说明它在市场上是有足够多的需求的，并不会因为所谓的 "TS 没有 JS 灵活" 或 "JS 是弱类型，比 TS 更优势" 等观点左右它的需求量。

意思就是你必须使用 TS 吗？

那也当然不是，你可以继续使用 JS，就像现在你依旧可以使用 JQ。

但...

你真的有不学习、不使用 TS 的资本吗？将好像 JQ 时代过渡到 Vue/React 时代的时候一样，多少人嚷着 JQ 更优秀、市场占有率更高，操作 DOM 多么的灵活，Vue 等框架心智负担多么的大，学 Vue 前必须先学习 JQ 等等... 现在在看看呢？你还能再招聘 JD 上看见只要求你会 JQ 的岗位吗？

所以说啊，哪怕只是为了你的饭碗，你也应该去学一学 TS、用一用 TS。

不要做低级程序员

优秀的程序员总是在技术普及之前就研究它的思想，总结它的优缺点，尝试将其落地。

大众程序员总是在普及的时候才开始学。

而最低级的程序员只有等自己找不到工作了才会被迫开始学。

善意的提醒

随着 Vue3 的普及，开源社区优秀的模板都是拥抱的 TS 的（React 那就更早了），而大多数公司的项目都是基于这些模板进行开发的。如果不出意外的话，招聘 JD 上会出现越来越多的 TS 字样。

还是那句话，哪怕只是为了自己饭碗。