Honest reflections on the technology that makes Hotwire look like a prototype
LiveView makes Hotwire look like a prototype. I do not say this to diminish Hotwire -- Turbo and Stimulus are genuine improvements for Rails applications, and the philosophy of sending HTML over the wire is correct. But LiveView takes that same philosophy and executes it on a runtime that was purpose-built for exactly this kind of work. The difference is not incremental. It is architectural. Hotwire bolts real-time onto a request-response framework. LiveView runs real-time on a runtime designed for millions of concurrent connections.
Here is what LiveView actually does: it maintains a persistent WebSocket connection between the browser and a server-side process. That process holds state, handles events, and renders HTML diffs that get sent to the client. No JavaScript. No API layer. No client-side state management. No React, no Redux, no Webpack, no npm. Just Elixir on the server, a thin JavaScript client that patches the DOM, and a WebSocket in between. The entire interactive UI lives in one place, written in one language, with one mental model.
The reason this works -- the reason it is not just a clever hack that falls apart at scale -- is the BEAM. Each LiveView connection is a BEAM process. Each process uses roughly 2KB of memory. A single server can maintain millions of these simultaneously. The preemptive scheduler ensures no single connection can starve others. The supervision tree ensures crashed connections restart cleanly. The garbage collector runs per-process, so a GC pause in one connection does not affect any other. Every property of the BEAM that seemed academic in Module 3 becomes practical here.
For someone who has dealt with the JavaScript ecosystem -- the build tools, the framework churn, the state management libraries, the bundle size anxiety -- LiveView is almost offensively simple. You write server-side code. The UI updates in real-time. That is it. The complexity budget you used to spend on frontend infrastructure gets redirected to actual features.
The honest caveat: LiveView is not appropriate for everything. Offline-first applications, highly interactive graphics, applications where latency to the server is consistently high -- these still need client-side solutions. LiveView requires a WebSocket connection, which means it requires a server, which means it requires latency to be manageable. For the vast majority of web applications, it is. But it is not universal, and pretending otherwise would be dishonest.
Conclusion #
LiveView is the strongest argument for the Elixir ecosystem. Not because it eliminates JavaScript -- that is a symptom, not the point. Because it demonstrates what becomes possible when your runtime was designed for persistent connections, lightweight processes, and real-time communication. The feature itself is remarkable. What it reveals about the BEAM's capabilities is more remarkable. This is the module where the entire curriculum comes together into something you can show people.
Predictions #
-
You will build a LiveView feature in an afternoon that would have taken a week with Rails plus a JavaScript framework
-
The absence of a JavaScript build pipeline will feel disorienting for exactly one day, then feel like freedom
-
You will start mentally categorizing features as "LiveView features" and "traditional request features" and most will be LiveView features
-
Real-time collaborative features that seemed ambitious in Rails will feel trivial in LiveView
-
You will demo a LiveView application to a Rails developer friend and watch their face go through confusion, skepticism, and then genuine surprise