Typescript的设计目的应该是解决Javascript的“痛点”：弱类型和没有命名空间，导致很难模块化，不适合开发大型程序。另外它还提供了一些语法糖来帮助大家更方便地实践面向对象的编程。1.数据流结构规范性
在业务需求的中级阶段，我们意识到数据流结构规范化的重要性。typescript恰好就是为此类需求而诞生的，而且充分考虑到兼容性。vue.js因为本质是MVVM框架，引入了数据流的概念。但JS是弱类型语言，数据流本身比较随意，比如一个Button的属性，基本属性有按钮文字，按钮状态，按钮进度等三个基本数据属性。但是团队中不同人可能有自己的想法，关于一个Button的定义命名都有可能不一样。
长期看来，注定无法维护。这时候数据结构的规范（接口，强类型）显得非常重要。引入这些概念，对基本组件的定义和规范在代码编写阶段自然就形成了约定（不遵守规范，编译都通不过），这比文档规范约束有效和方便得多。
对之前JS的代码完全兼容。2.使用ES6/ES7特性，具有优秀的自编译能力很多ES6/ES7项目的编译都是通过babel进行处理的，不熟悉的朋友可能整配置都要搞半天，而且babel还有babel5和babel6的区别，两者也并不太兼容。
typescript具有自编译的能力，不需要额外引入babel。
只依赖tsconfig.json，将此文件放到项目的根目录，即可全局配置。typescript不仅能满足babel的编译的功能，而且比babel做得更好。比如很重要的async/await语法，babel在使用的时候会引入相当大的一个文件：3.typescript2.0引入了@types，系统性地解决了绝大部分公共库的类型定义问题
WONDER迟迟没有在生产项目中使用typescript的一个很大的原因就是类型定义实在是太麻烦了。4.编译时的强类型Typescript设计了一套类型机制来保证编译时的强类型判断。从DefinitelyTyped到typings，最后是@types。微软自己也发现有这么个问题，所以也在一直演进。目前来看，@types算是一个不错的方案。充分利用npm进行管理和维护，且绝大多数公共库都已经支持@types，比如@types/jquery、@types/node等。
vue更先进一些，直接本身vue模块即支持typescript的类型定义。不需要额外的@types/vue。也就是npm install vue即可在typescript中正常使用。
最简单的，你可以申明变量的类型，那么任何其他类型的赋值将会引起编译错误。例如var foo: string; foo = true; //error: Cannot convert 'boolean' to string有意思的是，类似于C#的var变量声明，Typescript会对赋值的变量进行类型推断例如var bar = 0; bar = ''; //error: Cannot convert 'string' to 'number'强类型还有一个最大好处就是智能提示，例如你可以知道当前变量具有哪些属性和方法从这个例子可以看出module可以嵌套，访问时用'.'作分隔符，也可以用'.'作为分隔符来简写module的嵌套，只有带export关键词的才可以被外部访问，module可以合并，但是非export的对象在其他module下，即使是同一个名称，也不能被访问，如FuncA。6.个人觉得Typescript的一个设计亮点就是它并没有抛弃Javascript的语法另起炉灶，而是做成了Javascript的超集
（这个功劳应该记在Anders上），这样任何合法的Javascript的语句在Typescript下都是合法的，也就是说学习成本很低，如果你对Javascript有比较深入的了解，那么其实可以很快的上手Typescript，因为它的设计都是针对Javascript的使用习惯和惯例。7.已有的类库可以很方便的使用类似于C的头文件，Typescript允许你定义一些声明，声明已有的变量和类型，那么你可以很方便的用强类型的方式去调用已有的类库。
8.Typescript是静态类型，js是动态类型
首先要分清楚，强类型和弱类型、静态类型和动态类型是两组不同的概念，类型强弱是针对类型转换是否显示来区分，静态和动态类型是针对类型检查的时机来区分。TS对JS的改进主要是静态类型检查，静态类型检查有何意义？标准答案是“静态类型更有利于构建大型应用”。为什么静态类型有利于构建大型应用？我总结，利在两点。个人认为静态类型有利于构建大型应用更深层次的原因是强迫你好好做设计，动态类型中参数可以随意的传递随意的赋值，根本都不需要什么设计就能完成功能。9. Typescript 相比 ES6/7 有什么优势ES6/7 并非是一无是处的，比如 ES Module 就是一个很好的设计，其静态特性保证了实体的唯一性，也确实能够为静态分析提供很大的帮助。其一，静态类型检查可以做到early fail，即你编写的代码即使没有被执行到，一旦你编写代码时发生类型不匹配，语言在编译阶段（解释执行也一样，可以在运行前）即可发现。针对大型应用，测试调试分支覆盖困难，很多代码并不一定能够在所有条件下执行到。而假如你的代码简单到任何改动都可以从UI体现出来，这确实跟大型应用搭不上关系，那么静态类型检查确实没什么作用。
其二，静态类型对阅读代码是友好的，比如我们举个例子 jQuery API documentation 这是大家都非常喜欢用的jQuery.ajax，在这份文档中，详尽地解释了类型为object的唯一一个参数settings，它是如此之复杂，如果没有文档，我们只看这个函数声明的话，根本不可能有人把这个用法猜对。针对大型应用，方法众多，调用关系复杂，不可能每个函数都有人编写细致的文档，所以静态类型就是非常重要的提示和约束。而假如你的代码像jQuery这样所有函数基本全是API，根本没什么内部函数，而且逻辑关系看起来显而易见，这确实跟大型应用搭不上关系，那么静态类型对阅读代码确实也没什么帮助。总的来说，现代编程语言设计，很多特性已经有非常成熟的理论支持了，如果我们重视计算机基础，那么一些语言的适用场景就像是拼积木，可以用几句话概括。
像是TS对JS这样，只是单一特性变化。
（比如已经可以基本保证重构时的引用完备性，不会误伤不会遗漏）另外也提供了大量的语法糖为开发者提供便利。只是，对于大型工程而言，这样可能还不够。Typescript 的定位是静态类型语言，而非类型检查器。从 Tooling 上来说能提供的优势也远不止类型检查，比如很直接的一点就是 Intellisense over Compilation Error，一段代码，当你写了前两个字母没有提示了，或者写完就有个红波浪了，那它就已经错了，而不是等到编译的时候再告诉你第几行有错。
（可能很多人在大学学 C 语言的时候已经有斯德歌尔摩综合症征了？）而作为开发人员唯一要做的，就只是在接口处标明类型，其它的内部过程交由 ts 推理就好。而如果不进行标注，只靠自顶向底的类型检查的话，那么当出现类型不相符的时候，就会出现和运行时一样的错误栈，又如何知道到底是哪一步到哪一步写错了呢？极端一点的方面，如果是在 FP，组合变换了十几二十次，然后还肿么能明确每一步拿到的都是什么呢？如果有 ts 的话，只要你提供了初始的标注，那么后面每一步的过程也都是明确的了，哪怕返回到中间改了一个什么东西也能立刻知道对后面有没有影响。10. tsc 相比 babel 有什么优势这点很难说，因为二者的定位并不相同。
Babel 是一个 Javascript 预处理器的基础设施，虽然本身为 es6 而生，但现在 es6 对 babel 而言也只是一个普通的 preset 而已。理论上完全可以基于 babel 实现一个 ts 的编译器，但上面就已经谈到了，ts 的核心并不在那一个编译器。如果我们从 n。
