在2017-2019年期间，TypeScript显着增加。 发生这种情况的原因很明显。 这种语言有很多优点。
在 2018年
JavaScript状态调查中，将近一半
的受访者已经尝试过TypeScript，并计划在将来编写它。 TypeScript非常流行，但是值得在大型软件项目中使用吗？
在本文中，根据作者的数字指标和实践经验，我们进行了相当严格的尝试，以分析使用TypeScript在大型项目开发中的效果。
关于TypeScript增长
TypeScript是发展最快的语言之一。 当前，它是用JavaScript编译的语言中的领先语言。 以下是Google趋势中的TypeScript数据。
2014-2019年有关TypeScript流行度动态的Google趋势数据以下是来自GitHub的
信息 ，反映了程序员对开发各种编程语言的兴趣。
GitHub有关编程语言增长的数据（按贡献者数量计）以上是非常令人印象深刻的指标，表明TypeScript的日益普及，不应低估它。 但应注意的是，TS仍远未被公认是JavaScript生态系统的领先语言。 如果将JavaScript生态系统与海洋相提并论，那么TypeScript将成为海洋中的一大波浪。 根据Google趋势，这是JavaScript（红线）和TypeScript（蓝线）的比较。
2014-2018年Google趋势提供的有关JavaScript和TypeScript流行度动态的数据这是GitHub上有关2008-2018年用于创建存储库的领先编程语言的信息。
有关使用各种编程语言创建的存储库数量的GitHub数据您可以看到，就存储库数量而言，TypeScript不在前五种语言之列。
应当指出的是，2018年TypeScript的历史出现了转折，并且在2019年这种语言将在许多实际项目中使用。 如果您是JavaScript开发人员，那么在这种情况下，您将别无选择。 在不必考虑您的意见的情况下，已经决定要在需要处理的项目中使用TypeScript。 您无需害怕学习和使用TypeScript。
但是，如果您是决定在项目中使用哪种语言的人，那么您需要对TypeScript的优缺点有一个现实的了解。 在做出决策时，您将需要了解TypeScript的选择会影响项目的好坏。
我的经验表明TypeScript有其优点和缺点，但不能说它的使用通常会对项目产生积极的影响。 TypeScript吸引了许多开发人员，并且许多与该语言相关的东西，我在实践中进行了测试，我真的很喜欢它。 但是你必须付出一切。
背景知识
我来自静态类型语言的世界-例如C / C ++和Java。 刚开始，我很难适应JavaScript中采用的动态类型，但是一旦我习惯了它，我就感觉像是一个人到达了一条长长的黑暗隧道的出口并看到了光。 静态类型具有许多积极的功能，但动态类型也可以说相同。
在过去的几年中，我定期投入大量精力进行TypeScript开发。 结果，我获得了超过一年的TypeScript实践经验。 我带领几个大型团队使用TypeScript作为主要语言。 这使我能够评估TypeScript对大型项目开发的影响，并将相似的项目与使用常规JavaScript的相似的项目进行比较。
在2018年，去中心化的应用程序可能
会起飞 。 这些应用程序大多数使用智能合约和开源解决方案。 在开发用于有价互联网的应用程序时，程序中的错误可能会花费用户金钱。 现在比以往任何时候都重要的是，编写可靠的代码。 由于此类项目通常是开源的，因此我认为我们在TypeScript开发中使用的内容是好的，因为这将使其他TypeScript团队更轻松地使用我们的解决方案，同时确保兼容性我们的代码和使用JavaScript的项目。
在实际使用TypeScript的过程中，我开始更好地了解这种语言的优缺点。 我也很清楚TypeScript在软件项目上可以选择哪种类型。 我很遗憾地说TypeScript的体验没有我想要的那么成功。 如果TypeScript没有得到显着改进，那么我将不会在其他大型项目中选择该语言。
TypeScript的优势
从长远来看，TypeScript在我看来仍然是一个积极的发展。 我想喜欢这种语言，而且我仍然肯定喜欢它的某些功能。 我希望TypeScript开发人员及其支持者会在这种材料中看到建设性的批评，而不是对这种语言的无端攻击。 TypeScript开发人员可以解决它的一些缺点，如果可以，我可以重复分析这种语言的有效性并得出不同的结果。
静态类型非常有用，因为它有助于记录功能，使代码更易于理解并减少程序员的认知负担。 例如，我通常会发现Haskell类型的系统可以工作，不需要太多的时间和精力，便便又不引人注意。 但是有时候，即使是灵活的Haskell类型系统及其类型更高级的类型，也很难工作。 例如，尝试使用Haskell或TypeScript键入换能器。 这不容易做到，并且结果可能会比未类型化的结果稍差。
我喜欢这样一个事实，即TypeScript批注会干扰可选操作。 我喜欢TypeScript使用结构化类型的事实，并且对类型推断提供了一些支持（尽管在这一领域有很多改进的机会）。
TypeScript支持可重用的接口（与内置类型声明相反）。 接口可以以不同的方式用于注释API和功能签名。 单个接口可以具有许多实现。 接口是TypeScript的最佳功能之一，我希望类似的东西出现在常规JavaScript中。
TypeScript的优势之一是其工具箱。 例如，使用合适的编辑器（例如Atom或Visual Studio Code）为其创建高质量的TS插件，从而使开发人员可以使用JavaScript生态系统中最好的工具。 其他插件的开发人员应研究TS插件，并思考如何使用其内含的思想来改进其开发。
TypeScript性能分析
现在，我将评估TypeScript的多个指标，将等级设置为-10到10。这将帮助您更好地了解TypeScript对大型项目的影响（或不利）。
如果指标的分数超过0，则表明TypeScript对项目的积极影响。 如果分数小于0，则表示负面影响。 3-5分的评分值表示效果相当强。 2分表示平均暴露。 1分是相对较弱的效果。
我将继续使用的数字很难准确衡量。 在我的评估中，我会在某种程度上是主观的。 但是我尝试进行这些估算，以便它们尽可能实际地揭示在实际项目中使用TypeScript的利弊。
我分析过的所有项目（给出评分）都包含超过5万行代码。 它们是数位程序员几个月的工作成果。 这些项目之一是基于Angular 2的，它使用了TypeScript。 将它与使用Angular 1和常规JavaScript编写的类似项目进行了比较。 所有其他项目都基于使用TypeScript的React和Node。 将它们与使用纯JavaScript的类似项目进行了比较。 有些指标（例如错误密度）仅是大约估算值。 所有从事项目工作的团队均由经验丰富的新手TypeScript开发人员组成。 这些团队的所有成员都有机会与经验丰富的导师互动，这些导师帮助他们适应了TypeScript开发领域。
由于样本量小，我拥有的客观数据太异类，它们中有太多的噪音，因此，基于它们，就不可能基于足够准确的数据做出任何客观的判断，而又不会冒太大的风险犯一个大错误。 一个JavaScript项目显示生产中的错误密度比同类TypeScript项目少41％。 在另一个比较中，TypeScript项目的错误密度比同类JavaScript项目低4％。 在这种情况下，很明显，到达产品启动阶段的错误数量受的影响不是受项目中使用TypeScript的影响较大，而是受是否存在确保代码质量的其他措施影响更大。 这使指标失真到无法使用的程度。
如此广泛的客观指标导致我决定不使用它们，而是着重于项目能力的实施步伐和观察，这些观察表明了项目生命周期中花费了大部分时间的那些领域。 在下面，分析指标，我们将更详细地讨论这一点。
由于我的分析有很强的主观成分，因此您需要考虑对指标解释不正确的可能性（这在图表中有所反映）。 但是，此分析的一般结论可以提供使用TypeScript项目时可以期望得到的真实印象。
TypeScript性能分析我已经听到了有关TypeScript好处评级较低的反对意见，坦率地说，我无法完全拒绝这些反对意见。 实际上，TypeScript为程序员提供了一些非常有用，强大的功能。 毫无疑问。
为了理解我的分析中相对较低和极少的正面评价的原因，您应该很好地了解我将TypeScript与之进行比较的原因。 这不是“仅仅是JavaScript”，而是旨在有效开发这种语言的JavaScript和工具。
考虑图中所示的指示器。
▍开发人员工具
工具包是我最喜欢的TypeScript功能，这可能是使用该语言的最强实践优势。 由于使用了高质量的工具，减轻了开发人员的认知负担。 他掌握了有关接口类型的技巧，在此过程中实时发现了潜在的错误。 如果使用良好的插件在纯JavaScript中进行开发时，如果没有发生这种情况，我将给TypeScript更高的肯定评级。 但是在我们的例子中，使用JavaScript编程时已经可以使用0点，也就是说，与我们比较TypeScript时，它已经处于相当高的水平。
大多数TypeScript倡导者似乎不太了解TypeScript与之竞争。 关键是，工具的选择不是在没有任何辅助工具的情况下使用TypeScript还是JavaScript的决定。 这是关于在TypeScript和JavaScript开发工具的整个丰富生态系统之间进行选择。 常见JavaScript的代码完成和错误检测工具可提供通常认为TypeScript优势的80-90％。 例如，在使用代码
完成工具，
类型输出工具和
linters时，会发生这种情况。 当使用类型推断系统并应用ES6中显示的默认函数参数时，开发人员可以随意使用的技巧与使用带有类型注释的TypeScript代码时可用的技巧非常相似。
具有类型推断功能的常规JS代码自动完成的示例老实说，如果您使用默认设置来提供类型提示，那么您绝对不需要注释TypeScript代码。 这是减少辅助语法构造数量的出色技术，辅助语法构造的数量是TypeScript的缺点之一。
用于编写TypeScript代码的工具可能会更好一些，它们看起来更整体，但这还不足以赋予TypeScript更高的评级并弥补这种语言的缺点。
▍API文档
TypeScript的另一个主要优点是其更好的API文档。 实际上，我们可以说API的文档始终与源代码的状态相对应。 甚至可以基于TypeScript代码生成文档。 对于此TypeScript指标，也可以给予更高的评价-如果在使用JavaScript编程时，不能使用
JSDoc ，
Tern.js之类的东西以及许多用于生成文档的工具。 就个人而言，我不是JSDoc的粉丝，因此在我对此指标的分析中，TypeScript非常受欢迎。
应该指出的是，即使使用世界上代码内置的最好的文档，也不能没有真实的文档，因此，可以说TypeScript功能更有可能扩展现有的文档编译功能，而不是取代它们。
▍类型安全
事实证明，在比较TS和JS的类型安全性时，不可能揭示出特殊的区别。 TypeScript的支持者经常谈论类型安全的好处，但是不能说
类型安全显着降低了生产中的错误密度。 这一点很重要，因为使用代码审查和TDD对故障排除有严重影响（仅使用
TDD技术就可以减少40-80％的错误）。 如果将TDD与项目体系结构分析，规范验证和代码审查相结合，则可以将错误密度降低90％以上。 这些技术中的许多技术（尤其是TDD）可以帮助您找到TypeScript可以检测到的相同错误，以及TypeScript无法检测到的许多错误。
这里我们从
这项研究中给出一些计算。 TypeScript可以检测到的“公开可用”错误的理论最大值约为15％。 “公共”错误是指在项目开发阶段幸存下来并最终存储在公共存储库中的错误。
前述研究监视了事先已知的错误。 这包括知道哪些代码行已更改以纠正错误，而在键入代码之前就知道了问题及其可能的解决方案。 这意味着，即使知道错误的存在，也无法使用TypeScript来检测85％的“公共”错误。
为什么TypeScript无法检测到这么多错误？ 为什么我说检测到的错误中有15％是TypeScript的理论最大值？ 首先，值得注意的是，根据相关研究，规范错误导致公共GitHub存储库中约有78％的错误。 无法清楚地制定程序的规范或无法正确执行规范会导致最常见的错误类型。 这自动导致无法检测或防止TypeScript软件项目中的大多数错误。 该研究的作者除其他外，对TypeScript未检测到的错误进行了识别和分类。 这是带有有关此类错误信息的条形图。
TypeScript未检测到的错误“ StringError”示例是一个错误，如果在需要字符串的地方使用了字符串，即不会发生类型错误，但是此字符串本身的内容会导致错误（例如，URL可能不正确）。 使用静态分析，可以通过检查字符串的内容并使用对此内容的描述来识别其中的一些错误。 但是，这仅给出了纠正一小部分错误的一小部分的前景。 结果，我们说TypeScript不可能检测出超过15-18％的错误。
在这里，似乎15％已经足够了。 为什么TypeScript无法检测到更大比例的错误？
由于存在许多无法通过静态类型检测到的错误，因此拒绝使用其他质量控制方法（如代码检查和TDD）是不负责任的。 因此，依靠TypeScript将成为某些项目中用于处理错误的唯一工具这一事实是不公平的。 为了现实地感知我们对TypeScript有效性进行分析的指标，值得一提的是，在将其他方法检测到的错误排除在数量之外之后，计算TypeScript检测到的潜在错误数量。
假设如果您不采取任何措施来处理错误，则您的项目将包含1000个错误。 在对项目进行了正确的测试之后，可以生产的潜在错误数量已减少至100。现在，要查看TypeScript的实际可能性，让我们看一下使用它可以检测到多少错误。 由于使用TypeScript无法检测到大约80％的错误，并且考虑到理论上可以使用其他方法（例如使用TDD方法）检测到使用TypeScript检测到的所有错误，因此我们会非常慷慨地提出并假设TypeScript可以检测到另外8％的错误。 另外，在这里，我们假设没有发现TypeScript以其他方式检测到的错误中有大约一半。 结果如下：
- 没有应用错误控制措施的项目包含1000个错误。
- 使用解决非TypeScript错误的措施，检测到900个错误。
- 使用TypeScript检查项目后，仍然存在92个错误。 这意味着，由于实施了TypeScript，又检测到8个错误。
, , TDD, , TypeScript- , , . . TypeScript . TypeScript, .
, TypeScript, TypeScript 15% . — 150 1000. , , TypeScript, 900 . , , , TypeScript - . TypeScript , , , 908 1000 (, , , , TypeScript).
. , 30-80% . :
, , , , , , , TypeScript. : TypeScript . , . .
, , - TypeScript. TypeScript, ?
▍ JavaScript - (New JS Features, Compile to Cross-Browser JS)
TypeScript 0, JavaScript. , Babel JavaScript , , , .
TypeScript JavaScript. , . JavaScript , , , , TypeScript , . , , TypeScript «».
▍ (Recruiting)
, State of JavaScript, TypeScript , 33.7% TypeScript. 5.4% TS , , 13.7% , . TS- 20%, , . — , (, , , ).
, - , TypeScript . . , TypeScript .
▍ , (Setup, Initial Training)
, . , JavaScript, TypeScript- 2-3 , 6-8 . , , , , , , TypeScript, , .
▍ (Missing Features)
, , . TypeScript JavaScript. TypeScript , . , JavaScript- , , . , , , TypeScript .
TypeScript TypeScript. , , , . , , TypeScript- . , , , , .
▍ (Ongoing Mentorship)
TypeScript, . , , , . TypeScript -. , , , , , .
, TypeScript- , , , , . , , , , , .
. . , TypeScript-, - , . « » — , , . , — , TypeScript .
▍ , (Typing Overhead)
, , , . — TypeScript, . . , , .
, , . , , , . , , , .
, . , , .
, TypeScript « ». Haskell , . TypeScript, , , , , .
, TypeScript- . — , TypeScript- , , , , . TypeScript- , , . , , — .
« » . , .
« » — , . « » — .
« » — TypeScript. :
- . «» ( — Haskell).
- , , , . TypeScript- , , , , , , . , , TypeScript-, Stack Overflow.
TypeScript, , . , , .
, TypeScript , , .
TypeScript , . TypeScript , , , . TypeScript, TypeScript- , TypeScript.
, TypeScript , , « » TypeScript . , TypeScript-, .
TypeScript, , , , — , , TypeScript. TypeScript . , — , , TypeScript.
.
TypeScript , «JavaScript, ». : «JavaScript, ».
! TypeScript.
