WebAssembly needs a better definition
Why the current definition could hurt WebAssembly adoption
I still remember my first encounter with WebAssembly a few years ago. Some called it a low-level bytecode for the web, others a sandboxed environment for execution, and others yet an instruction format for a stack-based virtual machine.
At the time, I had mostly done web development so I was quite puzzled by those definitions. In fact, here is actual footage of me hearing about WebAssembly for the first time:
The following quote about teaching new concepts perfectly captures why I felt that way:
“Most beginners aren’t in a place where thorough explanation is helpful — mostly just annoying.” — Lyzi Diamond
While technically correct, none of the official definitions made any sense to me. I found myself thinking “Ok….. but what is it though?”. It wasn’t until I deconstructed the definition word-for-word and read Lin Clark’s blog posts that it finally started to make sense.
And I’m sure I’m not the only one.
Part of the problem is that many definitions try to condense the complexity of WebAssembly into just a few sentences, and end up with something that only makes sense to those who already know what WebAssembly is!
Which is unfortunate, given that a key demographic for WebAssembly is web developers, many of whom — like myself — have been actively avoiding phrases like “stack-based virtual machine” ever since their undergraduate years.
What do we do about it?
WebAssembly should have a definition that does not scare anyone away. To help us learn from a very successful language, let’s consider how JavaScript is defined:
By trying to condense everything known to humankind about JavaScript into a few sentences, the Wikipedia definition ends up being unhelpful to someone who is new to JavaScript, whereas the W3Schools definition is much more welcoming, and clearly conveys what JavaScript helps you do.
Unfortunately, the current WebAssembly definition looks a little too much like what you’d find on Wikipedia:
WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications — WebAssembly.org
While this definition contains a lot of technical words that describe WebAssembly, it still leaves beginners wondering: “No really, what is it?”, “What is it good for?”, and “How do I use it?”.
Let’s change that.
Is there a better alternative?
It would be helpful to feature two definitions on WebAssembly.org: one for folks who know what a stack-based virtual machine is (i.e. the current definition), and perhaps a more prominent one for newcomers—especially web developers—who just want to know whether it can be useful to them in their work.
I have no doubt that our community can come up with a definition that is less intimidating. I don’t know what it is exactly, but here’s a humble attempt that builds on the W3Schools definition of JavaScript:
Granted, this definition doesn’t encompass everything there is to know about WebAssembly — it doesn’t talk about the sandbox environment and the linear memory model, it skips over the portability and potential performance benefits, and it omits the idea of WebAssembly as a universal binary. Heck, it doesn’t even mention that WebAssembly can be used outside the browser. But that’s by design! JavaScript can also be used outside the browser, but we don’t usually lead with that because it can be confusing.
In other words, a definition doesn’t have to be all-encompassing from the very first sentence for it to be both useful and correct. It’s okay to start simple, and build up in complexity as we welcome WebAssembly newcomers to the dark side 😉.
What do you think?
I’d love to hear your thoughts: What was your first encounter with WebAssembly like? Do you agree that WebAssembly needs a more welcoming definition? If so, what would that definition look like, and what do you think of my attempt above?
Thanks to Maria Nattestad and Aaron Turner for their feedback on this article.
