The brilliant Rustwasm team has done a great job building a solid foundation for rust wasm support. However, since the organization has been closed, only parts of the crucial repos have been moved to new maintainers, remaining others like The book of Rust and WebAssembly and create-wasm-app unmaintained. The steps listed in the book to create Hello World are not working now. This is really discouraging to someone who's new to rust wasm. It seems the community is still pretty active in contributing to these repos, given the massive number of unmerged PRs. We just need new maintainers, new hearts for rust wasm. 
7 Likes
Never even tried create-wasm-app. I use Yew, a robust framework that is maintained and rapidly evolving. I wrote some data-heavy applications in it to render huge tables while providing instant search. This definitely has a use case. I still believe.
1 Like
Happy to report the Rust and WASM are alive and well and look like having a great future.
In the last few weeks I have created two Rust apps that run natively on Linux, Mac and Windows and in the browser when compiled to WASM.
Both are displaying real-time data visualisation. One uses slint to create the GUI the other is using wgpu for speed and 3d effects.
All the parts required to do this: wgpu, wasm-bindgen, web-sys, js-sys, wgpu, worked flawlessly and have been worked on very recently.
3 Likes
Glad to hear that the ecosystem of rust wasm is all good. 
However, I still believe repos like The book of Rust and WebAssembly and create-wasm-app should remain alive. These repos are first step for beginners to learn rust for wasm and should be actively managed to ensure they are easy to follow and use.
4 Likes
98% of web pages use UTF-8. (And even 96% of Chinese ones, which might profit a bit from UTF-16.) Yet JS, which we need as a bridge to the DOM, is stubbornly stuck on UTF-16.
Rust, being resolutely UTF-8, is among the languages suffering the most from this. Either we unnaturally comply with JS, forsaking much String comfort in Rust. Or we copy/transcode everything in both directions – a penalty for text-heavy apps.
Rust is now big enough to throw our weight behind getting this solved! Either browsers add UTF-8 passthrough. Or, better yet we finnally get a long overdue DOM API (WASD, maybe with manifest based permissions.)
1 Like
Unlikely. Browser developers essentially killed NaCl, by making sure it couldn't access the DOM, just to not “make user experience worse”, they killed Flash, mostly for the same reason, why would they go back and revisit that decision?
If you want to do something for the web that works with DOM then you have to transpile to Javascript… that's not technical decision, but more of a political one… yet essentially unfixable.
Browser developers is 90% Google, ever since the decline of FF and demise of IE. And they are vocally favorable of Rust. Or if Servo produces it well, the others can easily pick it up, as they already have Rust on board.
Well, Darin Fisher, who was personally responsible for the demise of Native Client and crippling of wasm is no longer with Google which means there are a tiny ray of hope… but it's so tiny we may mostly neglect it.
The core issue is not about Rust, it's about synchronous access to DOM.
Chrome team (like most people in Google) are big fans of asynchronous APIs and wouldn't allow any new developments that add new synchronous interfaces to the web. The only reason they even allow Javascript to have synchronous access to DOM is the fact that it was grandfathered that way last century by Netscape and there are too many web sites that rety on it, so it's impossible to rip it out (they barely managed to rip out Adobe Flash with the help of Apple and Steve Jobs personally… and even Adobe haven't fought too much for it).
But millions of developers who are doing web sites like syncronous things. The only reason they deal with async and asyncronous networks is lack of choice: network latencies make syncronous things too unstable on the planet-scale. But they most definitely don't want to give up their synchronous access to DOM!
And that's it. As long as one side insists that the only way they would allow any new technology to be allowed to exist is to ensure that it doesn't have synchronous access to DOM and the other side refuses to even contemplate anything that doesn't have synchronous access to DOM as possibility… we have a stalemate.
I don't see how it may suddenly be resolved any time soon: both sides are way too much stuck in their dogmas.
1 Like
Doesn’t WASM have synchronous access to JavaScript, and JavaScript has synchronous access to the DOM, so WASM can cause synchronous DOM updates through JS?
Yes.
Yes.
No. You can only call WASM from worker thread. Precisely to ensure that there are no synchronous path toward the DOM which would block the UI… I can understand why developers of Chrome don't want to give new, “shiny” ways of making web pages unresponsive. But I can understand why developers don't want to deal with hassles on asynchronous access to DOM.
The end result: Web technologies are everywhere… carefully wrapped in native apps to ensure that apps behave like their developers want them to behave.
Really funny result… It would have been hilarious if it wasn't so sad.
You absolutely can call wasm from the main thread. You only need web workers if you want multi threading or if you want to do long running computations in your wasm module and don't want to block the main thread, which are the same reasons to use web workers as with pure js code.
What is exactly a problem with this "synchronous access"? Yew is very much like React: you render components in html-like way, with CSS classes also, but you render them differently depending on properties and you have state and events. Also, you can make http calls to the backed API. The overall capabilities are at the level of React/Redux so enough for anything I can imagine.
I stand corrected, then. Thanks for bringing it up. So they have found another way to thwart people's efforts to port their apps to web, it seems like.
Yeah, you are right. Sorry, haven't looked. So now they provided a way to block the UI, yet torn out the other critical part: threads. Sigh.
Will they ever learn?
P.S. It's really funny how giants fail. repeatedly where “small upstrart” manage do dislodge them. Normally using tactics that giants employed in the past, no less. How hard is it to understand that something new and shiny (doesn't matter what: new CPU, new language, new anything) could only success in a world where it coexist with things that were done before? Full rewrite is never a way to go — yet that's something that big company try to push again and again. Fail every time, of course. Of course you have to pick what exactly you have to coexist with: Android boldly abandoned world of MODlets while simultaneously allowed poor-yet-cheap ports from Windows and, later, iOS. But if you cut out everyone… you fail. And all popular platforms, today, have synchronous UI access, native code execution, synchronous I/O and threads… Chrome refused to provide first till NaCl died, now, with webasm it refuses to provide the other two…
The async story is already pretty good in Rust. So we can go down that path confidently.
Servo is kinda the startup here. Let them split the eco-system by adding a new sub-target wasm-shiny! Wasm-bindgen --release would build both and we'd deliver the one best matching the browser.
If they and thus future FF get the fastest web-apps (in Rust) Chrome will wake up.
For that Firefox needs to be willing to do something that Google wouldn't accept. First of all Mozilla is too scared of fragmenting web, and second, it may already be too late… but we'll see. Things are possible, yes. Just not hopeful.
Wasm can block the UI just as much as javascript can.
Threads are absolutely supported through web workers. Perhaps not as ergnomic as I did like, but they are not as ergonomic as I did like in javascript either. And work is actually being done to make it easier to share things between threads to make thread usage more ergonomic.
You can emulate this on web workers as those can block on another thread using Atomics.wait() and equivalent wasm instruction. Synchronous IO is not possible on the main thread (outside of a couple of grand fathered ways like XMLHttpRequest, alert() and confirm()) precisely to avoid blocking the UI. Synchronous DOM access is fully possible as the DOM runs on the exact same native thread as the js main thread, while IO is done on other threads and in many cases even other processes.
The rule is the same all the time: if some platform, today is 1% of your income, then it gets today 1% of spending.
That's something Linux guys ignored, for years, and got near-zero penetration, till Valve, of all companies, started doing things to make porting of apps easier.
Threads, synchronous APIs and other things are not the goal, by itself, goal is to provide a cheap way of porting existing code.
Tomorrow, when your platform wouldn't comprise 1% of income for developers they would allocate more than 1% on it.
Now, when Google, finally, after so many years of doing crazy stuff, abandons ChromeOS and replaces it with Android… I wonder if they would do what Android did in the beginning, or would just repeat the same mistake they did with web platform?
At least if Google would finally do everything correctly there we would have no need to push for the web apps anymore… and that would answer the question of the rust wast, ultimately.
Well, Yew is somewhat maintained but not rapidly evolving. Something like leptos - Rust would fit into that description better.
NaCl was only officially killed after it was clear nobody else would implement it and the industry was going in the WASM direction. Neat tech, but that's not enough, and WASM is enough.
WASM can't access DOM directly not (at least obviously) because of any conspiracy, but simply because there's no functionality to expose it in the language directly: it's pretty much always been on the roadmap in one shape or another.
Interface type support has been being chipped away at then punted in a loop for close to a decade now IIRC, having been pulled into the WASI team and evolving into the whole Component Model design which is a Whole Thing. This is absolutely pretty annoying, since it sure seems like there should be a pretty straightforward way to shim current DOM APIs into WASM as-is, but that is exactly what people are already doing with things like wasm-bindgen, so it's not really a critical issue, and it does seem like it's heading in a relatively nice direction... eventually.
2 Likes
NaCl was killed when Darin Fisher invented PPAPI that no one wanted: some abomination that only supported asynchronous access to everything, not just to DOM. And then made NaCl unavailable for the web sites.
At this point it was essentially dead, what happened later with pNaCl was aready zombie work from the day one. Because when original NaCl was demonstrated in year 2011 there were lots of guys who wanted to use it to replace JavaScript with something better and/or to port their aging ActiveX controls to something better (Interner Explorer was in death throes, they needed some upgrade plan).
By year 2015, when half-hearted release of pNaCl happened war was already lost: Android and iOS won it. And, of course, Android is owned by Google, too, so it wasn't a big deal for Google, just huge loss for ChromeOS (it became “great OS with no apps”). They still kept it on life-support for ten more years while slowly preparing to accept the Android victory.
Too late for that, today if you want to release nice app you go with two: iOS one and Android one. Done. 90% of users are covered, 10% are not worth worrying about. Tomorrow, if Android arrival on desktop would be successful this would make WASM even more useless.
The big question is: would anyone still care when it would arrive? We would know in a couple of years, after Android arrival on desktop.