2 Punkte von GN⁺ 2026-03-13 | 4 Kommentare | Auf WhatsApp teilen
  • Beim Entwickeln der Setlist-Management-App (setlist.rocks) für seine Band entdeckte er nach langer Zeit die Freude an der Entwicklung mit Ruby on Rails wieder
  • Das aktuelle Rails 8 behält die klassische MVC-Struktur bei, wurde aber mit einem „No-Build“-Frontend auf Basis von Hotwire (Stimulus·Turbo) sowie Solid Cache/Queue/Cable modernisiert
  • SQLite wurde so weit optimiert, dass es mit den Standardeinstellungen sogar für echte Produktivsysteme geeignet ist, und mit dem Deployment-Tool Kamal werden containerbasierte Zero-Downtime-Deployments deutlich einfacher
  • Dank der Rails-Philosophie „Convention over Configuration“ und des umfangreichen Gem-Ökosystems lassen sich Ideen sehr schnell in Prototypen umsetzen
  • Die Popularität von Ruby und Rails ist zwar gegenüber früher zurückgegangen, doch als reifes und konsistentes OSS-Framework bietet es weiterhin Freude an der Entwicklung

Side-Project und Rückkehr zu Rails

  • Um die Setlists und Song-Notizen seiner Band zu verwalten, entwickelte er selbst eine Web-App und suchte damit nach einer effizienteren Lösung als bestehende Tabellen oder Chats
  • Im Entwicklungsprozess erlebte er die Einfachheit und Produktivität von Rails erneut und erwähnt, dass es sich im Vergleich zum heutigen komplexen Web-Ökosystem wie „pure Freude am Entwickeln“ angefühlt habe
  • Ruby wird weiterhin als Sprache mit natürlicher Syntax und hoher Ausdruckskraft bewertet, in der sich Gedanken leicht in Code übertragen lassen
  • Laut der Stack-Overflow-Umfrage 2025 ist die Popularität von Ruby und Rails gesunken, für persönliche Projekte bleibt es aber weiterhin eine bevorzugte Wahl

Veränderungen in Rails 8 und das Frontend

  • Rails 8 behält die bestehende MVC-Struktur bei und bietet zugleich eine integrierte Frontend-Einbindung auf Basis von Hotwire (Stimulus·Turbo)
    • Turbo fängt Link-Klicks und Formular-Submits ab und liefert Reaktivität auf SPA-Niveau
    • Stimulus ergänzt nur dort JavaScript-Verhalten, wo es nötig ist, sodass sich interaktive UIs mit minimalem JavaScript-Aufwand umsetzen lassen
  • Mit der Einführung von Importmap können JavaScript-Bibliotheken direkt von einem CDN geladen werden, ganz ohne Webpack oder npm
  • Zwar wurden AI-Tools für die UI-Erzeugung genutzt, zugleich wird aber auch ein Spannungsfeld zwischen Kreativität und der künstlerischen Seite des Codes angedeutet

Entwicklungs-Workflow und Produktivität

  • Mit der Rails-Philosophie „Convention over Configuration“ lassen sich Modelle, Routing, Controller und Views schnell aufsetzen
    • Als Beispiel wird die Erstellung eines Tag-Modells, die Automatisierung von RESTful Routing und die Verarbeitung von JSON-Antworten gezeigt
  • ERB-Templates und Live Reload ermöglichen schnelles Prototyping
  • Über das umfangreiche Gem-Ökosystem lassen sich Funktionen wie CSV oder PDF leicht integrieren

Backend-Verbesserungen: die Solid*-Reihe und SQLite

  • Solid Cache/Queue/Cable sind in Rails 8 standardmäßig enthalten, sodass Caching, Job-Queues und WebSockets auch ohne Redis möglich sind
    • Solid Cache bietet DB-basiertes Caching, spart RAM und vereinfacht die Architektur
    • Solid Queue verwaltet Hintergrundjobs datenbankbasiert und lässt sich allein mit der Einstellung SOLID_QUEUE_IN_PUMA=1 ausführen
    • Solid Cable unterstützt Echtzeitfunktionen als DB-basierter Action-Cable-Adapter
  • Bei SQLite werden über die pragmas:-Einstellung in database.yml Optimierungen wie WAL-Modus und NORMAL-Synchronisierung standardmäßig angewendet
    • Dadurch ist auch ein praktischer Einsatz in kleinen Produktionsumgebungen ohne separaten DB-Server möglich

Deployment-Automatisierung und Kamal

  • Mit Verweis auf die frühere Komplexität von Deployments mit Capistrano und Ansible wird Kamal als Standard-Deployment-Tool von Rails 8 vorgestellt
    • Der Ablauf Container-Build → Push → Server-Deployment → Health Check → Zero-Downtime-Umschaltung wird automatisiert
    • kamal-proxy übernimmt Traffic-Umschaltung und SSL-Verarbeitung
    • Die Datei .kamal/secrets unterstützt sicheres Secret-Management auf Basis von Umgebungsvariablen
  • In Verbindung mit GitLab CI sind Deployments allein per git push möglich und stellen damit die Einfachheit des früheren Heroku wieder her

Authentifizierung und weitere Funktionen

  • Rails 8 bietet einen integrierten Auth-Generator, mit dem sich ein einfacheres Authentifizierungssystem als mit Devise aufbauen lässt
  • Devise bleibt wegen seines großen Funktionsumfangs und der guten Dokumentation nützlich, zugleich wird aber auch die Einfachheit der Rails-Standardauthentifizierung als attraktiv bewertet

Der aktuelle Zustand und die Beständigkeit des Rails-Ökosystems

  • Die Popularität von Ruby und Rails ist zwar gesunken, doch große Dienste wie Shopify, Basecamp, SoundCloud und GitHub setzen weiterhin darauf
  • Viele Gems befinden sich in einer Wartungsphase, Rails hält jedoch weiterhin einen konstanten jährlichen Release-Zyklus ein
  • Es wird als Framework beschrieben, „in das zwar weniger neue Entwickler nachrücken, mit dem sich aber immer noch mit Freude entwickeln lässt“

Fazit

  • Rails folgt zwar nicht jedem aktuellen Trend, wird aber als Werkzeug hervorgehoben, das Freude am Entwickeln und Einfachheit zurückbringen kann
  • Statt auf Popularität wird der Fokus auf Freude am Bauen und Kreativität gelegt; abgeschlossen wird mit der Botschaft, Rails noch einmal auszuprobieren

4 Kommentare

 
joyfui 2026-03-14

Soweit ich mich erinnere, hieß es bei Rails nicht „Konfiguration statt Konvention“, sondern „Konvention statt Konfiguration“...

 
savvykang 2026-03-14

> most of the web frameworks I’d (...) required endless amounts of XML-Boilerplate und anderer Konfiguration, um alles miteinander zu verdrahten. Rails hat all das über Bord geworfen und das Prinzip „Convention over Configuration“ eingeführt.

Es scheint, als hätte das LLM ohne Änderung der Wortstellung genau in der Eingabereihenfolge ausgegeben. Im Original ist es korrekt.

 
xguru 2026-03-14

Es ist erstaunlich, dass das LLM so etwas falsch macht. Ich habe es korrigiert. Danke.

 
GN⁺ 2026-03-13
Hacker-News-Kommentare
  • Ich mag Rails wirklich sehr, aber nachdem ich in einer großen dynamisch typisierten Codebasis gearbeitet habe, fällt es mir schwer, für etwas anderes als persönliche Projekte zu Rails zurückzukehren
    Eine große Codebasis ohne Typen zu warten, ist selbst mit einer leistungsstarken IDE wie RubyMine ein Albtraum
    Ich frage mich, wie weit Sorbet inzwischen gekommen ist, besonders wie gut es mit RoR zusammenspielt

    • Ich denke, Rust/Loco ist derzeit das interessanteste Framework
      Es folgt der Philosophie von Rails gut und macht es zugleich leicht, Rust zu lernen
    • IHP ist ein von Rails inspiriertes Framework auf Haskell-Basis, das versucht, die Vorteile beider Welten zu verbinden
      Es ist einen Versuch am Wochenende wert
    • Das Problem ist nicht nur das Fehlen von Typen, sondern auch die Struktur, in der Funktionen oder Eigenschaften zur Laufzeit definiert werden, wodurch Debugging fast unmöglich wird
      Man muss echte Produktionsdaten lokal replizieren oder sich per SSH auf den Server einloggen und den Zustand über ein REPL untersuchen
      In der IDE zu debuggen war eine höllische Erfahrung
      Ich habe Ruby wirklich geliebt, aber nach Live-Debugging wurde es schwierig
    • Ich frage mich, warum große dynamisch typisierte Codebasen so albtraumhaft sind
    • Heutzutage wird durch agentisches Coding (agentic coding) die Bedeutung von Sprachen oder Frameworks immer geringer
      Es gibt jetzt keinen besonderen Grund mehr, ausgerechnet Ruby oder Python zu wählen
      Python wird sich im ML-Bereich noch etwas länger halten, aber am Ende wohl verschwinden
  • Ich freue mich auch, dass jemand das öffentlich ausspricht
    Ich bin inzwischen müde von überzogenen Microservices-Architekturen
    Abends arbeite ich an Projekten, die Probleme einfach lösen, ohne unnötige Struktur
    Früher habe ich viel mit PHP-Strukturen gearbeitet, aber sowohl Rails als auch PHP sind letztlich nur Werkzeuge zur Problemlösung

    • Seit Anfang dieses Jahres nutze ich RoR für ein neues Projekt, und es ist wirklich wie frische Luft
      Es fühlt sich an wie frühere Desktop-IDE-Entwicklung, bei der alles „in einer Box“ läuft
      Es ist, als hätte ich mich vom Management der komplizierten Bausteine der Webentwicklung befreit und die Einfachheit mit Fokus auf Produktivität wiedergefunden
      Und außerdem ist es großartig, kein TypeScript verwenden zu müssen. Ich halte TypeScript für einen wortreichen Haufen unnötigen Boilerplates
    • Ich frage mich, wofür STOA steht
    • Ich finde, die Aussage „die Übersetzung zwischen Gedanken und Code wird minimiert“ beschreibt das Wesen von Ruby sehr gut
  • Wir betreiben seit 2007 durchgehend Rails-Apps in Produktion
    Das Geheimnis der Langlebigkeit von Rails liegt nicht im Alter, sondern in seiner Stabilität und Praxisnähe
    Die Behauptung, dass man effizienter wird, wenn man JavaScript im Backend verwendet, wurde bereits widerlegt
    Die meisten Änderungen des Technologie-Stacks erfolgen wegen Lebenslaufoptimierung oder Trendangst, nicht wegen echter Engineering-Anforderungen
    Rails hat still und leise weiterhin echte Unternehmen angetrieben
    Niemand wird ernsthaft glauben, dass die 3,1 Millionen Pakete von NPM mehr Funktionalität bieten als die 190.000 von RubyGems

    • Wir nutzen Rails seit 2011 in zwei Unternehmen in Produktion
      Wir migrieren gerade zu Inertia + Vue.js, und das ist eine so starke Kombination, dass am Backend kaum Änderungen nötig sind
      Die Produktivitätsgewinne gleichen sogar die Schwierigkeit bei der Einstellung aus
    • Dass NPM mehr Pakete hat, bedeutet auch, dass es mehr Nutzer gibt
      Je mehr Nutzer, desto gesünder ist das Ökosystem
      Allerdings gibt es auch viele alte Pakete bei RubyGems, daher finde ich einen einfachen Vergleich schwierig
  • Die „Batteries-included“-Philosophie von RoR oder Django ist gut, aber die Wartung älterer Projekte kostet viel Zeit
    Wenn man ein 5 bis 6 Jahre altes Projekt aktualisieren will, wird das Abhängigkeitsmanagement zur großen Last
    Deshalb bevorzuge ich inzwischen Go mit einem einfachen Framework oder ganz ohne

    • Ich betreue eine Django-Codebasis mit über 300.000 Zeilen und habe nur 32 direkte Abhängigkeiten
      Wenn man nur wirklich notwendige Bibliotheken verwendet, bleibt die Wartung einfach
    • Das Problem scheint eher ständiger Wandel (churn) zu sein
      Außer für Sicherheits-Patches frage ich mich, warum man überhaupt aktualisieren muss
    • Bei Laravel habe ich solche Probleme fast nie
      Ich habe in den letzten anderthalb Jahren 5 Major-Versionen hochgezogen, und es war trotzdem relativ einfach
    • Letztlich hängt der Wartungsaufwand von der Strategie für das Abhängigkeitsmanagement ab
      Wenn man es am Anfang sorgfältig aufsetzt, muss man oft sehr lange kaum noch etwas anfassen
    • Ich frage mich, ob „Batteries included“ Upgrades eher schwieriger macht. Ich hätte eher das Gegenteil vermutet
  • Ich denke, die Upgrade-Erfahrung wird unterschätzt
    Bei Next.js ändert sich mit jeder Major-Version die Struktur komplett, aber Rails ist durch langsame Zyklen schrittweiser Abschaffung (deprecation) viel stabiler
    Wenn man ein Produkt kontinuierlich ausliefert, ist Stabilität der Schnittstellen viel wichtiger als das neueste Paradigma

    • Nur Menschen, die Rails lange betrieben haben, verstehen das wirklich
      Der Wechsel von pages zu app router in Next.js war faktisch eine Veränderung auf dem Niveau einer kompletten Re-Plattformierung
      Rails hat dagegen dokumentierte Upgrade-Pfade und vorhersehbare Deprecation-Zyklen
      Auch das Ruby-Versionsmanagement beseitigt dank rbenv/asdf fast alle Probleme mit inkonsistenten Umgebungen
    • Der Wechsel zum app router in Next war ein struktureller Umbruch, daher lohnt es sich an diesem Punkt, weniger meinungsstarke Alternativen wie TanStack Start in Betracht zu ziehen
  • Ich habe über zehn Jahre lang mit Rails alles gemacht, von DevOps bis zum Solo-Webentwickler, und würde wieder dieselbe Wahl treffen
    Rails ist ein aufgeräumtes und produktives Framework, das alles mitbringt
    Auch in der Stack-Overflow-Umfrage war es weiterhin unter den „Top 5 Stacks, die man im nächsten Projekt nutzen möchte“

    • Der Charakter von Rails als „Ein-Personen-Framework“ ist wirklich attraktiv
      Man muss sich fast gar nicht um die Infrastruktur kümmern, und auch das Deployment ist einfach
    • Leute, die tatsächlich mit Rails arbeiten, nehmen vielleicht gar nicht an Umfragen teil
      Am Ende zählt nicht, wie andere es sehen, sondern die Werkzeuge zu verwenden, die zu einem selbst passen
    • Rails erschien 2004 und ist damit jetzt ein Framework mit mehr als 20 Jahren Geschichte
      Es kam ein Jahr vor Django heraus
    • In der Stack Overflow 2025 Survey belegt Rails Platz 10 in der Kategorie „Admired vs Desired“ bei Web-Frameworks
      Link zur Umfrage
  • Früher dachte ich, Ruby/Rails sei für die meisten Probleme die optimale Lösung, und das denke ich auch heute noch

  • Ich habe Rails nie benutzt, aber ich kann das chaotische Umfeld der heutigen Webentwicklung gut nachvollziehen
    Deshalb habe ich mit Blick auf die Zukunft Elixir und Phoenix gewählt

    • In den letzten Tagen haben mir gleich fünf Leute Elixir empfohlen, als ich sagte, dass ich ein Projekt in Ruby mache
      Beim nächsten Projekt will ich es unbedingt ausprobieren
      Ich frage mich, was Elixir so attraktiv macht und worauf man beim Einstieg besonders achten sollte
  • Vor zehn Jahren haben wir das Streaming-Frontend eines großen schwedischen Rundfunkunternehmens mit Rails gebaut
    Auf Heroku haben wir mehr als 1 Million gleichzeitige Nutzer bedient, und es hat wirklich hervorragend funktioniert
    Danach bin ich in andere Bereiche gewechselt, etwa Streaming-Infrastruktur, API, AI/ML, aber nicht, weil Rails versagt hätte, sondern weil die Art der Probleme sich geändert hatte
    Rails eignet sich für Probleme rund um Datenmodelle und Business-Logik, für konkurrenz- oder infrastrukturzentrierte Probleme passen andere Sprachen besser
    Ruby bleibt eine schöne und ausdrucksstarke Sprache, die ich vermisse

    • Ich teile ebenfalls die Philosophie, das passende Werkzeug für das Problem zu wählen
      Trotzdem finde ich es schwer, persönliche Vorlieben für eine Lieblingssprache völlig abzulegen
      Ich frage mich, mit welcher Sprache du dein nächstes Projekt umgesetzt hast
  • Für Leute, die das Fehlen statischer Typen bedauern, gibt es großartige Lösungen wie Sorbet
    Damit kann man Rubys Produktivität, statische Typen und LSP-Integration zugleich nutzen
    Dank Shopify ist die Sorbet-Unterstützung auch in Rails gut
    Ich liebe dieses Ökosystem so sehr, dass ich immer noch gern mit Rails arbeiten würde
    Dank der Fortschritte bei AI-Tools denke ich inzwischen, dass nur noch die Größe der Vorstellungskraft die Grenze ist

    • Das derzeit größte Gesprächsthema im AI-Bereich ist OpenClaw
      Darauf aufbauend habe ich einen E-Commerce-Agenten gebaut, der rund um die Uhr Shops überwacht und Slack-Benachrichtigungen verschickt
      Wenn man an AI-bezogenen Projekten arbeitet, lohnt sich ein Blick auf selzee.com/openclaw