类型系统-前端进化的里程碑

大半夜的JavaScript Weekly发来贺电：TypeScript 2.0 Final Released！

没错，继Angular2发布以后，TypeScript今天也发布了2.0版本，这不由让我浮想一番。若是要说TS和JS最明显的差异，我想必定是Type System，因此今天咱们就聊聊类型系统在前端发展历程中，到底扮演了怎样的角色。

历史斗争

若是要你把PV上百万级别的Web Application用一门在10天内撸出来的编程语言来开发，我想你确定不会放心的。然而事实上咱们如今都是这样干的，JS已经成为了最流行的编程语言。JS如今所承担的使命已经彻底超出了当年设计的初衷，虽然TC39一直在填坑，而且发展到现在的ES6已经至关成熟了，但仍然留下了一些历史包袱，并不能改变这是一门动态弱类型脚本语言的实质。

所以在前端工程化不断壮大的过程当中，为了不踩坑，人类同JS最佳编码实践方式展开了旷日持久的战争。

最开始，你们都只是取其精华，去其糟粕，如《JavaScript语言精粹》一书所说：大家只须要用我说的就行了，其余的垃圾都不要学，而且千万不要在项目里面用。

通常状况下每一个公司都会出一套最佳实践的编码规范，程序员须要统一代码风格，按约定编写代码。但规范的约束力很低，结果在项目赶着上线的状况下仍是写出了翔同样的代码，因此更好的方式是用工具来规范代码，发现一些潜在问题，经过工具来强制约定编码。好比JSLint，JSHint，以及ESLint，都是设定了一系列编码约定，让你避免写出一些糟糕的代码。

另一种思路，就是抛弃使用JS做为开发语言，或者只是把他当成“JVM”,而后采用另一种设计更加严谨，不容易采坑的语言来编程，好比CoffeeScript和TypeScript,开发完后再转译成JS来运行。

若是以为这种方式过于激进，那么能够采用渐进的方式，好比Flow。Flow能够在开发时对代码进行静态类型分析，用写强类型的方式来写弱类型的JS。实质上这有不少好处：

1. 强制声明类型，IDE和编辑器能够经过静态类型分析发现代码隐藏缺陷，同时也可以提供更强大的自动补全，智能代码提示和纠错，达到Java/C++级别的开发体验。

2. 可避免类型隐式转换带来的消耗，提升运行效率。实际上JS引擎在运行时很大的开销都花在类型分析上。

3. 可读性/可维护性加强。一眼就能看出这个变量是String仍是Number，代码维护也更清晰，而且经过注释工具生成的代码注释也会更加详细，后面换人维护时也更容易上手。

这些优点，其实都是类型系统所带来的强类型语言所具备的开发优点，不管是在开发体验仍是后期项目维护上，都要优于目前的JavaScript。

接下来，咱们就以渐进的方式，来感觉一下类型系统带给咱们的好处。

类型系统

Flow.js

不少状况下咱们都是在维护项目，不可能为了增长类型检查来修改老的项目代码。Flow能够在不修改代码的状况下，经过注释的方式来进行静态类型分析，这为咱们提供了一个很好的过渡方式。你能够随时在任一个项目里面集成Flow。

/*
* @flow 
* 只须要在文件头部添加flow注释，Flow就会认为这个文件须要静态分析并检查
*/

function foo(x) {
  return x * 10;
}

// 这样调用Flow就会给出错误提示：string和number类型不兼容
foo('Hello, world!');

这种无侵入式的集成，能够检测出一些比较低级的错误，若是要支持更多强大的分析，就须要写侵入代码了，好比手动类型注释：

/* 
* @flow 
* var : [type] 指定变量类型
*/

function add(num1: number, num2: number): number {
  return num1 + num2;
}

// 这样调用就会报错，由于参数2已经被声明为number了
var x: number = add(3, '0');

这样的代码是不能直接运行的，仍是须要Flow工具转译成原生JS才能执行。这种方式就更适合新的项目，一旦新项目直接集成了Flow套餐，就能够直接使用Flow支持的更多功能，而且配合IDE给出更好的开发体验。

以Mac下的VSC为例，首先安装本地Flow环境：

brew update
brew install flow

而后在VSC中安装启用vscode-flow插件, ⌘+' 打开用户配置，禁用VSC自带的JavaScript校验功能(设置javascript.validate.enable为 false)，并设置好flow的安装目录：

剩下的套路就跟Babel，ESLint同样了，在项目根目录下面创建一个.flowconfig文件，配置一些校验规则：

vscode-flow插件检测到.flowconfig配置后就会启动flow服务去实时分析项目代码，当你开发的时候就能感觉到比原生编辑器更增强大的自动补全和智能提示了。好比当你require一个util模块时，flow能分析出util模块内结构，而且当你调用util方法不当时给出提示：

以上只是介绍简单流程，而且仍是无侵入式的校验，若是再加上手动类型声明的话，还能提供更多功能。

TypeScript

TS的作法更完全，若是有一个全新的项目能够自由选择技术方案的话，我必定会选TypeScript而不是Flow.js。惋惜的是，在公司里面大部分时候都依赖公司自身的技术体系，在作技术选型的时候都要依赖团队的技术栈。就好比你们都用ES6，你选择TypeScript，那么以后别人来维护你的代码成本就很是高，除非你能煽动整个团队，整个集团使用：）通常状况下这是不可能的，我想这也是TS难以普及的重要缘由。

可是，这并不妨碍TypeScript成为一门优雅的前端开发语言。ES6有的它都有，ES6没有他也有（泛型/枚举/类型推导等只有强类型语言才有的一些特性），而这些特性偏偏更加适合日益壮大的工程化的前端，适合编写出可维护性代码。再配合微软自家的VSC，开发体验妥妥的：

至于TypeScript 2.0带来了哪些新特性，请直接戳GitHub：
https://github.com/Microsoft/...

将来趋势

前几日GitHub 发布了2016开源报告，JavaScript众望所归的荣登榜首，让众前端激动不已：

然而让我意外的不是排在第一的JavaScript，而是最后的TypeScript：

看这增加趋势，微软是要协TypeScript在开源之路上越走越远了。

私认为，不管最后是否是TypeScript，类型系统都带来了更好的开发体验，代码质量，代码可读性和可维护性，这正是一个大型或长期项目所必须的，也是如今和将来的前端工程所须要的。因此实在是没有不学的理由，若是你以为TypeScript像极了C#更适合后端程序员，那么学习它或许是你迈向全栈的一小步哈哈。