作者 | Tim Daubenschütz
译者 | 弯月,责编 | 郑丽媛
头图 | CSDN 下载自视觉中国
出品 | CSDN(ID:CSDNnews)
以下为译文:
最近几个月,我注意到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生态?
☞将比特币用作结算网络中蕴含的经济学知识
点分享点点赞点在看