【翻译转载】TypeScript 被高估了

为什么 JavaScript 可能仍然是你最好的选择。

原文链接

The TypeScript language was released in 2012. It is nothing else than a JavaScript superset. It only start to take off a few years later. Since then, it has then been growing at an overhyped pace.

TypeScript 语言于 2012 年发布。刚发布时只是一个 JavaScript 超集。但几年后，它开始以过度炒作的速度爆炸式地增长。

It does bring some useful features to the JavaScript Ecosystem. However, are those enough to make us buy-in? What are the cons that nobody is talking about? Should you care about those?

它确实给 JavaScript 生态系统带来了一些有用的功能。然而，仅凭这些优点就足以让我们 all in Ts 吗？Ts 是否存在一些没人讨论的缺点？你是否应该关心这些缺点？

In this article, I will unveil the less bright picture of TypeScript and expose some reasons why you might want to rethink it twice before using it in your next project. We will look at the top 5 reasons you might reconsider its usage.

如果你想在项目中使用 Ts，我建议你阅读我的建议后再重新考虑是否要使用 Ts。本文将列出最值得考虑的 5 个 Ts 的缺点。

1.使你的代码混乱

(Clutters your codebase)

When using TypeScript we add a lot of verbosity to our codebase. By using clearer arguments and method names our codebase should already be self-explanatory. We don’t need any dummy type checking.

在 JS 中，通过使用更清晰的参数和方法名称，我们的代码库应该已经是非常明确的了。我们不需要任何虚拟类型检查。

但使用 TypeScript 时，Ts 会导致很多冗余的内容。

下面是一个例子：

const sum = (a, b) => a + b;

如果我们将其移植到 TypeScript，它将变为：

const sum = (a: number, b: number): number => (a + b) as number;

It is much harder to read and reason about. Without proper TypeScript knowledge, it is hard to understand it. It is different and not eye-pleasing.

As a consequence, the Developer suddenly now needs to understand a new language. Nowadays, most editors will be able to assist at the cost of lots of CPU cycles.

Ts 比 JS 阅读和理解都要困难得多。没有足够的 TypeScript 知识，Ts 将会变得难以理解。Ts 是异类，并且不赏心悦目。~（其实我觉得很好看）~

这导致了一个结果：开发人员现在突然需要理解一种新的语言。并且在你编写代码时，编辑器将占用更多的 CPU 资源来对代码提供帮助。

2.浏览器支持性差

（TypeScript is not supported on the Browser）

The Browser does not support natively the Typescript language. There is a proposal from the Microsoft team but it is still in the early stages. You can check it here for reference.

浏览器并不支持原生的 Ts 代码。虽然微软提出过一个针对的提案，但这个提案仍然在早期阶段，你可以点击这里 查阅

What does that mean? At the end of the day, we are shipping JavaScript code no matter what. What is the point in investing in Typescript? We would have to add a lot of extra steps in our workflows just to end up with some JavaScript files. It seems rather impractical.

这意味着什么？无论如何我们最后都要运行 JS 代码，那我们花精力去使用 Ts 的目的是什么？我们需要在项目中添加很多额外的步骤，而结果仍然 JS 代码，这个决定看起来十分不理智。

If the proposal from Microsoft makes it through we can rethink this claim. Nonetheless, we would still have to wait for the support to be decent prior~（这个不知道怎么翻译）~ to shipping Ts code to the Browser.

如果微软能将那个提案变成现实，那么这种说法值得参考。尽管如此，我们仍然需要等待浏览器能良好地支持 Ts 代码。

3.非常多的配置选项

（ Lots of configuration）

To be able to work with TypeScript we need to go into lots of configuration. We need to master the tsconfig.json configuration.

在使用 Ts 前，我们需要配置相当多的选项。我们需要掌握tsconfig.json的使用方法。

To start a TypeScript project we can run:

运行下面的代码来初始化一个 ts 项目

# install TypeScript globally
# 安装Ts依赖
npm install -g typescript
# init project
# 初始化Ts项目
tsc --init

Sections of the package.json:

• compilerOptions: It is the core configuration of the TypeScript project. It covers how the language should work. There are a lot of things to configure: type checking, modules, emit, editor support, … It is where we will spend most of our time configuring our project.
• include files: array of filenames or patterns to include.
• exclude files: array of filenames or patterns to exclude.

package.json中的部分设定：

• compilerOptions:最主要的配置选项，包含了代码如何工作的选项。其中包含：格式检查，模块，发行，编辑器支持……这是我们花费最多时间来配置的地方
• include files:包含的文件名或者模式数组
• exclude files:不包含的文件名或者模式数组

Once we completed the tsconfig config we are not close to done. We need to configure a Webpack~（这里也不知道怎么翻译）~ loader to process our TypeScript codebase. Do we want our TypeScript code to be processed by Babel? Should we use the ts-loader? It gets more and more complicated.

当我们配置完tsconfig文件，还不能马上运行 Ts 代码。我们需要配置一个 Webpack 加载器来打包我们的 Ts 代码。你会纠结于选择 Babel 还是 ts-loader 来打包你的代码。于是这件事便愈发复杂了。

On top of everything that we just saw, we would have to keep updating our TypeScript library. With every new release, there is a bunch of breaking changes. That means that a decent amount of time is invested on upgrades that happen every 4 months or so.

除此之外，我们还需要不断更新我们的 Ts 代码库。每一个版本都会有大量不同的更新。这意味着我们要花费相当多的时间在这些大约 4 个月就会产生一次的更新上

4.陡峭的学习路线（Steep Learning Curve）

The TypeScript language is much more complicated than JavaScript. It takes a while to be used to it and use it properly. There are a lot of features to master:

• Mapped Types
• Tuples
• Inference
• Template Literals
• Function Overloading
• Unions
• Generics

Ts 比 JS 更加复杂，需要花费一些时间来适应和掌握。下面是一些 Ts 的新特新：

• 映射类型
• 元组（Tuples）
• 类型推断（Inference）
• 模板字符串（Template Literals）~（这不是 js 的吗？）~
• 函数重载
• 联合类型（Unions）eg:number | string
• 泛型（Generics）

There are also some features that are hard to reason about. Unlike others, they produce some JavaScript code. This is the case with enums. There is no such feature in JavaScript.

Let’s look at the following enum:

Ts 的一些特性比较难以理解。不同于其他特性，它们产生了一些比较奇怪的 JS 代码。比如 enum，JS 里并没有这样的特性。

下面是展示的代码。

enum Status {
  Succes,
  Error,
  Warning,
  Info
}

For somebody coming from the JavaScript world, it would take a lot of time to master this feature. Furthermore, it does produce the following output:

对于 JS 使用者而言，这个特性会花费他们不少时间去掌握。~（我寻思 enum 用得也不多啊）~

此外，Ts 会产生下面的 JS 代码：

var Status;
(function (Status) {
  Status[(Status["Succes"] = 0)] = "Succes";
  Status[(Status["Error"] = 1)] = "Error";
  Status[(Status["Warning"] = 2)] = "Warning";
  Status[(Status["Info"] = 3)] = "Info";
})(Status || (Status = {}));

The above is quite a mouthful and something we need to be aware of when coding in TypeScript. That increases the complexity of our tasks.

上面的代码看上去有点冗余，我们在写 Ts 时需要注意这些类似的问题。但这增加了我们工作的复杂性。

5.与第三方的兼容性

（Compatibility With Third Parties）

Some third-party libraries don’t fully support TypeScript. Sometimes they don’t support it at all. Why would they anyway? As a result, we will be using an unchecked codebase which defeats the usage of TypeScript.

一些第三方库不完全支持 Ts，有时候是完全不支持，编写者没有理由这么做。但这导致 Ts 的我们会使用未经检查的代码，这破坏了 Ts 的原则。

That is not the worst scenario. Sometimes we might see libraries with half-baked TypeScript support and some inconsistent interfaces. That makes our tasks harder and trickier. How can we trust third-party TypeScript skills?

这还不是最糟的，有时候我们会遇见一些支持但不完全支持 Ts 的库，或者一些前后矛盾的接口。这让我们的工作更加艰难和麻烦。我们该如何相信第三方的 Ts 功能？

Luckily we can use the DefinitelyTyped package publisher. It is a repository for high-quality TypeScript type definitions. It has improved things a good deal. Still, you will find yourselves opening PRs more often than not to address the issues you might find.

幸运的是，我们可以使用 DefinitelyTyped 包社区，这是一个高质量的 Ts 类似的仓库，它可以一定程度上解决这个问题。如果你尝试使用它，你会发现你经常打开 PRs 去解决一些可能发生的问题。

6. 影响开发速度

（Hurts Development Speed）

One of the key aspects of development is to stay productive. All the previously mentioned issues contribute to having to pay a “TypeScript Tax”. That hugely damages our productivity. We become less agile and more constrained Developers. There is a good reason JavaScript does not include typing.

高效是开发的一个重要方面。Ts 各种问题导致我们背负了一个**"TypeScript 负担"**。这严重影响了我们的开发效率，让我们的开发工作变得更不敏捷和更拘谨。这也是 JS 不使用类型检查的原因。

Many advocate that TypeScript will save us from nasty bugs. However, the language avoids opting out of typings by providing the any or Function types. We can also use the @ts-ignore directive. So there is no real way to trust Typescript.

很多支持者说 Ts 能帮助避免很多恶性 BUG。然而，Ts 给予了any和Function这 2 个宽泛的类型，并且你可以使用@ts-ignore来逃过类型检查。这导致了 Ts 代码不一定那么可信。

How else can we be sure that our codebase is robust and bug-free? By heavily investing in testing. That is the only reliable tool we have to keep a resilient codebase with no edge cases.

那么，如何才能确保我们代码的健壮性，减少 bug 的产生？

只有通过大量的测试，才能让我们的代码在更极端的情况下仍然健壮。

We are also slowed down by the TypeScript asset compilation. Tools like ESBuild and SWC are making that process faster. However, many still use Webpack. In order to speed up Webpack, we can use Babel to strip the types. As Babel is not emitting any type of errors we will find out about those later down the road. It does sacrifice type safety for bundling speed.

同时，Ts 的编译器也会拖累我们，ESBuild 或者 SWC 能更快地完成这个流程。但是，大多数人都是用 Webpack。我们可以使用 Bable 代替 Webpack 来提升打包速度。但是这个速度是牺牲类型换来的，这会导致在编译时无法报出类型的错误，但这个错误可能在运行出现。

最后

（Wrap Up）

I hope this article helps you remove the bandages on your eyes. TypeScript is a good language but a bit too much overhyped.

You could still try to advocate for it in large codebases. It might have some advantages if your team has the knowledge. However, for small projects or MVP applications, I would advise against it. The team on tighter deadlines will be dragged by a technology that is not proven to be that useful.

Cheers

If you made it this far reading some non-sense reasons, happy April fool’s day to you 🤣

我希望这篇文章能减少你的偏见，Ts 是一个优秀的语言，但是现在被过度炒作了

你可以继续在复杂的项目中使用 Ts，当你的团队也掌握 Ts 时，Ts 可能会展现它的优势。

但是，对于小型的应用（Minimum Viable Product）或项目，我建议你拒绝 Ts。因为随着 DDL 的靠近，一个未被完全证实有用的工具可能会给你的团队造成不小的麻烦。

生词表

released 发布

nothing else than…… 仅此而已

cons 缺点

Ecosystem 生态系统

feature 特点

article 文章

unveil 公布

Clutters 使……混乱

verbosity 冗长

arguments 参数

self-explanatory 不言自明，自解释的

consequence 结果

editors 编辑器

assist 协助

cycles 时钟，周期（这里理解为 CPU 时针）

proposal 提案，建议

stages 阶段

shipping 航运（这里理解为运行）

investing 投资

extra 额外的

workflows 工作流

impractical 不明智的

claim 说法

Nonetheless 尽管如此

decent 得体的（这里理解为合适的）

master 掌握/熟悉

sections 部分

core 核心

covers 包含了

configure 设定

emit 发行

spend 花费

completed 完成

process 加工

complicated 复杂的

update 更新

decent 相当

amount 数量

properly 合适地

Furthermore 此外

mouthful 又长又拗口

be aware of 知道，了解

increases 增加了

task 工作

Why would they anyway 他们为什么这么做

defeat 打败

scenario 设想，可能发生的情况

half-baked 不完善的

inconsistent 前后矛盾的

interfaces 接口

trickier 狡猾的；机警的

publisher 出版者，出版商；发行人

repository 仓库

high-quality 高质量的

definitions 定义

more often than not 通常；多半

address 解决

productive 多产的，高效的

previously 前面的，先前的

mentioned 提及

contribute 是……的原因之一

Tax 负担

hugely 极度地，巨大地

agile 敏捷的

constrained 不自然的

typing 按类型把……归类

advocate

• *v.*拥护，提倡
• *n.*拥护者，提倡者

nasty 恶性的

opt 挑选

proivde 提供

directive 指令

robust 健壮的

reliable 可靠的，可信赖的（rely 信赖）

resilient 有弹性的，对困境有承受力的，有复原力的；

process 步骤

strip 去除

sacrifice 牺牲

bandage 绷带

overhyped 过度吹捧的

advocate 拥护

tighter *adj.*更紧的；更严格的（tight 的比较级）

dragged *v.*制动；拖动；打滑；松懈

proven 证明

non-sense 无意义的