Warum ich mich für Elixir Phoenix statt Rails, Laravel oder Next.js entschieden habe

 (akarshc.com)
7 Punkte von GN⁺ 2025-10-18 | 3 Kommentare | Auf WhatsApp teilen
  • Phoenix LiveView bietet eine hohe Effizienz sowohl bei der Anwendungsgeschwindigkeit als auch bei der Entwicklungsgeschwindigkeit
  • Ein Vorteil ist, dass sich alles monolithisch in einer einzigen Sprache umsetzen lässt, ohne Frontend und Backend separat warten zu müssen
  • Rails Hotwire und Laravel Livewire wurden ebenfalls in Betracht gezogen, erfordern aber bei Echtzeitfunktionen und Hintergrundjobs mehr Konfiguration
  • Das Phoenix-Framework von Elixir bewahrt die Eleganz von Ruby on Rails, bietet aber deutlich bessere Performance, hat Hintergrundjobs über Oban praktisch eingebaut und unterstützt eine vertraute, saubere Syntax
  • LiveView bietet WebSocket-basierte bidirektionale Echtzeit-Updates, schafft eine Balance zwischen traditionellem Server-Rendering und frontendlastigen Frameworks und erlaubt bei Bedarf die Nutzung von Alpine.js oder JavaScript-Bibliotheken über Hooks
  • Schnelle Entwicklung, hohe Nebenläufigkeit, die Möglichkeit, fast alles in einer einzigen Sprache zu schreiben, frühzeitige Fehlererkennung durch den Compiler und fehlertolerante Architektur auf Basis von Elixir/Erlang waren letztlich die entscheidenden Gründe für die Wahl

Warum ich Phoenix LiveView gewählt habe

  • Das Ziel beim Programmieren ist es, Probleme auf die bestmögliche Weise zu lösen, und die wichtigsten Faktoren waren dabei Anwendungsgeschwindigkeit und Entwicklungseffizienz
  • Wer React oder Next.js zusammen mit Laravel oder Inertia.js zusammen mit Laravel verwendet, muss sowohl den Frontend- als auch den Backend-Stack pflegen
  • Als Solo-Entwickler hatte ich keine Zeit, Zustand an zwei verschiedenen Stellen zu verwalten, und brauchte eine robuste monolithische Lösung, die alles gemeinsam abdeckt

  • Vergleich mit Alternativen: Laravel Livewire, Rails Hotwire, Next.js

    • Laravel Livewire und Rails Hotwire sind großartige Werkzeuge, die Frontend-Arbeit vereinfachen, ohne stark von JavaScript abhängig zu sein
    • Ein kompletter JavaScript-Stack mit Next.js wurde erwogen, aber JavaScript auf dem Backend ist nicht meine bevorzugte Wahl
    • Rails Hotwire war besonders interessant wegen seiner Fähigkeit, mit Rails schnell ein MVP zu bauen
    • Allerdings wurden Hintergrundjobs, Echtzeit-Updates und bidirektionale Kommunikation benötigt; das ist zwar auch mit Rails und Laravel möglich, erfordert dort aber mehr Konfigurationsaufwand

  • Die entscheidenden Vorteile von Elixir, Phoenix und LiveView

    • Elixir und Phoenix bewahren die Eleganz von Ruby on Rails und liefern zugleich deutlich höhere Performance
    • Stärken sind integrierte Hintergrundjobs über Oban, eine vertraute und gut lesbare Syntax sowie die bidirektionale Echtzeitkommunikation von LiveView
    • LiveView schafft eine ideale Balance zwischen Server-Rendering und stark frontendzentrierten Frameworks
    • Echtzeit-Updates über WebSockets und die Einbindung von JavaScript-Bibliotheken, etwa Alpine.js, sind möglich
    • Phoenix macht mit der Integration von Oban die Deklaration von Hintergrundjobs und die automatische Wiederherstellung einfach

  • Vorteile von Elixir/Erlang

    • Elixir ist eine auf Erlang aufbauende kompilierte Sprache und bildet die Grundlage für hochgradig nebenläufige Systeme wie WhatsApp und Discord
    • Sie bietet hohe Nebenläufigkeit, Fehlertoleranz und automatische Wiederherstellung bei Ausfällen

Gründe für die endgültige Wahl

  • Schnelle Entwicklung und starke Unterstützung für hohe Nebenläufigkeit
  • Eine einzige Sprache reicht für fast die gesamte Implementierung
  • Gut lesbarer Code
  • Der Compiler fängt die meisten Bugs ab, bevor sie in Produktion gelangen
  • Eine fehlertolerante Architektur sorgt dafür, dass die App fast nie ausfällt, und gewährleistet dadurch Stabilität

Fazit und Empfehlung

  • Phoenix ist nicht automatisch Rails, Laravel oder Next.js überlegen
  • Alle Frameworks sind hervorragend, und mit jedem davon wurden bereits verschiedene Projekte umgesetzt
  • Für die konkrete Situation und das Projekt (Hyperzoned.com) war Phoenix die beste Wahl
  • Wer über das hinausblickt, was er bereits kennt, kann einen besseren und effizienteren Weg finden, das nächste Problem zu lösen
  • Hör nicht auf zu lernen

Verwandte Beiträge

3 Kommentare

 
clastneo 2025-10-23

Aus demselben Grund wie bei JSP habe ich irgendwann das Gefühl, dass man es ab einem gewissen Niveau nicht mehr sinnvoll einsetzen kann.
 
GN⁺ 2025-10-18
Hacker-News-Kommentare

  • Ich habe die CKEditor-Integration selbst für Rails, Livewire, Phoenix und React umgesetzt. Von allen war Phoenix in Bezug auf die Developer Experience am beeindruckendsten. Das Framework ist sehr gut designt, sodass die Integration wirklich einfach war. Bei Rails und React, besonders bei Next.js, hatte ich dieses Zufriedenheitsgefühl überhaupt nicht. Bei Next.js ändert sich der Router viel zu oft, ständig wieder anders, sodass ich ihm nicht vertrauen kann. Livewire fühlt sich ähnlich an wie Phoenix, ist aber vergleichsweise weniger intuitiv und funktionsärmer. Zum Beispiel unterstützt Livewire keine Component Slots, Phoenix dagegen problemlos. Ohne Slots wird die Template-Struktur chaotisch und der Code unnötig kompliziert. Wer neugierig ist, kann sich ckeditor5-phoenix auf GitHub ansehen

    • Die Kombination aus PHP (Laravel) und jQuery ist auch 2025 noch brauchbar. Livewire würde ich persönlich aber nicht verwenden wollen. Node.js kann bei der Produktivität abfallen, ist aber sinnvoll, wenn man leistungsfähigere Features braucht. Async/await, socket.io und TypeScript werden alle unterstützt. Next.js ist nützlich, wenn man sowohl SEO als auch interaktive UI braucht, aber wie viele Websites brauchen wirklich beides gleichzeitig? Vielleicht Dienste wie LinkedIn

    • Ich denke nicht, dass Livewire eine Kopie von Phoenix ist. Vom Namen her klingt das plausibel, aber meines Wissens wurden beide Projekte fast gleichzeitig gestartet, und Livewire ist sogar das ältere Projekt. Hotwire kam davon am spätesten. Die beiden Projekte verfolgen unterschiedliche Ansätze, weil PHP und Elixir zu verschieden sind. Ich halte Livewire ebenfalls für ziemlich nützlich. Da WebSockets in PHP nicht so einfach einsetzbar sind, läuft es primär über HTTP, und in den meisten Fällen reicht das auch. Die WebSockets von LiveView können eher Overkill sein

    • Mich würden die konkreten Probleme mit Rails interessieren. Ich würde gern hören, welche Teile schwierig waren

    • Mich würde interessieren, was bei der Nutzung von Rails schwierig war

    • In Livewire 4 soll Unterstützung für Component Slots kommen. Es dauert aber noch ein paar Wochen. In der neuen Version soll es auch Verbesserungen bei Performance und Developer Experience geben

  • Dieser Beitrag wirkt, als würde der Autor das von ihm gewählte Framework verteidigen und Features anderer Frameworks absichtlich ignorieren. Die als Vorteile von Phoenix genannten Punkte gibt es in Rails ebenfalls. Außerdem erweckt der Text den Eindruck, Rails unterstütze keine Kommunikation zwischen Frontend und WebSockets, was für jeden, der in den letzten drei Jahren mit Rails Apps gebaut hat, schlicht falsch ist. Natürlich sind Phoenix und LiveView trotzdem gute Tools, aber ich bleibe vor allem wegen Hotwire Native bei Rails. Dass ich Mobile- und Web-Apps in kurzer Zeit allein bauen kann, ist produktivitätsseitig ein enormer Vorteil

    • Ich habe Ruby kaum benutzt, aber abgesehen von der Community würde mich interessieren, worin Ruby on Rails Elixir & Phoenix überlegen ist. Dank der BEAM-Plattform halte ich Phoenix theoretisch für klar überlegen: Soft-Realtime-Systeme, Fault Tolerance, NIFs, Actor Model, unzählige leichtgewichtige Prozesse, leicht verständliche Concurrency, funktionale Programmierung, OTP, GC ohne Unterbrechungen. Natürlich kann man nutzen, was man bevorzugt, und Hotwire Native werde ich mir auch einmal ansehen

    • Es ist klar, dass Rails per WebSockets mit dem Frontend kommunizieren kann. Ich bin selbst Rails-Entwickler, würde aber Phoenix wählen, wenn viele dauerhafte Socket-Verbindungen nötig sind. Phoenix kann über Dienste wie Gigalixir 100.000 Socket-Verbindungen deutlich günstiger und einfacher abdecken. Wenn man die Infrastruktur selbst betreibt, sieht es anders aus. Mit Heroku sind aber schon ein paar tausend Verbindungen schwierig, und teuer ist es ebenfalls

    • Mich würde interessieren, an welcher Stelle im Text behauptet wird, Rails unterstütze keine WebSocket-Kommunikation mit dem Frontend. Im Original steht doch nur: „Das geht auch in Rails und Laravel, braucht beim Setup aber etwas mehr Zeit.“ Das ist eine völlig andere Nuance

    • Die Kombination aus Rails + Hotwire ist ebenfalls sehr stark, und mit Hotwire Native noch mehr. Der Punkt des Artikels ist nicht, dass Phoenix und LiveView besser sind, sondern dass die Struktur von LiveView — servergesteuerter Zustand, getrennte Prozesse, leichtgewichtige Channels usw. — für bestimmte Situationen gut passt. Beide Ökosysteme lösen ähnliche Probleme auf unterschiedliche Weise. Rails setzt auf Konventionen und Progressive Enhancement, Phoenix auf die Concurrency und Fault Tolerance von BEAM. Am Ende ist entscheidend, welche Architektur besser zu dem Produkt passt, das man baut

    • Von Hotwire Native habe ich früher einmal gehört, danach schien es aber ruhig darum geworden zu sein. Mich würden praktische Erfahrungen in echten Mobile-Apps interessieren, ebenso Support, Dokumentation und der Reifegrad der Implementierung

  • Ich bin Elixir gegenüber ähnlich positiv eingestellt wie der Autor, aber als CTO waren meine Erfahrungen nach drei Jahren im Produktionseinsatz zunehmend gemischt, je größer der Umfang wurde. BEAM (Concurrency, Fault Tolerance) hat sein Versprechen gehalten, und Ecto, Oban, Remote iex und auch der Talentpool waren ausgezeichnet. Aber die Developer Experience wurde immer mehr zum Flaschenhals. In einem großen Projekt mit 300.000 Zeilen hatten wir folgende Probleme:

    • Kompilierzeiten: Schon das Ändern einer einzigen Codezeile führte in der Entwicklungsumgebung zu über 10 Sekunden Kompilierung und riss einen ständig aus dem Flow
    • Tooling: Das Autocomplete von ElixirLS war nicht verlässlich, daher ging viel Zeit für das Suchen nach Funktionsnamen oder Schema-Feldern drauf
    • LiveView: Für komplexe UIs war es nicht geeignet, sodass wir am Ende doch ein React-Frontend eingeführt haben und damit die Komplexität von GraphQL und Stack-Splitting vollständig zurückkam
      Wer über einen langfristigen Stack nachdenkt, dem hilft vielleicht diese 3-Jahres-Retrospektive

    • Dass eine Kompilierung in der Entwicklungsumgebung bei Elixir über 10 Sekunden dauern kann, überrascht mich sehr. Ich hatte immer nur gehört, Elixir biete mehr Vorteile als Rails. Mich würde interessieren, ob solche Fälle im echten Berufsalltag häufig sind

    • Beim Lernen von Elixir hatte ich eine ähnliche Erfahrung. Die Sprache gefiel mir, aber unter Windows mit WSL brach der LSP oft weg, was lästig war. Ich hoffe, dass der offizielle LSP bald kommt und das deutlich verbessert

    • Wenn Frontend-Code wie bei LiveView oder React nicht gut gepflegt wird, wird er in großen Apps schnell unübersichtlich. Je mehr Leute beteiligt sind, desto notwendiger werden Code Reviews und das Aufräumen unnötiger Logik. Das scheint bei allen Frameworks ähnlich zu sein. Hier gibt es wirklich noch viel Verbesserungspotenzial

  • Es wird behauptet, „Background Jobs, Echtzeit-Updates und bidirektionale Kommunikation mit geringem Aufwand zu unterstützen, lässt sich in Rails und Laravel mit ein wenig zusätzlichem Setup ebenfalls alles umsetzen“, aber Rails unterstützt standardmäßig bereits Solid Queue (Jobs) und Solid Cable (Realtime Messaging)

    • Seit ich vor Kurzem zu Rails gewechselt bin, finde ich SolidQueue wirklich sehr einfach: mit dem Standard-Setup sofort einsatzbereit. Mit dem Solid Queue Dashboard kann man sogar den Gesamtzustand auf einen Blick sehen

    • Nur beim Realtime Messaging finde ich das Setup von Solid Cable umständlicher als bei LiveView. LiveView übernimmt schließlich auch das Rendering, daher halte ich es in der Entwicklung gegenüber Rails mit SolidCable für deutlich weiter

    • Alles lässt sich auch mit Rails umsetzen. Es ist ein wunderschönes Framework, und mit Phoenix geht es einfacher und angenehmer. Ich empfehle auf jeden Fall, es einmal auszuprobieren

    • Aus Sicht von jemandem, der sowohl Rails als auch Elixir produktiv eingesetzt hat: Die beiden Systeme sind keineswegs gleichwertig. Oban ist in der Nutzung klarer, und für Retries reicht es, einfach eine DB-Spalte zu aktualisieren, dann kümmert sich der Oban-Supervisor sauber darum. Bei Solid Queue gibt es keine einfache Möglichkeit, erfolgreich abgeschlossene Jobs erneut auszuführen. Es gibt auch zu viele Tabellen, was die Verwaltung mühsam macht. Oban verwaltet einfach nur zwei Tabellen und läuft natürlich in derselben App, während man bei Solid Queue erst diverse Blogposts lesen und Setup-Werte anpassen muss, damit es ordentlich funktioniert. Die Defaults sind unzureichend. Dank der Eigenschaften von Erlang/Elixir ist Oban extrem einfach gebaut und funktioniert trotzdem hervorragend — das ist als Entwickler eine Freude. Solid Queue nutze ich eher notgedrungen

  • Ich habe lange mit Rails entwickelt, aber inzwischen sind Phoenix/Elixir mein Standard-Stack. Rails ist immer noch unschlagbar, wenn es darum geht, CRUD-Apps schnell zu bauen, und darin ganz klar hervorragend. Wenn die Komplexität aber steigt und die Zeit vergeht, sind Phoenix/Elixir insgesamt die besseren Werkzeuge

    • Seit dem Aufkommen von LLMs lassen sich solche einfachen Apps in wenigen Minuten erzeugen. Bei den wirklich wichtigen Teilen habe ich aber das Gefühl, dass Phoenix einem mehr Kontrolle gibt

    • Ich würde gern konkreter hören, was besser passt und was du als überlegen empfindest

  • In dem Satz „Wir schreiben Code, um Probleme auf die bestmögliche Weise zu lösen“ spürt man die Leidenschaft des Autors. Ich bin eher jemand, der zufrieden ist, wenn es einfach funktioniert, deshalb passt es für mich wohl besser, bei Rails zu bleiben

    • Über diesen Satz musste ich laut lachen. Realistisch gesehen wird die Arbeit am Ende nur langsamer, wenn man beim Coden immer nur an optimale Lösungen denkt. Für mich ist Programmieren auch Broterwerb und manchmal einfach ein Hobby

  • Oft heißt es, die Elixir-Community sei klein, aber sie arbeitet an ziemlich fortschrittlichen Libraries und versucht sich auf hohem Niveau. Das erinnert mich an die Aussage eines früheren Entwicklers: „Weniger ist mehr.“ Es gibt auch viel gutes Open Source wie elixir-dbvisor/sql

    • Im Gegensatz dazu wirkt das JS-Ökosystem durch seine schiere Größe eher anstrengend. Es gibt zehn Libraries, die jeweils unabhängig voneinander existieren, und niemand hält sich an Standards. Das ist ein bisschen so, als müsste man in einem riesigen US-Supermarkt ein Menü auswählen oder in einer Vercel-Kettenrestaurantwelt zu einer Wahl gezwungen werden

  • Wer die wahre Stärke von Elixir spüren will, sollte sich alle Vorträge von Saša Jurić ansehen

    • Saša Jurić ist der Autor von „Elixir in Action“, und das Buch ist ebenfalls ausgezeichnet

  • Dieser Text fokussiert sich eher auf Phoenix LiveView als auf das gesamte Framework. Mich stört tatsächlich, dass selbst dann, wenn man LiveView bei den Generator-Optionen in Phoenix weglässt, an verschiedenen Stellen trotzdem Standard-LV-Code übrig bleibt

    • Ich stimme zu, dass LiveView sehr meinungsstark ist und viel Boilerplate mitbringt. Ich mag die Knappheit und Ausdrucksstärke von Elixir, und LiveView fühlt sich für mich eher wie das Gegenteil an

  • Der einzige Grund, warum ich mich nicht für Elixir entschieden habe, war das Fehlen eines Type Checkers. Hat sich daran inzwischen etwas geändert?
 
colus001 2025-10-18

Livewire macht zwar Spaß, aber sobald die UI auch nur ein wenig komplexer wird, wird es zur Hölle. Ab diesem Moment verliert Phoenix dann schlagartig viele seiner Vorteile. Je länger der Zyklus wird, desto schwieriger wird es, deshalb kann ich es nicht wirklich empfehlen.