TypeScript出现的背景

JavaScript痛点

任何新技术的出现都是为了解决原有技术的某个痛点。

JavaScript是一门优秀的编程语言吗

每个人可能观点并不完全一致，但是从很多角度来看， JavaScript是一门非常优秀的编程语言；

而且，可以说在很长一段时间内这个语言不会被代替，并且会在更多的领域被大家广泛使用；

著名的Atwood定律：

Stack Overflow的创立者之一的 Jeff Atwood 在2007年提出了著名的 Atwood定律。

任何可以使用JavaScript来实现的应用都最终都会使用JavaScript实现。

其实我们已经看到了，这句话正在一步步被应验：

Web端的开发我们一直都是使用JavaScript；

移动端开发可以借助于ReactNative、 Weex、 Uniapp等框架实现跨平台开发, 而跨平台技术也是使用JavaScript；

小程序端的开发也是离不开JavaScript；

桌面端应用程序我们可以借助于Electron来开发；

服务器端开发可以借助于Node环境使用JavaScript来开发。

并且随着近几年前端领域的快速发展，让JavaScript迅速被普及和受广大开发者的喜爱，借助于JavaScript本身的 强大，也让使用JavaScript开发的人员越来越多。

优秀的JavaScript没有缺点吗？

其实上由于各种历史因素， JavaScript语言本身存在很多的缺点；

比如ES5以及之前的使用的var关键字关于作用域的问题；

比如最初JavaScript设计的数组类型并不是连续的内存空间；

比如直到今天JavaScript也没有加入类型检测这一机制；

JavaScript正在慢慢变好

不可否认的是， JavaScript正在慢慢变得越来越好，无论是从底层设计还是应用层面。

ES6、 7、 8等的推出，每次都会让这门语言更加现代、更加安全、更加方便。

但是知道今天， JavaScript在类型检测上依然是毫无进展（为什么类型检测如此重要，我后面会讲到）。

类型带来的问题

首先你需要知道，编程开发中我们有一个共识：错误出现的越早越好

能在写代码的时候发现错误，就不要在代码编译时再发现（ IDE的优势就是在代码编写过程中帮助我们发现错误）。

能在代码编译期间发现错误，就不要在代码运行期间再发现（类型检测就可以很好的帮助我们做到这一点）。

能在开发阶段发现错误，就不要在测试期间发现错误，能在测试期间发现错误，就不要在上线后发现错误。

现在我们想探究的就是如何在 代码编译期间 发现代码的错误：

JavaScript可以做到吗？不可以，我们来看下面这段经常可能出现的代码问题。

// 当前foo函数, 在被其他地方调用时, 没有对参数做任何的校验
// 1> 没有对类型进行校验(字符串或数字都可以传入)
// 2> 没有对是否传入参数进行校验
function foo(message) {
    
    
  if (message) {
    
    
    console.log(message.length);
  }
}

foo("Hello World");
foo("你好啊TS");

foo() // 错误的调用代码会报错(IDE不会报错), 报错后续代码不会执行

这是我们一个非常常见的错误：

这个错误很大的原因就是因为JavaScript没有对我们传入的参数进行任何的限制，只能等到运行期间才发现这个 错误；

并且当这个错误产生时，会影响后续代码的继续执行，也就是整个项目都因为一个小小的错误而深入崩溃；

你可能会想：我怎么可能犯这样低级的错误呢？

当我们写像我们上面这样的简单的demo时，这样的错误很容易避免，并且当出现错误时，也很容易检查出来；

但是当我们开发一个大型项目时呢？你能保证自己一定不会出现这样的问题吗？而且如果我们是调用别人的类库，又如何知道别人让我们传入的到底是什么样的参数呢？再或者说, 你封装一个函数给别人使用, 别人又怎么知道你的函数需要传入什么样的参数呢?

但是，如果我们可以给JavaScript加上很多限制，在开发中就可以很好的避免这样的问题了：

比如我们刚刚的函数中message是一个必传的类型，没有调用者没有传编译期间就会报错；

比如我们要求它的必须是一个String类型，传入其他类型就直接报错；

那么就可以知道很多的错误问题在编译期间就被发现，而不是等到运行时再去发现和修改；

我们已经简单体会到没有类型检查带来的一些问题， JavaScript因为从设计之初就没有考虑类型的约束问题，所以 造成了前端开发人员关于类型思维的缺失：

前端开发人员通常不关心变量或者参数是什么类型的，如果在必须确定类型时，我们往往需要使用各种判断验证；

从其他方向转到前端的人员，也会因为没有类型约束，而总是担心自己的代码不安全，不够健壮；

所以我们经常会说JavaScript不适合开发大型项目，因为当项目一旦庞大起来，这种宽松的类型约束会带来非常多的安全隐患，多人员开发它们之间也没有良好的类型契约。

比如当我们去实现一个核心类库时，如果没有类型约束，那么需要对别人传入的参数进行各种验证来保证我们代码的健壮性；

比如我们去调用别人的函数，对方没有对函数进行任何的注释，我们只能去看里面的逻辑来理解这个函数需要传入什么参数，返回值是什么类型；

为了弥补JavaScript类型约束上的缺陷，增加类型约束，很多公司推出了自己的方案：

2014年，Facebook推出了flow来对JavaScript进行类型检查；

同年，Microsoft微软也推出了TypeScript1.0版本；

他们都致力于为JavaScript提供类型检查；

而现在，无疑TypeScript已经完全胜出：

Vue2.x的时候采用的就是flow来做类型检查；

Vue3.x已经全线转向TypeScript， 98.3%使用TypeScript进行了重构；

而Angular在很早期就使用TypeScript进行了项目重构并且需要使用TypeScript来进行开发；

而甚至Facebook公司一些自己的产品也在使用TypeScript；

学习TypeScript不仅仅可以为我们的代码增加类型约束，而且可以培养我们前端程序员具备类型思维。