What is the state of the world with wasm at this point? It seems like it's been this huge tease for 10 years now, promising that we'll be able to build web apps in any language. But as far as I'm aware, garbage collection and DOM access is still nonexistent.
Good question, still a "green" technology but I have had great successes with it for the past 4-5 years in production (ASM.JS before widespread WASM compatibility).
"promising that we'll be able to build web apps in any language" is not how I see WASM, nor is it really used in this way outside of transpiling Unity3D/Unreal games (this may be the one area there is an exception). I use it to transpile C++ to WASM libraries used within React apps, Edge Lambdas, and Node.JS servers. Primarily down to 2 reasons: speed and efficiency. WASM unlocks excellence and resources in other disciplines/languages such as AI and AR tool chains, Engineers, OpenCV, etc. When used like this, it is outstanding.
What WASM will never be good at is being used for the whole experience. You lose the semantic web, and/or accessibility tooling. Web has some outstanding guidelines and frameworks to help the impaired, screen readers and the like. Using WASM to pump a native app into a HTMLCanvasElement will lose all of these advances, therefore, WASM shouldn't be used for this use case (outside of games). Like all tooling, there is a time and a place to use them.
Below are a few links which use WASM in production:
> "promising that we'll be able to build web apps in any language" is not how I see WASM
Unfortunately it kind of got branded this way for people who aren't close to the front-end industry. There's a segment out there who would like to write web apps but aren't willing to touch JavaScript with a ten-foot pole, and their hopes were gotten up that WASM would give them that. It's not exactly a lie, but it has so many asterisks that it may as well be.
In practice, the reality is that JS will continue to be the only first-class language for the web. WASM has many uses, some on the web and some outside of it, but the closer your app is to the DOM and to the browser as a platform, the less likely it is that you'll ever be able to pretend JS doesn't exist.
Blazor client-side (for dotnet) works fine with minimal asterisks, and even those issues are being slowly solved as WASM evolves with multithreading, GC, and DOM access.
> What WASM will never be good at is being used for the whole experience.
The Flutter team would disagree.
They are leaning on WASM for browser builds of Flutter apps, with the whole app rendering in a canvas.
They do accessibility via separately created accessibility trees.
The experience far from great at the moment, but give it a few years and I think it will get there. (better wasm optimisations, direct host interop without JS shims, GC, threads, maybe WGPU instead of canvas, ...)
If that's a good thing for the web is another question...
Unfortunately, Flutter apps still seem to be lagging on the accessibility front. The Flutter web gallery[0] has many examples of beautiful apps, but something as "simple" (on the web) as being able to select text is absent.
For some use-cases, this is a nonstarter. (Sadly, not to as many as I'd like! But let's simply not regress, to start.)
It’s worth keeping in mind that Flutter for web had its 1.0 release a matter of weeks ago. It’s very impressive with what they have done so far but let’s see where it goes. The amount of potential there is truly huge.
It’s genuinely hard to tell if you are serious about this or not. Either way it somehow perfectly encapsulated the kind of thing this website is famous for. Congratulations?
Flutter feels so strange to me. In many ways, it's reimplementing major parts of a browser, compiled to (web)assembly, running inside a browser compiled to assembly... Watch five years from now someone add a low-level programming framework to Flutter and then soneone else reimplement the browser using that
Turtles all the way down! It would be more humorous if we used Skia, since that arguably fulfill's OPs proposition that someone would eventually rewrite the browser in said framework
The flutter web text field don't even handle multiline text input with IME properly. Cause the whole text field to scroll while select character from IME dropdown. I'd doubt how could that be count as "good user experience".
WebAssembly Summit 2021 was this week, and that is definitely not how the people on the frontline are selling it, BBC is even on the process to fully rewrite they iPlayer in C++.
Well built in garbage collection is non-existent. You can definitely use languages with GCs, you just need to include the GC in the bundle. You can do DOM access as well, it's just not particularly efficient.
Overall I think WebAssembly definitely has some usecases, they're just not as visible as people expected. Sites like Figma or Lichess use WASM but not in a super flashy way.
Funny story, in 2013 I was working for the Google Earth team. A new clean slate version of Google Earth was in the works (which has been released since) and this was at the time that wonderful demos were being made with asm.js
I convinced one of the engineers to try compiling it in emscripten. It was a total success, running at 45 fps. The middle manager got so excited about this that he decided to make a full push for this version of google earth to be used since
it was truly cross platform product running in the browser at near native speed.
The portable Native client / webassembly team caught wind that this was happening and convinced management to kill the project. The middle manager who was overly excited about this technology, was also let go.
All this to make way for web assembly which was “right around the corner” but actually wasn’t (back in 2013). Today web assembly is essentially doing the same thing that asm.js was doing 8 years ago.
If Google had not messed up this decision it would
have really been a trailblazer for other companies to
follow suit.
Lol! The funny thing is that at that point, the code you were shipping was "just javascript" but in a machine generated format. When places go out of their way to tell you about their engineering culture, they often aren't.
TBH DOM is garbage for building apps, but if you need to use it it's clear that it's built for JavaScript. TypeScript made JS manageable and there's so much work in the JS ecosystem arround DOM interaction, I sincerely doubt you'll see anything come out of this. I haven't looked at Blazor/MAUI but having experienced MS frontend tech in Silverlight and Xamarin, I'll take the JS/DOM any day.
Ideally WASM would expose lower level APIs and then we can start treating the browser as the app sandbox that it is (in the case of buildign apps).
Svelte made me want to have time to write a new Common Lisp framework. Really, that's how one should look like, at least as far as the results on the client side are concerned.
DOM access is possible with a bit of boilerplate to make the WASM aware of the APIs. In Rust, crates like js-sys and wasm-bindgen automate most of this.
Rust also has the Yew framework, which is surprisingly nice to work with given that Rust is not a frontend language and it only uses the built-in macro system rather than a preprosessor like JSX.
It is stuck in MVP 1.0 capabilities, still years away to reach out the capabilities of Flash/CodeAlchemy and PNaCL in 2021, while tools like Emscripten feel like stone age technology, where you need to mount Lego pieces by yourself.
The priorities seem to have shifted, with most standardization efforts being focused on running WebAssembly on the server, rather than web browsers.
Flutter and Blazor are exceptions, but they had to reinvent everything their own way.
Regarding languages, the landscape is pretty much limited to Rust (when using compatible crates), Zig, TinyGo, AssemblyScript and C# (with Blazor).
The specification started with something very simple but keeps getting more and more complicated, not to mention breaking changes, that don’t encourage writing tooling for it. At least not until things settle a little bit.
In my view, the DOM is too cluttered and bloated, difficult to work with if you're a browser. There are a lot of things that should be made deprecated, but it's difficult to decide which things, since big browser are usually rivals (apple, google, microsoft, mozilla...).
Browsers are already pretty complex machines, considering javascript and the DOM and everything that comes along. Expecting all browser to let WASM have access to the DOM is a big demand.
WASM alredy got a killer app: being able to run any snippet of any language in a browser. For teaching programming, it's use, because projects like pyiodine can load a full python vm in a the browser and let the student experiment with the snippet without taking the risk of ruining my server.
Is anyone using a language other than C, C++ or Rust to target Wasm? Many other languages seem to have experimental support - but are any of them ready for production, or even making significant progress towards being ready?
Go also has good support and Java has http://teavm.org/ and JWebAssembly. There is also the general https://wasmer.io/ for using web-assembly in any language. They claim they have good support for other languages like Python and PHP but I personally never tested that.
Yes, and this is just an extension. Existing WASM compiler front-ends for non-GC languages don't have to necessarily use it. Wasm itself still won't take a performance hit, unless individual devs opt in by using front-ends for GC languages.
I mean, you can keep playing this game and take Microsoft ActiveX or Google NaCl as another spiritual successor. I maintain that WASM has been around for 3 years.
