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

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.

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.

(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

Ya, this was not worded well at all (and more likely just not well researched (in the article, I mean). The difference between hotwire/livewire and LiveView is that with LiveView you get a "live" connection to persistence BEAM process which comes with benefits like not having to rebuild things (like the current user) on each request and storing ephemeral state on the server (if you need it). Of course there are trade off like PWAs are not fun in LiveView (you likely just wouldn't do it, I never have).

> "live" connection to persistence BEAM process

This particular bit does seem interesting and would make sense to take advantage of the BEAM's cheap green threads. Couldn't find any info on LiveView's GitHub landing page nor the Phoenix website (haven't dug too much), do you happen to have a link?

The guides are the best place to learn about LiveView itself. Since guides are always included as part of the docs (reference docs) people always tend to shy away from them (not saying you are, it's just a thing with people it seems):

https://hexdocs.pm/phoenix_live_view/

Oh also wanted to point out that while there has been an ongoing effort for LiveView Native, it is not there yet (I actually haven't heard anyone talking about it in quite a while). I'm not too in the Rails world so I don't know how good Hotwire Native is, but I assume it's much further along than LV Native, so that's a big thing if you need that. No idea about LiveWire as I've never even been in the Laravel world.

The author is a self-professed front-end developer according to LinkedIn, which may be influencing experience with backend systems and functionality. I was wondering really why this terse post is sky-rocketing to #1 today, hopefully we get some good discussion from the community.

Any kind of comparison of popular frameworks activates all the dev nourons in my monkey brain.

Yeah I feel like most devs still think of rails as it was about... 8 years ago.

18

Yeah it has become much more solid recently

Websockets are the wrong choice. SSE is the way to go. That or your own UDP protocol.

What's the advantage of using SSE versus WebSockets in this instance?

It's standard http so you don't have to build your own bad version of http on top of it. It's handles disconnects for you. You can use the browsers built in compression over the life of the connection. You have access to brotli/zstd without having to ship it to the browser first (and it's the C++ version).

In short it means you don't have to do any manual diffing, just let the compression do it for you, and have something on the client like morph to merge it in to the dom. It's way more bandwidth efficient as compression is at the byte/char level not at the semantic html level (and not per message but over the whole stream).

Hotwire lets you use either. https://turbo.hotwired.dev/handbook/streams