I want to say I think they are talking about how great it would be if we could kick JavaScript to the curb and just use WASM for everything. I’m kind of in the same boat.
However, WASM currently doesn’t have direct access to things like the DOM, if I recall correctly (this might be the guardrails the OP was referring to?). So, it’s only really good for things that are heavy on the CPU. But, as a counterpoint, I don’t think it’s from a lack of effort from anyone’s point. The last thing I remember reading was that there were still a lot of things being worked on to make it happen.
Quick Perplexity search:
There are proposals and efforts underway to allow WASM to eventually call DOM APIs directly, without going through JavaScript. The main one is the “Interface Types” proposal which would allow WASM to bind to Web IDL interfaces.
Another related proposal is WASM GC (garbage collection) which was announced at Google IO 2023. This will allow WASM to share the same managed heap as JavaScript.
With such a complex system like that it would probably be beneficial to actually build the parts you care about and take advantage of libraries handling the querying of Data like ECS and rendering with bevy. Otherwise you’ll run into the risk of being limited by the library in one way or another.
Define a bunch of structs that you can use compositionally in bevy’s ECS. Create specific systems that react to components being added, removed, or changed. Set conditions like Burnability, Durability, Temperature… etc. React to those conditions or thresholds being met. Your reaction could even be a component. Damage(5), IgnoreArmorDamage(3), CurrencyUpdate(-5), GiveItem(Item::Sword(Stats {…}))
It basically gives you a foundation that feels like scripting but with the power of compile time safety for virtually everything. You get to “model” the data how you want instead of being limited or overwhelmed. And with ECS it really helps make things feel like Lego blocks that you can easily reuse across the entire project.