> E.g. you're a C/C++/Rust developer and you want to expose your product as a browser service - you transpile it to wasm and with a bit of JavaScript you integrate it into the end service
Speaking as someone who worked for two companies that tried to do exactly that, it's not that simple. The "bit of JavaScript" ends up requiring huge amounts of work, and the user experience feels un-browser-like, because you're fitting everything through a canvas element.
I have almost no exposure to JS but what I have seen so far in WASM projects didn't seem to require that much of a non-usual work but, of course, YMMV.
To me the most challenging part seemed to be in the domain of debugging when things would go south because all of the sudden you have to become very intimate with how things work under the hood and across the whole stack: JS -> V8 -> WASM runtime -> Emscripten -> C++. There's not many people capable of doing that job.
> user experience feels un-browser-like
Perhaps Photoshop is not the classical example but I think it's one of the most craziest ones out there - humongous and extremely complicated C++ codebase consisting of every imaginable optimization and heavy lifting deployed as a WASM "plugin".
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.
Speaking as someone who worked for two companies that tried to do exactly that, it's not that simple. The "bit of JavaScript" ends up requiring huge amounts of work, and the user experience feels un-browser-like, because you're fitting everything through a canvas element.