Writing Software for the Browser with Drifting in Space

If you have an interest in browser-based software, this is the Q&A for you!

We were lucky enough to sit down with Paul Butler from Drifting in Space — Paul is someone who’s been on our radar for a while due to his fascinating history as a data visualization specialist and software engineer, and who is currently working on a litany of projects around improving browser-based application development.

In this piece we’ll cover software distribution fundamentals, the state of the art for multiplayer experiences, and how to create software that makes the web feel like magic.

Sound good?

Let’s dive right in!

Y-Sweet Cloud is a yjs-based multiplayer-as-a-service tool from Drifting in Space

Railway: Ok, first question: Why do you like building for the browser? Is it just the most universal substrate for software today? What makes the browser such a special medium in your mind?

Paul: What I love about browsers is that they are an incredibly low-friction way to distribute software.

Part of that is the universality, like you mention.

As a developer, I don’t need to compile an app for AMD64 and ARM64, I can just build one JavaScript or Wasm bundle and have it run on any OS, any architecture.

Another part of it is the distribution mechanism itself: I can just send anyone a URL and they can be using the app in seconds.

But the big thing to me about how browsers reduce friction is that they isolate applications. I’m way less hesitant to click a link than I am to install an app from a new publisher.

As I see it, modern browsers are essentially a security technology. If you look at how web APIs are evolving now, the most interesting developments involve taking some aspect of the host machine and providing a secure way for untrusted code to access them.

For CPUs it’s WebAssembly. For GPUs it’s WebGPU. For hardware-accelerated media encoding it’s WebCodecs. For UDP networking it’s WebTransport. The use cases that only native apps can handle keep getting smaller.

Jamsocket, also by Drifting in Space, is a session backend platform built for WebSockets

Railway: You have such an interesting background, with experience as a software engineer, data scientist, quantitative analyst, and now working on browser-based software. What’s the thread that links your work together? Is it something to do with an interest in how we visualize information? Or something else?

Paul: I am generally a curious person. I was drawn to data science because it’s essentially being a professional question-asker — you have a business problem and a pile of data and get to say, “Ok, how do I get from here to there?”

I came to data science from a programming background, so I approached it as a tool builder. I am not satisfied with just answering a question, I tend to build tools to make it easier to answer similar questions the next time. I often had more impact by sharing the tools I created than the actual data science deliverables.

The work I’m doing at Drifting in Space is sort of the next level of that – I wasn’t satisfied with the tools available for developing tools, so I decided to spend my time on that.

Railway: Let’s talk about Y-Sweet Cloud. This is a managed Yjs backend product that provides CRDTs as a service, is that right? What can you tell us about this product? Is your goal to put to bed forever the “OTs vs CRDTs” debate?

Paul: Yeah, so to give readers some background, CRDT stands for conflict-free replicated data types. They’re a type of data structure that you can duplicate across a network, modify each copy independently, and then recombine to get a version of the data that incorporates all of the modifications. They’re one approach to building multiplayer collaborative applications, OT (operational transformation) being another. Yjs is the most popular open-source CRDT library.

The origin story of Y-Sweet is that I wrote a newsletter post arguing that large, document-like data should be stored in blob storage rather than in a relational database. It did the rounds of developer newsletters and Hacker News, and people started asking me, “Ok, cool, but how?”

So I wanted to build a simple but robust implementation that people could use.

I needed a way for a client to send incremental updates to a server-side JSON document, and I knew that Yjs could do that. As a bonus, going with Yjs meant plugging into an existing ecosystem of multiplayer components. You can take existing code editors or a tldraw canvas and have them integrate nicely, because they support Yjs.

Likewise, an app built on Y-Sweet can easily be modified to talk to a different Yjs backend, and vice versa. This interoperability was really important to us. With most commercial realtime backends today, you’re locked into a particular vendor, and developers who have been burned by vendor risk before are rightfully wary to use them.

I’m pretty pragmatic about when CRDTs are the right tool for the job, and have even argued that developers are too quick to reach for them when simpler approaches will do. But CRDT tech and the momentum around it got too good to ignore.

Railway: What are some Y-Sweet Cloud users doing with your software? What use cases do you find the most exciting?

Paul: As you might expect, a lot of the people we hear from these days are building AI apps. Even though there is nothing AI-specific about our tech, it happens to fit nicely into that sort of stack. My colleague Felicia has written about using a multiplayer data layer as an architecture for integrating AI into an app – basically, letting AI be another collaborator in a collaborative app. That direction excites me!

Plane is Drifting in Space’s open source WebSocket engine

Railway: What can you tell us about how Y-Sweet Cloud uses Railway? What does Railway enable that otherwise might be painful to tool?

Paul: Y-Sweet Cloud consists of several services: the realtime server itself, an API server, a web UI, and a marketing site. Aside from the realtime server, which is open source, everything lives in a monorepo.

What I like about Railway is that we can get a preview environment with all of these services with each pull request we open. When we merge to main, it automatically deploys to our staging environment. We then manually invoke a GitHub action to push to production.

Even though we already have an internal Kubernetes cluster and infrastructure-as-code setup, we decided to go with Railway for Y-Sweet Cloud so that we weren’t spending time writing YAML files when we could be working on the product.

Railway: If readers are interested in learning more about Y-Sweet Cloud and Drifting in Space, what’s the best place to get started?

Paul: You can learn more at y-sweet.cloud, or see our GitHub repo for y-sweet. You can learn more about the company at driftingin.space and follow us on Twitter at @JamsocketHQ.