@nianyu
1.别张口闭口就是 RN 完爆 weex，请你拿出当年的测试数据，拿出集成难度、调试等等方面的对比。当年云栖社区是有完整对比的。不要像一个泼妇一样，凭着自己的 YY 骂街。
2.文章里面还说了盛大游戏的代练业务。你是眼瞎看不到，还是为了喷假装看不到？
3.“一开始就没人用”，上面的 103 楼解释过了，那只是你见识短浅或者为了喷故意忽略事实。
4.那你能不能解释一下微软为什么要放弃 XP，Linux 还在维护旧系统？阿里觉得没用的东西 FB 不一定这样觉得，反之亦然。麻烦你提出问题前过一下脑子。
5.故意选择性忽略事实，为喷而喷，呵呵

@nianyu
1.weex 的核心一直都是渲染优化。你一直拿原生 API 来对比不是彰显你的无知是啥？
2.除了阿里系，盛大、百度、众安、电信等公司都有使用，部分公司在网上还能搜索到相关的分享文章。你没听说过只能说明你见识短浅或者为了喷故意忽略，不代表别人没用。举个例子，盛大的分享文章： http://www.uml.org.cn/AJAX/201901112.asp
3.说了很多次了 weex 核心就是跨平台应用的性能优化。你自己给它强加额外的“使命”有啥意义？

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

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

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

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

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

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

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

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

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

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

fastjson 的漏洞很多都是历史原因，一直修修补补。
摆脱历史包袱的方案是把安全模式开上。
gson，jackson 啥的漏洞一样也多。
所以其实大家都差不多，及时更新，然后哪个顺手就用哪个吧。

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

@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，这还不够天翻地覆吗？

一般不需要，除非有很重要的保密信息。不过有这种信息的一般也不会是谁都能看到的，本身的传播源就是可控的。
至于抓包，那是没办法的事，用户本地抓包、反编译，你也不好管控。
防范中间人攻击，那只要用户本身系统没有问题，你们服务器也没有问题，那就不存在问题。
如果真的有很特别的需求，那你自己再加一层简单的加密也行，但不要报太大希望，这个只能是增加破解成本罢了。
总的来说，如果没有特别需要，没必要。

灰度更新啊，根据硬件标识，一次推送一部分，一部分验证没有大问题了，再推送下一批，慢慢全量。
对用户来说就是玄学。
但对微软来说，这只是一个可控的更新推送过程。

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