Many years ago, there was a programming language experiment named Wyvern that promised the polyglot developer he could, in the same file, write each function in a different language, and it would all work. It was a crazy idea at the time, but now? Now we write this way all the time. The Web Assembly Component Model is only going to make that all the more true.

Web Assembly

WASM, also known as Web Assembly, is a bytecode and interpretation specification for a low-level programming language that can be executed in a safe, sandboxed manner. It takes all of the experience writing JavaScript interpreters (and other processors) and turns that knowledge into a virtual machine that is as fast as native code.

WASM has a virtue: at its core, the only thing it can do with the outside world is access an array of memory made up of 32-bit integers. That's it. On it's own it can't do anything else. You can write those functions in any language you want, but WASM is a pure, functional interface: you put data in, you get data out. Any language that supports functions of type (data: i32[]) -> i32[]) can be compiled into WASM. The list of common languages that can compile to WASM and are considered production-ready is already impressive: C, C#, C++, COBOL, F#, Forth, Go, Lua, Rust, TypeScript, WebAssembly, Zig. And there are many more in the works. The "mature" languages all support interfaces that allow each functiIon to access memory from the host environment (usually but not necessarily JavaScript, and becoming less "necessarily so" with every day), and provide mappings so that strings and dictionaries and such can be serialized back and forth via i32[] format.

All that copying and translating of i32[] can be expensive, though. WASM isn't always faster than native JavaScript, but it has its place when doing things like game programming where 3D rendering a frame has lots of internal mathematical needs.

The Wyvern Programming Language

Over a decade ago, the Wyvern programming language promised that if you had a strong type-definition for a language, you could add that language's syntax to Wyvern and it would Just Work. You could write one function in C and another in Python and a third in Scheme all in the same file and the Wyvern compiler would create the appropriate interfaces for each function to be able to call any other, as long as the types matched up.

Wyvern has involved into something else entirely. The reason for this is pretty simple: Most developers are good in one or two languages, and either don't know any others at all, or are weak in others, and definitely wouldn't want to switch the mental gears needed to go from reading someone's C to someone's Scheme while trying to puzzle out what a program does and why it's currently broken. I mean, I'm a heck of a polyglot, but right now, I consider myself an expert in both JavaScript and Python, skilled in Go, SQL and C, and an amateur at Rust, Haskell, and Scheme-- and I wouldn't want to have to mentally parse multiple syntaces in one file.

Only young academics head-deep into Programming Language Theory would think "You know, this recursive function to traverse the character list is best implemented in Scheme, but the renderer is easier in C, and I'll just shove them all into the same file."

The Web Assembly Component Model: Wyvern 2.0?

The Component Models for WASM provides a promise similar to Wyvern. You can write many different functions in whatever language is most appropriate for each function's need, and the WASM-CM will figure out how to make the passing of data between one function and the next as efficient and copy-free as possible within the VM. It will no longer be necessary, as it is now, for the host environment to mediate the passing of data between different WASM code.

There are different ways of thinking about this:

First, this could be Wyvern 2.0. The functions wouldn't necessarily all be in the same file, but they would be in the same project, and would require developers be fluent in the different languages used to implement the various functions used by the project.

Second, this could be an evolution in the skillset developers need to master. Functional programmers who think Haskell and Rust are nifty are part of this evolution. The function signature contains the truth, and the description of the function is all we need. Developers wouldn't need to be fluent in the language at all; they just use the function that Does The Thing.

We've already been here for awhile

We're sorta used to this method but without the discipline of Haskell or Rust. APIs send us data we just have to wrestle with, with no type safety and no assurances. We pull down libraries from the net and insert them into our code, trusting that they're not malicious. A recent project I worked on had 517 (!) dependencies, and that's actually pretty small for a complicated web development project. The browser development is brutal; we have to code in Javascript, Typescript, HTML, CSS, with all sorts of DSLs (domain specific languages) for search, for interacting with the network, for accessing the graphics engine (Canvas and WebGL and SVG, oh my!). We have to know the declarative languages used to describe the modern build and deployment systems, and there's a separate set of such languages for testing the components.

I've started to call this methodology "sorcerous programming;" we don't understand what's going on under the hood. We just try to use the library according to the description given in the documentation, invoking it through ritual and guesswork, testing our assumptions and empirically determining that the library's behavior is "good enough."

In many ways, the WASM-CM model is just going to make that sorcery more prominent. We have APIs we tickle for data, and it gives it, and we don't know where it came from. Large language models like Chat-GPT and Stable Diffusion produce text and images based on our prompts, but we have no idea why changing the position of two words in our prompt means the characters drawn will or won't have the right number of fingers. The React scheduler means that our web pages might behave correctly, but if the programmer doesn't have the right kind of experience it's entirely possible the page might misbehave if the computer is slower than the hot boxes developers typically have.

And The Train It Won't Stop Going, No Way To Slow Down

I'm hopeful. We're already in a place where Madness abounds; developers are burning out because they're expected to know how to do thirty different things while actually holding "the business value" or the "return on investment" in their heads. Programming has always been hard, but web development is notoriously so, spawning articles like How Web Development Got So Complicated andI Can't Keep Up. I don't know if WASM-CM will make it any better, or if it'll just be Another Thing we're all just gonna have to live with. But I have to be hopeful, because the alternative is just disappointingly more workload with less reward.