截至 2013-09-11 日：现在你打开 https://npmjs.org/ 你会看到基于 nodejs 的包已经超过 4W 了 , 基于 NodeJS 的模块数据增长惊人， 在过去的5个时间里，包的数量增加了了 1.4W个，增长接近 50%, 已经接近 Ruby。
关注下 pypi，npm, rubygems 社区上的开源包的发布，从 python（1991），ruby(1995)，和 node.js(2009) 发布日期开始， 这些社区上每年发布的开源包以下面的比例增长： python: 29,720 包/22 年 = 1351 包每年 ruby: 54,385 包/18 年 = 3022 包每年 node.js: 26,966 包/4 年 = 6742 包每年
这种 node.js 开源包惊人的增长现象，怎么会成为可能？
不内置电池
如果，你曾经需要一个 Python 的客户端库，你可能问你自己"我是要用 urllib, urllib2, 还是 httplib 呢？”，就像其他所有人 . 好吧，答案可能是你应该使用 requests. 它是一个很简单，直观的 HTTP 客户端库，很好的封装了很多标准库的陷阱和 bug，但很可惜的是它不像上面其他库一样是标准库。 Python 的“电池内置”策略在 90 年代中期绝对是正确的，这也是我很喜欢它的一个原因。在那个年代，没有现代化的包管理，查找和安装社区创建的库并不是很容易。现在，虽然，我认为这样效率并不高，但当时社区的开发者很少想去和标准库竞争，所以人们很少尝试着去写出提升标准库的改良库。
开发者也很不喜欢在他们的项目中使用非标准库。我听到过很多人隐忍着使用次等的标准库只是为了“不依赖外部库”。但在现在，大容量存储器如此便宜，又拥有现代化的包管理工具，人们不应该再采用“不依赖外部库”的策略. 相反，node.js 核心开发者实际上想尽可能的最小化标准库。他们已经多次从标准库里移除的特性，而鼓励大家使用社区实现的版本。这样的方法允许最大的多样性，让最好的实现版本胜出（当然，当有人实现出来一个更好的版本就会再次替换!）。 想像一下，这样对标准库维护者也是多么自由啊。node.js 标准库是 相当小，这样可以释放核心开发者更专注在核心的部件上。
小就是美 (The Tiny Module Aesthetic)
这种方法也并不是多特别，起码在 node.js 社区。这个社区被一群开发者领导，其中每个开发者都发布了几百个包。我从前都不相信有这种可能性. 当然，我们不可能限制其他语言也这么做，所以，我更相信是社区文化起了决定性的影响。 像 Ruby on Rails 这种大单体框架并没有侵占 node.js 社区的份额，我想部分原因在于"小模块更美"(“tiny module aesthetic”) 这种思想，而且这个思想也更适合 node.js。对我来说，像 Rails 这种大框架没有一个清晰的边界，所以他们倾向于无限的扩张从而包含一个应用可能需要的所有东西。这导致人们坚信 Rails 是所有问题的最好解决方案，从而阻碍了 Ruby 社区在 web 应用领域的变革。
这种小模块更美的思想也导致了一个高度重用的生态系统。当一个包只做必要的事情时，它非常容易理解和更容易集成到其他应用。相反的，大单体框架趋向于出现在大量的终端用户应用中，而很少被其他包依赖。这对我来说感到很遗憾，因为那些软件那么优秀，却那么难重用。
git 和 github.com 单种栽培 (monoculture)
老实说，对我来说软件开发过程中，很少有东西比版本控制让我更厌烦的。而且我发现 git 对我来说有点太复杂了。但是我还没听说过那个 node.js 开发者不用 git 的，这种单种栽培有非常大的价值。这意味着他们使用同一种通用语言，当他们想为其他人的项目贡献时，没有任何障碍。 Github.com 在降低开发者相互贡献的障碍时有同样的效果。我很少看见 node.js 项目不在 github 上。这意味着如果我想做出贡献，我可以马上知道去哪里找到源代码。 github 单种栽培的优缺点远远超过这些，但要完全说明它们，恐怕要开单独的一个文章来说明。
自由的许可 (Permissive Licensing)
Node.js 包倾向于使用非常自由的许可，例如 MIT 和 BSD 许可。实际上，使用npm init创建一个包时，缺省的许可是 BSD. 我想这是新时代的另一个标志。
很少的人会在意别人创建新分支 (forks) 却不回馈 (contribute back)。而且人们如果不回馈也收获甚少，因为要花精力维护自己的分支。
这很重要，因为没有人想去处理牵涉到法律后果和更多法律责任的事务。像 GPL 这样的许可，因为这个原因，最终减缓了软件重用。
npm 包增长迅速，得益于 javascirpt 开源库多有关。
nodejs 异步 callback 写法，会导致嵌套很深，很反人类，也注定只能是小众范畴。
语言是次要的，关键是看配套的工具和库是否齐全 (基于上面开发的人不可能什么都自己去写，关键是要快速出来东西，这就要求依赖的库要稳定和有人长期在跟踪维护)
#12 楼 @wxianfeng 中文 Node 活跃用户活跃的地方目测是微博... 没泡论坛习惯的 generator 语法目前正在山寨中。
老话说优秀之处非原创，原创之处非优秀。
话说刚才无意发现了这货 http://reactive-extensions.github.io/RxJS/ 搞 js 的同学们有研究么？据说是 m$的人搞出来的
#8 楼 @wxianfeng 你之前说的是嵌套过深的问题，我说 promise 就是指这个。现在你又改成异步和同步的编程思想差异了……这个我没什么好说的，人和人不一样，你觉得爽的别人未必会觉得。
NodeJS 崛起的势头如此凶猛，有一个很重要的原因是很多很多优秀的前端工程师（不是咱国内那种只写页面的工程师）对这个语言平台和异步编程思想是天然兼容毫无抵触的。你要知道有大量的前端工程师都没有或者很缺后台语言的经验和背景，不能写后台服务这个事儿把他们都给憋坏了，所以 NodeJS 一出现，这帮人就跟疯了似的往上冲，所以繁荣得一点也不意外啊。
其实 Node.JS 有个 http://coffeescript.org/ 的 Library 跟 Ruby 的语法很像，不同的只是回调和异步的思想，下面就是用 cs 写的 node.js 代码：
# Assignment: number = 42 opposite = true
# Conditions: number = -42 if opposite
# Functions: square = (x) -> x * x
# Arrays: list = [1, 2, 3, 4, 5]
# Objects: math = root: Math.sqrt square: square cube: (x) -> x * square x
# Splats: race = (winner, runners...) -> print winner, runners
# Existence: alert "I knew it!" if elvis?
# Array comprehensions: cubes = (math.cube num for num in list)
#37 楼 @jiyinyiyong 我记得曾经有个 benchmark，node 在 win 下的性能比 linux 下还要强一些，原因就是 m$亲自贡献了基于 iocp 的异步 io 实现....linux 流行的 epoll 和 iocp 比起来弱爆了...m$支持 node 主要是因为 win azure
