wasm可以说是大厂这几年的关注核心之一
比如去看看v8这两年的更新点，语法和v8本身特性升级非常有限，甚至他们自己都不想写新版本的Release Doc，但对于wasm，v8的支持非常活跃。
可以看到的是：比起以往在指针压缩字节码解释器上做大刀阔斧改革，v8团队已经找不到明确JS的更优解决方案，其重点已经放在wasm上，为什么是wasm？
因为自家flutter-web已经从canvas机制转向wasm。
可以看到的是：比起以往在指针压缩字节码解释器上做大刀阔斧改革，v8团队已经找不到明确JS的更优解决方案，其重点已经放在wasm上，为什么是wasm？
2赞
我没提议所有平台用 WASM，我的提议是先完善 WASM 支持，这本来就算是 JS 的特性之一，这相比增加另一门语言简单太多。
1赞
审核重新发下……就算优先实现WASM仍然不能解决IOS的性能问题，但是接入Haxe可以
1赞
UEditor编辑然后通过解析YAML文件可以导出到任何引擎,我2018上架过一个游戏就是直接在U3DEditor制作然后cocos2dx发布验证了其可行性
1赞
如果说你要解决物理系统等这些模块在 IOS 上的性能问题，接入 C++ 的物理系统实现不就可以了吗？
不必大动干戈接入另一门语言呀，毕竟现成的物理系统都是 C++ 写的。
如果说要解决业务代码在 IOS 上的性能问题，单纯接入 Haxe 貌似解决不了，首先 Haxe 不能转为 JS 来使用，否则依然没法 JIT，那么假设转成和引擎一样的 C++ 吧。
但引擎并不支持 C++ 写业务，那么就是说需要实现一遍 C++ 业务接口。
Haxe 只是支持转为各种语言，而不是支持与各语言交互吧？实际上也就是说等于引擎支持了用 C++ 写业务，还要额外再支持 Haxe 语言写业务。
那么排除有多少人会更喜欢直接写 C++，而不是使用一门新语言。
这个工作量等于是支持 C++ 再支持 Haxe，那和直接接入游戏行业里最热门的语言 C# 相比有啥优势吗？
还是需要大刀阔斧呀。
1赞
有什么优势？你可以问问为什么还有原生项目选择2dx-lua，或者更多的选择unity
1赞
支持了 Haxe 和 引擎 WASM，那么后期就可以抛弃 JS，更方便引擎维护，而不是现在的TS一套+cpp半成品一套，暂不知道WASM在热更方面做的怎么样。所以只剩C++还有待商榷
另外 Haxe 的优势我已经说了
-
可以从当前阶段缓慢过渡（编译为 JS）
-
学习成本，只需要学习一种语言
-
更方便接入引擎的 C++ 层（编译为 C++）
-
方便引擎后续扩展（编译为其他类型语言）
-
服务器和客户端可以使用同一套代码
-
语言带来的性能优势
总的来说，在原生端引擎就只能用 C++，那么不像现在这样使用胶水代码连接 TS，就只能选择一个和 C++引擎直接连接的用户层语言。C#没有C++连接C++方便吧？C#也不能从当前阶段直接过渡吧？然后只用于游戏C#或许够了，但是对于自身的发展，Haxe无疑可以做更多事，例如写网页，写安卓原生层代码（IOS不知道），C#能做到这些吗？
1赞
看大佬讨论看得我热血沸腾，好多不知道的东西，哈哈哈哈 
1赞
这个观点已经纯粹是站在你自己的角度了。
引擎选型不应该考虑全不全能这些，而且 C# 确实能做到这种所谓全能开发，包括 JS 不谈性能套 WebView 其实也能做到。
但这种全能其实都有很大牺牲，包括看了下 Haxe 的文档我觉得也是差不多，这种只是理想很美好，生态和哪怕很微小的语言差异会给你重重一击。
无论咋样，我觉得真考虑自身发展，那还是把语言变成工具，在什么平台上开发，就要会这个平台的官方语言或者热门语言，不要想着一个语言一把梭，能做到这个的语言我觉得有生之年可能都看不见。
接入 Haxe 也不存在什么缓慢过度阶段呀，如果编译为 JS，那么这个阶段我们除了学会了一门新语言，还得到了什么？
只有在可以转为 C++ 的那一刻，我们才终于得到了一些原生端的性能提升。
1赞
我想到还有一个难搞的问题， 若果真用Haxe去生成C++或js， 监控报错告诉你是C++或js 哪里出错了， 你还要把ta倒推回到底是Haxe里哪段代码出错了
1赞
缓慢过渡就是先转换语言，引擎可以后面实现编译C++，而不是直接从JS换成另外一门语言。
然后转C++和C#的选择无疑是C++引用C++更方便。那么为什么不选 Haxe？而是C#？然后原生还要去学 JAVA和Object-C。而学习 Haxe 后可以直接写安卓工程。C#可以吗？
1赞
转成 C++，和能与已有 C++ 代码像双胞胎一样交互是两码事…
这种情况包括 Haxe 能转成的任何语言。
看看两者互调是否是你想象的那么丝滑：
- haxe call cpp: Use a Cpp function in my Haxe Code - #3 by dmitryhryppa - haxe-cpp - Haxe Community
- cpp call haxe: https://stackoverflow.com/questions/72452935/calling-haxe-code-from-cpp-java-or-net
依然需要各种 @native 宏等等手段，要担心类型内存布局等等。
如果这就是你想象的丝滑，那么 C#、Rust 也一样的丝滑。
1赞
这种问题应该不用担心，有 SourceMap 去解决，比如 TS to JS。
1赞
怎么感觉越说越像在搞unity了
1赞
我回去看看，暂没时间
1赞
这是在 haxe 使用 cpp 的方法，和 C# 基本类似，都需要声明接口
https://github.com/cambiata/haxe-cpp-basic-example
而使用 haxe 可以编译为 C++，也可以编译为 C#，为什么还要选择 C# 呢？锁死发展上限？
另外你说的内存布局是 C++ 调用 haxe，那么什么情况下引擎会引用用户代码？完全没有可能吧，调用用户代码的地方只会发生在传递事件回调这些时候，而回调内则是 haxe 编译后的代码，是由 haxe 管理，所以你说的内存布局问题也不会发生
1赞
难得有坚持原生注重性能的，当前政策不好，小游戏当道。如果这个语言能把js转c++，那就能优化cocos的原生性能。不过我简单看现在的3.8x引擎代码，很多c++，在编译到android或oc的时候，会转成c++，至于刚体或某些模块，底层不清楚也说不了看法。支持楼主！
1赞
这个语言是把自己编译为多个语言的代码，包括字节码，它自己也有几个现成的小众游戏引擎（没编辑器），已经算比较成熟的语言了，唯一的缺点是入门较难（之前自己用过），关键字及语法这些比较简单，但是有很多其他东西，但可以渐进式学习
1赞
看新闻最近广东对版号有一定放宽，备案后可以上线测试，但其实还是版号垄断的局面，广东又有这么多垄断大厂，具体是不是大厂之间的博弈咱说不好。不过看b站的评论，舆论导向是“孩子饿死了知道喂奶了”，有少部分玩家是觉醒了的。对于当前局面，只有版号放宽才能让咱们真正的做个人，能被当人看。
1赞
我喜欢 Haxe 的语法，这点我们应该一致，但其它方面我并不打算去说服你，我只是越深入了解，越发现它与其它现代化的语言没有什么优势。
1赞