1.压缩体积，减小带宽。
2.混淆代码，一定程度上防止破解。
3.可运行，比如 JSX/Vue 的语法一般是不能或者不推荐直接运行的。
4.兼容性，打包的时候会进行一些向下兼容，比如 async 、const 之类的会转成低版本浏览器兼容的语法。

只能说具体情况具体分析了，没有最好的，只有最合适的。
举个例子，语雀就是一个庞大的 nodejs 的应用，所以 nodejs 实际上也可以写大型应用，并且相应的架构、团队合作也有比较成熟的方案（例如蚂蚁金服开源的 eggjs ）
语雀面临快速的迭代，并且目前为止，因为良好的基础设施，没有明显的性能瓶颈，所以 nodejs 是语雀目前为止最合适的选择。
后续会不会换成 Java ？这个还真不好说。可能有一天 node 成了语雀的性能瓶颈后会换吧。
相应的，你可以评估一下，你们团队的现状是什么样的，转投其他语言成本有多大，能带来什么（不止是技术上的，还要考虑到，业务能不能不耽误，总不能说因为你们要重构就一两个月不更新新功能吧）
另外不推荐不熟悉的语言，包括 Go 、PHP 、.NET 。也不推荐动不动就搞什么微服务啥的。不是他们不好，是因为你们团队没人足够熟悉，贸然换上它们会踩很多坑，而且很可能会出现各种“疑难杂症”，带来的收益也不一定会有想象中大。

@CRH 如果是这样的话，强制更新也是可行的，但是还是要考虑回滚、更新失败的降级措施（至少保证旧版本可以用）
总的来说，在服务端进行灰度比较可控一些，如果是推送到端上再发现问题，回滚起来很麻烦（比方说你们推送了一个新版本，白天开始用之后才发现后端的新代码没考虑到一些 case，这个时候靠强制推送来回滚比较麻烦）

@roth 绿码就是公安部推送的，这个是项目组的人亲自说的，至于会不会是披着公安部的皮那我们就不知道了

@roth 规则是上面定的还是公安部自己定的，有没有和其他部委联合，规则是不是公开的，那我们也不知道，毕竟 zf 自己也是有保密信息的。我知道的是，支付宝的绿码数据是公安部推送的，和支付宝没有半毛钱关系。
不要小看公安部，公安部是有自己的大数据系统的，做这个系统难度不大。
健康码系统肯定会有你最近的行踪，但详细到什么程度只有核心人员知道。哪怕是公安部自己，正常情况下一般人也是看不到具体数据的。至于让基层拉网排查，我觉得只是没必要动用太多数据，毕竟是个小事，层层审批很麻烦的，除非这个红码人员是逃犯……

举个例子，为什么说强制更新尽量少用。
你们的客户公司，老板正在出差，网络状况不太好。这个时候，他需要审核一点资料啥的。然后他点开了 App，很不巧，他被灰度到了，如果不更新就不能使用。然而他的网络情况让他下了好几遍新版本也没有下载成功。
很显然，他不一定要新版才能完成的工作，却因为强制升级而不能完成了。
对于 to B 来说，需要更多考虑用户体验，而不需要额外的营销手段留住客户。所以需要尽可能考虑 B 端客户的各种情况，能让客户正常使用是最重要的。
比如弱网，异地 /跨国漫游……这类 to C 产品不用太关心的因素。

首先，虽然说有强制升级 App 的能力，但这个给用户的体验太差了，没有必要还是不要使用最好。
楼主的方式改造是可行的，但是需要考虑一些问题，一是强制升级体验会很差，二是如果不强制升级，就有维护多个版本的成本。
说说我们的大概做法：如果接口更改是向下兼容的，只是加了一些字段什么的，一般不会改 URL 。因为迭代频繁的时候，每次都改 URL 成本太高。这种情况下，一般是正式一批服务器，灰度一批服务器，根据特定条件(比如 ID 范围、按所属企业啥的)，统一代理把它转发到正式 /灰度服务器。如果出现问题，只需要把转发重新改回线上就可以快速回滚。
如果是不向下兼容的，那一般会发布为一个新的接口，可以加上版本标志什么的。这个时候灰度其实就不需要后端做什么了，只需要客户端分批升级就行。

我想纠正一些东西：
1.首先，你是绿码还是红码，和支付宝半毛钱关系都没有，这个数据来源于公安部的系统。所以，具体用了什么数据，算法是啥样的，都是公安部自己的系统决定。
2.为什么是一个二维码，而不是其他东西：因为二维码是唯一一个可以低成本、快速铺开、有一定信息承载能力的形式。换成其他形式，比如纯文字是不能承载更多信息的，比如直接绑定身份证，那么没办法给所有小区、商店都配备设备。
3.显示码的时候会不会上传你的位置信息？你觉得公安部会没有你的手机信号定位吗……哪还需要这个？
4.为什么微信需要每次验证，支付宝不需要？因为是阿里做的，只打通了阿里的免登体系。你在微信里使用，其实也是阿里的服务，并不代表你用微信就不会存储你的信息。
5.为什么有些地方会单独出个 App ？这个和支付宝就没啥关系了，地方 zf 想这样玩，支付宝能怎么办？

其实这些都不是重点。
重点是开多少钱。

@assassin1993zj 特地上来给你点赞

@xuyuheng0905 钉钉移动端是 Native 实现核心功能，C++底层库（大部分代码是写了两遍的……）很多非核心功能都是小程序形式接入的

@xuyuheng0905 钉钉用的是 CEF……底层逻辑是两套……UI 是混合 Native 和 H5 的……

Go 不确定，和 Java 分庭抗礼短期内不太可能。另外 Go 面临的竞争对手不少，Go 本身也还不错，所以未来不好说。
Python+，算法还在发展，Python 是钦点的，没办法。
Node++，“大前端”是大趋势，没啥可选的。
另外 Java 目前当然是绝对的霸主。容器化等技术虽然尽可能做到底层不敏感、抹平差距，但是生态和技术积累是没那么容易建立起来的。
设计好的语言多了去了，为什么最后留下的是整天被人吐槽的 PHP、JS、Java ？语言设计的再好没有用，需要看它能不能解决实际问题。

@zaqzhin 我没觉得“白嫖教育”有什么问题啊？这也能杠？

@zaqzhin 你哪里看到我说白嫖怎样了？中性词是可以有褒义用法，也可以有贬义用法的，具体要看语境，这种知识小学老师没教？你举一个反例有什么用？并不能改变“白嫖”本身是中性词的属性。

还是分情况吧
[小型项目]
你爱用什么都可以。
[大型项目]
不知道楼上各位公司体量和 Slack、Dropbox、Alibaba 等公司比起来怎么样？
是大厂招不到能 hold 住 C++跨平台、能“把握框架与方向”的人吗？
是大厂只能招到对 C++“一知半解”的人吗？
是大厂觉得钱多了，放弃掉“成本更低”的跨平台方案，选择“成本更高”的原生方案吗？
目前大厂中最多的情况依然是：上层 UI 用原生或者 JS 跨平台实现，底层每个平台一套代码。这套代码可以是 C++，但一般不会是一套代码全平台共享。
为什么？ C++跨平台初期可以让团队尝到“甜头”。但是项目一旦慢慢变大，随着业务扩张、底层深入、人员变动，“跨平台”的代码也会逐渐变得越来越难维护。

@ismedone 你自己去查百科，里面根本没有提白嫖是褒义还是贬义，非要拿自己的理解强加到词语本身身上。我现在说“大千世界无奇不有”，你说我这句话是褒义还是贬义呢？那“无奇不有”词语本身是褒义还是贬义呢？