原文链接

TypeScript在前端环境中越来越受欢迎。已经有80％的开发人员承认他们想在下一个项目中使用或学习TypeScript。自从我第一次使用它以来，我就一直喜欢它。我肯定会在以后的所有项目中继续使用它。

有些人担心TypeScript是前端工具链的不必要依赖。是吗？跟着我来了解现实是完全相反的。

一个“动态类型语言专家”的故事

在我编程生涯的18年中，我从未喜欢过静态类型的语言。自从2001年开始编程以来，我一直选择动态选择语言：PHP，JS，Ruby，Elixir。我到处都用C ++和Java编写了一些程序，但是我一直讨厌那些环境。（“为什么我需要在各处传递类型？这太糟了。我自己可以照顾他们。”） 一切都在2年前发生了变化。那是我第一次使用TypeScript的时候。但是，从一开始我就没有爱上它。在最初的几天里，这实际上让我很烦。情况很快改变了。我在代码中输入的类型定义越多，我越经常注意到它使我免于浪费时间在控制台中手动调试愚蠢的bug。我开始欣赏这些类型。 在接下来的两年中，无论何时我在前端应用程序上进行协作，无论是Angular还是React，我都注意到，无论我使用什么框架，在所有.js项目中总会遗漏一件事：TypeScript 。 现在我必须承认。我不喜欢动态类型的语言了。我仍然可以在其中高效地工作，但是当我不能只在IDE中查找类型定义或在对代码进行原型设计时信任编译器时，这使我感到不满意。（我在Elixir中唯一仍然想念的是强类型。） 幸运的是，我们不必等到Ecma TC39提交者将静态类型系统引入JavaScript。我们可以改用TypeScript。特别是在新项目中，使用它的麻烦极少。

反TypeScript参数

尽管如此，仍然有人敢于争辩说将TypeScript引入您的项目将：

• 增加新开发人员的入职时间，
• 维护复杂化
• 与React发生很多冲突，
• 增加开发时间，
• 将项目锁定到一年后将不再存在的某些时髦技术中，
• 阻止招募优秀的JS人员，
• 使得不可能从非TS代码库中引入代码，
• 使得在遥远的将来很难编辑该应用。

我敢说他们都错了。TypeScript将为您解决以上所有情况，我可以为您提供具体的论据，为什么会这样。 这就是为什么我决定写这篇文章的原因。也许这将有助于说服您，您的朋友，同事或CTO使用这种出色的语言。 注意：在本文中，我不会解释“ TypeScript是什么”。我仅关注“ 为什么”您应该使用它。如果您仍然不了解TypeScript的真正含义，建议您首先阅读以下一些链接：

• “什么是TypeScript，为什么我要用它代替JavaScript？” — Lodewijk的Bogaards，StackOverflow
• TypeScript语言官方网站
• “ TypeScript —具有超能力的JavaScript” — Indrek Lasn，中等
• “ TypeScript深入学习” — Basarat Ali Syed撰写的电子书

TypeScript的优势

1.代码更容易理解

通常，当您处理一段代码（例如功能代码）时，要完全理解它，您需要掌握以下内容：

1. 它接受什么论点？
2. 它返回什么值？
3. 需要什么外部数据？
4. 为了产生返回值，这些参数和外部数据有什么作用？

在动态类型语言中，通常很难回答前三个问题。如果一个函数收到article参数，那么它到底是什么？它是具有某些商品属性的对象吗？有哪些确切的属性？是否有一个article.title或article.name？我可以始终假设article.title存在吗？怎么article.isPublished样我可能知道此属性article在应用程序的大多数位置都已合并到对象中，但是我可以确定，它始终也存在于此位置吗？

要回答所有这些问题，通常需要执行以下操作之一：

1. console.log(article)在浏览器中放置一个，运行脚本，（也许单击一下UI），然后阅读日志；
2. 查看该函数的使用位置，并从那里跟踪将哪些数据放入所有出现的位置；
3. 向您的同事询问最近是否正在使用此代码（希望他们仍然健在，在线并记住该代码）；
4. 假设它article与您所想的一样，只是希望它能起作用。

这听起来对您熟悉吗？

对我来说，这听起来像是任何动态类型化语言（例如JS，PHP，Ruby，Python，Elixir）中的典型Web开发工作流程。 在诸如TypeScript之类的静态类型语言中，您可以立即从IDE和编译器中获得上述所有问题的答案。您不再需要查看整个代码库，让同事困扰于问题，也不必冒生产中的错误的风险。

2.代码更容易实现

通常，当您必须创建新功能或新组件时，您的工作流程可能如下所示：

1. 引导组件函数，组成其构造函数参数，编写其余代码。
2. 如果它需要任何外部或复杂的数据（如user或articles），请猜测它的外观，将其保存在自己的内存中，并像在代码中那样使用它。
3. 将组件放到您的应用中，然后将道具传递给它。
4. 对其进行手动或单元测试。（您需要确保它收到了它应该拥有的道具，并确保它应该如何工作。）
5. 如果有什么不对劲，请返回您的代码，尝试找出问题所在，进行修复，然后返回步骤no。4。

在TypeScript中，它是相似的，但是更容易，更快捷：

1. 引导组件功能，定义其类型定义，并实现它。
2. 如果需要任何外部或复杂数据，请查找它们的接口并重用它们（全部或部分）。
3. 将组件放到您的应用中，然后将道具传递给它。
4. 而已。（如果您在调用方和被调用方之间正确地匹配了typedef，则所有内容都应该可以正常工作。现在唯一需要测试的就是组件的实际业务逻辑。）

因此，每当您以TypeScript编写代码时，它不仅更具可读性且不易出错，而且主要是，更易于推理。

3.代码更易于重构

您经常需要重构很多东西，但是由于它们涉及很多东西和文件，因此您太害怕更改它们了。

在TypeScript中，通常只需在IDE中单击“ 重命名符号 ”命令即可重构这些东西。

在动态类型的语言中，可以帮助您同时重构多个文件的最佳方法是使用RegExp搜索和替换。

在静态类型语言中，不再需要“搜索和替换”。使用诸如“查找所有事件”和“重命名符号”之类的IDE命令，您可以在应用程序中查看给定功能，类或对象接口属性的所有事件。

每当您想要稍微改善构建系统，重命名组件，更改user对象或删除不推荐使用的属性时，您都不必担心会再发生问题。TypeScript将帮助您查找重构位的所有用法，重命名它，并在重构后代码有任何类型不匹配的情况下向您发出编译错误警告。

4.更少的错误

在多年的前端Web开发中，我注意到，只要有一个人坐在我旁边，每当我做错字时都会对我大喊大叫，我可以节省大约50％的错误修复时间。可能为null的值，或者将对象传递到应该为数组的位置。

我很高兴地说，我终于遇到了那个伙伴：它叫做TypeScript。

多亏了它，现在编写无效代码变得更加困难。如果编译成功，您可能会确定它确实有效。

5.更少的样板测试

当您确定将变量正确地传递到所有给定位置时，就无需再对所有变量进行测试了。 与编写简单的样板单元/集成测试不同，您可以将更多的精力放在测试应用程序的业务逻辑上，而不是测试函数参数是否在彼此之间正确传递。 更少的测试意味着更短的时间来开发新功能，以及更小的代码库，从而减少了代码的复杂性，出错率并且易于维护。

6.代码更易于合并

您团队中的新初级开发人员刚刚发布了PR，引入了新代码。乍一看，一切都还不错：代码看起来不错，单元测试在那里，一切都通过了绿色。

您现在可以确定它可以正常工作吗？如果没有适当的单元测试该怎么办？（是的。让我们认识现实中的人们，我们很多人仍然没有写足够的数量。）您会信任公关创作者吗？还是您会花费宝贵的5分钟时间自行运行代码并进行测试？

如果您的工具链中包含TypeScript，它将为您提供另一项保证检查：typedef编译检查。

如果代码看起来不错，就可以进行单元测试，并且整个程序都可以编译，现在您可以确定整个程序可以正常工作。

使用TypeScript可以更轻松地信任其他开发人员。它可能会提高您查看和合并PR的速度。

（反之亦然：由于类型定义，对于新开发人员而言， 无需深入研究或自己运行代码，就更容易看到其他人的代码部分真正在做什么。）

7.帮助开发人员拥有正确的工作流程

用静态类型的语言编写代码时，首先需要考虑将要接收的数据类型，然后考虑要生成的数据类型。通常只有在那之后，您才坐下来进行实际的实现。

许多人会赌命，这是正确的编码工作流程。

例如，无论何时开发算法，都应首先考虑其理论公式，然后加以实施。

或者，无论何时进行TDD，您首先需要考虑代码在现实中的工作方式（它将接收什么数据以及它将产生什么数据），将其编写为测试，然后实施实际代码。

同样适用于TypeScript。它鼓励您在坐下来执行代码的内部实现之前，先考虑一下代码的接口。

TypeScript缺点

1.需要编译步骤

我的一些后端Node.js朋友告诉我，为他们介绍TS只是不值得的，因为在将.ts它们运行在Node上之前，需要对所有文件进行预编译会带来很多麻烦。 虽然可以肯定您可以通过良好的构建和开发设置来处理该问题，但我不能不同意它会为您的Node.js应用程序增加一些开销。 我在前端环境中对此表示不同。如今，每个人都在编译JS。您需要旧版浏览器支持吗？ES7的功能？CSS-in-JS？对于所有这些，您可能已经使用了babel。可以使用Babel编译TypeScript,就像JS的任何其他语法（包括ES7或JSX）一样。

将TypeScript带到您的前端项目中几乎不会给构建设置带来任何开销。（仅在根本不编译JS的情况下，这可能会带来开销，但是这种情况很少发生在前端。）

2.设置有点困难

我可以同意这一点。例如，TypeScript中的Next.js应用程序和Next.js应用程序之间有什么区别？在第二种情况下，您需要使Node.js服务器，webpack和jest测试运行程序能够与TypeScript一起使用。另外，每当添加诸如React，Redux，Styled-Components之类的库时，还需要为其添加typedef，例如npm i @types/styled-components（除非lib中包含TS typedefs文件）。

您需要回答自己的问题是，您多久做一次这样的事情？值得放弃TypeScript的所有优势吗？

摘要

我是说我们所有人都应该突然切换到TypeScript吗？不。例如，在一个现有项目中切换到它肯定是很多工作，并且在这样做之前，应该认真考虑一下。

但是，如果您要创建一个新的前端应用程序（必须随时间进行维护），那么情况就很清楚了。使用TypeScript。老实说，我很想听听在您的下一个前端项目中使用TS的原因是什么。

我只想这样说：通过使用TypeScript，您将获得许多强大的优势，而一开始只需付出很少的精力。 让我们来做TypeScript的人吧