The Evolution of Web Development: Rails in the Browser Link to heading
Fifteen years ago, Rails arrived like a thunderclap. David Heinemeier Hansson demonstrated a blog in 15 minutes, and suddenly, the world saw web development in a new light. Productivity skyrocketed. Convention over configuration became a guiding principle. Developers felt like magicians.
We’re entering a new era of web development: running Rails entirely in the browser with WebAssembly (Wasm). This isn’t just about performance or portability—it represents a fundamental shift in how we develop, deploy, and even think about software. I was tipped off to this development by Vladimir Dementyev’s article on web.dev.
Rails in the Browser: A Technical Perspective Link to heading
What does running Rails in the browser actually mean? The process starts with a traditional Rails setup, but instead of deploying it to a server, we package it for WebAssembly execution. Here’s how you’d do it:
- Initialize a New Rails Application:
rails new --css=tailwind web_dev_blog cd web_dev_blog - Generate the Scaffold for Posts:
bin/rails generate scaffold Post title:string date:date body:text - Migrate the Database:
bin/rails db:migrate - Run the Application:
bin/dev
At this point, we’d traditionally run this on a server. But instead, we compile it into WebAssembly using ruby.wasm, a project that enables Ruby execution in browsers and edge computing environments.
The Tradeoffs: Reality vs. Hype Link to heading
Right now, the reality is that Rails-on-Wasm doesn’t simplify development; it adds complexity. You need both the traditional Ruby stack and the WebAssembly stack, meaning an extra layer of tooling and potential failure points. While it’s an exciting proof of concept, we’re still far from WebAssembly being the default deployment target for Rails applications.
For this to become practical, a few things need to happen:
- A Unified Builder: A tool that eliminates the need to manually juggle Ruby and WebAssembly setups, allowing real-time code changes and recompilation in the browser.
- Streamlined Dev Environments: Right now, setting up Rails-on-Wasm requires juggling both a local Ruby stack and the WebAssembly toolchain. Instead of simplifying development, it introduces extra complexity. What we need is a self-contained WebAssembly-based Rails environment—something that bootstraps the process and allows live code editing and recompilation in the browser. If WebAssembly can truly abstract away the traditional setup, we might finally see a dev experience as seamless as simply opening a browser tab.
- Robust Data Handling: Running Rails in the browser means rethinking database interactions. Do we push more logic to the frontend? Do we rethink storage?
The Future of WebAssembly in Web Development Link to heading
Despite the current limitations, the potential here is massive. As WebAssembly matures, we may see:
- Seamless Development-to-Production Workflows: No more mismatched environments between local dev and production.
- Performance Gains: Running server-side code client-side could dramatically reduce latency.
- A Polyglot Web: Wasm allows languages beyond JavaScript to run efficiently in the browser, opening the door to new paradigms.
We’ve been here before. In the early days of Rails, people doubted it could scale, doubted it could handle real-world applications. They were wrong. Maybe, just maybe, we’re looking at the next transformation in web development. The tools aren’t ready yet, but the idea is too compelling to ignore.
One day, spinning up a full Rails app in the browser might be as easy as opening a tab. We’re not there yet—but watching it unfold is going to be fascinating.