大午夜的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。本质上这有许多优点：
强迫声明范例，IDE和编辑器可以经由过程静态范例剖析发明代码隐蔽缺点，同时也可以供应更壮大的自动补全，智能代码提醒和纠错，到达Java/C++级别的开辟体验。
可防止范例隐式转换带来的斲丧，进步运转效力。实际上JS引擎在运转时很大的开支都花在范例剖析上。
可读性/可保护性加强。一眼就可以看出这个变量是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#更合适后端程序员，那末进修它或许是你迈向全栈的一小步哈哈。
