为什么每个人都使用Node.js和NPM编译JavaScript库？
我真的很困惑与JS社区中的每个人使用Node.js和NPM与他们的JS库。 为什么我们不得不采取这种极端的措施呢？ 这解决了什么问题？
[编辑]我想我的问题是不重要的。
- 像Ember.js，Batman.js和最近雅虎的Mojito框架要求我使用node.js – 为什么这种依赖Node.js和NPM？
- 我们为什么要把事情搞复杂？ “如果你还没有，你需要安装node.js …”你读这样的消息，你关掉了。
为什么？ 在JS中已经有很多问题了 – 有太多的活动JS库/框架可供select – 通过JS库的logging最多将很快失效。 有太多东西需要寻找，往往会导致在一个应用程序的多个框架 – 依赖pipe理，路由器，MVC，模板等。在此之上，我们使用Node.js来使用这些库/框架…这会推动这些库的使用到新的JS开发者吗？ JS很容易！
“如果你还没有，你需要安装node.js …”你读这样的消息，你关掉了。 为什么？
NodeJS是Google的V8“独立运行”。 这是一个带有额外的低级API（networking，I / O等）的JS引擎。 NodeJS为JS开发人员提供了“缺less的平台”，这些开发人员仅限于在浏览器上工作。
为什么这个对Node.js和NPM的依赖？
Node.js除了将其用作应用程序（服务器，代理，机器人等）之外，还可以用作工具构build和辅助开发。 以Grunt为例，这是一个类似于Make的脚本化自动化工具。 脚本只是简单的JS，你不需要学习另一种工具或语言来做自动化。 另一个工具是Bower，它是一个前端软件包pipe理工具。 所有你需要做的是一个bower install jquery和它安装jquery这个单一的命令。 无需手动下载，复制和粘贴。
另一方面，NPM是Node.js的包pipe理器。 这是一个pipe理你在NodeJS上使用的模块的程序。 无需手动列出模块，也无需在别处开发时记住它们。 只要你有NPM的包装清单，重新安装只是npm install 。
为什么我们要把事情搞复杂？
不是。 事实上，我们正在为开发者提供方便。 您可以将这些任务卸载到NPM上的某些模块中，而不必担心工作stream程，pipe理库或手动执行任务。 那么你可以专注于你实际上在做什么。
最重要的是，我们使用Node.js来使用这些libs / frameworks …这将如何将这些库的使用推向新的JS开发者？ JS很容易！
如上所述，NodeJS是一个多function的平台。 它可以用作服务器（Connect，Express），自动化工具（Grunt），包pipe理系统（使用NPM，Bower等），testing平台（QUnit，Mocha），代理，游戏服务器，聊天机器人。
这对JS开发人员尤其有益，因为这些在JS中是不可能的。
在JS中已经有很多问题了 – 有太多的活动JS库/框架可供select – 通过JS库的logging最多将很快失效。 有太多东西需要寻找，通常会导致应用中的多个框架 – 依赖pipe理，路由器，MVC，模板等等。
那么，拥有丰富的框架是很好的。 在学习了一些之后，你的工作会减半。 实现多样性也很好，针对不同的编码风格和不同的实现方式。 一些图书馆从不同的方式上升，另一些则从其他方面的不兼容性和/或不完整性中崛起。
开发人员正在努力工作，通过规范化JS怪癖，让其他开发人员的生活变得更加轻松（因为浏览器供应商似乎无法遵循标准），而且大部分都是自愿完成的，比如免费啤酒 – 你应该为此感到高兴。 此外，没有人强迫你使用一个。
CommonJS标准（在我看来，最好由Node.js和NPM实现）将模块的概念引入到Javascript中。 多年来，Perl和Python社区已经certificate了为什么模块很棒：
- Unix风格的“做一件事，做得好”的库很小，经过严格的testing，可以很容易地组合（没有命名空间问题）来解决你的特定任务。
- 开放源代码模块 （CPAN，NPM等）的中央存储库 ，您可以轻松地将模块从（NPM）中提取出来，通过保持所有可用版本使其更高一级，因此您可以指定您的代码使用最后一次已知的“良好”版本，而不是希望当您重新部署一个CPAN时没有任何东西被破坏）。
- 对代码进行更好的同行评审 （因为他们更容易组合，他们被用在更多不同的情况下，所以这有助于减less错误，但也有助于改进模块，使之更为普遍）。
- 解决了更多的任务。 由于图书馆很短，几乎任何人都可以写一个。 这意味着有更多的废话来过滤（关于广泛使用的库的文章有助于这一点），但它也意味着一个库，解决一些非常具体的问题（如本地化string和date ）可能也存在。
然后一个名为browserify的Node模块使得客户端代码的实际构build过程变得非常简单，您可以使用您在NPM上find的任何代码。
这远离了像jQuery这样的图书馆（他们已经开发了自己的定制构build系统，所以他们也可以开始模块化他们的代码），他们认为他们需要解决用户可能拥有的所有问题，而不仅仅是生产其他库可以使用的结果。
很多时候你需要不同版本的javascript。 通常它是分散在不同的文件，有时它在咖啡脚本。 你经常需要构buildAMD兼容版本，以及CommonJS版本，以及定期最小化和非最小化版本。
还有依赖解决的潜力。
我甚至见过一个库，有一个生成的jQuery和原型…
编辑：注意到我正在回答问题体内的问题，但错过了标题中的编译问题。
你认为这是一个“极端措施”，你有什么标准？ 为了编写干净，易于读写的代码，这个过程已经完成了好几年，但是为了在线传输（也可能是其他优化）而进行了预编译。 Node.js为此提供了一个很好的解决scheme，因为它也使用JavaScript，因此人们使用它来编译JavaScript代码时很熟悉。 以前这通常是用像Python这样的东西来完成的，尽pipe工作起来，但对于我来说，看起来不像一个普通的语言那么有意思。