Hacker News Reader

Comment by xutopia | Hacker News Reader

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.

View on HN

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

The gem ecosystem and hiring pool is much better. Otherwise, as raw tech it's worse

One of the arguments is how noisy the languages are. Elixir is without a doubt more powerful, more scalable and more sophisticated than Ruby.

What Ruby has though is ability to express what you are doing in a clear syntax. Elixir has a lot of ritual (albeit less than erlang) to set up your most used things like GenServer - you don't abstract away the concurrent flow (which is good, concurrency should be obvious), but you also wouldn't write elixir without it, so code inevitably becomes filled with technical concerns.

I'm biased, I write elixir for a living after a decade in Ruby, and I'm happy with that tradeoff. But there are times where you need to do an imperative thing and make it clear as day, and Ruby often does a better job here.

Rails is also somewhat more ergonomic for fast prototyping than phoenix. ActiveRecord is a blessing and curse, it's insanely productive for making things do things in minutes, but lacks composition later on.

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

In the local Rails community where I live we haven't used Heroku for a while now. Most of us have moved on to using Kamal with a VPS of our choice. The surprising benefit is that you can even host multiple rails app on a single VPS so it is ideal for playing around with multiple hosted apps.

As for raw performance I'm sure you'd get better deal with Elixir out of the box than Rails out of the box but if you wanted to keep all the benefits of Rails and scale websocket usage look into AnyCable.

I didn’t say that rails doesn’t use websockets. What i meant is that liveview comes with websockets fully integrated into the framework. This doesn’t mean rails can’t use websockets, but liveview has implemented it more seamlessly at the core. I’ve also mentioned that rails and laravel are both great frameworks, but after using phoenix, i felt that liveview offered advantages in terms of performance and implementation. I’ve worked with all three frameworks and chose the one that worked best for my project. Have you had a chance to try phoenix? If not, do try it out then you’ll get what I meant.

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

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

I don't see anything in this post claiming that Rails doesn't support websockets, where are you getting that?

Author here: Not sure why everyone’s taking this as anti-rails or anti-laravel. It’s not. I just shared what worked best for my use case. Real-time updates are built into phoenix through channels and liveview, while in rails it’s handled through Action Cable and Turbo Streams. Both work great, but phoenix’s setup felt more integrated for what I was building.

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.

You can swap out the ActionCable backend with different providers.

Redis, postgres. I think there's a couple of commercial offerings.

solid_cable is a database polling mechanism which can also be swapped in.

Reply on news.ycombinator.com