不影响大家选择适合自己的方案，只是对于同样在使用 TS 的过程中遇到新痛点的人来说，不用可能也是一种可以尝试的选择。

JSDoc/ESDoc 用过很长时间，如果团队里有成熟的编码规范和可靠的实施的话，结合代码分析能力强的 IDE ，是完全可以替代 TS 的，这也是为什么很长时间里我对 TS 不感冒。

我举个例子，并不是所有用到 JS 的场景都是在浏览器和 Node.js 上跑的，一些场景下 JS 被用于作为一些其他软件的嵌入语言（类似于 Lua ），甚至有些需要在专用的界面输入 JS 脚本，此时 TS 的编译层可能就会成为使用效率的短板，但利用注释的 JSDoc/ESDoc 不会，因为它们本来就可以被标准的 JS 解释器/引擎正确处理。

另外就是 JS 本身是个极其灵活的语言，所以它对开发者要求很高，缺乏经验的开发者会有较大概率写出有缺陷的代码，而 TS 就是通过限制语言的灵活性，来帮助开发者降低心智负担，从而提升了工业生产的效率。但万一开发者是个精通 JS 的大佬级人物，将 JS 运用到出神入化了，这时候没准灵活性反而成了高优先级需求。就像一些 C 语言大佬的程序，代码难懂，但也确实比其他现有方案能更好满足功能需求。

不过说能替代也是说的一部分场景下的，总有些场景下，结合团队和项目情况来综合衡量，TS 可能更适合，这也是 TS 存在并被广泛使用的原因。

TS 要想取代 JS ，大概率只有普及 TS 原生引擎这一条路可以走；只要没法取代 JS ，就一定只能苟在 JS 技术栈的子集里。换言之本来就是一个技术栈，绝大多数人是两种都会/用/容易上手的，也没必要单立派别啥的。