> But 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.
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).
Solid cable is quite a bit of setup though,compared to Liveview. The way LiveView manages the rendering for your is leaps ahead of how actual rails SolidCable development feels.
> It’s way ahead of both Rails Hotwire and Laravel Livewire. LiveView communicates through WebSockets
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.
The best, most popular serverless platform? There are stacks much worse than PHP, like JVM for example ;)
It (JVM) is getting better lately, for example with virtual threads, but still in same resources you can handle much more traffic via PHP and it can be hosted virtually on every hosting!
Not sure why you say JVM is "worse" than PHP. It handles most real world workloads with no problem and is probably one one the most fine tunes VMs out there. It supports concurrency out of the box.
That said JVM is only a target, so if Java is not your cup of tea, you are free to pick and choose from any of the various JVM languages, like Clojure, Kotlin, Scala etc.
My biggest problem with Elixir is the lack of support for 3rd-party libraries and the small community. I love the idea of it, but every time I try to ship a real project in LiveView, I'm left feeling like the community is not that mature. Maybe coming from a Go backend React frontend stack, that might be the case, but maybe for quick CRUD apps, it's great.
Interesting article, but I had to scroll all the way to the bottom to find what you actually built. I consider this important information, because the right tool for the job will depend on what the job actually is!
(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.
I am curious how much longer NextJS will last considering it is a lock-in vehicle for Vercel.
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?
The Elixir live view model to me look like one of the only sane programming models for modern web development right now... Otherwise your best choice still remains to be server side rendering.
One benefit i found over rails was just some of the libraries were more modern. I'm not a backend developer, so maybe I'm just not skilled enough to know how to do these things, but I found rails libraries tended to be dated and missing more modern features.
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.
All good, but did you know that Next.js is a full stack framework? You can have backend and frontend in the same code base. You don't need Laravel if you use Next.
that’s true, next.js does a great job offering a full stack experience. the difference with phoenix is that it’s built on the beam, which gives you concurrency, fault tolerance, and real-time capabilities out of the box. liveview also lets you build interactive frontends without managing separate api layers or client frameworks, keeping everything unified and fast.
A lot of people tend to flag Elixir for its size and rightfully so, but the community is trying to punch above it’s weight with SOTA libraries. As an old developer once told me: less is more. https://github.com/elixir-dbvisor/sql
> 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.
I love how this article reads more like the individual ignores features and capabilities of other frameworks to then state that the framework he chose is better.
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.
> 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
Where is the article saying that? I only see " Those things are possible in Rails and Laravel, but they take a bit more effort to set up." which is a very different (and more nuanced/personal take) then what you're stating.
I implemented CKEditor integrations for Rails, Livewire, Phoenix, and React. I think the best developer experience was with Phoenix - at every step I was surprised by how well thought-out the framework is and how easy it is to build integrations for it. I definitely can’t say the same about Rails or, especially, React with the awful Next.js. For anyone curious: https://github.com/Mati365/ckeditor5-phoenix
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.
I am not sure you can say Livewire is a copy. The name suggests that is the case but both projects were started at similar time Livewire is afaik even older project than Liveview (Hotwire is youngest - in a way). They both take different approaches because PHP/Elixir have very different characteristics.
I think Livewire is still pretty great. Since PHP can't do websockets easily they focus on http and in most cases thats just fine. Liveview websockets can be an overkill.
Oban is great, but for most cases you don't need it. In languages with a less good concurrency model we are used to needing some form of library or system to manage "background jobs", but in Elixir you can just spin up some GenServers under a supervisor to do work. Start there and only use Oban if there's some form of consistency/resumability guarantee that you need.
After Elixir announcing being "feature complete" a few years ago, and then Phoenix going down the LiveView path for quite sometime ... I feel like the Phoenix/Elixir stack became less exciting to me.
Hope to be wrong though. Erlang based systems are really interesting and under appreciated.
As someone who did Rails professionally for a very long time, Phoenix/Elixir is now my default stack.
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.
Doesn’t the LV approach suffer from latency issues?
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?
58 comments
[ 3.1 ms ] story [ 56.9 ms ] threadI'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).
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.
It (JVM) is getting better lately, for example with virtual threads, but still in same resources you can handle much more traffic via PHP and it can be hosted virtually on every hosting!
That said JVM is only a target, so if Java is not your cup of tea, you are free to pick and choose from any of the various JVM languages, like Clojure, Kotlin, Scala etc.
(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?
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.
> 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.
Where is the article saying that? I only see " Those things are possible in Rails and Laravel, but they take a bit more effort to set up." which is a very different (and more nuanced/personal take) then what you're stating.
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.
I think Livewire is still pretty great. Since PHP can't do websockets easily they focus on http and in most cases thats just fine. Liveview websockets can be an overkill.
Hope to be wrong though. Erlang based systems are really interesting and under appreciated.
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?