typescript笔记一：有了JS，我们更需要ts

typescript诞生了七个年头，类型的检查对于前端工程师来说，到底意味着什么？

如今的前端工程师需要学习的东西太多，既是需求非常多，加班很厉害，项目类型非常多。但是依然不能把前端所有的方面都覆盖到。有了JS，有了ESNEXT，我们还真的需要TS吗？我以前的想法是ES是亲儿子，未来的浏览器也会支持ESNEXT语法，现在用只是为以后做准备。先学也对于前端工程师生涯发展有帮助，并不在意TS的发展。如今TS的发展可以说是风生水起。这究竟是什么一种情况？

其实原因也很简单，究其原因有这么几个：

• TS贴近ES
• TS的编译能力强而且稳定
• TS的生态非常好

TS贴近ES

TS的class的提案非常早就确立了，而且拥有 private 和 public 属性，不填也是可以的。

TS的生态

ts和babel

typescript可以和babel结合，babel-preset-typescript。ts不是一个人在战斗，由于JSX并非模版语言，它是babel识别的语法，基于typescript 和babel的联袂合作，才有了TSX。

ts和node

typescript不能直接在node上运行，TypeStrong/ts-node，为了node执行服务提供开发的方便，实际部署生产环境，你可以将代码编译成为commonjs便于node服务器运行。

eslint

在tslint的让位后，eslint和typescript有机地结合，形成了可怕的生态链。typescript-eslint可以让ts的项目与vue或者react等其他厂商代码风格有趣共存。

DefinitelyTyped

DefinitelyTyped/给一些非ts编写的项目提供了便于开发者的类型定义文件，也符合微软的intellisense提示功能，在VSCODE上有非常好的开发体验。

吐槽

不像TS和react的完美结合，TS和vue之间则是有点隔阂。首先，vue2.0的对象声明写法让大量变量保存在vue对象当中，让ts并不好推断它的类型。举个栗子，vuex中的mapGetters和mapActions等魔法函数曾经是尤雨溪引以为傲的“艺术创作”。在ts面前则是非常“愚蠢”，store里面变量的类型不好判断。还有，plugins的机制也是把属性直接绑在vue对象当中，同样造成很多问题，我就不说mixins。

有些人说用class写法，首先，vue的class写法大大增加代码的学习成本，其次，尤大大在vue conf上直接class提案中修饰器的不稳定性。所以我还是建议大家不要使用vue的class写法。

在vue3.0的设计当中，新的语法有效避免this属性的使用。我相信ts在vue项目中会发展得很好，大家期待一下vue3.0吧。