@aylizhiyuan 求大神分析

@aylizhiyuan 快来啊~~~~~~~~~~~~~

哪个用的习惯就用哪个就好嘛，一个框架除了代码质量、架构设计，还有文档、推广、科普等，不是一句二句说的清的

老实说，火不火其实关系不大，没必要太纠结。

搬运下之前在 https://github.com/atian25/blog/issues/18#issuecomment-289940960 的回复吧：

@cncoder 这么说吧，作为一个学生，能这么早关注业界的东西，挺不错的了。

但有几点建议：

估计egg再火，BAT中的BT也不会用

• 怎么样的才叫 BAT 都在用呢？光阿里内部，几千号前端，百来个小组，是不是 100% 都在用，才叫用呢？你怎么知道 BT 中没有团队在用呢？
• 退一步，Koa 算不算 BAT 都在用呢？Koa 比较底层，一般团队都会需要在上面做一层包装，如果回头你进的团队是这样的，你会不会告诉你老大：「我估计我们这个框架，也就我们团队在用，公司级别都推不动，更别提 BAT 了，所以我拒绝使用」？甚至如果你的团队还在用 express 呢？

只怕学完变成以后工作的“周末玩具”

• 作为学生或者说初学者，建议像海绵那样，多去学习，多去吸收，不要太功利化。
• 学习 Egg.js 不代表你必须用它，它也不会成为你学习后，一生都会用的东西。
• 而是要去思考，Egg.js 遇到了什么问题，解决了什么问题？同类框架是如何解决这个问题的？他们之间的对比是怎么样的？谁优谁劣？如果他们的方案各自优点结合起来，又会怎么样？
• 不要人云亦云 KPI，那是别人黑着玩的，跟你有什么关系么？看看文档，看看源码，能有收获就值了，如果发现写的很烂的话，直接跳坑咯。没有一个框架是你学习后可以用一辈子的，程序猿最怕的是「你那不叫十年工作经验，是一年工作经验用十年。」

方便以后造轮子

• 在文中其实提过 「其实大家的基础框架用不用 egg 真的无所谓，最重要是有一套适合团队的约定。」
• 或者这么说，未来你参与面试的时候，面试官希望听到你说 「我用过 xx 框架」，还是希望听到你说：「我在做 XX 项目的时候，预研过 XX 和 YY 框架，最终因为 XX 等原因，我选择了 XX 框架。在这过程中，我遇到了 XX 问题，为此我去看了 XX 源码，发现他们是基于 XX 原理的，还有优化的空间，于是自己尝试了 XX，解决后写了 XX 总结文章，甚至尝试给 XX 框架提了一个 PR 解决了这个问题」

@i5ting 谢狼叔科普

@atian25 谢谢回答！

@atian25 猪哥说的好实在啊

我在做XX项目的时候, 发现 XX 和 YY框架都不好, 最后我就自己去造轮子 ZZ 了, 然后项目黄了 :) 手动滑稽 😂

kjkhkkjk

OK

@aitian25 打这么多字不容易，给个赞 自豪地采用 CNodeJS ionic

@magicdawn 笑死我了

@magicdawn 似乎很在理，学暴雪，做款游戏造一套引擎！

取其所長就行了，Node的風格不適合大框架，適合組合。

会火

@arden 请问有什么依据没

已经火了~

能学到东西就好。其实看eggjs，很多东西与其他语言后端涉及上还是很相似的，通过它的用法，学习它是怎么去处理一类问题的

@i5ting 🙈^_^

所以为啥不学koa和express？阿里的东西不都是那样么？

我给团队的最终选型是 egg，至于火不火我不知道，只说说我为什么选它

1. 他是基于 koa 的，koa 是一定要选择的，只因为 async/await 。egg 是对 koa 的包装，即时你的团队是用 koa 的，但是不可避免的要自己包装一层，所以有现成的并且很优秀为什么不用？
2. egg 的作者们都是大牛，给 node 和 koa 都贡献过代码，所以我相信他们，或者看 egg 源代码，如果你能力可以，那么你应该能看出来 egg 写的比其他一些什么框架代码质量/可维护性/可读性都高出很多
3. 测试做的非常棒，据我所知没有几个国内开源项目有这么高的覆盖率
4. 扩展度也很高，很多功能以插件方式提供的，所以正如 egg 官网说的一样，你可以基于 egg 搭建一套适合企业业务的基础框架出来
5. 更适合企业团队开发使用，他有一些约束和规则
6. 暂时想到这么多，其实还有一些原因的

顺便说说我理解的使用 egg 的正确方式

1. 建议企业级团队使用，个人弄个小项目的话我觉得用什么都没多大区别
2. 要根据自己企业业务在 egg 之上再包一层，最终会变成 “kao --> egg --> 你的企业框架 --> 业务代码” 这个层级关系
3. 跟 egg 无关，企业团队项目最好用 ts，假如你希望你的项目变成“大”项目“长”项目的话

@okoala 哈哈 是的 看这个问题就知道了。。。 我也有份功劳啊

@rwing 多谢回答，学习了:thumbsup::thumbsup:

我觉得egg入门容易，并且简单易学。火不火只是时间问题。

@rwing async/await和koa没啥关系吧。。。koa2虽然开始大规模并且推荐async/await但是你express想用async/await就不能用了？

egg是一个相当庞大的封装，egg的源码里能学到很多东西。。

这问题已经火了啊

@artisan 能用是用，但是你会发现各种别扭啊，这就好像，你想用v12的发动机，那么底盘/车身/轮毂都要配套才能把发动机发挥到极致，你不能随意搭配个夏利的车身是不是？

@atian25 不能同意更多

个人觉得这种纯开发规范、插件级别的封装，对于公司可能很有用的东西，开源社区可能并不会很感冒。。远不如一个基于 ts/flow 的支持 静态类型的 框架关注度大。。比如 typeorm 之前我看才几百 star，如今已经2k+了。。也许你会说 egg更多，但是 egg 是在有大公司做推广的，typeorm 则基本是社区的产物，star 质量也不一样。。

@zaaack 是的，因为一直觉得node生态还在成长，企业级开发那块可能相对来说标准还没定，egg就是想立个标杆吧。个人理解

@yilikun 标杆立早了，用函数去返回类，这对于静态类型的支持可不太好。。😂

来自酷炫的 CNodeMD

@zaaack 指的是 module.exports = app => class Test extends app.Service {} ? 有支持 module.exports = class Test extends egg.Service {} 的

@atian25 哦哦，学习了。。

综上所述，大家可以看到，我们是如何一步步渐进的去进行框架演进，得益于 Egg 强大的插件机制，代码的共建，复用和下沉，竟然可以这么的无痛。 注意：不管是应用/插件/框架，都必须编写单元测试，并尽量实现 100% 覆盖率

@dayuoba 引用的嘛，哪里的

来自酷炫的 CNodeMD

@yilikun 官网文档，渐进式开发那一章

https://eggjs.org/zh-cn/tutorials/progressive.html#写在最后

综上所述，大家可以看到，我们是如何一步步渐进的去进行框架演进，得益于 Egg 强大的插件机制，代码的共建，复用和下沉，竟然可以这么的无痛。

• 一般来说，当应用中有可能会复用到的代码时，直接放到 lib/plugin 目录去，如例子中的 egg-ua。
• 当该插件功能稳定后，即可独立出来作为一个 node module 。
• 如此以往，应用中相对复用性较强的代码都会逐渐独立为单独的插件。
• 当你的应用逐渐进化到针对某类业务场景的解决方案时，将其抽象为独立的 framework 进行发布。
• 当在新项目中抽象出的插件，下沉集成到框架后，其他项目只需要简单的重新 npm install 下就可以使用上，对整个团队的效率有极大的提升。
• 注意：不管是应用/插件/框架，都必须编写单元测试，并尽量实现 100% 覆盖率。

@atian25 了解

来自酷炫的 CNodeMD

对我学习node有点点帮助！

@zzw64205659 只是点点帮助吗…微笑

来自酷炫的 CNodeMD

喜欢就用，管他火不火

这个话题提出来半年了，现在egg社区如何呢？

不能，从npm的生态和cb/co/yield/async/await 各种风格的写法，就知道nodejs的整个生态是倾向于多样性的，就是传说中的百花齐放，npm中很多模块，就相当于传统语言的一个api 在其他语言中很难看到一个字符串leftpad做为一个package这样的情况　所以nodejs这个大环境是傾向于发散的，而象java那样ssh封装了再封装，最后拼凑成一个类似解决方案的大一统的框架在nodejs中不会出现，因为那样就失去了nodejs灵活性,而且从另一个层面带来了调试和侦错的复杂性

火不火其实关系不大, 就是习惯问题. 比如国内的 egg, thinkjs 等. 基于 koa 去实现的, 所以呢我也自己基于 koa 写了一个框架吧, 用typescript 开发, 并已上线了自己的网站 http://fm126.xyz/ 感觉也挺好的.

开发者当然希望自己使用的框架越火越好 这样框架才能不断更新维护。

赌博式学习方法

12年最火的技术是啥? 现在埋在什么地方?

不管能不能火，反正我觉得对我们公司来说是一个很值得尝试对技术。需要nodejs，把java的业务逻辑放到nodejs来做，以此解放后端。而egg我最看重的就是他的规范订的特好，一般开发人员只需要填代业务逻辑代码就好，这样就抹去了一些能力上的差距

我认为, 无论什么语言, 应该像javaEE那样的设计才正确 所以, 我自己用nodejs去模仿javaEE的设计, 底层用koa

解决问题还是根本

@151263 那nest.js适合你

我们的新项目用的就是EGG，看上的是它的规范

@Daniel1989 是的，但是建议配合ts使用，味道更佳～

@dengnan123 猛德 一笔啊楠哥

@dengnan123 赶紧出个教程耍一耍

@yilikun @dengnan123 可以看下 「当 Egg 遇到 TypeScript，收获茶叶蛋一枚」

https://cnodejs.org/topic/5ac5ecdee34737560fccaa40

@atian25 大赞！！解决痛点的好文章！

@atian25 貌似只有使用ts才能在vscode里用cmd跳转到对应的方法？

@yilikun egg-ts-helper 那个修改下，应该也能部分解决 js 版的

额。。 突然发现这个贴已经过去一年了啊。时光如梭。

@atian25 对啊！一不小心挖了个坟，那时候还在犹豫，现在已经是这番光景。。

@yilikun

2018 年 EggJS 怎么样了？对它的看法有什么变化？

这个不会是你提的吧

时光如梭么

来自酷炫的 CNodeMD

@atian25 哈哈哈 这个还真不是~小弟现在是蛋蛋的忠实拥趸，已经切身感到蛋蛋的火热了，不用提问啦

@tomgao365 是啊！

@yilikun 那就过去分享下你的使用感受吧，哈哈

@magicdawn 皮

来自酷炫的 CNodeMD

@atian25 这个可以有！先收藏，最近比较忙，闲了去喷一哈～

@151263 这个言论未免太过了吧。。发展至今每个语言都有它自己的优缺点，只能说分场景，在某个场景‘更’适合用某个语言

火不火得起来先不说，最近刚开发一个网站Awehunt就用的egg。之前用过express和koa，坦白讲，express相对陈旧，对promise等新模式支持不足，koa太简易了，几乎所有周边得一个个找或造轮子。egg刚好弥补了这两点缺憾，用起来感觉轻便，易扩展，同时官方也提了cookie/session/security等很多周边的支持。没有的自己extend/middleware一个也很快。