@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 频繁多了，前几年阿里自己用的相当多。

@panzhc 握爪，x 壳现在连网站访问都是白名单过滤了

公司一般也不在意那点空间……
实在在意的话，只有在某个地方记一下，然后定期清理……

是否商业化，和“企业级”没有什么关系。
“企业级”只是描述这个框架经过了大量企业真实业务验证的，是有能力解决大型企业、复杂业务问题的，而不代表一定会有商业化的成分。
商业支持完善，那叫商用框架，不叫企业级框架。
就像同样是企业软件，既有免费的，也有商业化的。
“商业化”和“企业级”没有必然关系。“企业级”也可以是非商业化的，比如 Apache 的很多开源项目都可以称为“企业级”。商业化的也不一定都是企业级的。

接上文，“企业级”的框架，应该是这类经过了复杂业务验证的框架。相比起直接用各类零零碎碎的东西，它能带来优点：
1.规范化和一致性。这类框架一定是自己企业内部经过了一段时间实践的，会在各方面进行一些规范约束，团队协作体验会比较好。
2.开箱即用能力。将一些更底层的内容，诸如怎么连 XXX 、怎么在其他模块中使用等常见的东西，都做了一定程度上的封装。这样一来使用方便，二来一定会有一些最佳实践在里面，性能和稳定性都有一定保障。
3.可扩展性。在有规范约束的情况下保持可扩展性，这个是不太好实践的。一定是经过大量业务验证，不断迭代才会有的。
4.稳定和性能，虽然经过了包装，跑跑 benchmark 啥的性能一般会比拆开用差，但实际业务的表现就不好说了。即使差一些，也是在可接受范围内的。