For sure! Iced is quite novel in that you can use the same codebase to cross-compile entire complete apps across multiple targets. So far web and WASM (with low-level WebGPU, as opposed to WebGL) binaries and desktop targets are officially supported. It uses native Metal (on MacOS) and Vulkan (on Linux and Windows) graphics APIs directly. Additionally, an iOS example does exist, where Rust is compiled to arm64-ios.
And since Rust doesn't require the inclusion of a traditional GC, it's a perfect fit for WASM. WebAssembly doesn't support a GC OOTB, it's still in the proposal phase. Go and Blazor still have to include a GC.
Ironically, Rust dev build artifacts (the target directory) wind up taking up a lot more space on disk than node_modules and dist or build. I'm assuming rustc is just doing a heck of a lot more when it's doing the mostly comprehensive ADT type-checking Rust is famous for. But the web release binary is usually comparable to a React app, if not samller. Additionally, the native build is usually around 10-100x smaller than an Electron app. If you're feeling real adventurous, you can even compile without support for CPUs made 10 years ago, or even try recompiling the Rust stdlib in a similar fashion, but that's also a lot harder to do, admittedly.
There's a lot more to say on this topic, and it goes real deep, but needless to say, I think Rust and WASM has a real shot at a future where it could replace Electron, React, and React-Native. In addition to, you know, the promise projects like Lucet and WASI have towards entirely outmoding Docker and Kubernetes for deployments. And projects like Sled and TiKV have real promise for high-performance KV stores. More scalable (and cheaper) than Redis, while faster than LevelDB, which, to a degree, helps lessen the need for fiddly fine-grained tuning like what is commonly done in RocksDB. Remember, pretty much all databases are essentially key-value stores because of their indexing strategies. They just have different query frontends and other implementation details here and there. But they usually all have WAL or AOIL or whatever, and there'll be background optimization processes, and oh hey, now you have something resembling a B-Tree or LSM tree.
But, as you mentioned, all that is a discussion to be had in a different post entirely. One I'd love to have, though, and perhaps we could compile it into a separate dev.to post.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.