koahub.js小白作者请教egg.js的一封邮件
发布于 2 年前 作者 einsqing 4380 次浏览 来自 分享

您好,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 回复

佩服你的勇气,已经 @dead-horse

@i5ting 给他发邮件了,没回。

请问 无论从开发效率还是可扩展性来讲都是nodejs开发web来说的一个超越 的结论是从哪里得出来的,而且我很好奇很多前端或者非php转node的开发者有几个会喜欢这种如此类php的强约束风格。。。 没有仔细看实现的思路,但是看代码结构我就更愿意使用 eggjs,这是我的个人感受

不要意思,刚才看到邮件,直接在这里回复了。

代码我没有细看,但是一个没有完善的单元测试的框架是没有说服力的。

@hyj1991 又说实话。。。哈哈

@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 之类的。光这些已经让人没兴趣去看代码了。

untitled1.png

@fengmk2 谢谢给予宝贵的意见

untitled1.png 点开了一个类看了下, 就看到了没有必要的冗余呀

  • 可以用 assert
  • 按照你的逻辑, 直接 arguments.length < 2 就好了

额… 点编辑变为删除了…

作为 egg 团队成员一名,我也简单回答几点:

  • 第二个问题关于 「Node.js 在阿里」 ,在知乎那个回答中我有提到了: https://www.zhihu.com/question/50526101/answer/144952130
  • 第三个关于「推广」,老实说,我们几乎没有做任何推广,目前也没有打算做什么推广,egg 团队的成员都是资深的开源参与者,我们只是想通过开源来完善我们的框架,并且回馈社区。如果实在要说推广的话,我想唯一能沾边的是:
  • 从一个用户的角度,我会这样去「评估」一个框架和类库:
    • 是否足够规范:包括上面提到过的,单元测试覆盖率,commit 规范化,有没有 code review 机制。(这点决定了看第一眼后会不会 star
    • 基础框架的话, 是否有足够分量的应用案例,大规模稳定运行的历史
    • 对自身的定位,做什么,不做什么,设计架构是否合理
    • 可扩展性,定制性,生态
    • 引入它,能解决什么问题,会带来什么新问题
    • 等等

@leoner 改,这两天就改掉。可以不用那样写,但是有可能用户控制器里使用了constructor,所以判断了下。虽说不提倡用arguments,但是挺好用的。ctx, next必须同时传进来,所以不能直接写 arguments.length < 2 ,而且还必须提示用户哪个值没传进来。

@atian25 谢谢指导

其实,一个框架出来,它是解决什么问题,都应该有明确解释。 如果要我说,koahub只是你兴趣爱好下的小作品,很多人都能模仿和实现。问题在于开源能给开发者带来什么。

代码风格的确很 php

个人比较崇尚开箱即用,当需要开发新业务的时候,能尽可能的少写新代码。 所以我自己一套就是把业务分离的代码合到一个包里,当需要开新项目,直接安装这个包即可。 开箱即用,几分钟搭一套新系统。

推广github开源项目,第一步就是去阿里买上1000个star再说。

我个人觉得是这样,

  1. php开发人员的架构能力一般都比较差
  2. thinkphp被很多高端开发人员认为很烂
  3. 所以你仿照thinkphp,没啥特色啊,而且我认为你没把他当一个框架去做啊。。。更像是小品级的东西。。。

要不去参与thinkjs3的开发吧。。。

我使用koa最大的痛点是不能直接用Node原生/connect/express生态中的很多模块,而不是mvc或者开发者不知道怎么找模块

@rwing koahub.js目标做成小白框架,看两眼就会用了。

来自 KoaHub.js

@steambap 直接改,没办法。楼上都是大神,所以对约束反感,喜欢想引什么包引什么包。我要做个快速开发框架

来自 KoaHub.js

@yuu2lee4 thinkjs就算了,道不同

来自 KoaHub.js

@jiangzhuo 哈哈,这就没意思了

来自 KoaHub.js

@lymanlai 你已经大神了,初学者尴尬了,坑太多

来自 KoaHub.js

@sankyutang 快速开发框架,框架的出现就是为了提高开发效率,不然直接裸代码了

来自 KoaHub.js

做技术的都有这么一个特点,刚开始可望有规矩(类似TP的形式),再后来(能力上升)就是可望充分自由

@einsqing

理念和定位不太一样,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 文档那一章有提到
回到顶部