仓颉还是个饼，不是说立马接入，我只是感觉 Cocos 即使要再选一种语言也更可能选仓颉，毕竟和华为有挺多合作，我看之前仓库也有在对 eTS 做兼容优化。
当然，不聊爹，聊仓颉本身，我觉得也挺优秀的。
1赞
Haxe有很多公司资金支持，你可以在官网看到，而且已经运行很多年了，并且死亡细胞就是用Haxe语言写的
1赞
wasm 还是保持观望比较好， 君不见微软/谷歌/苹果没对wasm有多上心， 试想想现都没有wasm内直调i/o 的方法， 都是需要胶水代码。相反再看看像v8这种在jit下， 跑起来性能更虐wasm.
1赞
是C++阿，Haxe直接编译为C++，这就是我说的方向，直接引用引擎代码。至于为什么不直接用C++我上面已经说过了
WASI 在做了在做了。
v8 运行 WASM 也是会 JIT 的，本来就是同一个编译管道：WebAssembly compilation pipeline · V8
这类兼容、性能问题都能通过迭代解决，不用担心，主要是看技术原理上是否有阻碍。
还好啦，当然比不上对他们自己的系统上心，他们应该恨不得直接废除浏览器，但现在不也还好吗。
Make Web3 great again!
1赞
而且还有一点，C++比WASM快，引用panda的话
1赞
WASI 就那社区体量以及那佚代速度， 我想webgpu全面普及ta都未成熟。
至于V8, 怎麽想都是只会把资源投放在提升JS方面，因为js的社群实在太大.
1赞
这是肯定的，现在基本上都是预估 WASM 技术迭代到最后，性能大概会比原生慢 1.5 倍左右。
但我们说的不是业务代码吗，Cocos 引擎还是应该用原生性能的语言编写，只在 Web 平台上转至 WASM 运行，业务代码达到比原生慢 1.5x 已经够够的了吧，多少大型游戏还在 Lua 和蓝图。
我说的一直是先支持 WASM，这样就可以先解放用什么编程语言，你觉得 Haxe、Rust、C# 好，无所谓都可以，虽然性能不如直接编译成 C++，但你至少在使用方面没问题，这样看看人们自然而然会选择什么编程语言，针对更多人使用的语言做内置支持（像 JS）不就可以了吗？
1赞
我觉得以语言转语言这种风险实在太大， 比如转C++， 如果是转出来的C++有问题， 你还是从C++层处理。最致命性的问题是， 你在开发模式上用Haxe上跑得好好的， 打包成C++后不成， 那在项目进度上就多了一层延期风险。现在cc原生就有这様的情况， 开发模式下你在浏览器上跑， 一切没问题， 去到原生出问题了又要废劲排查。
这里真不得不佩服godot， 一个游戏引擎有多种语言版本， 这老外社区真玩得贼6
1赞
那只是轻中度的业务层，一深入涉及到网格，寻路，光照这些是不够用的。这就把上限锁死了
你的提议是所有平台用 WASM，而我的提议是原生用C++或者C#或Lua，而Web端可以用WASM及JS，而唯一支持我提议的只有Haxe能实现
并且使用我的提议能获得更大的性能提升，更小的过渡代价
1赞
所以这就是引擎应该做的事，而不是开发者，这就是我的提议，我虽然想尝试但是我认为赚钱比这个更重要
1赞
多语言支持我感觉短期是优势长期是劣势，看起来很美好满足所有人的喜好最终只会造成生态的分裂，Cocos2dx就是教训曾经也是支持c++ lua js Python等作为开发语言最后结果就是各自为战社区分裂了
2赞
问题是 WASM 是 JS 引擎的特性之一呀，支持它很简单而且是理所当然的，对于 Cocos 引擎来说，支持 WASM 就像支持 JS 的语法一样，其实不需要做太多的事情。
这 Web 规范都是他们制定的，如果谷歌不想做，那么就连规范都不会给通过，就像现在 JS 语言的提案受到浏览器厂商牵制很大，但是只要制定下来了就是会实现的。
1赞
所以需要一种万金油语言，Haxe满足了所有条件，一种语言可编译为多个语言
1赞
wasm可以说是大厂这几年的关注核心之一
比如去看看v8这两年的更新点，语法和v8本身特性升级非常有限，甚至他们自己都不想写新版本的Release Doc，但对于wasm，v8的支持非常活跃。
可以看到的是：比起以往在指针压缩字节码解释器上做大刀阔斧改革，v8团队已经找不到明确JS的更优解决方案，其重点已经放在wasm上，为什么是wasm？
因为自家flutter-web已经从canvas机制转向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赞