驳《抛弃 JS,使用 TypeScript》

看完《抛弃 JS,是用 TypeScript》的评论之后还蛮出乎我的意料的,我之前以为会有人对 TS 持观望状态,结果发现事实是两极分化状态:喜欢的人特别喜欢,不喜欢的人还是喜欢 JS。

本文把大家对 TS 的意见汇总一下,就当是自己驳自己了。

1

“抛弃 JS”这个说法有待商榷,毕竟TS和各大框架的根还是JS;TS不是被浏览器原生支持的标准而JS是。

没错 JS 不死,我部分同意这个观点。但是对于一个全面是用 TS 的前端来说,JS 就是「不值得再使用」的语言,或者说得直白点,你让一个用 TS 的人回去用 JS,他会觉得这等价于在项目中引入 bug。

所有关于「抛弃」一词是否恰当的评论,其实都认为 TS 只是一个可选项或者一个辅助。这也许是看问题的角度不同,从这个角度来说,我认为 TS 是一个必选项,不用 TS 就是一种质量损失。

或者我再说主观一点:「唾弃 JS,使用 TypeScript」。因为我认为,矫枉必须过正。

你说要开一扇门,大家不允许;你再说那就开一个天窗,大家就允许了。


2

纯ts自然爽,想要多爽就有多爽,但是呢,js生态@types/**/*.d.ts的质量参差不齐,有的库甚至没有,对类型强迫症极其不友好,为了保持高度的类型约束,我总是在覆写别人的d.ts,体验真的不怎么样。

这就说明 TypeScript 的布道还做得不够。以后没有 TS 支持的库我们都要唾弃它:「连 TypeScript 都不支持,差评!」哈哈。


3

说的那些强类型检查避免bug的好处,WebStorm 都能办到,为啥一定要用ts?
  1. 大部分库提供了 TS 类型申明,才使得 WebStorm 能更好地提示类型,所以第三方库要用 TS。
  2. 没有提供 TS 类型申明的库或代码,WebStorm 只能大概推测存在失误,所以自己的代码也要用 TS。
  3. 如果没用 TS,WebStorm 根本没法做到像现在这样智能,我想这已经说明问题了。

当然你可以坚持用 JS,然后靠着别人的 TS 类型声明和 WebStorm 可能出错的弱的推断写代码,没有大问题,但是小问题会很多。

4

ts对于前端技术发展肯定是好的,但是有没有必要在每一个项目都用它,且严格模式,就不一定了。还是要看团队水平和业务场景,否则你会发现一个新人在那调了一个下午的any,as,影响业务进度

你说了两个问题:

  1. 没必要在每个项目都用 TS。
  2. 新人不会用 TS。

第一个问题我原文的观点是这样的:

  1. 所有项目都应该用 TS,因为能减少 bug。
  2. 如果有些老项目是 JS,可以逐步引入 TS,因为能减少 bug。

第二个问题我的观点是:

  1. 培训你的新人,让他知道 any 是邪恶的。
  2. 在 tsconfig 里把 any 禁掉,不允许隐式 any。

如果你司不愿意培训新人,那我觉得他们用 JS 会比 TS 更加危险。


以上是知乎网友的评论,非常地有建设性。

同时我把文章也发到掘金,评论质量就很那啥了。我在原文说的很清楚,没看完就不要评论,站队也不用评论。那边有一半的评论(26个评论中的13个评论)是

  1. 标题党(这种人一般是没看完文章)
  2. 培训机构的人写得任何文章都是为了割韭菜(屁股论)
  3. 文章没水平

然而,他们除了抛出一个毫无意义的观点外,居然拿不出任何论据,这种我就直接不看了。


当然另外13个评论还是在正常讨论的。

5

经常各种类型未找到声明怎么搞,引入一个插件,插件也没有声明文件。。。最后导出都是any类型.

这正说明 TS 的布道力度不够。不过解决方法也不是没有。

假设你引入了一个库,没有 TS 支持,你创建一个声明就好。这个声明不需要把库全部描述一遍,你只需要描述你用到的那一部分。

怎么知道自己用到了哪些呢?这个时候TS的先进性就体现出来了,TS 会在你用到了却没有声明的地方报错。

你的声明文件只需要消除这个报错即可。就算有 100 处报错,你也能在十分钟能搞定这些声明,没有你想象中难。

不要用 any,永远不要。


这就牵扯到另一个话题了:

TypeScript 能提升你团队的整体质量

以前大家用 JS 的时候,随便怎么用都行,bug 一大堆也没人知道,大家相安无事。

用了 TS 之后,就不行了,低级 bug 全暴露出来了,必须解决掉才能上线。

这个时候你团队里的烂程序员就非常想用 any 了事。

一定要踢出这样的队友。

为了保证团队质量,这些事一定要做:

  1. 禁止隐式 any。
  2. 所有显示 any 必须给出充分的理由(理论上来说,任何理由都不会是充分的,因为所有地方都可以不用 any,就看这个人有没有质量意识了。花10分钟减少未来60分钟的处理 bug 的时间,这点道理都想不明白就是没有质量意识)。
  3. Code Review,发现 any 就喷代码垃圾,如此三个月,团队焕发新生。

当然,如果你在不注重代码质量的团队里干活,用 JS 也挺好。

编辑于 2019-07-02

文章被以下专栏收录