You can leverage normal HTML though? Blazor does this with C#, you don't write it all to a canvas element, you just use C# to modify the html itself, basically replacing the 'react' part of the UI.
Yes, but it's important to think about the bridge/shim between your application code (the web assembly module) and the host (the browser). If you have a C++ game which draws to the screen with SDL, then you can use a shim to convert SDL calls into html canvas calls [1]. But if a backend engineer wants to compile their java swing application to web assembly, there is a larger impedance mismatch from Java Swing => react html, then from Java Swing => html canvas.
If your application is built upon a web framework which already has this translation layer, like Blazor, then the amount of harness/shim-glue code you need to write goes down.
For games canvas is fine. There is no 'web native ui' people expect.
I really don't think the use of this is running existing Java swing applications on the web. Maybe a bit of a hack for legacy software, but it's really using Java instead of Javascript, but using the normal DOM/HTML.
100% agreed with you. Here's the part where I agree with user "PoignardAzur":
* user "menaerus" goal is have "C/C++/Rust developer [...] expose your product as a browser service", which they can transpile to wasm - cool.
* they will need "a bit of JavaScript you integrate it into the end service" - UI targets the DOM, sounds great.
The questions become:
* how much code will need to be written into each layer (rust wasm, react html ui, bridge between the 2)?
* what level of experience with that tech will you need todo that? ie: writing a react ui which interfaces with a wasm shim is some non-trivial javascript to say the least.
* based on the above: how far has wasm enabled a "c/c++/rust developer" to easily port their application to the web without also being a super strong frontend developer?
I'm trying to draw a contrast between:
A) I have business logic which is not well suited for javascript (image processing on binary data, figma, etc), and I have rust/c++ developers AND javascript frontend developers to build the application
B) I am a rust/c++ developer who wants to target the web with their rust/c++ product, but doesn't want to dive deep into frontend/js/react tech.
In the long term, I am optimistic that scenarios like "B" will be opened up by application (web) frameworks which target wasm via backend technologies and their MVC patterns. But in the short term, the amount of "glue code" to be written is non-trivial.
