求大神分析一波~~
老实说，火不火其实关系不大，没必要太纠结。
搬运下之前在 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 解决了这个问题」
我给团队的最终选型是 egg，至于火不火我不知道，只说说我为什么选它
- 他是基于 koa 的，koa 是一定要选择的，只因为 async/await 。egg 是对 koa 的包装，即时你的团队是用 koa 的，但是不可避免的要自己包装一层，所以有现成的并且很优秀为什么不用？
- egg 的作者们都是大牛，给 node 和 koa 都贡献过代码，所以我相信他们，或者看 egg 源代码，如果你能力可以，那么你应该能看出来 egg 写的比其他一些什么框架代码质量/可维护性/可读性都高出很多
- 测试做的非常棒，据我所知没有几个国内开源项目有这么高的覆盖率
- 扩展度也很高，很多功能以插件方式提供的，所以正如 egg 官网说的一样，你可以基于 egg 搭建一套适合企业业务的基础框架出来
- 更适合企业团队开发使用，他有一些约束和规则
- 暂时想到这么多，其实还有一些原因的
顺便说说我理解的使用 egg 的正确方式
- 建议企业级团队使用，个人弄个小项目的话我觉得用什么都没多大区别
- 要根据自己企业业务在 egg 之上再包一层，最终会变成 “kao --> egg --> 你的企业框架 --> 业务代码” 这个层级关系
- 跟 egg 无关，企业团队项目最好用 ts，假如你希望你的项目变成“大”项目“长”项目的话
@rwing async/await和koa没啥关系吧。。。koa2虽然开始大规模并且推荐async/await但是你express想用async/await就不能用了？
@artisan 能用是用，但是你会发现各种别扭啊，这就好像，你想用v12的发动机，那么底盘/车身/轮毂都要配套才能把发动机发挥到极致，你不能随意搭配个夏利的车身是不是？
个人觉得这种纯开发规范、插件级别的封装，对于公司可能很有用的东西，开源社区可能并不会很感冒。。远不如一个基于 ts/flow 的支持 静态类型的 框架关注度大。。比如 typeorm 之前我看才几百 star，如今已经2k+了。。也许你会说 egg更多，但是 egg 是在有大公司做推广的，typeorm 则基本是社区的产物，star 质量也不一样。。
@zaaack 指的是 module.exports = app => class Test extends app.Service {} ? 有支持 module.exports = class Test extends egg.Service {} 的
综上所述，大家可以看到，我们是如何一步步渐进的去进行框架演进，得益于 Egg 强大的插件机制，代码的共建，复用和下沉，竟然可以这么的无痛。 注意：不管是应用/插件/框架，都必须编写单元测试，并尽量实现 100% 覆盖率
@yilikun 官网文档，渐进式开发那一章
https://eggjs.org/zh-cn/tutorials/progressive.html#写在最后
综上所述，大家可以看到，我们是如何一步步渐进的去进行框架演进，得益于 Egg 强大的插件机制，代码的共建，复用和下沉，竟然可以这么的无痛。
- 一般来说，当应用中有可能会复用到的代码时，直接放到 lib/plugin 目录去，如例子中的 egg-ua。
- 当该插件功能稳定后，即可独立出来作为一个 node module 。
- 如此以往，应用中相对复用性较强的代码都会逐渐独立为单独的插件。
- 当你的应用逐渐进化到针对某类业务场景的解决方案时，将其抽象为独立的 framework 进行发布。
- 当在新项目中抽象出的插件，下沉集成到框架后，其他项目只需要简单的重新 npm install 下就可以使用上，对整个团队的效率有极大的提升。
- 注意：不管是应用/插件/框架，都必须编写单元测试，并尽量实现 100% 覆盖率。
不能，从npm的生态和cb/co/yield/async/await 各种风格的写法，就知道nodejs的整个生态是倾向于多样性的，就是传说中的百花齐放，npm中很多模块，就相当于传统语言的一个api 在其他语言中很难看到一个字符串leftpad做为一个package这样的情况 所以nodejs这个大环境是傾向于发散的，而象java那样ssh封装了再封装，最后拼凑成一个类似解决方案的大一统的框架在nodejs中不会出现，因为那样就失去了nodejs灵活性,而且从另一个层面带来了调试和侦错的复杂性
火不火其实关系不大, 就是习惯问题. 比如国内的 egg, thinkjs 等. 基于 koa 去实现的, 所以呢我也自己基于 koa 写了一个框架吧, 用typescript 开发, 并已上线了自己的网站 http://fm126.xyz/ 感觉也挺好的.
不管能不能火，反正我觉得对我们公司来说是一个很值得尝试对技术。需要nodejs，把java的业务逻辑放到nodejs来做，以此解放后端。而egg我最看重的就是他的规范订的特好，一般开发人员只需要填代业务逻辑代码就好，这样就抹去了一些能力上的差距
@yilikun @dengnan123 可以看下 「当 Egg 遇到 TypeScript，收获茶叶蛋一枚」
