HNHacker News
TopNewBestAskShowJobs

akarshc

116 karma · joined May 2, 2019

submissionscomments
akarshc··on Why I Chose Elixir Phoenix over Rails, Laravel, and Next.js
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.
akarshc··on Why I Chose Elixir Phoenix over Rails, Laravel, and Next.js
I guess hiring a developer who knows rails or even laravel can easily pick up with phoenix.
akarshc··on Why I Chose Elixir Phoenix over Rails, Laravel, and Next.js
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.
akarshc··on Why I Chose Elixir Phoenix over Rails, Laravel, and Next.js
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

akarshc··on Why I Chose Elixir Phoenix over Rails, Laravel, and Next.js
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
akarshc··on 35 Questions to Master Web Development (and Get Hired)
Think you’ve mastered web development? Here are 35 fun and visual concept-based questions that cover everything from frontend fundamentals to backend logic. Each one is designed to test your skills, teach you something new, and help you truly master web development concepts that make you stand out as a real Software Engineer.
akarshc··on Show HN: Finding Focus with Hyperzoned
You’re absolutely right. With the way things are evolving, AI can really help in picking up tasks, and that’s exactly what this tool is designed to do.
← PreviousPage 2 of 2