在网上搜了一圈前端使用ts的优缺点，各种拿去跟ES6,JS比较的。你说你跟eslint校验比较下tslint还有理可循，你跟JS,ES6是在比啥呢？
本篇文章总结一下使用TS的优"缺"点。
先说好的
1.个人在使用TS的时候，基本上把接口文档抄了一遍，接口一旦有任何的输出不对劲你都可以很明确的知道到底是谁在瞎几把改字段，熟练掌握后慢慢的你可以自己定义接口交给服务端，这样可以少点适配器，当然使用了ts还用个p的适配器
2.如果你的代码足够规范的话，一旦增删改了公共接口，提交数据的函数或者跟这部分数据有关的页面和函数立马全部报错，你只要对着控制台一个个修复增删改的字段就行了，当然dom部分的代码还是得手动修复。这点非常有利于别人维护你的代码。以前改代码的时候我总是战战兢兢，改了一个接口生怕哪里疏忽了没改，毕竟不是你自己写的，就算是自己写的时间久了也容易忘记，现在好家伙，只要一改接口相关页面全报错了，我tm直接好家伙。
个人认为第二点真的尤其好用，用了TS你再也不用对老项目唯唯诺诺了，现在只需要修改相应的接口文件，你就可以对老项目里的代码重拳出击了。
说完好的，再来说说缺点
1.TS最大的缺点就是费代码，费键盘！以至于很多小伙伴在刚开始用TS的时候认为这个东西毫无用处，我之前在使用了相当长一段时间的TS后都是这么认为的，直到我体验到了上述两个优点，所以这东西真的是见效太慢了！十分之劝退新人。
2.除此之外，TS还有一些美中不足的地方，比如不能与时俱进，检测不到数据双向绑定的dom里的字段是否正确，这个功能急需主流三大框架帮咱们彩笔程序员解决一下，要是能把dom模板一并检测了，那真的是美滋滋。
3.我个人认为TS最大的问题就是没有try catch这样的错误处理方法，如果能在检测到错误的时候抛出一个可以被捕获的异常的话，那真真是极好的，有时候我们就是需要数据是错误的，比如number类型的数据给了一个非number，我们就可以通过一些方式提示用户数据应该为数字，而不是数据存在非number的可能性就必须将数据定义为number|非number,当然这点是个人理解。