The State of WebAssembly 2022 | Hacker News Reader

The State of WebAssembly 2022

blog.scottlogic.com

148 pointsColinEberhardt78 comments

WebAssembly is great as a developer, but it’s bothering me as a user that some websites require it for what looks to me like basic functionality.

The last one to bite me is Linode’s login: I can’t even login to my account to adjust a DNS setting without WebAssembly. That’s a problem because the browser I use, Firefox on PowerPC 64 (a current production CPU, not an old Mac) does not support it.

Yes, I can and have found workarounds, and I do have a variety of machines around that include AMD64 CPUs. It’s still an annoyance for no good reason that I can see.

As for the linked article, I’m not surprised to see Rust rising there because in some quick tests I did, everything worked as advertised with minimal friction.

Unfortunately that kind of (now) obscure platform is unlikely to get great support from web browsers in general.

This is really basic functionality though. It could gracefully degrade to an HTML form.

It could, but it is a bit of a stretch for your average web developer to

1: Know that webassembly does not work on the PPC version of Firefox.

2: Have access to a PPC machine for testing in 2022.

It is an unfortunate but exceptionally rare edge case that few websites will ever actually encounter.

I disagree. Bog-standard functionality like a login form on a web based service should at the very least have a version that uses HTML.

(I wrote a web app in 1998, pushed the team to adopt shiny new HTML 4.0 and Java, but all the front end was data validation that was replicated on the back end anyway. In retrospect it was a lousy way to develop the system - I started with fancy and worked my way down, ass backwards that blew the dev budget - but at least the damn thing had a layer of fail-safe server that worked (handled errors and notifications) no matter what you threw at it.)

I'm writing this on an ancient iPad with JavaScript disabled. This is a text site. It works.

If you are building an app that requires Javascript in order to do what the customer wants, then having the login form also use Javascript does not seem like a problem to me. Building an HTML-only fallback that successfully logs the user in but takes them to a page that does nothing without Javascript seems like a waste of resources.

Tons of websites don't have html fallbacks for the small userbase that disables javascript. You'd be hard pressed to convince them to support html fallbacks for what I assume is an even smaller userbase (PowerPC)

Please note that Javascript works well (no JIT but fine otherwise) in Firefox on PowerPC 64, things like ProtonMail, GMail, YouTube, diverse online maps etc. work fine, even WebGL (Shadertoy, Three.js etc.). It’s just WebAssembly which doesn’t.

Huh, TIL. There's no C interpreter fallback for WebAssembly in Firefox that works on all platforms?

It seems that WebAssembly support requires the JavaScript JIT (Just-In-Time) compiler:

> “Unfortunately I have not had time to do much more work on the JIT because of the holidays, family responsibilities and $DAYJOB. I won't be offended at all if someone beats me to the punch especially as I'm starting to see WebAssembly becoming a hard dependency even for some add-ons (without the JIT there is no support for wasm).”

> https://www.talospace.com/2019/12/firefox-71-on-power.html

That’s from December 2019. As of 2022-05-31, there has been some progress but it’s still not working:

> “I can't figure out where the bugs are in our POWER9 Ion JavaScript JIT implementation, though I still strongly suspect it's because we use sign-extended 32-bit ints. This is enough to pass the test suite but still breaks with the web. MIPS does too and we are strongly based on the MIPS port, but one wonders if MIPS suffers from the same issues, and I'm quite sure it's not tested anywhere near as well. As 32-bit arithmetic instructions aren't orthogonal in Power ISA this change would require some significant rearchitecting and I've just come off a really bad week at work, so I'll just try to pull up the current JIT to 102 so that those of you building the new ESR can continue to use Baseline Interpreter and Baseline Compiler, and then it will be time for more major surgery on the source code. You can help (please!).”

> https://www.talospace.com/2022/05/firefox-101-on-power.html

Looks like it’s not that simple.

This seems really odd to me. If it's possible to convert wasm to C[1], then it should be possible to convert wasm to asm.js and just execute that. That may not be ideal, but surely it's a better stopgap solution than letting the happy path fail for years on end.

1: https://github.com/WebAssembly/wabt/tree/main/wasm2c

Emscripten can still compile to asm.js (which is a subset of Javascript), and this can be used as fallback path on ancient browsers. But without special asm.js support the performance cost will be very high. Of course the actual question is: why does a login form need to load a WASM blob.

I wish I could somehow ship a website as a single wasm file. Currently there's quite a bit of HTML/JS ceremony involved in order to execute a wasm file, but I'd rather be able to serve up an "index.wasm" and be done with it. Is there any movement towards this?

yes, <src module="main.wasm"/> is under consideration. Maybe you need a tiny wasm_dom.js but direct DOM manipulation is in the pipeline too.

Where is the spec for either of those? The <src> doesn't even make sense.

The ceremony is a one time thing, and the boilerplate is a copy and paste away. You can pretty easily ship an entire application as an self contained html file.

I was thinking to fork a browser engine, and bind wasm directly to the DOM without any JS. Anyone interested in teaming up on this?

As long as they don't let WebAssembly have raw access to the host filesystem, they'll do well. "No access" is the best access choice for the default.

As adoption ramps up, the pressure to make filesystem access "easier" will increase. I just hope they hold it off, as isolation is the key feature of the platform.

> As long as they don't let WebAssembly have raw access to the host filesystem, they'll do well. "No access" is the best access choice for the default.

Not sure where this worry even comes from? Browsers have never let anything (not even JS) have raw access to the host FS, so not sure why Wasm would be different.

Edit: Ah, I realize now you might be thinking about running Wasm outside of browsers, via some other runtime. If so, I'd understand the concern as most desktop technologies allow unfettered access to FS and more.

Browsers have never intentionally let anything outside the filesystem, the site the page is loaded from, etc... there are always escapes.

The design of the WASM vm seems to preclude escapes, unless people get sloppy and make ladders that can be climbed out of. That's where my concern comes from.

> Browsers have never let anything (not even JS) have raw access to the host FS

I'm not sure what you mean by "raw access", but the File System Access API certainly allows web applications to do a lot of things.

> The File System Access API (formerly known as Native File System API and prior to that it was called Writeable Files API) enables developers to build powerful web apps that interact with files on the user's local device, like IDEs, photo and video editors, text editors, and more.

https://web.dev/file-system-access/

> After a user grants a web app access, this API allows the app to read or save changes directly to files and folders on the user’s device. Beyond reading and writing files, this API provides the ability to open a directory and enumerate its contents. Additionally, web apps can use this API to store references to files and directories they’ve been given access to, allowing the web apps to later regain access to the same content without requiring the user to select the same file again.

> Additionally this API also makes it possible for websites to get access to some directory without having to first prompt the user for access.

https://wicg.github.io/file-system-access/

It's not just a draft, it's been part of Chrome since version 78 in 2019.

> After a user grants access, this API allows web apps to read or save changes directly to files and folders on the user's device. It does all this by invoking the platform's own open and save dialog boxes.

https://blog.chromium.org/2019/09/chrome-78-beta-new-houdini...

Discussion at the time:

https://news.ycombinator.com/item?id=21032537

Some of the folks developing wasmtime plan to run it as a server environment where any users can submit code to be run. They are very incentivised in making sure the sandbox can’t be broken.

Technologies like WASI are coming on right now to do exactly this kind of access in the context of a sandbox. From what I can tell, they're going through a lot of the same progression of JVM and .NET IL back in the 90's and early 2k's but for whatever reason seem to be more openly embraced in all the places where WASM is gaining a foothold.

I'm just keeping my fingers crossed that this one sticks .. oh and, please make WASM run in a browser without JS :)

> I do wonder whether some respondents are incorrectly identifying AssemblyScript as JavaScript?

Perhaps we should include HTML and CSS in the list of languages to choose from next year! :P

I picked JavaScript thinking of AssemblyScript as a tool (not a language) to use JavaScript (with types) as a language compiled to WebAssembly. Maybe the results are not accurate.

I also use Wasm for web (the largest category of use so far) and would not use a JavaScript engine inside Wasm to talk to plain JavaScript in a browser (I don't think any web developer would hehe).

Perhaps the survey should have an option to choose

"JavaScript running in a JavaScript engine inside WebAssembly",

and

"JavaScript compiled to WebAssembly",

to make the results clear as to which "JavaScript" people are using.

Does a JavaScript engine inside WebAssembly even count as a "WebAssembly language"? Or is that C++ and Rust actually?

Does running a browser in WebAssembly make HTML and CSS WebAssembly languages too?

I think that NEAR users just use the SDK, I don't think the users chose JS specifically for it to be in Wasm.

I actually think there's a third way of "using JS to write Wasm", which is to have a JS library which has instructions to emit "hand-written" Wasm bytecode. Example of such a library: https://github.com/iden3/wasmbuilder

That's actually what I was thinking about when picking this option! Think of the following situation:

- You're a JS developer, and want to write a client / library mainly with JS

- You want to use Wasm only for some narrow, performance-critical parts

In this case, you may not want to use something like Rust, because that adds tooling overhead, makes the Wasm bytecode bigger & makes it harder to hand-optimize the Wasm. On the other hand, you might not want to directly write the Wasm in raw WAT, because that has crappy DX.

In this situation, having a JS library is a viable way to make the writing of raw Wasm somewhat more efficient. Example of this pattern being used in the wild: https://github.com/iden3/wasmcurves/blob/master/src/bls12381...

That's definitely interesting, but seems a bit less convenient compared to, for example, writing some TypeScript (compiled to Wasm) and importing that into the JS like we already can with AssemblyScript. AS recently gained the ability to output native ES Modules (containing Wasm and exposing the exported APIs) to import into native ES Modules in plain JS (with type definitions).

Without interface types to unify passing strings around or more complex handles to resources. WASM is going to be rough on the serverside.

I still have not found a consistent way to construct a sqlite connection, pass it to wasm (language agnostic) and then return and close it.

Interface types appear to continue to be making progress: https://github.com/WebAssembly/interface-types

From your link:

> Note: This proposal is currently inactive, with work having moved on to the component-model repo.

This is never getting done, is it... this is the fourth rewrite of such a feature.

Don’t be so dismayed. I’ve been following the progress and the move was a good one. It allows them to ship the thing most people care about.

These things take time. If all else fails just write a polyfill. Component model doesn’t add anything new runtime requirements that can’t be polyfilled

You can do that with bindings currently. Interface types should only make it easier (for languages with utf-8 strings, as interface types does not support WTF-16 strings like in Java or JavaScript yet).

Blazor/dotnet is the framework using WASM. C# is the language.

Very good point, I'll fix that for next year's survey. Fortunately for people working with WebAssembly those two terms are synonymous, so this will not effect the results.

Btw, while you're here, another suggestion: Perhaps include Node.js as a runtime option? It's not a pure wasm VM, obviously, but it may be a common way to run wasm on the server simply because npm packages can include wasm. (OTOH, users of such packages might not even know they're using wasm...)

Yes indeed, I got ASWebGLue (WebGL bindings for AssemblyScript) running in Node.js this way, with bindings to the webgl-raub package.

Props to Colin on the survey. It's always super useful to have more insights on where the market is going.

I'm super happy to learn that Wasmer (https://wasmer.io) is the most popular runtime (regarding most people having heard of it). But I would like to cheer all the other runtimes for their awesome work, it's always good for the ecosystem to have a healthy amount of competition on the runtime space :)

What is a use case for running a javascript vm in webassembly? Why not run javascript in the browser itself? Is it for server-side webassembly stuff?

You can "pre-initialise" the JavaScript VM so that your JavaScript code starts much faster at the cost of some small ongoing performance penalty.

I think the main use case is "serverless" or "edge compute" where start-up time is often hugely important.

Why not just use a language that's better suited for serveless or edge computing? Why is JS the hammer to every programming nail? Aren't programmers supposed to be able to learn and use multiple languages, depending on best use case?

Perhaps they are, but they don't want to.

Yeah, my interest in this is for server-side purposes. I can imagine wanting to build a feature that allows users of my web application to write and execute their own custom code - think triggers and hooks for custom logic.

If they're creating code that will run on my servers I need to have an EXTREMELY reliable sandbox around it - I see WebAssembly as providing the best possible option for that these days.

Letting them write their customizations in JavaScript which I then execute in a JavaScript interpereter inside a WebAssembly container sounds like a pretty good option.

Node.js has reliable sandboxes for JS code without the need for Wasm.

1. what's the functional programming story - immutable data structures, garbage collection?

2. WASM's best use seems to be to cross-compile C++ GUI apps in a browser (like Unity engine). Ok, but it's not platform native, so will this feel like weird Java desktop GUIs all over again? The best apps are native

3. Web apps are I/O bound. How does wasm help?

Thanks to WebGL, all plugins are back, that is how WASM helps.

Have a look at Grain for a ML like language with GC runtime.

Javascript already has WebGL? What is wasm adding

See this subthread: https://news.ycombinator.com/item?id=31810249

A smaller, lower level target than JS. In a sense the better question is “what does it remove”.

Two things:

- speed up in some cases - ability to compile the same app to native

wasm is a low-level architecture - it gives you a linear heap to play with however you want. If you want immutable data structures and GC on top of that, you can certainly do that, in the same exact way we do it on other platforms.

The weird Java desktop GUIs were weird not because they weren't native code, but because the standard Java UI didn't use native UI APIs, nor did it even try to at least look native (as e.g. Qt does). But, just as there are native UI libraries for Java, there could be the same for wasm. It's just too early to tell, given how immature the whole wasm-outside-of-browser story is in general.

1) Kotlin just shipped an experimental wasm compiler with 1.7.0 that is not actively marketed at this point but starting to work. They are depending on a few feature flags in chrome to turn on experimental garbage collection and a few other things. Jetbrains decided a while ago to build on and wait for the standardized wasm functionality for memory management and garbage collection instead of shipping their own version of that (like blazor does). My guess is that once this stabilizes, a lot of other languages will start targeting wasm more actively.

2) Actually, wasm is showing up in a lot of js/ts applications as an optimization. Mostly developers don't even notice their npms are pulling in some wasm. For example react does this apparently. What is native is a pretty fuzzy notion these days. A lot of mobile apps are hybrids that lean heavily on embedded browser components.

3) IO gets done by the browser via native libraries. The Javascript facade for this is pretty narrow (browser fetch API basically). If you are manipulating lot of data (e.g. graphics) in binary form, having some native code with actual types is helpful.

> JavaScript cannot be compiled to WebAssembly

Wait, what? Why? Is WASM not Turing-complete?

It would need a JavaScript interpreter to go with it.

You need a runtime like the browser or Node in WebAssembly. I suppose you could write one in Rust and then compile it to wasm. But then what do you gain by doing this?

Wasm is Turing-complete. What people typically mean by this is that in a browser context, compiling JS to Wasm does not currently make it run faster than just running the JS as JS.

Javascript can be compiled to WebAssembly, and there are people doing it:

https://bytecodealliance.org/articles/making-javascript-run-...

Can someone point out a known web page/service that uses WebAssembly?

Google Meet uses it for a bunch of processing.

Figma uses it.

We're using it right now to drive a new physics integration.

Just curious what your thought are regarding this (https://zaplib.com/docs/blog_post_mortem.html) if you have seen it. Does implementing a physics engine in Rust and complied in wasm provide you guys with quite a big performance boost? Asking because I've considered doing so for my team, but have reservations about the performance increase.

We’re not implementing in Rust but taking an existing piece of middleware (Bullet) and using it. Performance wise it’d be an apples to oranges comparison but our general understanding from benchmarks, our own personal experiments and blogs like the one you posted there is not to expect miracles but more consistency and less footguns (e.g. megamorphic behaviour).

This is another good summary: https://ianjk.com/webassembly-vs-javascript/

I would say there is hope when SIMD is supported across major browsers if your workload will make use of it. Just waiting on Safari. And there might well be more performance to eek out of the JIT compilation.

Thanks! This was useful

Figma is probably the biggest web application that uses it for the main feature they offer (the entire in-browser editor is C++ compiled to Wasm).

You can read more about how they use it here: https://www.figma.com/blog/webassembly-cut-figmas-load-time-...

> Because our product is written in C++, which can easily be compiled into WebAssembly, Figma is a perfect demonstration of this new format’s power. If you haven’t used Figma before, it’s a browser-based interface design tool with a powerful 2D WebGL rendering engine that supports very large documents.

Ok, this is a great example. I will check that out!

You can run Python directly in the browser via Pyodide: https://pyodide.org/en/stable/

well, I have just implemented webgpu support for Pyodide ;). Soon, we will able to train neural nets right in the browser :). So, right now I'm working a very minimal grad based nn framework

How do I know it's running in the browser?

Mozilla uses WebAssembly in it's offline translation extension. Here's a web-page demonstrating the same stuff:

- https://mozilla.github.io/translate/

These are neural models that are compressed and optimized to run on user's CPU. I write some of the code which repurposes the underlying (C++) library for extension's needs, all of which gets compiled via emscripten to WebAssembly for use in the browser.

Previous discussion on HN: https://news.ycombinator.com/item?id=31596888

Whenever you use Zoom or Meet in a browser you're using WebAssembly. Lots of other sites do too, but you just need to open the devtools to notice it.

Other big examples: Unity games, Photoshop, Figma, Google Earth, etc.

Unreal Engine games on the web soon as well :)

https://venturebeat.com/2022/05/12/wonder-interactives-the-i...

Adobe Photoshop and Autodesk for example.

Kinda surprised by the survey results, I wonder what it is about the rust community that they prefer it so much or perhaps the data is biased.

I would really expect languages that typically implement server side APIs to be most interested. But the python/Ruby/go people I guess aren’t that into it

Where is the .NET / C# in the data? :(

Packed under Blazor.

it looks like most developers not interested in mem64 feature. I can't really understand this thing.

Ladies, Gentlemen and all non binaries, current vm runtimes have 32 bit adressing and therefore you can have at most 4gb memory for your webasm application. I think it should be top priority to make it 64bit

Top? Not sure about that. You can do a lot of things (most, I'd say) with far less than 4gb.

It would also be kind of nice if web developers knew they couldn't use more than 4GiB per tab, so didn't even try to get close :P

> so didn't even try to get close

That would imply they weren't _already_ trying.

This kills me aha, I bought a computer with 16gb of ram in 2011, started getting OOMs in 2014/2015. My laptop has 32 gigs and desktop 64 and I still have the occasional OOM in media creation work (and no doubt I'd have the same editing a large 3D scene, making a detailed part in a CAD software, editing a detailed SVG or 8k image with 35 layers, running a complex electronics simulation... All the things that people buy computers for lol)

Tool for the job. I think there are probably reasons why editing a large 3d scene or doing detailed CAD work are probably best done outside of a wasm VM.

lol, I'm using webassembly vm for training neural networks in browser by using webgpu. Sometimes, you need to copy data from vm's heap to gpu by using my awesome tinygrad based framework. In this case, vm is sort of limited and it needs to have 64bit adressing.

Reply on news.ycombinator.com