Where's the facepalm emoji?
Rails Hotwire uses websockets... The research done here seems to be so basic it literally missed something written on hotwired.dev's landing page, albeit it's mentioned far down enough you have to scroll a teeny tiny bit (half a page on my screen)...
Rails also has background jobs and all the other things considering Phoenix is modeled after Rails.
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?
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
Smalltalk was a fun language to work with, albeit academically.
Goroutines probably come closest.
Thank you, this is the key factor -- a fundamental design decision that influences the foundation.
(Although I must say the advantages you listed — a strong compiler, concurrency, reliability — do sound universally good.)
It would have been interesting to see the specific problems you had when building specific features, and how the unique advantages of this stack helped you solve them.
However as far back as I can recall it’s shift onto the dev stack was less about “is it a good framework” and more about “this framework can help Product org prototype faster”.
With the advent of Llms, will Product org even care about the dev speed for prototyping?
?? Phoenix Live View IS server side rendering...
Specifically I wanted to run both the API and website on the same server (since it was a small company), and with Rails the gem Devise didn't natively support both and while rodauth claimed to support both I couldn't get the build flag to work. With phoenix it just worked out of the box with the most popular libraries, allowing me to move on without becoming an expert in backend frameworks. I agree with most everything else the author said too, specifically about it being more performant and liveview allowing me to build more dynamic websites easily.
Sounds like a Devise problem.
It's worth noting that the creator of Elixir was also an author of Devise.
But you do need to solve a lot of stuff that Laravel already solves for you.
- no JS (well a tiny bit ships with Phoenix but I never have to look at it), no NPM, nothing that breaks every week
- the whole system lends itself to executing on multiple cores
- GenServers BEAM processes in general are amazing
> I still needed background jobs, real-time updates, and two-way communication that just works. Those things are possible in Rails and Laravel, but they take a bit more effort to set up.
These all have first class support in Laravel out the box.
Rails has everything he mentions as an advantage of Phoenix. He's also implying that Rails does not use web sockets to communicate with frontend which is not only wrong it should be evidently wrong to anyone who built a Rails app in the last 3 years.
That's not to say that Phoenix and LiveView aren't phenomenal tools, they are! However what's keeping me in the Rails world is Hotwire Native. I truly feel like a one man army building mobile and web apps in a quick turnaround time.
That being said use what you like and hotwire native sounds cool will give it a try. I also think the author of the blog shouldve went a bit deeper with his points
To be honest one of the reasons I don't like Phoenix is that even if I opt-out of LV in the generators, I still get a lot of LV code.
As for Livewire - it feels like a simplified copy of Phoenix. In my opinion, it’s less advanced and less intuitive. For example, Livewire components don’t support slots, while Phoenix components handle them without any issues. Slots are critical for clean component composition - without them, you end up with messy, repetitive templates and a lot of unnecessary logic in the components themselves.
When it comes to Next.js, constant router changes and questionable decisions have become a daily routine. There’s no point integrating with something that gets rewritten every week and can’t be trusted to stay stable.
Using Node.js would hurt productivity but it's more powerful if needed. It may be needed because it has async/await and it has socket.io. It's also possible to use Typescript.
Next.js can be useful if you need everything (good SEO + highly interactive) but let's be honest how many websites need good SEO and websockets? LinkedIn maybe.
Next.js server performance isn’t great either - honestly, it’s pretty bad. Pages don’t feel that fast for users despite all the tricks and optimizations. In my opinion, metrics like LCP and others are much easier to optimize in older, more traditional frameworks. Unless you’re building a full-blown web application, a classic web page will almost always be faster and simpler to deliver without all the Next.js complexity.
In newer versions, import maps are recommended instead. The problem is that import maps enforce ESM, while Sprockets (as far as I know) doesn’t support ESM at all. On top of that, there are compatibility issues with Turbo links, various form libraries, and the limited extensibility of the import map library itself - adding extra dependencies is just painful.
Installing CKEditor wasn’t straightforward either, so I ended up creating a small DSL to simplify it. But then came another challenge: providing support for custom plugins in a way that would work with every Rails version, even without a bundler.
All of this is made even harder by the fact that CKEditor is distributed in both cloud and NPM versions, which complicates integration paths further.
In contrast, Phoenix makes things much simpler. From what I remember, the standard setup uses esbuild, which automatically pulls NPM dependencies from the deps directory - the same place where Elixir libraries are installed. This means you can distribute a package that includes both the Elixir and NPM parts of the editor, without having to manually modify package.json or worry about dependency conflicts.
7 years in on an elixir startup that has well over a thousand active paid accounts using our system every day to run critical businesses. I have to politely disagree.
USE OBAN from day one for any kind of background jobs. do not trust genservers. they lose their state if a pod goes. There's no retry logic built in.
> Start there and only use Oban if there's some form of consistency/resumability guarantee that you need.
oban is easy enough to integrate. it takes like 10 min of your time and you get a LOT out of the box. use genservers if you're running ephemeral servers but if you are creating background tasks, absolutely use oban for anything you plan to put on production.
Oban is such an easy value proposition to justify. consider it as important to learn as core phoenix
Hope to be wrong though. Erlang based systems are really interesting and under appreciated.
But I could be completely wrong (or have the wrong perception).
Note: not at all suggesting hardwork/progress isn't being made.
edit: eh, I just went to check and they just has a release today :D
https://elixir-lang.org/blog/2025/10/16/elixir-v1-19-0-relea...
2. Teach them Elixir
3. Profit
Possibly the one thing that Rails still does better is generating quick throw away CRUD apps with their generators. Rails is still pretty much flawless in that regard. That beings said, when things mature and complexity grows Phoenix/Elixir is definitely the better all around tool.
If I understand correctly all state is managed by the server, which means even the most trivial UI interaction needs a roundtrip. Not to mention the cost of managing the state and connection of every client. So how does that work in practice?
Same goes for whether they’re on some flakey mobile connection in a car or on a train.
It’s also super easy to accidentally send a ton of data down the wire on component mount. I worked on a massive LiveView app at a company you’ve heard of and these kinds of issues were a problem the whole time.
You also give up the standard stateless HTTP request/response model when you go with LiveView. This is not necessarily bad, but people should be aware that they’re turning their stateless web tier into a stateful web tier. It’s an entirely different model (and in my opinion, more challenging).
LiveView is cool technology but I don’t want people to overlook the fact that it has some sharp edges you have to be aware of when building large products.
But yes, for interactive elements it's not optimal. They have some JS helpers for simple things but you may need to drop down to JavaScript hooks yourself if you want do better.
I've been playing around with Hologram, which transpiles Elixir to JavaScript. It's very early days but it has the potential to be a much better solution than LiveView.
client disconnects, state desyncs, then reconnects, then liveview figures out via crdt and other things how to accurately diff the state
feels like i have to trust it too much - i'd have a lot more confidence if people were vocal about how they are running it at scale, battle-tested etc. etc.
shopify is straight up yolo running rails edge, which is a crazy endorsement
jherdman•2h ago
I'm pretty sure this isn't true at all with Rails. Out of the box you get Solid Queue (jobs), and Solid Cable (real time messaging).
nop_slide•1h ago
When paired with https://github.com/akodkod/solid-queue-dashboard you get a nice overview.
jamiecurle•1h ago
Thing is with Elixir though, yes the tools are right there, but you do have to take time to understand them. I've been on and off with Elixir since 2016 and I'm currently wrapping up on a fairly complex elixir project with zero UI. (connecting Shopify GraphQL to a series of 3rd party fulfilment providers who use SFTP (gross). So yes, GenServer, Supervisor etc are all right there as first class citizens, but whilst they are relatively simple to start using, you can end up with some horrifically structured code that would have been much better written without the distributed stuff.
Personally, I prefer Django. Been using it since 2006 and as a person who started off in design but ended up as an engineer, nothing beats Django's template engine (braces for incoming). Django isn't perfect but nothing is. When I have to get something done quick and there's UI work for me to do, I go to Django. When performance or no UI, I go elixir. If someone else is doing the UI, I go phoenix.
akarshc•1h ago