7个拒绝使用TypeScript的坏借口

译者按： TypeScript 学习成本不高，项目切换成本不低，不过仍是值得试一试的！

• 原文：7 bad excuses for not using TypeScript
• 译者: Fundebug

为了保证可读性，本文采用意译而非直译。另外，本文版权归原做者全部，翻译仅用于学习。

自从 6 年前诞生，TypeScript 逐渐被各大型公司接受。 也许你有充足的理由说服本身不要使用它，这些都让你错失了 TypeScript。在这篇文章中，我会列举你们为什么不选用 TypeScript 的一些缘由，好比学习曲线、工具、开发效率、稳定性以及对标准的兼容性。

1. 学习曲线过于陡峭

首先须要强调一点：TypeScript 并非一个彻底崭新的开发语言。像 CoffeeScript 和 Reason 吸取了 Ruby 和 OCaml 的语法和语义融入到 JavaScript 语言中。TypeScript 从某种程度上说，更加保守。

它只是在 JavaScript 的基础上添加了类型系统(TypeScript 是 JavaScript 的超集)，因此它的学习曲线会相对平滑。特别是相对于彻底切换到不一样编程语言来讲。 下面是一段 TypeScript 代码：

class Greeter {
  greeting: string;

  constructor(message: string) {
    this.greeting = message;
  }

  greet() {
    return "Hello, " + this.greeting;
  }
}

对比用 ES6 编写的相同功能的代码：

class Greeter {
  constructor(message) {
    this.greeting = message;
  }

  greet() {
    return "Hello, " + this.greeting;
  }
}

正如 TypeScript 语言的一个设计者 Anders Hejlsberg 说到：“若是你懂得 JavaScript，那么你就已经懂得 TypeScript 了。” 稍后，我会介绍如何将现有的项目切换到 TypeScript 去。

2. JavaScript 是标准，TypeScript 不是

当 TypeScript 在 2012 年诞生的时候就有了类和模块的概念，标准 JavaScript 直到 2015 年都尚未！

今天，TypeScript 语言紧随 ECMAScript 的定义，几乎实现了Stage 3全部的提案。也就是说，当你在使用 TypeScript 的时候，你其实已经在用最新的 JavaScript。并且感谢 ES3/ES5 编译器，最终输出的.js文件即便在旧版本的浏览器也不会出问题。

3. 破坏了 JavaScript 的动态性

若是你熟练使用脚本语言工做，你会喜欢它惊人的开发效率。你能够在代码中随时修改数据结构，而没必要事先声明。这种自由度，也伴随着代价。这种动态语言有了 bug 有时候很难搞定，它不会像静态语言同样，在编译的时候有作类型的验证来保证代码的正确性。

好比下面的 JavaScript 代码：

function greeter(person) {
  return "Hello, " + person.firstName + " " + person.lastName;
}

经过代码咱们能够判断 person 参数是一个对象，它有 firstName 和 lastName 两个属性。可是咱们没法保证在运行时必定是这样。

特别是当你的项目越大，和类型相关的 bug 就越可能触发。

为了不出现问题，咱们能够加上不少运行时的验证，以及单元测试：

function greeter(person) {
  if (!person || !person.firstName || !person.lastName) {
    throw new Error("invalid arguments");
  }

  return "Hello, " + person.firstName + " " + person.lastName;
}

// Jasmine spec:
describe("greeter", function() {
  it("returns greeting on valid input", function() {
    expect(greeter({ firstName: "James", lastName: "Hetfield" })).toEqual(
      "Hello, James Hetfield"
    );
  });

  it("throws on invalid input", function() {
    expect(() => greeter()).toThrowError("invalid arguments");
    expect(() => greeter(5)).toThrowError("invalid arguments");
    expect(() => greeter({ firstName: "Jason" })).toThrowError(
      "invalid arguments"
    );
  });
});

可是，这样的实现方法很累赘，开发者须要在每一个函数前面都加上这样的判断来保证正确性。换个思路，若是咱们给函数的参数加上类型，这个事情不就省去了么。

interface Person {
  firstName: string;
  lastName: string;
}

function greeter(person: Person) {
  return "Hello, " + person.firstName + " " + person.lastName;
}

// Jasmine spec:
describe("greeter", function() {
  it("returns greeting", function() {
    expect(greeter({ firstName: "James", lastName: "Hetfield" })).toEqual(
      "Hello, James Hetfield"
    );
  });
});

上面的代码更加简洁，甚至连测试也只须要考虑代码的逻辑而不是数据的正确性。

TypeScript 有强大的类型系统来作类型推断。你并不须要像在 C# 或则 Java 中那样，显示的列出数据的类型。下面是一个例子：

let user = { firstName: "James", lastName: "Hetfield" };
console.log(greeter(user));

上面的代码能够成功编译。请注意咱们并无声明 user 是 Person 类型的。

TypeScript 编译器并不会强制你必须在全部地方都声明类型，你能够在正确性和效率上本身作一个权衡。你甚至能够在项目不一样的区域自定义类型的严格程度。这样的灵活性超出了之前全部的开发语言。

4. TypeScript 火不过 5 年

没有人能够确保哪一种语言、工具或者框架必定能够持续活跃，特别是在前端这一领域。一个StackOverflow 博客的做者这样写道：

在 JavaScript 框架的使用有两个明显的阶段。由于框架的流行首先有一个快速的上升期，而后当开发者接触到其它新的技术后，慢慢的平稳的降低。整个周期也就几年的时间。

你自己处于一个快速迭代的行业，而你开发的项目能够从某些特定的技术中受益。尽管 一、2 年后，你已经切换到其它技术，可是你当时学到的经验依然值得。

5. TypeScript 没有社区驱动

TypeScript 由微软在 2012 年发布，考虑到公司的形象以及其开发平台，很容易产生“只不过是给.Net 开发者打造的一个 JavaScript 开发玩具而已”的想法。特别是当时只有 Visual Studio 对 TypeScript 有足够的支持。事实上，TypeScript 的源代码最开始是发布在CodePlex上，一个微软本身的 GitHub。

不过，现已不复当年，TypeScript 身后的开发团队意识到为了让语言被普遍接受，他们须要深刻前端开发社区，为开发者提供高质量的开发工具而且接受反馈不断改进。他们不只仅是把代码公开而后默默开发，而是拥抱了一个开放式开发的方式。

在 2014 年，TypeScript 的源代码移到了GitHub托管。并且整个开发都在 GitHub 上公开透明。他们同时接受外部提交贡献，包括记录 bug，提出建议以及提交 pull request。全部的 issue 会按期更新，几天以内就会有回应。核心团队发布了语言的设计理念用来指导团队不偏离目标并积极吸取社区的建议。他们有一个保持更新的roadmap(基本上每两个月发布一次更新)，并记录重大的更新。

在我写这篇文章的时候，全部主流的跨平台 IDE 或则编辑器像 Eclipse、Webstorm、Emacs、Vim、Sublime、Atom 和 VS Code 都对 TypeScript 有着很好的支持，要么是内置的，要么经过插件。为了和现有的库和框架交互，核心团队花了不少时间来建立类型定义文件。另外一个值得一提的是编译器 API 的文档很是完善，能够很好地构建第三方工具。TypeScript 的开发者团队也鼓励开发者在StackOverflow上提出技术问题。

6. 切换成本太高

为了充分发挥 TypeScript 的优点，你须要花费很多时间来声明类型并修复编译错误，这会很繁琐。TypeScript 的建立者们有考虑到原有 JavaScript 项目切换的问题，提供了相应的方案。

根据官方的迁移指导，你能够直接运行 TypeScript 的编译器。编译器会抛出一些低层级的 bug，好比没有 return 语句，代码块中有永远不会执行的代码。而后，你能够将.js 文件重命名为.ts 文件，而后再处理编译结果。编译器默认的选项没有特别严格，你能够开启更加严格的验证。整个迁移有一个底线：整个过程是至关平滑的，它不会使开发中断。你能够选择慢慢将一个项目切换到 TypeScript，或则来个快速的切换(参考:3 天搞定 60 万行代码的迁移)。社区还有一个叫作TypeWiz的项目能够自动给代码添加类型信息。

7. 可是我使用的库都是基于 JavaScript

为了和现有的 JavaScript 模块无缝对接，TypeScript 支持类型声明文件。举个例子，若是你使用的库中导出了一个 camelize 的函数，你能够定义一个类型声明文件并给出以下的定义：

declare function camelize(s: string): string;

当你导入类型声明文件后，TypeScript 会正确获取函数对应的类型。

TypeScript 同时也发布了DefinitelyTyped，这个 repository 包含了全部流行的库的类型定义文件。在我写这篇文章的时间点，DefinitelyTyped 已经包含了超过 5000 个 JavaScript 包的类型定义。使用方法很是简单：

npm install --save-dev @types/jasmine

类型文件会自动被编译器包含，而且在编辑器中也会有对应的代码提示。几乎全部或则大多数你使用的包都已经有对应的类型定义文件了，要么自身有相应的类型定义文件，要么在 DefinitelyTyped 能够找到，你只须要下载安装就好。Slack 的开发团队分享了他们的经验：

考虑到代码维护，咱们真的很感谢 TypeScript 强大的生态系统。咱们是 React 和 Node/npm 的重度用户，第三方库也有对应的类型文件极大方便了开发。不少咱们导入的库已经和 TypeScript 兼容。若是没有，那么也能够在 DefinitelyTyped 找到。好比，React 并无自带类型定义，你能够经过npm install @types/react来安装，无需其余额外操做。

结论

使用静态类型检车能够帮助你消除不少 bug，对于一个基于 Node/JavaScript 的项目，TypeScript 是你最好的选择。对于一个相对小或则试验性的项目，也许没有必要。可是，一个大型的项目，TypeScript 绝对值得你尝试。它带来的好处远远大于它带来的复杂度。一些大型的公司都开始使用也是最好的证实，好比 Google、Slack、Asana、Ember 等等。但愿这篇文章给你启发，让你从新燃起对 TypeScript 尝试的欲望。

关于Fundebug

Fundebug专一于JavaScript、微信小程序、微信小游戏、支付宝小程序、React Native、Node.js和Java实时BUG监控。 自从2016年双十一正式上线，Fundebug累计处理了9亿+错误事件，获得了Google、360、金山软件、百姓网等众多知名用户的承认。欢迎免费试用！

版权声明

转载时请注明做者Fundebug以及本文地址： https://blog.fundebug.com/2018/12/26/7-bad-execuses-for-not-using-ts/