为什么每个人都使用Node.js和NPM来编译JavaScript库？

Question

我真的很困惑JS社区中的每个人使用Node.js和NPM与他们的JS库.为什么我们不得不诉诸这种极端措施？这为我们解决了什么问题？

[编辑]我认为我的问题不是重点.

1. 像Ember.js,Batman.js以及最近雅虎的Mojito这样的框架要求我使用node.js - 为什么这种依赖Node.js和NPM？
2. 我们为什么要把事情搞复杂？"如果你还没有,你需要安装node.js ......"你阅读这样的消息并且你已经关闭了.

为什么？JS中存在大量问题 - 有太多活跃的JS库/框架可供选择 - 通过JS库的记录,大多数将很快变为非活动状态.有太多东西需要寻找,这通常会导致应用程序中的多个框架 - 依赖关系管理,路由器,MVC,模板等.最重要的是我们使用Node.js来使用这些库/框架...这会将这些库的使用推向新的JS开发人员吗？JS本来就很容易!

Answer 1

"如果你还没有,你需要安装node.js ......"你阅读这样的消息并且你已经关闭了.为什么？

NodeJS是谷歌的V8"自己运行".它是一个带有额外低级API(网络,I/O等)的JS引擎.NodeJS为JS开发人员提供了"缺少的平台",他们仅限于在浏览器上工作.

为什么这种依赖Node.js和NPM？

Node.js,除了将它用作应用程序(服务器,代理,机器人等)之外,它还可以用作工具构建和辅助开发.以Grunt为例,它是一个类似于Make的可编写脚本的自动化工具.在简单的JS中编写脚本,您无需学习其他工具或语言来进行自动化.另一个工具是Bower,它是一个前端包管理工具.您需要做的就是bower install jquery使用该命令安装jquery.无需手动下载,复制和粘贴.

另一方面,NPM是Node.js的包管理器.它是一个管理您在NodeJS上使用的模块的程序.无需手动列出您的模块,也无需在开发其他地方时记住它们.只要您拥有为您制作的NPM包装清单,重新安装只是一个问题npm install.

我们为什么要把事情搞复杂？

不是.事实上,我们正在为开发人员提供便利.您可以将这些任务卸载到NPM上存在的某些模块,而不必担心您的工作流程,管理库或手动执行操作.然后你可以专注于你实际在做什么.

最重要的是我们使用Node.js来使用这些库/框架......这将如何将这些库的使用推向新的JS开发人员？JS本来就很容易!

如上所述,NodeJS是一个多功能平台.它可以用作服务器(Connect,Express),自动化工具(Grunt),包管理系统(使用NPM,Bower等),测试平台(QUnit,Mocha),代理,游戏服务器,聊天机器人.

这对JS开发人员来说是有益的,因为这些在JS中是不可能的.

JS中存在大量问题 - 有太多活跃的JS库/框架可供选择 - 通过JS库的记录,大多数将很快变为非活动状态.有太多东西需要寻找,这通常会导致应用程序中出现多个框架 - 依赖关系管理,路由器,MVC,模板等.

嗯,有一套丰富的框架是很好的.在学习其中一些之后,你的工作将减少一半.实现多样性也很好,可以解决不同的编码风格和不同的实现方法.一些图书馆从不同的方法中崛起,而另一些图书馆则从其他图书馆的不兼容性和/或不完整性中崛起.

开发人员正在努力通过规范JS怪癖来使其他开发人员的生活更轻松(因为浏览器供应商似乎无法做出遵循标准的正确事情)并且大多数都是自愿完成的,比如免费啤酒 - 你应该是为此感到高兴.此外,没有人强迫你使用一个.

Answer 2

CommonJS标准(在我看来,Node.js和NPM最好实现)向Javascript 引入了模块的概念.多年来,Perl和Python社区已经证明了为什么模块很棒:

• Unix风格的"做一件事,做得好"的库很小,经过严格的bug测试,可以轻松组合(没有命名空间问题)来解决你的特定任务.
• 开源模块的中央存储库(CPAN,NPM等),您可以轻松地从中提取模块(NPM通过保持所有版本可用而使其高一级,因此您可以指定您的代码使用最后一个已知的"好"版本而不是希望在重新部署la CPAN时没有任何损失).
• 对代码的更多同行评审(因为它们更易于组合,它们在更多种情况下使用,因此这有助于减少错误,但也有助于改进模块更加通用化).
• 解决了各种各样的任务.由于库很短,几乎任何人都可以写一个.这确实意味着有更多的垃圾可以过滤(关于广泛使用的文章的文章有助于此),但它也意味着一个解决一些非常具体的问题(如本地化字符串和日期)的库可能也存在.

然后,一个名为browserify的Node模块使客户端代码的实际构建过程非常简单,您可以使用在NPM上找到的任何代码.

这打破了jQuery等图书馆的"厨房水槽"心态(他们开发了自己的自定义构建系统,因此他们也可以开始模块化他们的代码),认为他们需要解决用户可能遇到的每一个问题,而不仅仅是生产其他库可以使用的结果.