Neat project! And thanks for the explanation :-)

Do you think the browser issues are being addressed already or will be addressed soon? or do you think it's a low priority for them? I would think enabling complex WASM apps would be a priority (especially for Google/Chrome) but you never know.

There is definitely a tremendous amount of work going into emscripten/wasm. Minetest is multi-threaded, and so relies on SharedArrayBuffer which only became available in 2020.

The UX issues do seem to be stubbornly persistent though. I ran into the same issues long ago porting games with NaCl and asm.js. I'm not sure what is preventing progress there.

Two of the browsers are owned by the same companies that control two of the walled-garden app stores. The better the UX is for web apps, the less need people have to jump through app store hoops.

I sympathize with the persistent UX issues with web-based voxel engines. I think what is really needed is a UI/UX expert (unfortunately not me) willing to push forward and drive fixes across the entire stack: the game engine, Emscripten, and even investigating and submitting fixes/enhancements to web browsers - owning the complete experience.

For what it's worth, when porting NetCraft I did make an effort to isolate, fix and upstream various UX fixes to Emscripten:

https://github.com/satoshinm/emglfwbugs

with _some_ success; the developers of Emscripten are happy to accept pull requests. But I agree there's a lot of papercuts, and tracking down each of the usability nits could essentially be a full-time job...

For the keybinding problem, I've found using backquote/tilde key for escape can sufficiently workaround the un-interceptable escape key. It also works well on mobile browsers without escape keys.

But the problems with multi-gigabyte world storage, multi-threaded networking, SharedArrayBuffer, may require more invasive architectural changes. At this point, maybe a rewrite focused on web support from the beginning would easier than a port? But _a lot_ of work was put into Minetest over the years, it is great having the library of mods already developed for Minetest, available on the web. Although the same could be said for Minecraft itself.

In any case, thank you for your work porting Minetest to the web. I appreciate it moving the needle in the "web-based Minecraft clone" niche. Even if it may not the be all to end all, hopefully the UX blockers can be resolved, fit and finish, if not in Minetest itself maybe it will inspire others to create something anew with lessons learned from your port. One step closer to the metaverse.

"keyboard side effects(e.g. Ctrl, W), "

You can intercept and cancel the standard browser events and therefore prevent closing the tab for example with Strg W.

Storage option on the web for more data is indexedDB. It is quite fast and stable by now.

What kind of network issues do you have?

But general performance I would not suspect to go drastically up anytime soon, since you already use wasm. (Unless you find some emscripten flags, that speed up things, but this is not my area)

A handful of key combinations cannot be cancelled. With the Full Screen API, the page also loses use of the ESC key, which is extremely important to Minetest's menu interface. (That's why F11 is the recommended way to go full screen)

For storage, a bare minimum Minetest world needs 1GB, grow-able to multiple gigabytes. I don't think IndexedDB is meant for that.

The network issues are specific to Firefox. Multiple threads in Minetest do network I/O. In Chrome this works fine, but on Firefox only the main thread can do I/O, and so network requests are proxied to the main thread (this is done transparently by Firefox, using a mutex internal to firefox). Unfortunately this arrangement leads to a deadlock given the particular way it is used.

"For storage, a bare minimum Minetest world needs 1GB, grow-able to multiple gigabytes. I don't think IndexedDB is meant for that."

It actually is. My app also uses way over 1 GB after a while with no issues. The global limit is just tied to the users avaiable free space.

"The maximum browser storage space is dynamic — it is based on your hard drive size. The global limit is calculated as 50% of free disk space."

https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_A...

"The network issues are specific to Firefox"

And honestly, I would not care too much and just make it clear, that it does not yet run stable in firefox and recommend chromium. (With a link to the technical limitations of what you just wrote, so you do not get yelled at so much by the firefox only crowd, who otherwise assume you did it out of evil neglect)

I regretted the huge amount of work I did to cater to firefox limitations. Its market share is just too low and chromium works also on linux.

(I use FF for browsing myself though)

You actually can't override a few of the events such as Control-W [1], however that could easily be fixed by using an alternate keybind for the game instead.

This port uses a proxy for networking, as the main game uses UDP-based networking [2]. Perhaps it would be possible to upstream basic WebSocket/WebRTC packet-wrapping support to the servers in the main Minetest project?

I am also curious about the storage issues.

[1]: https://source.chromium.org/chromium/chromium/src/+/main:chr...

[2]: https://dev.minetest.net/Engine/Network_Protocol

"You actually can't override a few of the events such as Control-W"

I definitely did overwrite it in my app, but I just checked and remembered, that you also have to be in full screen mode.

WebRTC data channels would be ideal, so that clients can connect directly to servers (or at least regional proxies) in a UDP-like way. Vanilla minetest would need to include an WebRTC endpoint for this to become universally available. There are lots of details that would need to be worked out.

Although the support isn't amazing [1], I believe you can capture C-w and friends [2].

[1]: https://caniuse.com/mdn-api_keyboard

[2]: https://developer.mozilla.org/en-US/docs/Web/API/Keyboard_AP...