Building in-person developer communities with Paul Butler from Drifting In Space
Paul Butler built a New York meetup for a community he suspected didn't exist yet, aimed at people who quietly stopped calling themselves "web developers" once their codebase became Rust compiled to WebAssembly rendering straight to a GPU. It started with a batch of takeout tacos.
Paul Butler is the co-founder of Drifting in Space, which builds Jamsocket and the open-source Plane server behind it — infrastructure for browser applications that need a 'session backend': a temporary remote process tied to the lifetime of a single browser tab.
We get into how heavyweight browser apps like video and 3D editors get around WebAssembly's memory ceiling by offloading compute to a remote machine, why he started the Browser Tech meetup community from scratch, and the very specific customer profile: people building something so ambitious for the browser that a user would upgrade their RAM to run it.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
What problem is Drifting in Space actually solving?
We've watched application software move into the browser for well over a decade — you can trace it back to database apps and Google Docs in the 2000s, and increasingly it's things like 3D editing, video editing, CAD software, and geographic data manipulation. The problem is these applications expect heavyweight resources, 32 or 64 gigabytes of memory, and WebAssembly gives you maybe 4 gigabytes in the best case. We built a way for these browser-based applications to spin up what's essentially a child process on a remote server, with a low-latency direct connection, splitting compute between the browser and that remote machine. We even support remote rendering in that child process, streaming the result back as compressed video and rendering it inside the app as a React component.
Is the goal something like a more powerful Figma?
We took real inspiration from Figma's architecture — they've been generous writing about what was, at the time, a genuinely pioneering approach, and you see similar patterns in things like GitHub Codespaces. We're extending that underlying idea by adding a high-compute layer — making the scheduler aware of how much memory, GPU, and CPU capacity each machine has, so you could build something that pulls down 10 gigabytes of data per user. You obviously can't do that at Facebook scale, but you can at the scale of an internal enterprise app dealing with large datasets, or an expensive SaaS product. Vector graphics editing is inherently a computationally lighter problem, which is why Figma can do a lot purely by compiling to WebAssembly — but something like a video editor or 3D modeling tool needs real heavyweight compute that WebAssembly alone can't give you.
You've said browser apps have generally had to accept being behind desktop apps. Is that changing?
People have long been excited just by the low-friction experience of opening a URL and being immersed in an application, and for a while we've tolerated that kind of app being janky, slow, and less featureful as the trade-off. As technologies like WebGPU, WebTransport, and WebCodecs mature over the next few years, I think that changes — there'll be genuine competition on performance, not just on the table-stakes fact of running in a browser at all.
How did the Browser Tech meetup community actually start?
We started the company in early 2022, when people were still wearing masks and in-person events were still frowned on. Around August, things loosened up, and there was a real hunger, at least in New York, to meet people again. A lot of the pre-COVID meetups had simply ended — organizing them takes real energy, and corporate sponsors often churned through people, making it hard to reboot. So there was this blank slate with very few recurring meetups happening. We also noticed browser development had bifurcated during COVID — one world building Next.js apps and Gatsby blogs caring about SEO and bundlers, and a very different world of people writing Rust compiled to WebAssembly, sometimes bypassing the DOM entirely to render straight to the GPU. Those developers were technically deploying to the browser, but they weren't really identifying as 'web developers' in the traditional sense — the browser was just the new operating system to them. We wanted to be in the same room as those people, and when we looked, that specific community didn't really exist yet in New York.
What did the very first version of that meetup actually look like?
We looked at who was building these kinds of applications in New York, and just invited people out for tacos — including Runway ML, who were building a video editor in the browser. When we asked if they'd host, they said yes, so we basically got a bunch of takeout tacos and sat down with a handful of application developers in the city. That's when we realized there was a real critical mass of people, and it made sense to formalize it into a proper meetup with talks.
What kinds of talks have people actually given at Browser Tech?
High-performance React, a talk from Runway on creative ML tools running in the browser, scaling DuckDB in the browser, and one of the most fascinating — a talk from Vamp, a 3D editor that runs in the browser using server-side pixel streaming of GPU-rendered content back to the client. It's a genuinely powerful architecture to see up close.
What's the actual value of getting these specific people in the same physical room?
Talking to a lot of these builders in customer conversations, we kept finding that people were independently discovering the same things or hitting the same problems with no real means of knowledge-sharing between them. More mature communities, like React or Svelte, have well-established online and offline spaces where people talk through the tools they use. But for people pushing the raw edges of browser APIs — WebGL, WebAssembly, all the 'web-prefixed' technologies — there were scattered single-technology meetups in some cities, but no space for people actually building advanced, ambitious applications using all of that together. That's specifically the blank space we felt we could fill.
How do you keep Browser Tech from just feeling like a marketing arm for Drifting in Space?
We've deliberately kept the Browser Tech brand and community at arm's length so it doesn't read as just our megaphone. We obviously benefit from it — we usually give a couple of talks and demo what we're working on — and I run a newsletter that occasionally mentions our own work, but I try to keep an independent voice in it rather than making it feel like pure self-promotion.
Does running the community and newsletter feed back into product development?
A little, yes. Writing the newsletter is easy for me because it's really just what I've already learned talking to customers and following the industry — I was already building up a mental map of what's happening in the browser and who's pushing it forward. We love signing up for betas of new collaborative apps, running them in the office, and talking through how they were built. One recent issue was about GPU-rendered UIs — applications that talk directly to a GPU API like WebGL to render their entire interface, barely touching the DOM except to grab a canvas element's context. We noticed that pattern emerging over the last couple of years and wrote about the trend, rather than deconstructing any single app.
How would you describe your actual target customer?
People building genuinely ambitious applications in the browser — pushing right up against what's currently possible there. The technology solves a real problem: you've hit a wall, either because you're dealing with so much data you can't reasonably send it all to the browser, or because the computation itself is too heavy. Video editing at 4K can mean gigabytes or terabytes of data you simply can't push over the network. We have a demo where we load a massive point cloud, millions of points, deliberately choking the browser, then almost instantly switch to remote rendering on a dedicated GPU machine and stream it back. If you're building a blog or an e-commerce site, you're not our customer — but if you're building something that, if it ran natively, someone would upgrade their RAM just to use, that's the scope we're aimed at.
Do people usually self-identify as a fit, or do you have to convince them?
Often people self-identify — they've already sketched out in their head roughly what infrastructure they'd need to build this themselves, concluded it would be better if someone else had already built it, and then found Plane. It becomes a discovery moment rather than something we have to pitch hard.
How is the open-source project structured relative to the commercial product?
Plane is our flagship open-source project, and Jamsocket is built on top of it as the managed version — there's a full spectrum from fully self-hosted to fully managed, plus a middle ground where you run the actual compute on your own machines but use our central control plane to coordinate it. In that middle setup, none of your application data ever passes through us — only coordination and routing data. We handle DNS, certificates, orchestration, and scheduling on our end.
How does the business actually make money given the open-source core?
We get paid for infrastructure. Someone running the fully open-source version could, in theory, never talk to us at all, though we could negotiate a support contract. Revenue comes from the managed side, priced on usage, and from the middle control-plane option, which is more of a monthly fee plus a per-machine fee — closer to a Datadog-style model.
Technically, how does a session backend actually work from the browser's side?
You push a Docker container to us, and instead of deploying it immediately, you get an API — every time you hit it, we spin up an ephemeral instance of that container and hand back a hostname. From the browser, you open a WebSocket connection to it; whatever's running inside the container needs its own WebSocket server, but we're not prescriptive about the framework — Node.js, Python, whatever you want. Once that connection closes, if it was the only one connected, we schedule the container to shut down. We call this 'session-lived' — the process stays alive exactly as long as the browser tab is open.
What does the actual customer profile and buying moment look like?
People often come in to poke around individually first, but where we see real adoption is typically seed and Series A stage companies — teams building something new or hitting real scaling pain, realizing that naively putting one vertically-scaled machine behind a load balancer stops working once they've relied on in-memory state. A common pattern is someone saying they saw Plane on GitHub or Hacker News six months earlier, didn't think much of it at the time, and then had a moment of recognition once they actually hit the exact problem it solves.
Is this a genuinely new concept that requires its own vocabulary?
Yes — we've had to build the vocabulary around this ourselves. We call this pattern a 'session backend': a process that lives for the lifetime of a browser tab. Figma was doing something like this, Codespaces was doing something like this, but there wasn't really a name for it before. Educating people about that architecture has been a slow process, but once it clicks, it clicks completely. We wrote a blog post specifically to help that click happen, and we've given talks in person that are now on YouTube — trying to explain the same underlying concept from a few different angles, without pushing Plane as the only possible solution, since other people are solving similar problems with their own infrastructure on top of things like Kubernetes.
You had a hot take recently about cookie banners hurting Hacker News traction. What's the actual theory?
My theory is more nuanced than 'cookie banners are always bad' — it's that they're specifically detrimental when you have zero social proof yet, which is exactly the situation you're in trying to move from the Hacker News 'new' page to the front page. I looked at sites like Fly.io and Supabase and noticed they simply don't drop cookies on their blog at all, tested it from a few different IPs to confirm, and we've followed the same approach ourselves, using Plausible instead of anything that requires a banner. To be clear, that's not an argument for violating GDPR — it's about not needing the banner architecture in the first place if you're not tracking that way.