PHP (Laravel) + JQuery still works for me in 2025, but I would never use Livewire.

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.

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.

I wonder what made it hard for you in Rails.

I'm curious about your experience with Rails. What specifically caused issues?

> For example, Livewire components don’t support slots

IIRC, Livewire 4 will support slots, but... that's still a few weeks away from release. There seem to be a number of perf and qol improvements in LW4.

I want to give both of these a try, especially if you say react+next.js is awful. You'd think TS-TS would be well thought out

It makes me sad that today you cannot say react without nextjs in the same sentence.

React used to be the leader in how to make ui reasonable in the generic client sense. Having done java swing, android, swift ui, and custom game dev ui work with all the forms of state management, react was on to something… until the ssr fad attacked. Now it is all but nextjs in disguise.

Ive only used ruby a handful of times, so my comment might be ignorant. But other than community , what does ruby and ror do better than say elixir & phx, i feel like the latter is leagues ahead simply because nothing can compare to the beam platform for soft real time systems, you have fault tolerance, nifs, actor model , you can have millions of processes running at the same time for cheap, easy to reason about concurrency , fp makes code concise imo, otp, the beam gc doesnt stop the world etc I just think on paper phx is superior thanks to the beam platform

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

> 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.

I’m actually a rails dev but I’d reach for phoenix if my app required a large number of persistent sockets (e.g. high-volume MCP servers). I say this mostly because the hosting story is better for phoenix (gigalixir) than rails (heroku, or similar services that run behind a request router). Of course if you want your own infra this argument doesn’t apply. But a $100 gigalixir box can easily serve 100k persistent connections — even a few thousand persistent connections is a non-starter on Heroku.

That’s a fair take, rails with hotwire is genuinely powerful, especially with hotwire native. but the post wasn’t about claiming phoenix is better, it’s about how liveview’s model (server driven state, process isolation, lightweight channels) fit a specific use case. both ecosystems solve similar problems differently, rails leans on conventions and progressive enhancement, while phoenix leans on concurrency and fault tolerance from the beam. at the end of the day, it’s less about which is superior and more about which workflow clicks better for what you’re building.

Bit of an tangent, but I remember hearing about Hotwire Native a while back, and then relative silence. Can I ask how your experience has been with it, and the level of support/documentation/features for the kind of mobile apps you've been building with it?

Yup. the rails 7 demo showed websockets back in Dec 2021:

https://www.youtube.com/watch?v=mpWFrUwAN88&t=25m46s

The problem is the websocket implementation (last time I tested it) sucked. I'm assuming even now if you're doing non-trivial websockets you need to use the node or golang implementation.

Yeah def odd, I'm a recent rails convert and SolidQueue is dead simple and is setup out of the box.

When paired with https://github.com/akodkod/solid-queue-dashboard you get a nice overview.

All the things are possible in rails as well. it is a beautiful framework, but it is so much easier to use with phoenix. Do try it out

Take it from someone that uses both systems in production, they are not equivalent. Oban is leagues easier to use and obvious than Solid Queue. Solid Queue has no easy way to rerun a successful job, in Oban you can just update some dumb table columns and done, the Oban supervisor will sniff it out and workworkwork.

Solid Queue has a ton of database tables. Oban has `oban_jobs` and `oban_peers`. Oban just runs, simple on the same app. Solid Queue you can do that but it requires reading a lot of obscure blog posts and changing the settings. No sane defaults.

Just as a whole the Erlang and Elixir primitives allow oban to be built truly in the most retarded, obvious way and get away with it. It's wonderful to use as a dev.

Solid Queue I'm bearing because I get other stuff I need from Rails.

I think LLM have really closed that gap. Quick throwaway stuff can be generated in a couple of minutes. But phoenix gives me back all the control in cases I care.

why / what do you find works better?

I had to laugh out loud when I read that sentence.

Really? I write code to pay my bills and sometimes just for fun.

Trying to do everything "the most optimal way possible" is going to get in the way of actually getting stuff done.

"Why do we code? To prematurely optimize all the things".

Rails is awesome!

OTOH JS is too big for my taste. Everything has 10 implementations with no consensus about doing things. So everyone chooses their own horrible menu. Like an American super market. Or you go full chain restaurant with whatever Vercel pushes currently

iirc he wrote elixir in action. also. really good.

Yup - an important distinction that wasn't obvious to me when I first jumped in. LiveViews are very opinionated and generate a ton of boilerplate. Not always a bad thing, but Elixir is elegant because of how spartan and expressive the code is - LiveView is kind of the opposite IMO.

Although I agree that LiveView sucks up too much air in the ecosystem, you can just ignore that and develop web apps the standard ways of you want.

Not everyone has VC funding where profit does not matter.

> Otherwise your best choice still remains to be server side rendering.

?? Phoenix Live View IS server side rendering...

I have been pretty happy with Elixir - the syntax takes getting used to, but I'm usually impressed by its elegance.

Phoenix I'm mixed on - it has a few things that "just work" and I'm happy about, but being an opinionated framework I find myself bumping into those opinions the more I want to do things my own way. Usually there's an escape hatch, but being new to both Elixir and Phoenix it's not always obvious to me how to do things when the happy path fails.

> Oban is great, but for most cases you don't need it.

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

For a startlingly large number of use cases, you don't even need to go that far; the built-in task system can typically cover almost all the use cases you'd reach for simple background processing, and exposes an interface very similar to the promise interface in other languages

With GenServers, what happens if you pod/machine crashes? You lose all the unprocessed jobs. Oban gives you safe retries, and guarantees consistency. If you're using a relational DB, I would infact suggest to start with Oban, and then take a look at the jobs and see if you are okay with losing jobs and move to GenServers.

I haven't found Oban difficult to work with and it has the added benefit of ensuring your jobs are run only once. There is also the cron functionality that I find really useful for scheduling.

Almost 20 years after I bought my first Erlang books, I would never recommend Erlang OR Elixir to anyone but a senior dev who likes coding on their own and want to try something different. This pool is almost 0 people, since I was someone who wanted to play with it. I found the juice not worth the squeeze, in time investment vs capability. The build system alone is enough to throw most people off.

In the corporate world ecosystem and fungibility of programmers are the top priority. The only way Elixir will get traction there is by Elixir companies literally growing to Fortune 500 size and showing the language/ecosystem is viable at that scale. Even then I doubt the advantages of Elixir will move the needle for that type of company because once you scale up the challenge is 99% people, teams, and communication; the elegance and efficiency of the code and ops don't matter much in those types of environments.

I'm always curious about C# because it seems to be fast, feature-full, not too much bloated, etc. I'm an elixir dev/fan, but what's wrong with C#? How would Elixir shine compared to it?

Sounds like you need to sell it better ;p

> I feel like the Phoenix/Elixir stack became less exciting to me.

Isn't that what's supposed to happen? It's not really fun to build on top of an exciting platform. Boring means if I build it today, it's likely to continue working for a long time. I've always got more to do than time to do it, so having to rebuild everything all the time because of underlying excitement is not by idea of a good time.

hasn't elixir kept innovating? The whole static typing/inference system seems pretty cool and keeps improving.

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...

Can you explain more? What became less exciting and why exactly?

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!

Request-level concurrency has always scaled well. As for lightweight concurrency, have you worked with PHP Fibers? https://medium.com/@binumathew1988/leveraging-php-fibers-for...

Exactly, this is all blogspam at this point. Ignores all the features available in Rails so he can pick Elixir/Phoenix the “winner”.

I watched a few demos and it is clearly magic and I was very impressed. Though I can't picture how a more standard run off the mill web app would be built with it.

Elixir is pretty "nifty", and has Rails feels. I have worked on and seen its performance compared to scaled up Rails application. The BEAM / OTP is a very cool system to program on top of. I think it would be a great underlying system to develop a consciousness for AI systems with its concurrency paradigms and message passing, node connecting, other builtins. I'm not sure if the AI/ML focused Elixir projects like Nx have really taken off, but again, an Elixir based system that accepts numerous connections, passes messages around like exciting synaptic communications between functions... it just seems cool, maybe just on paper...

Just curious, what libraries did you miss in particular compared to Go?

curious what your process was for hardening your API for security? or is that still a pending step?

I'd rather fix AI slop in simpler languages, thank you very much.

And by the time performance is a startup's concern in majority of cases, they would have to rewrite most of the code anyway, including critical parts, so why not start with a language that's easier to find developers?

latency is minimal because liveview sends only dom diffs, not full page updates. most interactions feel instant. each connection runs as a lightweight beam process, so managing per-user state scales efficiently. for very high-frequency ui updates, some client-side js may still be needed, but for forms, lists, modals, and live updates, liveview is smooth and responsive.

In practice it's mostly fine actually.

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.

https://hologram.page/

I believe that's still true of Erlang, but Elixir has UTF-8 encoded strings. In practice the only time you need to use Erlang strings from Elixir is if you're using an Erlang API.

In Elixir it's bytestring.

Both Erlang and Elixir support two types of text representations.

The first is a linked list of Unicode codepoints (also called a character list or a charlist for short). In Erlang, this is written using double quotes. For example, "abc" in Erlang is actually the list [97, 98, 99]. In Elixir, the same representation uses single quotes: 'abc' is a list of integers.

The second is a UTF-8 encoded binary. In Erlang, this is written using the <<"abc">> syntax. In Elixir, double quotes represent UTF-8 binaries, so "abc" is a binary.

So:

Erlang "abc" = list, <<"abc">> = binary

Elixir 'abc' = list, "abc" = binary

For efficiently handling textual data, Phoenix extensively utilizes iolists (https://hexdocs.pm/elixir/1.15.8/IO.html#module-io-data) to eliminate copying. It's used in performance critical areas such as generating http responses and template rendering. In general, on the Erlang VM, iolists are a first-class, widely used data structure for efficient I/O.

do real time updates and two way communication work out of the box with a cluster as well?

Next.js is still missing lots of backend stuff. Background jobs, cron jobs, queues, etc.

BEAM / Erlang / OTP / Elixir feels different:

- 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

> You don't need Laravel if you use Next

But you do need to solve a lot of stuff that Laravel already solves for you.

I used to feel the same way, but at a certain level of Node.js experience I came to prefer the backend JavaScript idiom. It's much lighter and more pragmatic, and gives the knowledgeable engineer a lot of flexibility. So stick with it.

Have you checked out t3 stack? Curious which pieces are missing from that that you'd deem critical

Chris McCord directly addresses this in his recent ElixirConf talk. There's a threshold amount of training data needed for LLMs to work well, and Elixir more than clears it. Beyond that threshold, having more data doesn't make a tremendous difference. This means the "frustration gap" for newcomers essentially disappears - people who heard "Elixir is good" can now just ask an LLM to build something and start immediately, easing their way into understanding functional programming paradigms in order to be productive. I use Claude Code daily for Elixir development and it understands the language perfectly. The real strategic advantage is that while other ecosystems scramble to solve agent orchestration problems, Elixir/OTP already solved them decades ago. Lots more here: https://www.youtube.com/watch?v=6fj2u6Vm42E&t=1321s

I worked with Elixir/Phoenix for over 3 years, and I recently started to learn Crystal, mostly to create CLI apps or other programs where I want to create a simple executable binary. I wanted a more expressive language than Go, and easier than Rust.

Out of curiosity, I took a quick look at some of the web frameworks available, they are interesting. Lucky's Components looks pretty good, but I still prefer Phoenix's Components because the syntax make it very close to raw HTML. Compilation is not incremental and is single threaded which means I have to wait at least 5 seconds every time I make a change (this was on a minimal project). It's not that bad, but compared to Elixir/Phoenix where it's almost instantaneous, it makes a difference.

Still, Crystal is an awesome language, and if for one reason Elixir was not a choice for a web project, I would definitely consider a Crystal framework.

Having done both for years, I can say confidently that you can use Phoenix without recreating Rails. The differences are important, and IMO Ecto is a much better approach to interacting with a database than ActiveRecord. I've also never seen a bug in my application due to upgrading Ecto, and I definitely can't say that about ActiveRecord.

the sentiment around NextJS is terrible, I have rarely seen something go from "oh this might be cool" to "stop pushing this badly engineering crap on me" so quickly. Yes, it's widely used and that's to be expected given the amount of money spent in promoting it, but it's not loved by any mean and I see this as a fatal flaw that they'll have to reckon with sooner or later. It's so bad that it worsened React's reputation by association - React already had some issues to care about, but they went in Next's direction, and people have noticed

There's absolutely no reason to use Vercel. I've always run Next on our own servers, for multiple clients and some very complex projects. Page Router or App Router.

A lot of ruby gems have definitely seemed to suffer from brain drain the last few years.

It's worth noting that the creator of Elixir was also an author of Devise.

> the gem Devise didn't natively support both

Sounds like a Devise problem.

Give your new hires my free course: https://liveviewcrashcourse.com

If the only metric you care about is "scaling a dev team", use JavaScript. You're welcome.

I guess hiring a developer who knows rails or even laravel can easily pick up with phoenix.

by hiring people without the expectation to be already proficient in it, as long as they are willing and capable of learning it in a reasonable time

1. Hire good developers

2. Teach them Elixir

3. Profit

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

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).

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.

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

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