Why was Wasm support removed?

[perry-blueberry]

Looks like this had WASM support previously but it was removed. The only reason I can find is because CI took a long time. :thinking:

[janhohenheim]

In short: it was too tedious to maintain. Long story: I noticed that Wasm had a tendency to break regularly in surprising ways:

• Most dependencies are not explicitly tested against Wasm and tended to break randomly pn runtime when updating versions
• Anything involving shaders tended to work differently on WebGL (16 byte alignment, wgsl calls behaving slightly differently, etc.)
• The performance on Wasm fluctuated drastically between Bevy versions. Code that ran fine on one version suddenly became really laggy
• Testing native and Wasm locally took a really long time since building one invalidates the other. On my current machine (which I need to upgrade), a full build of native takes about 30 min. When I switch to Wasm, that's another 30 min. Finally I want to work again on native, which takes 30 min again.
• IDEs tend to automatically run cargo commands for native in the background, which invalidated the Wasm build
• Performance around 3D scenes, especially loading, takes too long on Wasm due to a lack of parallelism. See for example how the Yarn Spinner demo takes to load even though it is an extremely simple game. This is bad enough to the point that I don't consider Bevy in its current state usable for 3D projects on the web (yet).

And lastly, I personally am interested in making 3D games for native platforms and not Wasm. This means that Wasm support is primarily a feature I added for others and not for myself. But combined with the mentioned issues, supporting Wasm meant spending a significant amount of time on something I didn't enjoy. I noticed I avoided working on Foxtrot at all, which is not a mindset I wanted to be in, so I removed Wasm support.

That said, if anyone is opened a PR that added Wasm support again, I'd merge it but wouldn't maintain or test it. Maybe add a note in the Readme that says Wasm support is experimental.

[perry-blueberry]

Thanks for the write-up!

Testing native and Wasm locally took a really long time since building one invalidates the other. IDEs tend to automatically run cargo commands for native in the background, which invalidated the Wasm build

I have seen these things happen under certain circumstances but I wonder if it's just due to settings or something. When I've seen this it was either due to clippy or cross (cargo for cross compilation) that kept on invalidating the builds. I just tested building back and forth a few times with native and wasm, as well as saving in vscode and I had the same incremental compile each time. No full rebuild for me.

See for example how the Yarn Spinner demo takes to load even though it is an extremely simple game.

It loaded in maybe a second for me. Some Unity games I've played usually take quite a while longer IIRC.

And lastly, I personally am interested in making 3D games for native platforms and not Wasm. This means that Wasm support is primarily a feature I added for others and not for myself. But combined with the mentioned issues, supporting Wasm meant spending a significant amount of time on something I didn't enjoy. I noticed I avoided working on Foxtrot at all, which is not a mindset I wanted to be in, so I removed Wasm support.

Totally understandable! It's a very interesting reference project either way.

[janhohenheim]

Yeah, I really need to upgrade my CPU if the demo only takes a second for you 😅 It's a about 10 for me haha.

Good to know that the rebuild issues with IDEs became better in the meantime!

Closing this as answered :)