WebAssembly / HTML5 target

[bram-dingelstad]

One of the last things missing is a WebAssembly target. For this we need to switch away from LuaJIT (atleast of that platform) because the project having no intention to compile to WebAssembly

Some things we need to do:

• Find a proper LuaJIT FFI replacement for Lua 5.1+ that compiles to WebAssembly

[gilzoide]

Hi! Yeah, being able to target HTML5 / WebAssembly would be very nice indeed.

Well, there are some FFI libraries for Lua, like cffi-lua and luaffi, but I don't know if they can be built for WebAssembly right now. Definitely needs further investigation.

Another possibility would be to implement the plugin in Lua/C, but that would take a lot of work. That's exactly where the FFI shines, interacting with native code directly from Lua.

[IntangibleMatter]

I know it's probably more than a bit slower but doesn't Lua compile to wasm? If nothing else this does (even though it's a bit old), and maybe we could just use that for targeting web? Might complicate things but it might make it faster to setup wasm.

[gilzoide]

@IntangibleMatter It's less about compiling Lua to WASM, but rather how the plugin uses LuaJIT's FFI to talk to the Godot API instead of plain Lua/C bindings.
The FFI is a lot easier to use and makes it possible for LuaJIT to inline calls to native code while JITing, so that was the reasoning behind the choice.

Again, we could implement the plugin in C/C++ using purely Lua bindings, but it would be a lot of work.
The Godot API in 3.x is quite large, there are structs for every native type in the engine (String, Vector2/3, Color, Array, Pool Arrays, Dictionary, Object) and one function for every method they support. It would be super annoying make bindings for this, although something like sol2 should make it much more pleasant to write.
The new GDExtensions API in 4.x is a lot simpler and would be far easier to setup with plain Lua/C bindings.