Great article. I think wasm is one of the more interesting things to happen in the last few decades in computer science, though there are many. I think it’s here to stay for sure, but am always curious where the adoption curve will go.
I don’t know much about wasm, but isn’t it the equivalent of bytecode? That’s just a compiler and an interpreter, how is that a significant development in the last few decades in CS?
It’s a workaround for the historical trash fire of JavaScript in the browser. Since nobody could agree on a way to do something other than JS in the browsers they came up with this gradual replacement where initially WebAssembly was just a special version of JS, then they turned that into a bytecode interpreter. The end goal was to let you use any language as your browser scripting language but the implementation isn’t there yet. It’s pretty painful to do anything with the browser APIs via WebAssembly because you’re still using the terrible JS APIs rather than something more ergonomic for the language you’re using and you need to write JS shims around all your non-JS code.
Basically it’s a start, but it falls short of what’s needed. Since you end up needing to write a bunch of JS anyway you’re mostly just creating more work for yourself rather than being able to avoid JS in the first place.
That said, by accident it’s also created something close to a universal bytecode since a very wide variety of languages support compiling to WebAssembly.
It isn’t interesting for being bytecode. Rather for being the first universal sandboxes runtime for the browser and elsewhere. Being able to write in many language and compile to wasm targets is awesome. Safety guarantees and performance are both great too. And it can run in tiny environments.
Except that it isn’t really the first iteration of any of those things. Java did most of 'em more than a quarter century ago: browser-embedable, multiple languages could target the JVM, and, yes, sandboxed—the only issue was startup (not runtime) performance. That wasm doesn’t share those startup performance woes makes it useful, but not revolutionary.
As for tiny environments, a typical desktop system from around 1999 is somewhat similar to a Pi Zero W in terms of ability.
Speaking based on my own PC in that era: it had 512MB RAM and the video card was capable of running FFVII PC version with hardware drivers, so there was some very modest and primitive 3D capability buried in there somewhere. I believe the CPU was a ~500 MHz P3, so I’ll grant you that one, and the one about RAM speed. Well, I did only claim they were “somewhat similar”.
The sandboxes are different. The embeddable Java plugin sandbox was a bit different and susceptible to confused deputy and other attacks. So yeah, I guess you can say it is iterative but they’re kind of worlds apart. You can run thousands of wasm modules in a single process and have them all be completely isolated. Its performance and security gains, portability, and usability are all superb.
I guess I can’t really defend it well, but I think it is interesting and important.
It’s kinda cool as in you can compile a bunch of languages to wasm, so instead of being locked to JavaScript (/typescript) you can instead code in e.g. rust, have all the advantages of the compiler and still run in the browser.
Great article. I think wasm is one of the more interesting things to happen in the last few decades in computer science, though there are many. I think it’s here to stay for sure, but am always curious where the adoption curve will go.
I don’t know much about wasm, but isn’t it the equivalent of bytecode? That’s just a compiler and an interpreter, how is that a significant development in the last few decades in CS?
It’s a workaround for the historical trash fire of JavaScript in the browser. Since nobody could agree on a way to do something other than JS in the browsers they came up with this gradual replacement where initially WebAssembly was just a special version of JS, then they turned that into a bytecode interpreter. The end goal was to let you use any language as your browser scripting language but the implementation isn’t there yet. It’s pretty painful to do anything with the browser APIs via WebAssembly because you’re still using the terrible JS APIs rather than something more ergonomic for the language you’re using and you need to write JS shims around all your non-JS code.
Basically it’s a start, but it falls short of what’s needed. Since you end up needing to write a bunch of JS anyway you’re mostly just creating more work for yourself rather than being able to avoid JS in the first place.
That said, by accident it’s also created something close to a universal bytecode since a very wide variety of languages support compiling to WebAssembly.
It isn’t interesting for being bytecode. Rather for being the first universal sandboxes runtime for the browser and elsewhere. Being able to write in many language and compile to wasm targets is awesome. Safety guarantees and performance are both great too. And it can run in tiny environments.
Except that it isn’t really the first iteration of any of those things. Java did most of 'em more than a quarter century ago: browser-embedable, multiple languages could target the JVM, and, yes, sandboxed—the only issue was startup (not runtime) performance. That wasm doesn’t share those startup performance woes makes it useful, but not revolutionary.
As for tiny environments, a typical desktop system from around 1999 is somewhat similar to a Pi Zero W in terms of ability.
I would imagine a Pi Zero is significantly more powerful than a 1999 desktop system.
Pi zero has a 1Ghz single core and 512 MB RAM. 1999 would be a P3, which started out from 500 MHz and I believe RAM was less 512 MB at that points.
And that’s just high level figures, that ignore faster RAM speed, massive improvements in IPC / CPU microarchitecture.
I would even speculate the hypothetical 3D capabilities of 1999 desktop could probably be simulated in software.
Speaking based on my own PC in that era: it had 512MB RAM and the video card was capable of running FFVII PC version with hardware drivers, so there was some very modest and primitive 3D capability buried in there somewhere. I believe the CPU was a ~500 MHz P3, so I’ll grant you that one, and the one about RAM speed. Well, I did only claim they were “somewhat similar”.
The sandboxes are different. The embeddable Java plugin sandbox was a bit different and susceptible to confused deputy and other attacks. So yeah, I guess you can say it is iterative but they’re kind of worlds apart. You can run thousands of wasm modules in a single process and have them all be completely isolated. Its performance and security gains, portability, and usability are all superb.
I guess I can’t really defend it well, but I think it is interesting and important.
Maybe we should get away from “browser than can run apps” and move towards “app sandbox that also happens to render html”.
It’s kinda cool as in you can compile a bunch of languages to wasm, so instead of being locked to JavaScript (/typescript) you can instead code in e.g. rust, have all the advantages of the compiler and still run in the browser.