Well, the reason why we are looking for replacing NaCl with Wasm is pure pragmatism. We don't have the resources to maintain something like NaCl or Wasm ourselves. It happened that the market basically shifted from NaCl to Wasm, so sticking to NaCl is just making us alone, or so.
The latest distributable NaCl SDK is from 2016, 2017 for what was the non-stable one. Even the tools to download them requires patches to not fail at downloading them today. Those SDK even require Python2 which is deprecated since years and we recently had to port that part of the distributable NaCl SDK ourselves to remove the build dependency on deprecated Python2.
This distributable SDK only provides support for running nexe on 32-bit and 64-bit x86, and 32-bit arm and 32-bit mips. The way we currently run our game on arm64 on Linux is very hacky by running a 64-bit engine with a 32-bit nexe gamecode (with 32-bit NaCl runner), maybe the same hack can be done on Windows arm64 (I don't know), but there is no hope for doing that on arm64 on macOS (so, no native M1 support).
I know there is some NaCl stuff that is still maintained as part of Google Chrome browser. I seen the Linux Chrome/Chromium browser still ships some updated NaCl runner. I looked at them to see if we could borrow newer NaCl stuff from Chrome instead of using the now deprecated old distributable releases. I have seen Google had ported NaCl to arm64… but I also seen that Google removed NaCl support from macOS build of Chrome, so that terminated my hope for native Apple M1 build. So maybe I missed some download, but the only recent builds of recent NaCl runner I found in Chrome/Chromium downloads was in x86 builds.
I personally don't mind about using NaCl or Wasm, but we need to have someone else maintaining the stack we use. I sometime tell people to better not fork game engines as maintaining a game engine quickly turns into a full time job, and I know it because we actually maintain our own game engine. The same would happen for a virtual machine and a compiler, so I'm afraid maintaining NaCl would just adds us yet another fulltime job, something we cannot sustain.
If NaCl gets new interest from other parties, gets updated and maintained and ported to newer architectures, we may continue to use NaCl as porting to a newer version of NaCl would be a smaller effort than porting from NaCl to Wasm, but we don't have the resources to maintain NaCl ourselves…
Right now we are already facing some limitations with NaCl being aged, if I'm right we are currently stuck on some old version of our GUI library (RmlUi) because newer version requires a newer C++ standard that is not implemented in the distributable NaCl SDK we use. This issue is very ironic because we switched from Q3VM to NaCl to not be held back by a virtual machine technology that only supported its own very old compiler and very old C standard.
If I'm right slipher said once that on some topics the design of NaCl was superior to Wasm one.
It's even possible that NaCl would not only be faster but also that the sandbox model is better…
But in the end, it happens that Wasm won, very likely because of all the web traction out there.
What we would like to see from NaCl, Wasm or any competitor :
- Compiler supporting recent C++
- Multithreading
- Recent architectures (like arm64 on Linux and macOS)
A plus would be to only have a single binary for all the architectures, or at least, only one per bitness. Right now we have to link and distribute amd64, i386 and armhf nexe because we never found resources to implement pexe translation in game (if it's doable to begin with).
Another plus would be to be able to produce executables from any platform. With the NaCl SDK we currently use we can only produce armhf nexe from amd64 host (maybe it also works from i686 host), so one cannot build an arm NaCl game from an arm machine.
Another interesting solution I recently seen may be Blink (not the web engine). It's a stripped down emulator that just runs amd64 static binaries everywhere. With blink, one may just have to produce one static linux amd64 build for every platform. But this is clearly aimed for portability, not for “Near Native Performance”.