TypeScript 的存在削弱了 JavaScript 生态系统？
以下为译文：
最近几个月，我注意到GitHub上的TypeScript软件包急剧增加。在浏览一些我关注的人的代码库，或者为了解决项目中的问题而寻找依赖项时，就经常遇到新出现的TypeScript软件包。每当我遇到的TypeScript包越多，我就会越担心。
首先声明我对TypeScript没有研究，也不了解TypeScript。不幸的是，在搜索依赖项时，这种问题就会涌现出来。当我有意或无意地将TypeScript引入到项目时，我的这种感觉也会越来越强烈。主要是因为我选择软件包的标准包括：
选择我希望为之做贡献的软件包，例如一个编写良好却鲜为人知的软件包；
选择大型社区维护良好的软件包，但其中可能包含我无法轻易贡献的代码，例如内部使用C库的热门软件包。
在构建应用程序时，我希望采用这些标准以达到一定的质量标准。或者是因为我可以自己快速修复bug，或者是因为我能够依靠强大的社区来修复它们。
然而，对于npm中的TypeScript软件包，现在出现了一个不透明的问题，也就是我不了解该语言，也不清楚该软件包的语言及其社区规模。
另外，TypeScript可能只是另一个CoffeeScript。
因此，从本质上来说，问题在于TypeScript的作者将其软件包发布到了Node.js的软件包管理器npm上。对我而言，这就是在削弱JavaScript的生态系统。自成立以来，贴别是在经历了Coffeescript的发展后，npm一直在恪守仅托管JavaScript软件包的诺言。然而，由于许多人在发布由TypeScript转换成JavaScript的包，npm不得不打破了这个诺言。
微软将TypeScript作为“JavaScript的超集”来宣传是有一定道理的，而且由于TypeScript可以“编译”为JavaScript，又何妨将软件包发布到npm呢？但二者毕竟不一样，TypeScript不是JavaScript。毕竟，你也不会认为C和Objective-C是相同的，不是吗？在这两个例子中，两种语言都是子集/超集的关系，但它们解决问题的目的不同。
因此，我认为TypeScript作者应遵循以下几条原则：
为他们的TypeScript包建立单独的命名系统；
将他们的软件包构建并发布到TypeScript自己的软件包管理器。
然而，在我看来，继续将TypeScript包发布到npm会削弱JavaScript的生态系统，因为这种做法会分裂这个社区，并污染npm的空间。
这篇文章发布以后，也在网上引发了热议：
评论1：
只有外行才会把TypeScript和CoffeeScript放在一起比较。
CoffeeScript明确地拒绝使用ECMAscript，而TypeScript接受并欢迎ECMAScript。
太多的人都期待着TS中的.?操作符，因为他们不想再重复CoffeeScript走过的路（定义自己的操作符，与官方标准完全不同）。
TS和JS的唯一区别就是类型标注。除了类型标注之外，TS和JS完全一样。
Objective-C实际上可以编译C，所以Object-C是C的超集。作者这里的观点也很误导。
所有TypeScript的webpack插件都会把TypeScript的东西剥离，留下的只有JS.
TypeScript发布到NPM时也是转换成JS才发布。
作者提到的那些他能改的bug，换成TypeScript的话估计都能被类型系统发现。TS的bug比JS少25%。
评论2：
作者承认自己没用过TypeScript也不了解TypeScript，就敢说TypeScript污染了JavaScript社区？
他也知道TypeScript是JavaScript的超集，而且能编译成JS，我不认为这有什么问题。TypeScript可以让复杂的项目更容易管理，我们应该鼓励使用TS。
单独给TS做一个包管理器没必要。微软收购了github，所以现在npm也属于微软，他们在扩展JS来支持TS方面做得很好。
我的想法跟作者正好相反，从某个角度来说TS才是标准。
对此，你怎么看？
原文：https://timdaub.github.io/2020/09/01/typescript/
本文为 CSDN 翻译，转载请注明来源出处。
推荐阅读：
每日打卡赢积分兑换书籍入口
👇🏻👇🏻👇🏻