The Glorious Return of Bytecode
Every time compute architecture dominance shifts the question of portability comes up. With developer machines using one architecture and servers using another, portable languages like Python increase in popularity. Recent graduates running a MacBook with ARM chips know what I’m talking about. That’s right: the shift from SPARC to x86. Think back to when expensive robust servers on SPARC, Alpha, Power, MIPS, and S390x architecture were being developed on x86 or PowerPC workstations and laptops. Java and C# were a breath of fresh air, as an optimized bytecode “binary” could be passed around to any of these platform/OS combinations and run easily in a world before virtualization or Docker. Imagine an optimized and memory safe build of your application that runs on Windows, Solaris/BSD/UNIX, Linux, and Mac regardless of whatever architecture 32/64 bit and whatever page size is being used. Imagine seamlessly moving your app from Intel to cloud-native ARM at lower cost and carbon footprint. This is the advantage bytecode gives. It’s also the advantage WebAssembly is bringing back for a world of cloud computing.
Then there was a significant shift in dominance as Intel’s commodity x86_64 (CISC) displaced most server chips, cloud chips, and even Apple’s original PowerPC silicon. With Intel being the defacto ISA there was no need for portability and bytecode languages largely fell out of favor. Intel became too comfortable in their dominance as low power efficient ARM (RISC) chips took over the mobile market share. Now after multiple scandals and vulnerabilities Intel sees market share shifting to ARM in servers, cloud, and even Apple going all-in on ARM. After all why should Apple maintain different binary builds for mobile devices and laptops? In addition to ARM we see RISC-V emerging as a potential competitor to keep ARM on its toes.
Now that there are multiple architectures available to developers again, most young devs are focusing on Python which provides portability but is still distributed as bloated script to be interpreted on each run and is highly inefficient when used at scale without JIT bytecode. I’m not one to hide my distaste for Python. Its overuse has resulted in bloated containers and services and production releases shipping with basic syntax errors and unchecked type violations, never mind the slow performance. A lot of young developers may scoff at what they consider older languages like Java or C# but the advantages are worth a fresh look. These language provide native type safety, threading, and static analysis at a performance that Python can’t match. While not performing as quickly as native C/C++, bytecode will almost always have better performance than an unparsed script.
The good news is WebAssembly solves a lot of problems presented by scripted languages. With a unified bytecode for any language to use in compilation it isn’t just Java that benefits from portability. So it doesn’t matter so much if you’re a Python or JS coder or a Java coder as long as the language supports compilation to WebAssembly aka Wasm. For more details have a look at this simple sample and repo with a Hello World written in Rust and compiled to Wasm. You can browse the binary build which shows the Wasm output is far smaller than an actual Rust binary would be.
Conclusion
This revisit of history is a great highlight of Web 2.0 -> Web 3.0 managing to iteratively improve on older technologies. Webassembly is not new (2017) but fixes a few flaws in earlier web-oriented cross-platform languages, mostly by unifying them into a generic assembly instead of a language-specific bytecode. It will be interesting to see how the technology takes off and if this concept will expand into backend use cases or offline application development.
