Why I Chose Elixir Phoenix over Rails, Laravel, and Next.js

Phoenix vs Rails/Laravel Capabilities

• Several commenters say the article understates Rails/Laravel: both have first‑class support for background jobs, websockets, and real‑time (ActiveJob, Sidekiq/Solid Queue, ActionCable/Hotwire; Laravel queues/broadcasting).
• Others argue Phoenix feels more “integrated”: real‑time, background jobs, PubSub, and process supervision all ride on the same BEAM primitives, with fewer moving parts and less external infrastructure.

LiveView vs Hotwire / Livewire / Next.js

• Multiple corrections that Hotwire does use websockets or SSE; the difference is architectural, not transport.
• View: LiveView gives each connected client a stateful BEAM process; ephemeral UI state lives server‑side, reducing client JS and avoiding bolted‑on layers.
• Counterpoint: this “websocket‑first, stateful web tier” is a real tradeoff:
  • Latency depends on round‑trips; quick mobile interactions and flaky networks can feel rough.
  • You must think about connection lifecycle and state reconnection; browser back button, reconnection delays, and large LiveViews can become problematic.
• Hotwire is praised for progressive enhancement and working even when websockets drop; Livewire is seen as a simpler, less mature take on the same idea.
• Some feel Next.js (especially App Router) is over‑complicated, fast‑moving, and brittle for long‑term maintenance, though others defend it as powerful when used well.

Background Jobs: Oban, GenServers, Solid Queue, etc.

• One camp: BEAM + GenServers mean you often don’t need a “job system”; simple supervised processes or Tasks cover many use cases.
• Strong rebuttal from production users: use Oban from day one if jobs matter—GenServers lose state on node/pod failure and lack retries. Oban’s simplicity, reliability, and minimal schema are praised; Solid Queue is seen as more complex and less ergonomic.
• Discussion on clustering with Kubernetes and how BEAM’s “let it crash” model complements, rather than replaces, container orchestration.

Performance, Concurrency, and BEAM Model

• Many emphasize BEAM’s strengths: lightweight processes, actor model, fault tolerance, soft real‑time behavior, and high connection counts with small resources.
• Comparisons made to PHP (fibers still need external runtimes), JVM (very capable but heavier), and Node (strong ecosystem but less “batteries‑included” and more infrastructural churn).

Ecosystem, Libraries, DX, and Tooling

• Some complain Elixir’s ecosystem is smaller and missing certain libraries; others counter that the smaller community “punches above its weight” with high‑quality libs (Ecto, Phoenix, LiveView, Oban, Nx, Livebook, Nerves).
• DX concerns:
  • A large‑scale Elixir/Phoenix shop reported slow compile times and flaky LSP/autocomplete in a 300k‑LOC codebase.
  • Others with similarly sized apps say compiles are “blazing fast” and suspect circular dependencies or heavy GraphQL setups.
  • LiveView can become unwieldy for very complex UIs, pushing teams back to a React frontend and re‑introducing split‑stack complexity.

Adoption, Hiring, and “Boring vs Exciting” Tech

• Corporate buyers reportedly hesitate to adopt Elixir; many only recognize JS/Python/C#/Java as “safe” options. Ecosystem size and developer fungibility are major concerns.
• Suggested strategy: hire strong engineers and teach Elixir rather than filtering for prior experience.
• Some see Elixir’s “feature complete” status as reduced excitement; others view stability and lack of paradigm churn as a major advantage for long‑lived systems.

Critiques of the Article and Meta Points

• Several readers feel the article unfairly glosses over what Rails/Laravel already provide and reads like a post‑hoc justification of a preferred stack.
• The author (in comments) reiterates it was a personal use‑case write‑up, not a general verdict, and acknowledges Rails/Hotwire and Laravel are excellent but argues Phoenix/LiveView felt more seamless and robust for the specific project.