阿里 egg.js 香不香？

• 資深大佬 : hezhiming1993

  不香，KPI 产物，类似 weex

• 資深大佬 : wukongkong

  Nestjs 它不香吗

• 資深大佬 : XanderChen

  我想知道为啥有的帖子是这种黑了吧唧的配色。

  总感觉被盯上了。

  另外 egg.js 不香，一点都不好玩。

• 資深大佬 : lmmortal

  @XanderChen node.js 节点就这个配色 丑死了

• 資深大佬 : miniwade514

  @XanderChen node 版块就是这个配色

• 資深大佬 : Hanggi

  感觉可以放弃 egg 了，node_modules 去网上查查怎么工作的，为什么这么多东西。

  Nestjs 是正解。

• 資深大佬 : miniwade514

  你对香的定义是什么。用 egg 确实能比较快地把一个网站搭起来，用来做做内部系统还是不错的。

• 資深大佬 : ochatokori

  我不知道 nestjs 之前它是挺香的

• 資深大佬 : xabc

  辣鸡

• 資深大佬 : wy1993

  阿里的 kpi 产物太多了，当时 weex 把我前东家忽悠的一愣一愣的

• 資深大佬 : FakerLeung

  nest 感觉比它香。

• 資深大佬 : shuangya

  基本还行，至少比大部分框架好。但总感觉还是偏简单了，离 spring 差距挺大的。
  说 KPI 产物的也是够了，现在阿里集团和蚂蚁金服大部分 node 应用都是基于 egg 或者 midway(基于 egg)的。weex 也是正常的淘汰换代罢了，都那么多年了，前端技术升级换代比 weex 频繁多了，前几年阿里自己用的相当多。

• 資深大佬 : Mithril

  珍爱生命，远离阿里的 KPI 垃圾。

• 資深大佬 : Hanggi

  @shuangya 正常淘汰？前端主流技术哪个换代了，麻烦科普一下。

• 資深大佬 : dany813

  还行吧，快速搭建后台是可以的

• 資深大佬 : imydou

  http://m.sui.taobao.org/

  打不开好久了

• 資深大佬 : seakingii

  能不用就尽量不要用阿里开源的东西
  目前为止他们开源的东西没有一个能给人有好印象的
  感觉他们的公司缺少工程师的文化基因

• 資深大佬 : shuangya

  @Hanggi
  react 从 15 升级到 16，重构了底层渲染，带来了 hooks 。
  weex 内测后，vue 刚发布 2.0，现在已经发布 3.0 了。
  webpack 当时还是 2.0 版本，构建技术依然大量使用 gulp/grunt 。现在已经是 webpack 的天下了。
  SSR 相关技术在这几年内迅速发展，比如 nextjs，四年内从 2.0 发展到 9.0 。
  weex 发布同年，微信小程序发布，次年支付宝也发布小程序。
  2018 年，Google 、微软等厂商高调支持 PWA 。
  构建工具换代，框架大升级，小程序铺天盖地，SSR 从 1 到 99，这还不够天翻地覆吗？

• 資深大佬 : arfaWong

  Nestjs 真香

• 資深大佬 : JavaIO

  香吧

• 資深大佬 : int64ago

  等你们业务有阿里的复杂度时再来喷是不是 KPI 产物，一群人张口闭口 KPI，真的 KPI 是借助这个升上去就不管了，去看看 commit 历史先

  要我说 Egg 从 Node Web 研发模式上确实带来了不少提升，至于性能确实不怎么样，至于用不用需要结合很多因素综合判断的

• 資深大佬 : lpd0155

  彩蛋警告

• 資深大佬 : int64ago

  @lpd0155 #22 所以彩蛋是 KPI 吗？

• 資深大佬 : newlifeinsc

  我觉得挺好的，在 koa 的基础上扩展的，长期运行也很稳定，可以试试

• 資深大佬 : zhuweiyou

  不香

• 資深大佬 : labulaka521

  开发完了后隔段时间再给你整个彩蛋 哈哈哈哈

• 資深大佬 : Warder

  next.js 多好，typescript 默认配置好了。 想玩简单点的话就 express 吧。

• 資深大佬 : revalue

  看你拿来干什么，没前提，这样香不香讨论没意义

• 資深大佬 : Hanggi

  @shuangya 所以说，主流框架还是没变，只是更新了，没有换代。没人逼迫你用最新的。

  你看看人家 Angular，整个编译器都重写了一遍，接口兼容性几乎没变。
  react hooks 你可用可不用，而且不需要重写，老版本代码就可以一点一点改成 hooks 。
  gulp 和 grunt 依然有很多项目在用。
  你用框架打包都是人家给你写好的，你根本不需要管什么构建工具。

  你觉着 jquery 是不是已经被淘汰了，你可以去 npm 搜搜 jquery 下载量。
  Angular.js 1.x 版本，到现在还在维护，谷歌内部也有大量网站基于 1.x 。

  对老版本的兼容是开源项目的一种责任和义务。
  国内厂家各种技术宣传，然后所有人一拥而上，结果人家毁灭性升级，大家就都懵逼了。
  很多公司在技术选型的时候没有做足横向和纵向比较，没有针对自身项目和团队适合度做很好的考量。

• 資深大佬 : find456789

  kpi 不要用

• 資深大佬 : zzNucker

  我觉得 eggjs 还算比较好的框架

  和 nestjs 是两个方向

  不要无脑黑，并不是什么 KPI 垃圾

  上的要不拿个自己的东西出来我们看看是不是所谓的垃圾？

• 資深大佬 : fengxianqi

  用了一下，从开发体验上略臃肿吧，this 上挂了太多东西，约定也很多（当然这可能是卖点）

• 資深大佬 : gouflv

  thinkjs nextjs 都挺现代的

• 資深大佬 : joouis

  作为一站式解决方案还可以，进程管理、中间件集成这些没吐槽的那么差吧

• 資深大佬 : Hanggi

  其实 egg 在 v2 的时候直接上 ts 可能还有救。

• 資深大佬 : airyland

  作为基于 koa 的框架并不差，遇到阿里的开源不管 3721 喊个 kpi 产物是不是一种 PTSD 。
  没有利益关系。

• 資深大佬 : Cbdy

  可以试试 nextjs

• 資深大佬 : shuangya

  @Hanggi 你只看到了工具表面没有变。但底层早已有了巨大变革。
  weex 很不幸的就是“底层”，更不幸的是，它面临的竞争对手是“小程序”。所以它的淘汰换代也就是顺理成章的了。
  你要继续用也没问题，weex 也不是现在就不能用了。也没人强制你升级，阿里内部也有存量的 weex 应用。目前 weex 也没有完全淘汰，还在继续维护。
  你看到 jquery 下载量居高不下，但不知道你有没有看到，大厂们的新网站，有多少是基于 jq 的，又有多少是基于 react/vue/angular 的？大厂永远是决定技术的大方向的，因为开发者都要恰饭。
  四年前移动端占比，和现在比起来怎样？
  这几年前端变化已经足够大了。表面没变，但终端和底层的变化可以算是翻过一篇了。总有一些东西会成为历史的尘埃，包括你所列举到的 jq 、Angular 1 。weex 淘汰只是正常的换代罢了。

• 資深大佬 : chanchan

  阿里开源,一门生意罢了

• 資深大佬 : Hanggi

  @shuangya 所以说技术选型很重要。

  我在说的是，前端技术升级很频繁，但是只要站好队，大部分技术并没有被替代掉。

  如果你 5 年前已经开始用 React/Angular 了，到现在他们依然是最火的，不管是向前看还是向钱看。

  技术换代的理由绝不是你所谓的 Vue 2.0 刚发布，结果 Vue 3.0 出来了，学不动了，前端好乱。

  而是过去一个用 jQuery 1000 行才能写出来的功能，用 React/Angular 200 行就搞定了。
  过去用 js 写的大项目，随便修改一个地方就会有 100 个地方出 bug，改成 Typescript 以后系统稳定了很多。
  这些才是真正换代的理由。

  不要被技术牵着鼻子走，而是要驾驭它们。

• 資深大佬 : shuangya

  @Hanggi 你所说的只是理想状况，所谓的“站好队”也只能是个假设。你现在假设五年选 React/Angular，只是今天它们成为了主流。但你永远没办法确定下一个五年后，主流会是什么。今天如日中天的 React/vue，会不会在五年后也变成历史。
  技术选型当然会有一定的“前瞻性”，但这个东西只是仁者见仁智者见智，没有标准答案。更多的时候是看当下的情况。实际上，包括 weex 在内，它们的出现的，都是有一定历史背景，可以解决实际问题的。
  几年后 weex 面临淘汰，小程序却蓬勃发展，这种事情几年前谁又能想到呢？就像 jq 如日中天的时候，谁又能想到现在 react/vue 是绝对的主流呢？
  与其早早的花时间想着要“站好队”，不如及时拥抱变化。

• 資深大佬 : hhhfffhhh

  weex 带来的一些用户体验提升还是不错的，但是一些交互 /动效等的开发体验还是让人头疼。
  weex 至少在那几年是不错的选择，在历史的潮流中，也算是“完成使命”了，哦，不，应该说“后浪”推”前浪“了

• 資深大佬 : acthtml

  eggjs 不错哦，是目前的第一选择。

• 資深大佬 : Mithril

  喷阿里的 kpi 库主要是因为给人的印象太差。Antd 发过彩蛋，OceanDB 连尸体都扒了。
  确实是开源软件社区驱动，你爱用不用觉得不爽自己改。但是你作为一个发起者和主要维护者，这种态度难免让人对你发布库以后能不能正常维护下去产生怀疑。
  做面向普通消费者的终端和内部网站你加个彩蛋没问题，但是用你库的开源用户真的有精力去审查你每一个版本的变更记录吗？你用 Linux 看了每次内核升级的 Release Note 了吗？
  OceanDB 这就不说了，确实是牛逼的数据库，觉得有钱赚不继续开源也无可厚非。
  总而言之阿里做的没什么不对的，开源的几个东西也都挺好的，但就是让人不爽，且并非技术原因。反正开源产品你爱用不用，那就不用了。

• 資深大佬 : noobma

  @Mithril 大佬，ocean db 尸体都扒了是啥意思

• 資深大佬 : Mithril

  @noobma 这项目最开始是开源的，好像还是 GPL 吧。后来就不开源了，Readme 直接说后续不开源且不维护开源版本，好几年不更新了。
  最后整个库都删了，就留一个 ReadMe 带个链接。
  Github 上还能搜到其他人的 fork

• 資深大佬 : shuangya

  @Mithril Antd 那次的始作俑者内部已经处分了。人的问题确实没办法，毕竟谁也不知道平时很正常的人会不会有一些“恶趣味”。但在那之后，流程上已经有改善了，比较大的库，正式版本都会强制 review，并走发布审批流程。
  ODB 这个其实挺正常，国外也有不少软件出于各种考虑，开源改闭源，比如 redis 的周边（ Redis Graph 等）、Neo4j 之类的。

• 資深大佬 : OSF2E

  @shuangya 前端技术发展各个阶段不是独立的，就好比战斗机是在一代二代基础之上发展出三代四代五代的，每一代技术都有至少一个代表性产品，现阶段的 react 大概属于五代前端技术、理念、思想的产物，jq 属于三代，ng 处于四代……所谓“站队”，一定程度上代表了前端从业者目前对前端技术的认知所处的水平，而非简单的“粉”某个产品。

  以上言论仅代表个人见解，且篇幅有限，可能存在较大歧义。

• 資深大佬 : hurrytospring

  @shuangya ..你说这么多都升级了，而 weex 还没动，不正是证明 kpi 产物吗

• 資深大佬 : Mithril

  @shuangya 转闭源是没问题的，说的也不是这个。而是你转就转了，把原来的库还删了。
  另外你说这俩我看 Github 上还都是维护着的，估计是一些周边闭源了吧。真的完全开源转闭源的印象里还是不多的，大部分都是一些周边闭源，或者 license 限制，再不行就停止更新换个名直接闭源。毕竟一个项目等到大部分人都能接受的时候主体框架已经基本完成了，这时候再闭源你得花更多精力去添加差异功能才行。
  总而言之信任这个东西建立起来很难，毁掉却很容易。毕竟开源的东西不像你花钱买的，有合同限制，能追究责任。在自己公司的产品，甚至核心产品里面使用其他公司的开源组件本身就说明对他有足够的信任。
  国内各个厂家的开源库已经不少了，希望对这方面也能重视起来。

• 資深大佬 : shuangya

  @OSF2E 是的，比如在 React/Vue 之前就有类似 Backbone 这类 SPA 框架，就有各种 JS 模板引擎。
  但每个阶段自然而然产生的方向都是很多的，比如前端就有 Coffee Script 、Parcel 、React Native，这几年又新出现了很多方向，比如 Serverless 、小程序、Bundless 等等。
  但我认为，“站队”和认知水平没有绝对关系。这东西和股票有一些相似，虽然会有客观因素在里面，但主要还是主观意愿。哪怕同样是业界大佬，也会有不同的选择。“站队”只是代表个人比较看好某个方向。
  所以，技术人员没必要在“站队”上花太多功夫。没有人能断言自己选的方向就是正确的。所以选对没有不重要，重要的是能不能解决实际问题。过几年发现没选对怎么办？学新的就行了，毕竟技术本身也是在不断进步的。

• 資深大佬 : shuangya

  @Mithril Neo4j 从 3.6 开始，企业版闭源。Redis Graph 添加了 LICENSE，严格意义上已经不算开源软件了，也是说加就加。
  建立信任这个东西，阿里自己也是在想办法的，不然也不会弄很麻烦的审批之类的来规范发布行为。不过众人眼中的看法肯定一时间也扭转不过来。只不过希望不要戴着有色眼镜去看其他项目。

• 資深大佬 : shuangya

  @hurrytospring 我都说了，weex 出现的时候是有它的历史背景，是解决了当时的移动端 Hybird 应用性能低下、体验差的问题。
  但这几年移动端本身硬件、浏览器内核、小程序的发展，已经让 weex 的意义越来越小，被淘汰也是理所当然的问题。
  这和是不是所谓的“KPI 项目”有半毛钱关系？某个产品完成了它的历史使命，功成身退了，这不是自然而然的事情吗？这种项目大有人在，比如 zepto 、struts 等，这也能被喷成“KPI 项目”？

• 資深大佬 : littlebaozi

  吵起来了，吵起来了。出售瓜子板凳

• 資深大佬 : loy6491

  感觉是不是有人把 Next.js 和 Nest.js 弄混了

• 資深大佬 : Hanggi

  @OSF2E 先不提 jq，人家定位不同。
  React 怎么就第五代了，ng 怎么就第 4 代了？
  你的意思是 ng 再发展一段时间就变成 react 了吗？
  我觉得如果你好好用过这两个框架就不会有这种结论。

  拜托，angular 早好几年就出了仿 react 的状态管理框架了，ngxs 了解下。但是 ng 根本不需要这种状态管理好吗？

  你不会觉得 redux 是第六代吧？ redux 就是一坨屎。flutter 的状态管理了解下。

  你去想想为什么现在大家都说真香的 Nestjs 仿的是 angular 而不是 react ？细细品。。。

• 資深大佬 : nianyu

  @shuangya 啥历史背景啊解决 hybrid 性能问题当时已经有 rn 了，硬搞个 weex 出来。这也没问题然后大肆推广阿里拼命吹，然后呢？用过的没有一个不骂的。反馈的 issues 也不回复。

• 資深大佬 : nianyu

  还有这 egg 也一样，阿里系的拼命吹然后还踩 nest 一手。看看知乎的那个 i5ting 就知道了仿佛一个跳梁小丑，成天就 node egg 秒天秒地

• 資深大佬 : lblblong

  @Hanggi 因为 angular 把前端开发搞的像在写后端一样，所以当你要参考三大前端框架做一个 nodejs 的后端框架的时候，只能参考 angular，而如果你要参考三大前端框架做一个视图层框架，就参考 react 比较好，比如 flutter 就参考了 react 的设计理念

• 資深大佬 : lupkcd

  @shuangya 真能吹？ 那按你说的 RN 不是死得更快

• 資深大佬 : g0thic

  阿里很多开源项目 尤其是前端相关的都是把国外社区已有的项目拿回来改造一下适合阿里自己用 再封装一下加个企业级前缀开源推广出去

• 資深大佬 : taxiaohaohhh

  一般般香

• 資深大佬 : monkeyWie

  真的不香，什么东西都挂载在 this 上，IDE 上写起来提示也没有，代码跳转也不支持，全靠全局搜索

• 資深大佬 : liberty1900

  马云：你们在说什么，我只是个英语老师

• 資深大佬 : dany813

  老哥们火力强劲

• 資深大佬 : lancelock

  熟悉 node 可以用它来写一写前端的工具链，写后端服务就没必要用它了，有那么多更好的选择

• 資深大佬 : ShotaconXD

  有阿里两个字的都不想用

• 資深大佬 : Torpedo

  上貌似都变成阿里开源靠谱不靠谱了。有点离题啊。

• 資深大佬 : StickmY

  midway

• 資深大佬 : AmiKara

  egg 这玩意本来也就前端玩玩的吧，你用来开发个人小项目还是很舒服的，各有各的优点，没必要非要把他说死

  说 egg 是 KPI 产物也没错，人家想晋升肯定得搞点东西出来，虽然它是在 koa 的基础上封装的，但是人家文档写的也挺完善，社区也没死，各方面来讲也符合开源的标准，唯一的缺陷就是不支持 ts，但是据说在阿里内部是有基于 ts 的 node 框架的。

• 資深大佬 : dodo2012

  有人说说阿里开源的是 kpi 是一种病，这真没办法，这货前科太多

• 資深大佬 : song925

  eggjs nestjs 都还行吧

• 資深大佬 : star7th

  你们真的用过 eggjs 了吗？谈不上最好但好歹在国内还算可以吧。那个作者也挺热心的，一直在维护。说是纯 kpi 产物的你们够了。
  国内有几个好的 js 框架呢。我觉得，它虽然没到顶尖水平，但若作为一个开源项目来看，文档写得完善，很多场景也有相应解决方案，这是已经比大部分开源项目好了的。不要因为人家比不上世界顶尖水平的框架就觉得人家差。

• 資深大佬 : Mithril

  @shuangya 这就是我说的通过改变 License 限制使用来盈利。这么做的很多，包括 MongoDB 和之前的 React 。
  但不管哪家都没直接把库删掉。
  开源代码放出来就已经形成了某种意义上的公共财产，虽然说你的 License 限制了我在某些情况下不能使用它。其他人实现类似功能的时候也可以做参考。而且 License 变更之前的最后一个版本也可以 fork 出来其他人来维护个新的。
  现在的情况就是，阿里一时半会没法扭转众人眼中的形象，连带着阿里开源的其他产品一起受影响。这不是有色眼镜这么简单的问题。比如一个架构主推用 Antd 做了公司的几个大项目，被彩蛋搞到几个项目的前端全部要重写。你要去扭转他的印象是不可能的。只能靠时间来影响那些新人了。

• 資深大佬 : amundsen

  @star7th 对，我公司前端组用的就是 eggjs，比较过 koa2 和 express，只能说什么方案适合就选怎么，有些项目也不会选用 egg，用 koa2 。

• 資深大佬 : ohoh

  看你们煞有其事, 一本正经, 头头是道的将 nest.js 与 next.js 张冠李戴

• 資深大佬 : qbhy

  香！

• 資深大佬 : pockry

  用 eggjs 开发过爬虫后台，感觉还是挺香的，定时任务也不错，LS 看不起 eggjs 都开发的啥牛逼玩意啊，还是说没 ts 的都是垃圾？

• 資深大佬 : coderunI

  变成无脑喷了，真是服了

• 資深大佬 : CocaColf

  上有些还是黑过分了，Egg 的做业务还是很好用的，虽然感觉开发体验不算太好，但完全不至于是坑、是 KPI 产物，毕竟在阿里内部也承载了这么多年了。不过个人现在转用 Nest.js 了，主可以了解一下这个

• 資深大佬 : oliverchen

  nestjs 、nextjs 、nuxtjs 、nustjs……这些名字增加心智负担，选个蛋

• 資深大佬 : mywaiting

  有一说一，就 eggjs 这点代码，管它官方维护不维护，随意魔改都不是问题啊。只要我想用，我能用到天荒地老

• 資深大佬 : shuangya

  @lupkcd 1.我没说 RN 怎么样。2.事实上大厂用 RN 的也不多。
  @nianyu 1.有 RN 就不能有 weex ？什么逻辑？那有 angular 和 react 还搞个 vue 是不是很多余？ 2.当时历史背景就是纯 H5 的应用性能低、体验差，别不承认。3.没人骂的东西才是真的凉了，骂 vue 的人多不多？骂 react 的多不多？ 4.大项目的 issue 不可能 100%回复，维护者精力是有限的，你自己随便挑个知名的开源软件看看是不是几千个 open 状态的 issue，还有一堆开了很久没有回复的。

• 資深大佬 : zhengjing

  koa 中小型项目完全足够了。

• 資深大佬 : nianyu

  @shuangya 你说啥呢？谁也没说纯 h5 性能不行啊？关键有点样子的产品也没谁是纯 h5 做的。后来 fb 又出了 rn，出来多久了阿里开始搞 weex 。说别的没用我就为你几个事
  1 你说的 weex 是底层，请问哪里底层了？为什么人家 rn 还是迭代，底层架构技术都要换了
  2 为啥当时社区几千个 issues 不处理？各种 bug 也不处理
  3 主要作者走之后你看看现在几个更新？
  4 一个 kpi 产物主要作者在的时候都不响应社区反馈，为何当初一吹在吹 忽悠别人用？
  5 你说其他开源项目也有一堆 issue 没处理，出了不维护的大多数作者团队还是在处理的只是精力有限一次处理不过来，不像大 weex 压根理都不理
  6 别说为啥有 react 还有 vue，最起码人家生态是全的。一开始 weex 跟 rn 的生态就不是一个级别的，只有阿里在硬吹

• 資深大佬 : joesonw

  egg.js 对于小团队上根本不好使, 还是 nest 好用. 对于大团队呢, 人家肯定也得自己弄一弄了.

• 資深大佬 : shuangya

  @nianyu
  1.weex 主要功能是把 JS 的模板渲染成原生组件，并提供和原生交互的 API 。实际上和小程序提供的能力高度重合。这不算“底层”范畴吗？
  2.你只看到了没有处理的，看到处理了的 BUG 吗？都说了维护者精力有限，只能处理一部分。
  3.主要作者走了是因为项目已经进入维护阶段了，换句话说就是逐步淘汰了，你还希望有多少更新？你会投精力到一个“逐步淘汰”的东西上？
  4.别一天到晚把“KPI 产物”挂在嘴边，说了很多次在当时是有解决实际问题的。“不响应”是你只看到了没有被响应的，选择性忽视了响应到的。
  5.同上。
  6.说得好像 react 、vue 一出来生态就全的一样，谁家生态不是慢慢发展起来的？难道谁能东西还没做出来就把生态发展起来了？

• 資深大佬 : OSF2E

  @shuangya #51

  @Hanggi #56

  事先声明，以下内容仅代表个人见解，为方便表述使用了一些可能会存在歧义的名词或者概念。

  事先声明，一直对 vue 的创始人以及使用 vue 的技术群体充满了敬畏之情，万一说错了什么，敬请谅解。

  JQuery/Vue/React/Angular 属于基于浏览器端 DOM/BOM 接口的“交互向”或者“视觉向”的前端应用开发框架，这四者可以作比较。

  EggJS/NestJS 可以放在一起作比较，主要是在用来开发服务器端 NodeJS 环境下业务系统，统称为“数据向”的前端框架。

  Redux 只能算是针对 React 某一部分功能的加强或者扩展，同样与 JQuery/Vue/React/Angular 不是一类产品。

  如果把 JQuery/Vue/React/Angular 比作战斗机的话，egg/nestjs 就可以比作坦克，毕竟两者的战场完全不一样。

  总之，不是一类的东西放在一起比较没有意义。

  先比较 JQuery/Vue/React/Angular 四个框架之间的差异。

  每一代浏览器端前端框架都解决了至少一个核心技术难点，就好比每一代战机都会在至少一个核心技术方面有重大突破一样，可能是发动机、隐身、雷达、武器等方面中的任何一种或者多种。

  话题回到浏览器端前端框架的问题，这里说的“分代”，不是指的产品，而是指的产品背后的技术思想。

  JQuery 所代表的的三代技术思想主要解决的是垮浏览器端 DOM 接口的兼容性问题。

  Backbone 属于三代半，在 jq 的思想基础之上，实现了基于数据绑定思想的 MV*架构。

  判定四代的标准是不依赖 jq 操作 DOM （但仍然要操作 DOM，也就是所谓的虚拟 DOM ），同时实现了基于数据绑定思想的各种 MV*架构。

  发展初期的 Vue/React/Angular 站在同一起跑线上，均属于四代，但由于种种原因早已渐行渐远了。

  Vue 核心思想就是速成，快速上手、高速开发。

  Angular 在三四代技术思想之上，核心发展思想是创建规范化的前端工程开发流程，写出尽可能优秀的代码。换句话说就是开发前端应用的时候要有开发系统软件、桌面软件、服务器端业务系统一样的“硬姿势”，导致的结果就是开发工作颗粒度太细，开发效率低，学习曲线陡等问题，导致大多数开发者在潜移默化中把开发出良好用户体验的前端应用的目标调整成了写出符合 ng 标准的代码，代码质量确实提高了，但开发出来的东西用户不买账，或者开发出用户满意的东西工期太长。

  可以看出 Angular 和 Vue 在某些层面是站在绝对的对立面的。

  Angular 后续版本重点解决的是自身的性能问题，比如 ng8 引入，ng9 扶正的 Ivy 引擎，对于 API 用户来说没有思想上的改变。

  Vue 的后续版本则是类似于 IE6789 风格的升级。

  v16 之前的 react 核心技术思想是单向数据流，还有 JSX 勉强也算，redux 则不是 react 官方的东西。

  为什么说 v16+的 React 属于五代技术思想？

  v16 之后有三个很重要的东西，Fiber/Hook/Concurrent，网上有很多优秀的分析文章，这里不再赘述。

  React 把近十几年优秀的前端开发思想集成到了一起，而非通过打包工具、第三方库、语法糖、接口等方式把这些思想层面简单粗暴的堆到一起，毕竟前端开发是门手艺活儿，手艺人需要的是灵活发挥的空间，以及齐全趁手的工具。

  再就是与浏览器端 JS 开发的层叠样式设计开发、交互动画设计开发等方面的技术问题，开发流程、代码架构等思想上应该是统一的，React 实现了这一点。

  这里扩展说一下，CSS 的布局思想由 BFC 发展到 FFC 再发展到 GFC，与 React 的单向数据流思想不谋而合。

  更进一步说，UI 设计，布局设计，动画设计，交互设计，以及状态管理策略设计，应遵循单向数据流风格的开发流程，React 可以保证这一类型的开发流程的顺利递进，而 Vue/Angular 不行，它们只关心怎么写 JS/TS 代码。

• 資深大佬 : hoythan

  有一说一，非常好用，开发巨快捷，运行起来也稳定。支撑过两千万 PV 项目，没出毛病。

• 資深大佬 : hoythan

  @monkeyWie …自己不会编辑器怪人家代码不行，你可真行。

• 資深大佬 : shuangya

  @OSF2E 有一些道理。这几个框架可以拿来“分代”。但 JS 的范畴不止这些，每个方向都会有不同的划分。比如数据可视化方向的 echarts 、antv 等，图形方面的 WebGL 、WebGPU 等，引擎方面的 v8 、wasm 等，基本上各个方向都可以拿来分分。
  事实上今天的前端，已经不能是传统意义上写写界面的“前端”了。所以，既要了解技术细节，又要选择性“忽略”技术细节。

• 資深大佬 : OSF2E

  @shuangya

  对，“一把梭”的前端技术时代已经过去了，算法向、视觉向、交互向、数据向、架构向、编译器向的前端工种以及前端产品以后会划分的越来越清晰。

• 資深大佬 : nianyu

  @shuangya
  1 我不觉得搭个 bridge 就算底层了
  2 我搞个开源项目一共 1000 个反馈，我解决了 10 个也叫解决了，嗯真棒，反观其他项目 1000 个是解决不过来至少解决几百个
  3 别说逐步淘汰这种话，我都说了作者再的时候跟进都不及时，况且为啥人家 rn 为啥一而再再而三的推翻之前架构不断重构？
  4 同上
  5 同上
  6 因为 weex 一开始就没打算好好弄什么生态，干完一票就走人

• 資深大佬 : shuangya

  @nianyu
  1.按这个说法，React 的 Fiber 连 bridge 都算不上，那算是什么？底层的概念都是相对的。
  2.麻烦你拿数据说话，有多少反馈，其中多少是有效的，多少是作者处理了的，多少是没有处理的。别一天到晚阴阳怪气。
  3.FB 觉得 RN 没有到淘汰的时候，继续迭代有啥问题？阿里觉得 weex 到了淘汰的时候，停止更新又有啥问题？你咋不说 Linux 还在一直更新微软就放弃 XP 了呢？说得好像是个产品就一直有价值，就不能放弃一样。
  6.怀着最大的恶意揣测别人也是够了，谁不希望自己的产品能有良好的生态，能够一直持续下去？如果 vue 今天没有做起来，相信你也会去踩一脚“因为它一开始就打算干一票走人”

• 資深大佬 : thonatos

  但凡阿里相关都要扯上 KPI，框架都技术升级了，咱就不能升级一下喷点？

• 資深大佬 : nianyu

  @shuangya 你觉得算底层就算呗，反正我不觉得这玩意是啥底层。就算 rn 没出来之前都有好几个类似的东西，而你上来张口闭口这玩意是底层 使命完成了自然淘汰。闭口不提完成了啥子使命？最火的时候要生态没生态 除了阿里内部其他公司有几个用的？跟 vue 是一回事？阿里吹真快把我逗死了。兄弟这玩意最火的时候都没建立起什么生态，他完成了啥子历史使命呢？ 能不能告诉我？ 别说什么纯 h5 性能差了？我上面都说了根本没几个纯 h5 的应用，很多功能都做不了还纯 h5 个屁啊。rn 出来之前都有 condava dcloud 出品的那个。后来 rn 出了。然后阿里就搞出个 weex，解决了啥啊？你告诉我呗。性能 生态被完爆。他咋就完成历史使命了呢？ 搞出个没人用的东西然后不维护了 美名其曰完成了历史生命 哈哈

• 資深大佬 : Hanggi

  @OSF2E 哈？你在说什么？你确定三种框架都用过吗？

  别的不说了，总之，这年头千万不要说其他框架不行

• 資深大佬 : shuangya

  @nianyu 别把无知当无谓。
  当时的历史背景就是纯 H5 性能差。数据统计，淘宝的大促页面，weex 比纯 H5 平均渲染时间少了三分之一，这就是它的功劳。现在因为硬件和内核的发展，加上统一的小程序引擎，weex 的存在必要性大减，这就是“完成了当时的设计使命”。
  Weex 的 UI 框架有 EEUI，并且兼容传统的 CSS 。开发框架有 Vue 、Rax，有图表库，有地图库，有原生 API 封装库。后续进入 Apache 孵化。这就是你所说的“没有生态”？
  另外你把 RN 和 Weex 类比还可以，至少他们原理类似。但你把 Condava 拿出来对比就只是在彰显你的无知了。
  别一副理所当然“我不知道就是没有”的样子。还是那句话，别把无知当无谓，自己不知道开口就喷。

• 資深大佬 : hezhiming1993

  上吵死了

• 資深大佬 : hezhiming1993

  翻页搞起