前端不适合硬上TS，后端更合适。TS带来的负担和副作用很大，特别是前端。复杂一些的前端项目，光TS兼容问题都能折腾死人。千万别给人洗脑了，非TS不可。TS是个矛盾的产物，它的存在就是一个矛盾。这点在前端同学身上表现的最为明显。因为他们折腾的东西少，技术区域有限，不够广泛。

TS 要解决什么问题？动态语言的类型匮乏带来的运行隐患。它能解决吗？能解决部分。为什么不能解决全部问题？ C/C++/Java等也是强类型语言，如果能它们早就能了。

动态语言的类型设定，是为了开发方便。脚本语言写起来省时省力，所以这并不是真的“缺点”，而是一种特性。我就要这么方便的写JavaScript，至于什么用户点击 callback 类型是什么，没人关心。

现在，TS要求给它加上类型定义，这实际上也是一个枷锁，与动态语言的初衷是背道而驰的。如果你用TS做过前端的项目，特别是开了严格模式 – strict，你就知道我在说什么了。真要追求严谨完美，你连用户点击回调的类型都要定义出来，然而它真有必要么？用户关心这些东西么？纯粹自己给自己找麻烦。这也是TS的矛盾之处。

反而是后端使用JS的时候，用TS编译有很大的优点，接口定义很清楚，容易检查排除问题。遇到超复杂的定义，直接 any 搞定，不要有任何心里负担。因为所有的类型问题，都可以通过大量反复的测试解决，测试保证。

当然，TS还有其它好处：语法书写统一、编译期自动检查排错等，但它不是万能，也不是非有不可。别把它当成银弹。