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 翻译，转载请注明来源出处。

更多精彩推荐
☞头秃，在线求名字：网易使用昵称交流，再也没有“哥，姐，总”
☞高科技公司的 CEO 要写代码吗？
☞文件系统：隐匿在 Linux 背后的机制
☞CPU有个禁区，内核权限也无法进入！
☞5年5亿美金，华为昇腾如何构建全行业AI生态？
☞将比特币用作结算网络中蕴含的经济学知识
点分享
点点赞
点在看