The State of WebAssembly 2022 survey has closed, the results are in … and they are fascinating!
WebAssembly has gone through quite a transformation this last year, while the wasm language landscape is slowly shifting, the more notable change is in what people are using WebAssembly for. The use of wasm for serverless, containerisation and as a plug-in technology has leapt considerably, with WebAssembly System Interface (WASI) becoming ever more important.
Want to know more? let’s take a look at the details.
Summary
I ran the first ‘State Of’ survey last year, where we learnt that:
- Rust is the most frequently used and most desired WebAssembly language.
- AssemblyScript is the second-most desireable WebAssembly language.
- WebAssembly is expected to have a significant impact within Web, Serverless, Gaming and Containerisation applications.
- Better debugging support is the area that people feels needs most attention.
So what’s new this year? Before we look at the detail, here are the highlights:
- Rust usage and desireabillity has continued to climb
- Python has seen a big climb in usage
- JavaScript has become a viable WebAssembly language
- It’s been a good year for Blazor, with a big climb in usage and desire
- Wasmtime is the most widely used runtime
- The use of WebAssembly for Serverless, Containerisation and as a plug-in host has climbed significantly
- Survey respondents are using WebAssembly much more frequently
- Non-browser APIs are what WebAssembly needs the most
It’s been quite the year for WebAssembly!
In the next few sections we look into the survey results in more detail and explore some of these changes. Many of the survey questions were repeated from last year, allowing direct comparison. Last year there were 250 respondents, this year this increased to 299.
Language
The first question explored which languages people are using by asking the question which languages do you use, or have you tried using for WebAssembly development?
Rust once again comes out on top, with 45% saying they use it frequently or sometimes. WebAssembly and Rust do have quite a close relationship, most WebAssembly runtimes are written in Rust, as are the various platforms based on wasm. It also enjoys some of the best tooling, so this result doesn’t come as a big surprise.
This year JavaScript come in second place. I didn’t add a JavaScript option last year (and no-one indicated they use it via the ‘other’ option), this is a big shift since last year!
JavaScript cannot be compiled to WebAssembly, so how does this work? There’s a cunning workaround for this challenge; rather than compiling JS to Wasm, you can instead compile a JavaScript engine to WebAssembly then use that to execute your code. This is actually much more practical than you might think.
@ilblackdragon at #consensus2022 announcing Near’s JS SDK based on QuickJS (https://t.co/CtDNUfOW0r), the tiny JS VM written by the famous superhacker Fabrice Bellard, which runs hosted as a guest VM in the WebAssembly host in the @NEARProtocol blockchain nodes. Big news! pic.twitter.com/GbvfSrlfwU
— BrendanEich (@BrendanEich) June 10, 2022
This year 67% of respondents are frequently using WebAssembly, which is a big jump from 47% last year.
The following chart shows the percentage of respondents who use a given language ‘frequently’, or ‘sometimes’, compared to last year:
This shows that Rust usage has climbed steadily, but the biggest climbers are Blazor and Python. It’s certainly been a big year for Python, with the launch of Pyscript, an interactive online playground. AssemblyScript has had the biggest fall in usage, which surprised me a little. I do wonder whether some respondents are incorrectly identifying AssemblyScript as JavaScript?
The next question asked which language people most want to use for WebAssembly development:
No surprises here, Rust comes out on top. It has been on the top spot for the ‘most loved’ language in the StackOverflow survey for the past six years.
Let’s see how this compares to last year:
Rust has had a modest rise in desirability, but the biggest climber is Blazor, with Go following just behind.
It’s been a good year for Blazor!
WebAssembly Applications
Next up, we’ll explore what people are using WebAssembly for, and their future aspirations.
The survey asked what are you using WebAssembly for at the moment?, allowing people to select multiple options and add their own suggestions. Here are all of the responses, with ‘Other’ including everything that only has a single response:
Most people are using WebAssembly for web development. However, if we compare this year’s results to those from last year, there have been some big changes:
The use of WebAssembly for serverless and containerisation has climbed. If you want to know why WebAssembly is such a significant technology for these applications, I’d recommend tha article, Pay Attention to WebAssembly, or When WebAssembly Replaces Docker which coves the various talks at Kubecon this year.
The biggest rise is in the usage of WebAssembly as a plug-in environment. It is a fantastic runtime for hosting untrusted code within a secure environment. The Lapce code editor is a good example of this.
The usage of WebAssembly for games dropped, but I’m not sure why 🤷
Runtimes
Considering how the non-browser based usage of WebAssembly on the climb, this year I asked a new question about runtimes - which have you heard about or used?
wasmtime, from Bytecode Alliance is the most widely used, with wasmer, which is developer by a start-up, coming in second.
Features
WebAssembly follows a public proposal process governed by W3C. This survey included a subset of the more mature proposals at phase 2 (specification available), and phase 3 (implementation), asking which people are most interested in.
The threads proposal, which adds shared linear memory and atomics, comes out on top, followed by support for exceptions and garbage collection.
WebAssembly System Interface (WASI), which adds further system-level integration APIs to WebAssembly is becoming increasingly important, so I also asked which WASI proposals people are most interested in:
I/O types comes out on top, followed by sockets, filesystem and native threads. Notably, if you compare this chart to the previous one for WebAssembly proposals, there is a far greater interest for WASI overall.
Finally, I asked people what do you feel WebAssembly most needs to be a success in the future?
non-browser APIs comes out on top, which further highlights peoples interest in, and the importance of WASI.
Demographics
Finally, the survey included a few questions that outline the demographics. I’ll briefly share those results here.
Respondents were asked to declare their skill level in JavaScript, Back-end and WebAssembly development:
Interestingly last year the survey respondents showed most proficiency in JavaScript and front-end development, this year we saw that the survey attracted people with greater back-end skills, most likely reflecting the changing focus of WebAssembly.
They were also asked about how long they had been using, or had known about, WebAssembly for.
This year shows a more experienced set of respondents, with the most frequent response indicating ~2 years experience compared to ‘< 1 year’ last time round.
Conclusions
Thanks to everyone who participated in this survey. The results are available as a CSV file if you wish to do your own analysis. If you uncover any interesting results, please do share them.
As I mentioned in the introduction, it has been quite the year for WebAssembly. I was certainly aware that this technology is shifting more towards being a universal runtime, but didn’t expect the change to be quite so marked.
Join the discussion on this post on Hacker News or Reddit.
Regards, Colin E.