If you’re sending data from one computer to another, it’s probably JSON. But it hasn’t always been this way.
How we Transmitted Data Before JSON
Before JSON got popular (2005ish) we had XML, CORBA, Java serialization, Python Pickle, and a bunch of other clever and complex encoding schemes. One thing that Really Sucked about these schemes was getting different platforms to share data.
Perhaps my writer program would make an XML file with schemas and namespaces and UTF-8. Perhaps your reader program would ignore all that ceremony and do the basics. And then our data would degrade in transit! Seeing
’ replaced with
is still a very familiar failure mode.
Or perhaps we’d use Java Serialization. That 100% Pure Java solution was easy to get started, awful to change, and impossible to secure. This was a standard industry practice in the bad old days!
JSON is Universal
Today, JSON is everywhere.
Because reading and writing JSON is simple, clients and servers need not agree on a tech stack! You can use a programming language that you like on your server; I’ll use what I like on the client; and it’ll just work.
(If you really need a compact encoding you can use Protobuf, but even that specifies a JSON representation.)
How we Build Software Before WebAssembly
Before WebAssembly gets popular (2024ish), we have the JVM, NodeJS, Python, Rust, and a bunch of other clever and complex programming platforms. One thing that Really Sucks about these platforms is getting them to share behaviour.
Perhaps I write a Kotlin library that implements my company’s authorization policies. Perhaps your Go program would like to call my library. Now we’re in hell! You can fork a process, or deploy my library as an HTTP service. Whatever we do, it’s going to be slow and clumsy.
WebAssembly is Universal
WebAssembly is rolling out everywhere.
I’m looking forward to packaging up business logic as a WebAssembly library and letting my users consume it everywhere: the JVM, NodeJS, Python, Rust, plus tons of niche programming platforms.
Extism is running with this. They’re making abstractions so bridging into WebAssembly is easy.
My team at Cash App is working on something similar with Zipline. But instead of using WebAssembly for polyglot, we’ll be using it for dynamic updates.
WebAssembly in 2024
I got really excited by reading Andy Wingo’s post:
It is in this sense that WebAssembly is a new fundamental abstraction boundary.