▲ 178 points
back
105 comments
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:
https://holition.com/play/holition-brings-home-twenty-awards...
https://winners.webbyawards.com/2020/apps-mobile-and-voice/a...
https://www.youniqueproducts.com/beautyguide#.YIS9hOhKguU
https://www.charlottetilbury.com/us/products/charlottes-virt...
> "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.
In general I agree with your points, but:
> 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...
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.
I'm optimistic dom access will get better soon. Check out https://hacks.mozilla.org/2019/03/fast-bump-allocated-virtua... for example.
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).
You would love Svelte. It makes the entire web ecosystem look and feel like the dark ages in comparison.
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.
It probably needs a killer app. To me it feels like it's a solution looking for a problem.
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.
Pyodide is pretty amazing. https://pyodide.org/en/stable/
Figma is pretty killer
> in any language
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.
There is Blazor, which compiles C# ASP.NET-like code to a client-side application that runs on wasm.
Wish I had a RemindMe! bot on HN for comments like these.
There's no garbage collection in WASM. Why do you think that there is garbage collection in WASM?
And WASM has been around since 2017, which is only 4 years, not 10 years... Bitcoin has been around much longer (~12 years), for example.
It's a spec proposal. https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...
Emscripten hit 1.0.1 around November 2012 (looked it up on GitHub)
So if wasm is the spiritual successor to Emscripten's "Compile C to JavaScript and run C in a browser" then it's only 8 years.
For those wondering, Wasm3 describes itself as "the fastest WebAssembly interpreter". Other webassembly runtimes are JIT based, rather than being interpreters. The project's readme (https://github.com/wasm3/wasm3) talks more about this decision.
For more on the difference, and an explanation of what JIT is, check out this section of the book Crafting Interpreters (https://craftinginterpreters.com/a-map-of-the-territory.html...)
Wasm3 calls its interpreter design a "meta machine": https://github.com/wasm3/wasm3/blob/main/docs/Interpreter.md...
It is heavily based around tail calls. I recently wrote a blog article about how we applied a similar tail-call-oriented strategy to accelerate protobuf parsing to 2+GB/s: https://blog.reverberate.org/2021/04/21/musttail-efficient-i...
I also recently landed a change in Clang trunk that offers guaranteed tail calls, so that this tail call design is safe in non-opt builds: https://reviews.llvm.org/D99517 I think wasm3 could benefit from using this attribute when it is available.
How do guaranteed tail calls work when you needs to put arguments on the stack, which usually prevents tail call? (and whether a specific call needs to pass arguments on the stack depends on the platform, and the number and type of arguments)
> Other webassembly runtimes are JIT based, rather than being interpreters.
Do none of the notable ones do normal compilation?
Some runtimes like wasmtime support AOT compilation artifacts that can be loaded.
But in general you can't "just compile" Webassembly, because you need a runtime.
There is a C project that can compile an executable that includes the runtime and the compiled WASM, but the name is escaping me right now.
Note that JIT in the WASM world doesn't quite mean the same thing as for eg Java. Almost all runtimes compile a whole module at once, not individual functions.
What would the difference be between “JIT” and “normal” compilation for WebAssembly?
I think the model is typically that optimisation applied in "normal compilation" are applied when the source language is translated to WASM, meaning that the WASM -> native translation can be quite straightforward and still performant.
I worked on one as an undergrad:
https://github.com/gwsystems/aWsm
Full AoT compilation, C programs run within 10% of native
wasm2c/WasmBoxC springs to mind:
https://kripken.github.io/blog/wasm/2020/07/27/wasmboxc.html
I'm a newer dev so pardon my ignorance. Is webassembly the new, more open JVM? Feels like that write once, run everywhere but this time with any(most) mainstream language.
I certainly would not say ‘more open’. It is newer, but that's a mark against it, not for it.
It lacks most of java's ‘batteries’—there are projects like WASI that try to resolve this at a low level, but they miss the point somewhat. On the other hand, wasm is saddled with fewer assumptions about the type of code that will run on it. Wasm has generally poorer performance, which is mostly (though not entirely) an artifact of its design, and hence not easily rectifiable[0]. It's not clear to me the extent to which the jvm suffers similarly[1].
Socially, I think wasm is not as interesting as java. Write-once-run-anywhere was solved in practice not by java but by open source; by compatibility libraries like sdl; by standards, like posix and opengl; and by static linking. (Yes, it's not quite as convenient as just plopping in a jar, but it's close enough.)
I don't think we're ever going to see a desktop full of wasm apps. Despite stated goals, the point of wasm was always to be an evolution of the web as a platform for applets. The Birth and Death of Yavascript[2] has many insights thataways (even though it failed to predict wasm as such).
0. https://www.usenix.org/system/files/atc19-jangda.pdf
1. It's also difficult to directly compare the performance of the two systems in their current state. A number of proposals for both (gc for wasm, value types for java, simd for both) are yet pending and are likely to change the runtimes' respective performance profiles.
2. https://www.destroyallsoftware.com/talks/the-birth-and-death...
It seems like it's headed that way. At the moment, it's only really practical to generate WASM from compiled languages, or really small languages, like Lua. And your interfaces to the browser (and thus, the outside world) itself are pretty limited, so still lots of javascript involved.
I'm also trying to build a mental model of what wasm is so someone correct me if I'm wrong.
As I understand, the JVM adds a thick layer of abstraction between incoming bytecode and output machine instructions. A wasm "runtime" OTOH adds a much thinner abstraction between incoming wasm and outputted machine code. It's a fairly 1:1 transformation.
However, I think you're correct in that, in order to serve as a host for GC'd and/or web-API-aware scripting languages (DOM, etc), a wasm runtime will need to become more JVM-like. How will wasm remain "web assembly" while doing that? No idea. This is where my mental model breaks down.
Wasm lacks a lot of lower level system specific operations that the jvm offers.
In a way, but wasm is designed to be a lot better at sandboxing.
Self-hosting (compilers) https://en.wikipedia.org/wiki/Self-hosting_(compilers) :
> In computer programming, self-hosting is the use of a program as part of the toolchain or operating system that produces new versions of that same program—for example, a compiler that can compile its own source code
How big of a milestone is self-hosting for a language?
Has anyone built a compiler extension and libffi-based runtime that supports compiling otherwise normal native code to WASM (eschewing hard linking for runtime resolution)?
Would be fun to make it so that native apps for any platform can be run from an interpreter
Emscripten?
I feel the need to repost this link:
https://www.destroyallsoftware.com/talks/the-birth-and-death...
I'm somewhat curious at what pace WASM will gain "market share" while it's only practical to target it with C, C++, Rust, etc.
Supposedly, there are plans to expand it to where it looks more like a virtual machine and less like ASM. Adding things like garbage collection, direct DOM manipulation, polymorphic inline cache, etc. Things that would make it possible to run a decent scripting language without pulling in some huge runtime.
Or forgetting the scripting languages, just the direct DOM access might make it less tedious to use with compiled languages.
It's sort of a second run at getting "applets" right, but in a cross-language way.
Looks like wasm3 is created by embedded/hardware guy, that is really interesting.
anybody wasmer.io