What is the "state of the union" so to speak with respect to WASM and Rust? Is wasm-pack still really being maintained? It seems "rusty"--the documentation certainly is. Is trunk the new wasm-pack? Somewhere I read that it might be. Has WASM in browsers hit a dead-end? Seems like the excitement around it is dying. Which all gets to a core question, is using Rust to compile WASM for use to produce production modules that others will incorporate into their JavaScript web applications of various frameworks considered wise? Or, is it too early?
The year 2024 is near its end. Nobody feels excited about AJAX technology, responsive web app, bidirectional websocket communication and running WASM on browser. They're all just boring normie things you do for your day job.
1 Like
Trunk is an improved alternative over wasm-pack intended for building/bundling applications. Or at least that's the impression I get reading trunk's readme.
Wasm-pack doesn't seem to acknowledge trunk's existence (wasm-pack was first in fairness).
1 Like
So your argument is that Rust is not a solution for better implementations of the mainstream solutions that run the world? It's just for hobbyists and experimenters? I highly doubt that is the general community consensus.
(And my question said nothing about AJAX nor responsive web apps)
I feel you've misread their reply: they're saying, like AJAX et al before it, WASM isn't exciting anyone anymore not because nobody is using it but because everyone is using it.
I'm not sure how you got to "Rust isn't mainstream" from that, honestly?
WASM is actually a little behind in Rust right now, actually; reference values, multiple memories and the like have been standardized in WASM, but currently can't be accessed from Rust. Some of that is due to LLVM support, some due to language design issues, but in 1.82 it seems some of the behind the scenes stuff got unblocked so we might be seeing more in that area soon-ish?
3 Likes
Thank you. You are correct and I did misread the reply. I thought the author was arguing that WASM fell into the category of the other tech he claims nobody is interested in unless it is for their day job. I was trying to poorly snarky counter that couldn't be true unless the rust community is only interested in it as a hobby. I've been using Rust now for two and a half years to develop a fairly innovative system in my day job so it is no mundane day job language for me.
I agree with you that WASM in Rust does seem behind which is why I presented my question. Since WASM seems to be important, we found it surprising that wasm-pack seems unstable. We're debating if we need to abandon it for something else like Trunk or just forgo a bundler all together. We support a web worker based SDK on browser with vanilla JS, React, and Native React variations. We do some high-end multi-party secure compute (zero knowledge) encryption work all in Rust and compiled into WASM for distribution of the client.
I appreciate you taking the time to talk about some of the lagging areas for Rust with WASM. I would add build tools to the list. Hopefully we will see some forward progress.
Personally, if I was more on the front-end side and didn't have my "day job" occupying nearly all of my working hours I would gladly jump in and help the community. I spend my time on the Rust-based communications layer between our client crypto module and our backend. And, I handle our backend work except the crypto algorithms themselves. So there are far more qualified than me out there to help with Rust WASM. I reached out in response to seeing my front-end peers who are trying to make our SDK work struggling with this issue or that.
Thank you for setting me straight on my misinterpretation of the prior response.
1 Like