您好，Dead-horse
我是koahub.js作者，之前是做php开发的，一年前转做nodejs开发，开发过程中发现存在各种各样的问题，于是一狠心就开发了koahub.js框架。框架也是基于koa.js开发的。看到您开发egg.js非常棒，耽误您几分钟时间，想请教您几个问题。
1.请教一下您对koahub.js的看法？从我的角度和从koahub.js用户的角度分析，koahub.js非常棒，无论从开发效率还是可扩展性来讲都是nodejs开发web来说的一个超越。
2.请教一下阿里内部对node.js看法，都使用到了哪些场景？
3.请教一下如何做项目推广，egg.js出来之后，我一直在关注，从刚开始的100多star，到现在的2000多star？koahub.js的推广效果很差，但是koahub.js群里的50多个人，都对koahub.js给予了很高的评价。
附: koahub.js 官 网：http://js.koahub.com
回复 (30)
请问 无论从开发效率还是可扩展性来讲都是nodejs开发web来说的一个超越 的结论是从哪里得出来的，而且我很好奇很多前端或者非php转node的开发者有几个会喜欢这种如此类php的强约束风格。。。
没有仔细看实现的思路，但是看代码结构我就更愿意使用 eggjs，这是我的个人感受
不要意思，刚才看到邮件，直接在这里回复了。
代码我没有细看，但是一个没有完善的单元测试的框架是没有说服力的。
佩服你的勇气，已经 @dead-horse
@i5ting 给他发邮件了，没回。
@hyj1991 你的意思是说，cnode社区，大部分都是前端或者非php转node的？只有约束之后，才能见开发效率。不然我直接用koajs了，干嘛用eggjs？eggjs也约束了好吧。
@einsqing 个人意见，而且我说的是不喜欢 类php的约束风格 ，并不是说不喜欢约束，eggejs的约束风格和express/koa一脉相承，所以我愿意接受
举个例子：app/addon，node中addon一般指的是c++扩展，名称就很具有误导性，还有自动路由映射，请问写个路由配置文件很麻烦么？
当然萝卜青菜各有所爱，能做出一个完整的框架和配合的文档，本身我是很佩服的。但是如果用的人少或者接受的人少，有可能有我所描述的一些原因。
最后还是强调，以上都是个人意见。
@hyj1991 addon这个目录thinkphp也是这样设计的。没做框架之前，写了n多路由配置文件，很影响生产力，所以开源的第一个koa库就是自动加载路由的。
@dead-horse 我也觉得有这样的原因。所以接下来我也把单元测试写一下。
也请将 commit log 好好写写，而不是update update fix fix 之类的。光这些已经让人没兴趣去看代码了。
点开了一个类看了下, 就看到了没有必要的冗余呀
- 可以用 assert
- 按照你的逻辑, 直接
arguments.length < 2就好了
额... 点编辑变为删除了...
作为 egg 团队成员一名，我也简单回答几点：
- 第二个问题关于 「Node.js 在阿里」 ，在知乎那个回答中我有提到了: https://www.zhihu.com/question/50526101/answer/144952130
- 第三个关于「推广」，老实说，我们几乎没有做任何推广，目前也没有打算做什么推广，egg 团队的成员都是资深的开源参与者，我们只是想通过开源来完善我们的框架，并且回馈社区。如果实在要说推广的话，我想唯一能沾边的是：
- cnode 之前的文档直播贴 https://cnodejs.org/topic/5870e9da04dcf9a706a745f0
- 上面提到的知乎的那个回答
- 从一个用户的角度，我会这样去「评估」一个框架和类库：
- 是否足够规范：包括上面提到过的，单元测试覆盖率，commit 规范化，有没有 code review 机制。（这点决定了看第一眼后会不会 star）
- 基础框架的话， 是否有足够分量的应用案例，大规模稳定运行的历史
- 对自身的定位，做什么，不做什么，设计架构是否合理
- 可扩展性，定制性，生态
- 引入它，能解决什么问题，会带来什么新问题
- 等等
@leoner 改，这两天就改掉。可以不用那样写，但是有可能用户控制器里使用了constructor，所以判断了下。虽说不提倡用arguments，但是挺好用的。ctx, next必须同时传进来，所以不能直接写 arguments.length < 2 ，而且还必须提示用户哪个值没传进来。
其实，一个框架出来，它是解决什么问题，都应该有明确解释。 如果要我说，koahub只是你兴趣爱好下的小作品，很多人都能模仿和实现。问题在于开源能给开发者带来什么。
代码风格的确很 php
个人比较崇尚开箱即用，当需要开发新业务的时候，能尽可能的少写新代码。 所以我自己一套就是把业务分离的代码合到一个包里，当需要开新项目，直接安装这个包即可。 开箱即用，几分钟搭一套新系统。
推广github开源项目，第一步就是去阿里买上1000个star再说。
我个人觉得是这样，
- php开发人员的架构能力一般都比较差
- thinkphp被很多高端开发人员认为很烂
- 所以你仿照thinkphp，没啥特色啊，而且我认为你没把他当一个框架去做啊。。。更像是小品级的东西。。。
要不去参与thinkjs3的开发吧。。。
我使用koa最大的痛点是不能直接用Node原生/connect/express生态中的很多模块，而不是mvc或者开发者不知道怎么找模块
@steambap 直接改，没办法。楼上都是大神，所以对约束反感，喜欢想引什么包引什么包。我要做个快速开发框架
来自 KoaHub.js
@yuu2lee4 thinkjs就算了，道不同
来自 KoaHub.js
@jiangzhuo 哈哈，这就没意思了
来自 KoaHub.js
@sankyutang 快速开发框架，框架的出现就是为了提高开发效率，不然直接裸代码了
来自 KoaHub.js
做技术的都有这么一个特点，刚开始可望有规矩（类似TP的形式），再后来（能力上升）就是可望充分自由
理念和定位不太一样，egg 的出发点是阿里内部不同的业务场景下，各团队之间如何达成共建和差异化的平衡点，解决求同存异的问题，所以我们最主要的是一套约定，以及插件扩展机制，与此同时，还提供了上层框架的封装机制。
在阿里内部，在 egg 之上封装了很多上层框架，如适合蚂蚁业务场景的 chair，适合 UC 业务场景的 nut 等等。 研发同学根据业务场景选择对应的开箱即用的上层框架（框架还支持多层继承）。而这些框架之间又复用了非常多的 egg 插件。(当然，egg 本身也足够开箱即用了。) 在使用这些上层框架开发业务的时候，遇到的一些共性的问题，都会抽象成一个个独立的插件，当场景足够通用的时候，这些在应用层总结下来的最佳实践，就会根据需要逐层下沉到框架中，形成一个良性的循环。
所以我一直的观点是，用 egg 和目前市面上的框架去对比，是不恰当的，它们不是一个层面的，要跟 egg 对应的同业务场景的上层框架去对比才有意义。 说个不是很恰当的比喻：不能直接拿 connect 来对比其他框架，至少要拿它的上层框架 express 来对比。
回到框架这里，我认为在 egg 之上，通过 egg 提供的 loader api 去定制某些目录的加载规范（类似我们在 egg-sequelize 插件中增加了 app/model 的加载规则，然后再加上 router 的自动加载（几行代码可以搞定），就差不多能成一个类似的符合你需求的上层框架了。
至于约束，我的理解是要看对象
- 对于团队架构师或技术负责人，它是积木，足够的 optional，只需简单的做加法，组装插件即可封装成适合自己团队的上层框架。
- 对于团队开发人员，它又足够的强约束，保证不会出现千人千面的代码风格和设计。
- 具体阐述在 https://zhuanlan.zhihu.com/p/25223435?refer=eggjs 文档那一章有提到