JavaScriptWeekly半夜发来贺电：TypeScript2.0FinalRelease！是的，继Angular2发布之后，TypeScript今天也发布了2.0版本，这让我不由得浮想联翩。如果要说TS和JS最明显的区别，我想一定是TypeSystem，那么今天我们就来聊一聊TypeSystem在前端开发过程中扮演的角色。历史奋斗如果你想用10天之内开发出来的编程语言在PV上开发其他Web应用，我想你不会放心。然而，事实上，我们现在都在这样做，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会认为这个文件需要静态分析检查*/functionfoo(x){returnx*10;}//这样，调用Flow会给出错误消息：字符串和数字类型与foo('Hello,world!')不兼容；这种非侵入式集成可以检测出一些相对低级的错误。如果要支持更强大的分析，就需要编写侵入式代码。例如手动类型注解：/**@flow*var:[type]指定变量类型*/functionadd(num1:number,num2:number):number{returnnum1+num2;}//这个调用会报错,因为参数2已经声明为数字varx:number=add(3,'0');此类代码不能直接运行，或者需要通过Flow工具翻译成原生JS来执行。这种方法更适合新项目。新项目直接集成Flow包后，可以直接使用Flow支持的更多功能，配合IDE提供更好的开发体验。以Mac下的VSC为例，先安装本地Flow环境：brewupdatebrewinstallflow然后在VSC中安装并启用vscode-flow插件，?+'打开用户配置，禁用VSC自带的JavaScript验证功能（设置javascript.validate.enable为false），并设置flow安装目录：其余套路同Babel和ESLint，在项目根目录下创建.flowconfig文件，配置一些验证规则：vscode-flow插件检测到.flowconfig配置后会启动flow服务实时分析项目代码。在你开发的时候，你能感受到比原生编辑器更强大的自动补全和智能提示。比如当你require一个util模块时，flow可以分析util模块的内部结构，当你错误调用util方法时给出提示：以上只是简单流程的介绍，还是非-侵入式验证。如果您添加手动类型声明可以提供更多功能。TypeScriptTS更彻底。如果有一个全新的项目可以自由选择技术方案，我肯定会选择TypeScript而不是Flow.js。遗憾的是，公司大部分时间依赖于公司自身的技术体系，在做技术选型时依赖于团队的技术栈。比如大家都用ES6，你选择TypeScript，那别人维护你代码的成本会很高，除非你能带动整个团队都用它：）一般来说，这是不可能的，我觉得这也是TS普及难的一个重要原因。不过，这并不妨碍TypeScript成为一门优雅的前端开发语言。ES6有的它有，没有ES6的它也有（泛型/枚举/类型推导等只有强类型语言才有的特性），而且这些特性更适合成长中的工程化前端，适合写。维护代码。再加上微软自家的VSC，开发体验妥妥的：至于TypeScript2.0带来的新特性，请直接戳GitHub：https://github.com/Microsoft/...前几天GitHub发布的2016未来趋势中开源报告，JavaScript如大家所料高居榜首，这让大家激动不已：不过，让我意外的不是JavaScript榜首，而是TypeScript榜首：看这增长趋势，微软要和TypeScript在开源方面进行合作了.路越来越远。我个人认为，不管是不是TypeScript，类型系统带来更好的开发体验、代码质量、代码可读性和可维护性，这正是一个大型或长期项目所需要的，而且是现在和未来前端工程需求。所以真的没有理由不学习。如果你觉得TypeScript更适合C#这样的后端程序员，那么学习它可能是你迈向全栈的一小步哈哈。
