I've built apps both with Elixir/Phoenix and with Rails. Yes, the Elixir/Phoenix stack is amazing and is definitely superior over Rails in several ways; however, with regards to Bootstrapping and releasing a real-world app/business (web based), Rails is still the king.
I've got in-depth experience with many Rails apps and quite a few Phoenix apps (and many other stacks). I used to agree with your opinion, though I think Rails no longer holds a massive edge. Phoenix is now just as effective at releasing real-world products especially run-of-the-mill web apps. And when things get complex after a bit of time (usually due to business logic evolving) - much more effective.
The place where I feel Rails still holds an edge is the massive amount of gems available, but hex is absolutely catching up and I'm only running into missing packages/libraries when I'm doing "weirder" things these days. The ecosystem continues to evolve for the better. On the other hand Phoenix destroys Rails in any realtime scenario. Maybe those edge cases matter to your particular project then again maybe not.
phoenix's channels (for realtime) is the only multiclustered websocket solution with long polling fallback that I know of that will scale to thousands of users out of the box. My startup uses websockets and its never been a bottleneck vs the headaches I've deal with doing similar stuff in nodejs. its just an absolute unit for doing realtime.
And now they have liveview which takes that and builds on it to accomplish magic.
rails has done great things but comparing it to phoenix on realtime stuff is like comparing a moped to an f16
> comparing it to phoenix on realtime stuff is like comparing a moped to an f16
Have you tested this? I ask because under the hood, Rails is using Faye, and Faye is using EventMachine.
About 10 years ago I load tested Faye vs. Node in a websocket scalability test for a websocket based chat app I was writing, that, funnily enough had a polling fallback. We had scalability needs up to around 10k or 20k simultaneous connections if I remember right and I wanted to know their ceilings before we wrote the real code and invested in either.
Faye kicked Node's butt on simultaneous connections and throughput. Node fell over while Faye was still going. Eventmachine, which Faye uses, can scale like nobody's business. It IS an F16.
I worked at a startup using rails. I also spent several years as a nodejs engineer.
I built my startup in elixir.
having experienced all 3, I can tell you in real world perfrmance, the metaphor is accurate. if you're boostrapping a startup and you need fast, stable websockets. elixir is the GOAT.
yeah, elixir is still going to destroy it at runtime. the concurrent story is even more important with the features you’re talking about and especially in that segment, it’s not even close.
runtime performance for web requests absolutely demolishes rails. its not even close. I was seeing sub 10ms response times in developer mode. database queries end up being the overwhelming botteneck,
Then there's realtime. phoenix channels is the standard. everything else is a janky copy thats issing one or more factors that make it so good. elixir users lightweight threads so there's less overhead per connection which means you can run WAY more connections on a single machine. Live view takes this further but allocating a persistent process per user on which state can be synced to the frontend without writing ay javascript.
ruby on rails has more and better gems when your'e starting out but once you get some traction, maintenance on an elixir app is much easier due to it being functional.
I just don't understand this, the ergonomics are about the same. Phoenix was inspired by Rails and Elixir by Ruby, after all. I've also worked with both and I'd say it's a match in terms of productivity.
Rails likely has an advantage of documentation given its age and all the major mature businesses using it like Shopify.
A lot of newer languages have documentation/blog posts that's heavily centered around starting out with a new project vs all the bugs with existing Github issues/stackoverflows and design considerations of the framework and 3rd party plugins being fully fleshed out.
When Shopify adopted Rails is was quite new technology though...So they literally didn't follow this advice. In fact the CEO was part of the Rails core team.
Here's a talk in 2008 by the CEO about their caching issues
I've been using Rails since 2007 I'm familiar with what it was like back then.
I'm talking about 2024. I have a large tolerance for risk, and I'd be a risk taker for my own new projects or for a very early startup. Or if a tech offered something significantly new and better than the alternatives, like Rails did in 2007 vs PHP.
But now that I'm older, and I value getting things in front of customers with the minimum amount of bullshit. I'm not seeking out learning some fun tech purely for highs of a good fancy new language/framework (I've done that enough). I'd rather not chase down framework bugs. I want to google a bug and see 5 other people already had it.
I also started using Rails a long time ago (circa 2005), and I have become older too (46 years now).
But I must say I think there is not much bullshit, and quite a bit of stability, in what Elixir / Phoenix bring to the table (saying this after maintaining a production French state-owned service running on top of Elixir for more than 3 years now).
There are also not that much framework bugs, the level of retro-compatibility is huge compared to Ruby in particular (except for LiveView which is still a bit young, but the rest is ... quite stellar).
I quite find that I could use exactly your last paragraph to describe _why_ I wouldn't pick anything else than Elixir these days. The TCO is great, the maintenance story is remarkably stable at the moment etc.
Googling works decently well now with Elixir too, the community is mostly fairly responsive.
I used it for 5ish years and never felt like I really understood the framework; there way too much magic going on.
What forced the switch was using Livewire; cool idea but horrible performance, poor documentation, no support, and constant rewrites. Knowing it was based off of Live View I looked into that and there was no going back.
I'm glad you found something that works better for you, but I wouldn't say that not learning to use the framework (which you don't need to understand the internals for to use) automatically makes the other option better. It just means Elixir clicked for you better.
Laravel really forces you to do things the "Laravel way" and as soon as you try to step outside that box you run into tons of headaches along the way, and upgrades become painful. I haven't found that to be the case with Phoenix at all.
There's also lots of "magic" going in in Laravel behind the scenes and it can be pretty painful to try and figure out exactly why something happened.
Livewire was a mess over all. It had a lot of breaking changes along the way and performance was terrible for anything but the most basic tasks. The support was poor; the docs were alright at best, the screencasts were paid, and Caleb never showed his face in his own Discord, which was troublesome because there weren't enough people using it for the community to support each other. The weird bugs and behaviour were all over the place and the errors you received when you ran into one of them did nothing to help you track it down.
I guess to sum up my feelings: PHP was fine but Elixir did click better. Laravel is a black box and Phoenix is objectively a better framework.
The last Laravel project I used was using Livewire V2.
Not all of the problems were strictly "Livewire" problems, but also just the limitations of PHP. Having to send the state back and forward and rehydrate the state on the server on every request is just slow no matter what you do. Live View has an active process for every connected user that maintains state so you only have to send tiny little diff's back and forward.
Do LiveWire responses get so big that the size becomes an issue?
Haven't used either LiveWire or LiveViews seriously. Honestly trying to understand what you're saying.
I was under the impression LiveWire only sent the data for the component being updated so realistically the main issue is latency (just as with LiveViews).
I mean, sending 0.1kB vs 1kB is 10x worse but in practice this doesn't seem like it would have a real impact in UX for the majority of use cases.
Livewire has to send the full state of the request for the component. Search results is a good example where the state can start to get big. Once it hits the server re-hydrates the models. They are also HTTP requests which have some handshaking.
Live View only sends the diffs excuse the state lives in an active process on the server, and it uses web sockets which is much faster than http requests.
I've built apps both with Elixir/Phoenix and with Rails. Yes, the Elixir/Phoenix stack is amazing and is definitely superior over Rails in several ways; however, with regards to Bootstrapping and releasing a real-world app/business (web based), Rails is still the king.