4 ms·

You’re right. Hotwire (specifically Turbo Streams) does use WebSockets under the hood when available. And yes, Rails has background jobs, ActiveJob, and other r

You’re right. Hotwire (specifically Turbo Streams) does use WebSockets under the hood when available. And yes, Rails has background jobs, ActiveJob, and other robust primitives that Phoenix was inspired by. That said, the key difference is not whether both use WebSockets, but how deeply integrated and unified the real-time model is in Phoenix. LiveView is not a separate layer bolted onto traditional Rails views. It is part of the core rendering lifecycle. Every UI update, state diff, and event is handled natively within the same process, leveraging the BEAM’s concurrency and fault-tolerance. In Rails, Hotwire sits on top of the request–response model, giving you partial reactivity without rearchitecting how views work. It is elegant, but still a composition of multiple layers (Turbo, Stimulus, ActionCable). Phoenix LiveView, on the other hand, was designed from the ground up around real-time stateful components, which leads to fewer moving parts, no client-side JS framework to maintain, and native process isolation per connected user. So while they share concepts, the philosophy and architecture diverge. LiveView feels closer to a full reactive runtime, not just HTML over the wire. P.S: I do love rails

pythonaut_16 1y ago
This is actually one of the huge tradeoffs and pitfalls of LiveView. Its websocket model is all or nothing. For example I have a small side project using LiveView where users would typically pull their phone out, quickly record data, then put it away again. But due LiveView only working with a connected websocket they often have to wait ~1s for the socket to reconnect, and get an annoying error message while it does. I'm sure there's more I could do to configure this but the default at least is terrible. I believe with Hotwire I wouldn't have this problem, my view would just work and then restore the websocket when it can. I use Phoenix and LiveView for a lot but I wish we could get more of these rough edges polished up.
- akarshc 1y ago
  that’s a really valid point. liveview’s websocket-first model can feel heavy for quick, intermittent interactions like mobile data entry. it shines when the user is continuously connected, but those short bursts do expose rough edges. hotwire’s approach of progressive enhancement and optimistic rendering handles these scenarios more gracefully since the view works independently of the connection. phoenix and liveview are still amazing, but improving these “short session” experiences would make it even stronger.
- bartblast 1y ago
  (Disclosure: I'm building Hologram) You might find Hologram interesting for this use case - it transpiles Elixir to JavaScript so your UI runs client-side. No persistent connection needed, so no reconnection delays or error messages. Still write in Elixir, still communicate with the server when needed. It's early stage with some rough edges, but there are already Hologram apps in production: https://hologram.page https://hologram.page

pythonaut_16 1y ago

This is actually one of the huge tradeoffs and pitfalls of LiveView. Its websocket model is all or nothing. For example I have a small side project using LiveView where users would typically pull their phone out, quickly record data, then put it away again. But due LiveView only working with a connected websocket they often have to wait ~1s for the socket to reconnect, and get an annoying error message while it does. I'm sure there's more I could do to configure this but the default at least is terrible. I believe with Hotwire I wouldn't have this problem, my view would just work and then restore the websocket when it can. I use Phoenix and LiveView for a lot but I wish we could get more of these rough edges polished up.

akarshc 1y ago
that’s a really valid point. liveview’s websocket-first model can feel heavy for quick, intermittent interactions like mobile data entry. it shines when the user is continuously connected, but those short bursts do expose rough edges. hotwire’s approach of progressive enhancement and optimistic rendering handles these scenarios more gracefully since the view works independently of the connection. phoenix and liveview are still amazing, but improving these “short session” experiences would make it even stronger.
bartblast 1y ago
(Disclosure: I'm building Hologram) You might find Hologram interesting for this use case - it transpiles Elixir to JavaScript so your UI runs client-side. No persistent connection needed, so no reconnection delays or error messages. Still write in Elixir, still communicate with the server when needed. It's early stage with some rough edges, but there are already Hologram apps in production: https://hologram.page https://hologram.page