什么场景下不应该使用 TypeScript？

TypeScript 很棒，但有时用它编程只是在浪费时间。TypeScript 的优势在于它能在编译时调试 JavaScript，但有些情况并不适合我们使用 TypeScript，比如构建小型应用程序或原型应用时。

作为一名前 C#程序员，我是 TypeScript 和强类型编程语言的忠实粉丝——说是这么说，但我也知道不是每个项目都很适合用 TypeScript 的。本文将探讨哪些类型的项目中 TypeScript 能完美满足项目需求，又在哪些项目类型中使用 TypeScript 只不过是在浪费时间。

TypeScript 的优势在于它能在编译时调试 JavaScript，为你节省很多麻烦；但如果你在错误的场合使用它就是另一回事了。就像使用其他工具一样，我们要用它来构建应用程序之前需要先了解我们应该做哪些准备，然后才能放心地大动干戈。

那么什么情况下我们不应该使用 TypeScript 呢？首先我们来搞清楚 TypeScript 到底是什么东西。

小技巧：推荐使用 Bit 来将组件及其依赖项和安装内容打包在一起，从而创建真正模块化的应用程序，获得更好的代码复用、更好的可维护性并减少开销。在应用之间共享组件，使团队能更快协作构建应用。

什么是 TypeScript？

TypeScript 是一种开源的编程语言，由微软开发并维护，相当于 JavaScript 的超集；它可以在代码编译期间检查类型，并为编程语言添加了可选的静态类型。

微软设计 TypeScript 时主要考虑的是大型应用程序的开发需求，例如用户超过 500 人的企业级应用程序。TypeScript 还可以用于后端应用程序（例如 NodeJS），为其提供强类型语言。

那么什么时候我们不应该使用 TypeScript 呢？在下面的这些场景中你可能会重新考虑是否要使用它：

构建小型应用程序或原型应用

我认为这种情况是相当明显的。当你在构建原型应用以尽快展示生产级应用程序的功能效果时，你肯定不愿意在 JavaScript 中额外的类型检查器，因为它们可能会影响你的工作效率和交付速度。

我们比较同一种功能的两段代码：

JavaScript

const myFunction = (x, y) => x * y;

TypeScript

const myFunction = <T>(x: T, y: T) => x * y;

在项目中添加 TypeScript 代码需要我们声明很多类型，上面就是一个例子。大概没人想在原型设计阶段做这种事情。

请注意，TypeScript 用起来是很啰嗦的，因为我们需要声明很多类型才能完成工作。有人可能会说 TypeScript 的代码虽然啰嗦但容易调试，函数出错的时候尤其有用——但这取决于你或你的开发人员是怎样使用类型系统的。你的开发人员可能只是简单地在函数中输入各种类型，因此就算出了问题也没什么用。

也有很多人会争辩说，提前添加类型检查能为我们节省很多时间，在构建原型应用时可以预防很多会让你头疼的错误。确实，从长远来看静态类型可以为你节约大量时间，但如果你是在构建自己的原型应用，这个应用可能压根就不会进入下一阶段，你也就没法体验到类型系统的长期收益了。

此外，我认为 TypeScript 在这个阶段带来的好处是微不足道的，因为我们毕竟是在构建一个很小的应用程序。我们很少遇到类型问题，因为 JavaScript 是一种动态编程语言，无论类型如何都可以解析数据；因此与其他编程语言相比它非常宽容，用起来相当轻松。

TypeScript 未能带来预期的结果或价值

只有当 TypeScript 提供了你预期的那些好处时才有自己的价值，否则结果会变得很糟糕。在你将 TypeScript 深度用于实践工作之前，必须首先搞清楚为什么你要使用它，为什么要在项目中应用它。如果它没能提高你的生产力，没能增强你正在构建的应用程序的可靠性，那么你就没有从中获得什么价值。

比如说，首先你应该确定要构建的应用程序是什么类型。它是原型应用？还是一个企业级应用？抑或是将由数百名开发人员使用的 API？是一个仅关注用户交互或动画的应用程序？或者是一个充满复杂计算和公式的应用程序？

你需要评估 TypeScript 在你的使用场景中到底能提供多大程度的改善和价值，然后再决定要不要用它，这样才能充分利用它的优势。

你的开发人员缺乏经验而不愿意适应它

你应该仔细评估和观察开发人员使用 TypeScript 的经验水平。你还可以研究他们为了使用它需要多久的学习时间。如果团队中的开发人员都不熟悉 TypeScript，你可能就得放弃强制推广这项技术了，除非这样做的投资回报率很高。

没有令人信服的理由，我们就不能强迫团队适应 TypeScript，具体还要取决于团队处理的项目类型。另外还要考虑团队成员之前所拥有的技能类型组合。他们有 OOP 的开发经验吗？接触过 C#和 Java 这些吗？如果答案是否定的，那么强迫他们使用 TypeScript 就是弊大于利的。

最后，你应该主动询问你的团队是否愿意适应和使用这项技术。如果你没有正确评估你的团队拥有的技能组合，没有正当的理由也没有对你正在解决的问题作出恰当的分析，那么你可能会做出非常自私的决定。

我们要深入分析团队和项目是否真的需要 TypeScript，然后才开始研究如何在项目中使用它。你的团队成员一定会感谢你的谨慎态度的。

使用 TypeScript 仅仅是为了跟风

最后但同样重要的是，如果你只是为了“跟风”而使用 TypeScript，我认为你的方向是错误的。为了练习和掌握 TypeScript 而使用它没什么问题。但仅仅因为“跟风”而在生产级应用程序中使用它是不合理的，不代表你就能从中获得更多价值。

我们不能用技术的流行度来衡量我们正在使用的工具价值，这是一个非常糟糕的指标。TypeScript 犹如一场风暴，席卷了整个 JavaScript 生态系统，吸引了大批开发人员广泛使用。我认为这是因为大多数使用 TypeScript 的开发人员都有 Java 或 C#的背景和经验，所以 TypeScript 才得以出头。

我得承认自己就是这类开发人员的一员，当年微软刚发布它时我就开始使用 TypeScript 了，因为我那时候还不习惯使用标准的 JavaScript。

我经常面临需要在各种新技术中来回切换使用的情况。但作为一名软件工程师，随着我的经验愈加丰富，我也意识到如果一项新技术无法提供我们需要的价值，那么跟风使用这些技术就是毫无意义的。

小结

微软给我们送上了 TypeScript 这份礼物，为 JavaScript 生态系统送来了更趁手的开发人员工具；但它既可能是一种祝福也可能化身为一种诅咒，这取决于我们如何使用它。

我的建议是，你只需要了解 JavaScript 的工作机制即可，添加 TypeScript 会成为一种代码优化方法，但前提是在正确的上下文中正确地使用后者。

希望本文能帮助你决定到底在什么时候应该使用或放弃 TypeScript。

英文原文：https://blog.bitsrc.io/when-not-to-use-typescript-2431177135b3