Webassembly: Do I Want That?

From a first glance at the Webassembly (abbreviated as WASM) site, it’s hard to tell what it’s for. A little bit of digging, though, gives me the idea that it’s a way to write an application that gets delivered to users from a web server and which runs in the browser. This is sort of like Java applets or Angular or Flutter apps. The world, apparently, needs yet another one of these things because…well, obviously, because they all suck in various ways as anyone can tell you. So why does WASM not suck? Apparently, the way that WASM is cool is that you write the code in the programming language that you actually like to use, and then there’s a compiler that will read that and output WASM. So you don’t have to burn out your brain remembering the syntax and idiosyncrasies of lots of stupid programming languages and frameworks, just a couple.

So, okay. Maybe it’s good? Let’s see: my favorite programming language today is Swift. I write servers with Swift. I’m working on a project right now that has, as a requirement, a client component that should work for Windows users, Linux users, Android, iOS, macOS, etc. The point is, the client is just a REST client that sends data to the server and gets data back and displays it to the user, and there’s no good reason to require the Solo Registrar to have a particular brand of hardware or operating system. Nonetheless, such a client has a bunch of state and, let’s be real, there’s going to be a lot of fiddly UI work involved. Sure, it would be nice to do all that fiddly UI work in a language and using frameworks with which I’m already comfortable.

Is WASM plus Swift a good choice for this project?

Well, let’s see. The guys at Pointfree just released a video showing how their observation library integrates with WASM, so that’s pretty cool. That means that maybe my favorite client framework, The Composable Architecture, will work? Maybe? Okay, let’s keep going.

Oh, you use carton to build and package a WASM project and that’s because it manages the toolchain, cool, cool…oh, you don’t actually get to use SwiftUI, you use some other thing called Tokamak and it is some kind of subset of SwiftUI, and they’re looking for support. Hmm.

Wait, you don’t get concurrency? Oh, you sort of get tasks, if you call out to JavaScript and use its event loop? This is sounding sketchier by the paragraph. Listen, I’m writing a REST client. I don’t actually care about displaying a button that the user can click on in order to increment a local counter. I want to display a button that the user can click on to fire off a web request, and when the request returns data then I want to display a view that organizes that data in a way the user will find helpful.

My frustration is building, here, people. Like, maybe I can do what I want, here? But none of the toy examples showing, “Hey, our new kick-ass framework is totally awesome for building the thing you want to do!” actually show any instances of doing the things I care about. Meanwhile all the notices that, “Our kick-ass framework is not yet complete, and here are some of the things it doesn’t do yet,” are disturbingly close to the things that actually matter, like shoving long-running tasks into the background so you don’t have an unresponsive UI, or actually constructing a UI in a way that remains idiomatic to the programming language you’re using. I mean, if I wanted to be programming in JavaScript, or if I wanted to be driving myself crazy keeping track of a zillion CSS rules, I would be using Angular or React or something.