kaelzhang

@AlanZhang 其实 bower 在某种程度上只是一个脚本管理器，把脚本下载到本地，然后让开发者自己搞定后面的事情。另外 bower 并没有用 commonjs，这样一个直接的问题就是，模块间都是用全局变量来交互，这样很糟糕，也因此无法多版本共存。

@tinymao 唔，难道是打开方式不对，哪天再来趟点评把，如果是妹子的话手把手教

@chemzqm 阁下是少有的经常会用包管理的人哪，握个爪。最近正准备写个文章谈谈这个问题。不过从生态环境来看，它会潜在地让用户去制造更多的fork，并且去依赖这些 fork，这个长久来看会有问题的。嘛，而且tj一年前就已经基本上把项目给樱桃哥一个人来维护了，这个才是硬伤 D:

@clowwindy 一个人因为 he or she 的问题被开除了，一个人休产假，还有一个人各种事情都忙不过来，哎好想 donate 点钱，让 izs 全职写 node 啊。

@pepsin 嘿嘿，谢谢

@iwege 感谢关注~

其实，无论是 browserify 还是 component，都会默认自带模块系统，因为 requirejs 还是 seajs 做的事情很有限，比如对 [semver ranges](https://github.com/mojombo/semver/issues/113) 的支持，对 [file module](http://nodejs.org/api/modules.html#modules_file_modules) 和 dir 的支持，对 __dirname，__filename 的支持，对 require.resolve 的支持。

当有了包管理器之后，模块加载器其实是不需要存在的，而且用户也不需要写 `define`, `define.amd`. 而且现在生态系统并不好，每个开源项目里面都要去写一大堆 AMD, UMD, *MD，它们基本上是我们平时开发过程中不需要去操心的，事实上，我们只需要跟 nodejs 一样写代码就好了。这也是为什么这些 *MD 一直都只是 proposal。
我们永远希望让开发者写更少的东西。

只有 [Module/1.0](http://wiki.commonjs.org/wiki/Modules/1.0) 是必要的

目前直接拿 daux.io 的设计了，下个版本会开放 theme 的 api。

@cfddream 哎呀忘记了，多谢提醒

npm: http://npmjs.org/package/document
git: http://github.com/kaelzhang/node-document
doc: http://kael.me/document