Du benutzt Rails falsch
(bananacurvingmachine.com)- Anhand eines Gesprächs zwischen zwei Entwicklern über die Integration von Rails 8 und Vite wird die unnötig komplex gewordene moderne Webentwicklungsumgebung satirisch aufs Korn genommen
- Einer von ihnen fügt unzählige Tools wie Vite, React, Babel, Tailwind, Docker, Husky hinzu und bezeichnet das als einen „modernen“ Stack
- Der andere zeigt hingegen eine sofort lauffähige App nur mit dem Standard-Rails, ganz ohne Konfiguration, und macht damit den Nutzen von Einfachheit deutlich
- Der Text verspottet die aktuelle Abhängigkeit von komplexen Toolchains und betont die Botschaft „Benutz einfach Rails“, wodurch er zum Nachdenken über die Tugend der Einfachheit anregt
- Er weist darauf hin, dass der ursprüngliche Zweck von Rails — Produktivität, Konsistenz und die Freude an der Entwicklung — zunehmend in Vergessenheit gerät
> “Just F#$%^& use Rails”
Übersetzung des Originaldialogs
Kevin: Hey, hast du Vite für Rails 8 ausprobiert? Es ist wahnsinnig schnell.
John: Davon habe ich gehört. Das ist doch ein Build-Tool, oder? Hatte Rails nicht schon so etwas?
Kevin: Hatte es. Aber Vite ist etwas moderner. Du musst Node und npm installieren und ein paar Skripte konfigurieren, aber es lohnt sich.
John: Moment, Rails braucht jetzt Node?
Kevin: Ja, wenn du React verwenden willst. Heutzutage nutzt doch jeder React.
John: Gab es dafür in Rails nicht schon etwas?
Kevin: Gab es, aber jetzt solltest du Vite zusammen mit React Refresh verwenden. Dann werden die Komponenten sofort aktualisiert. Wenn du TypeScript nutzen willst, musst du das auch noch konfigurieren.
John: Schon beim Zuhören klingt das kompliziert.
Kevin: Ach was, das ist nichts Besonderes. Du installierst Babel, richtest .babelrc ein, fügst vite-plugin-ruby hinzu, und für die Styles solltest du natürlich PostCSS verwenden.
John: PostCSS?
Kevin: Klar. Und selbstverständlich musst du auch Tailwind verwenden — du willst doch wohl nicht im Ernst jedes CSS von Hand schreiben.
John: Natürlich nicht.
Kevin: Danach bringst du den Code mit ESLint und Prettier in Ordnung, und vor dem Commit richtest du mit Husky noch Hooks ein — dann ist es perfekt.
John: Also Vite, React, Babel, PostCSS, Tailwind, ESLint, Prettier, Husky. Ist das alles?
Kevin: Fast. Wenn du auch noch Server-Side Rendering willst, solltest du Next.js oder Remix verwenden.
John: Moment mal, wir reden schon noch über Rails, oder?
Kevin: Klar. Heutzutage sind Hybrid-Stacks doch der Standard! Wenn du reaktive Komponenten ohne JS-Framework willst, sind StimulusReflex oder Hotwire auch gut.
John: StimulusReflex? Klingt wie der Name einer Marvel-Figur.
Kevin: Ha ha, nein, das gibt es wirklich. Das ist für Echtzeit-Updates. Aber dafür musst du ActionCable konfigurieren, und Redis brauchst du auch.
John: Redis?
Kevin: Ja, du brauchst eine Pub/Sub-Schicht. Keine Sorge, du musst einfach nur noch einen Docker-Container mehr starten.
John: Ich muss also auch Docker verwenden?
Kevin: Natürlich. Um Abhängigkeiten zu isolieren, ist das unverzichtbar. Wenn du die Umgebung vollständig reproduzierbar machen willst, brauchst du außerdem Docker Compose, Deployment über Fly.io und eine Pipeline mit GitHub Actions.
John: Das ist ... ziemlich komplex.
Kevin: Das ist einfach moderne Webentwicklung, mein Freund. Ganz simpel. Und was machst du so?
John: Ich probiere nur ein bisschen herum.
(John führt einen einzigen Befehl aus. Die App startet sofort. Formulare funktionieren, das Laden ist schnell, und die Navigation ist blitzschnell.)
Kevin: Wow, das sieht ziemlich komplex aus. Welchen Stack benutzt du?
John: Einfach pures Rails.
> Just F#$%^& use Rails.
3 Kommentare
Ich liebe beide Tools. Die beiden Tools haben Überschneidungen bei Ökosystem und Einsatzzweck, sind aber keine völlig identischen Werkzeuge und sollten nicht nach ihrem Schwierigkeitsgrad bewertet werden. Mit Vite kann man Skripte umfangreich und fein abgestimmt schreiben. Stimulus oder Hotwire sind hingegen besser dafür geeignet, die Entwicklung von Skripten auf ein Minimum zu reduzieren.
Der Großteil des Inhalts scheint sich auf Frontend-Entwicklung zu konzentrieren...
Hacker-News-Kommentare
Dieser Artikel wird seit über 10 Jahren immer wieder neu geschrieben.
Die sogenannte „Komplexität“ ist letztlich nur eine Liste von Werkzeugen, die jeweils ein bestimmtes Problem lösen.
Nicht die Werkzeuge selbst sind das Problem; die Realität ist, dass moderne Webentwicklung eine inhärente Komplexität hat.
Ähnliche „versteckte“ Komplexität sieht man auch bei ASP.NET oder Desktop-GUI-Frameworks.
Wenn man Rails zum Beispiel als API-Backend nutzt und das Frontend von React übernommen wird, ist das eine völlig andere Architektur als ein traditioneller monolithischer Rails-Ansatz.
Eine Werkzeugliste wie Vite, React oder Prettier ist eine Auswahl für völlig andere Probleme (wenn man Rails im Frontend nutzen will, sollte man einfach Rails nutzen; Zwischenformen mag ich nicht besonders).
Das eigentliche Problem ist die Art, wie gelernt wird.
Heutige Entwickler lernen oft zuerst Frameworks, bevor sie die Grundlagen des Webs beherrschen (HTML, CSS, serverseitige Logik, Datenbanken).
Jedes Tool existiert aus einem Grund, und alle sind Werkzeuge, die das moderne Web braucht.
Das nur als „zu viel“ zu sehen, verkennt die Realität der Branche.
Komplexität ist der Webentwicklung nicht inhärent.
Im Gegenteil: Heute kann man mit weniger mehr erreichen.
Hotwire funktioniert fast wie pures Rails, und man kann mit einer einzigen Zeile ein modernes Erlebnis konfigurieren, bei dem Inhalte über WebSockets in Echtzeit aktualisiert werden.
Auch der übliche Weg, JS in Rails bereitzustellen, ist dank import maps sehr einfach geworden (kein separater Build-Schritt nötig).
Tailwind lässt sich ebenfalls sehr leicht hinzufügen.
Sogar das Deployment ist mit kamal viel einfacher geworden.
Deshalb stimme ich nicht zu, dass Komplexität wesentlich ist, und Hotwire trägt gerade dazu bei, sie zu verringern.
Lernen sollte nicht heißen, „mehr zu lernen“, sondern zu lernen, „mit weniger mehr zu machen“.
Echte technische Stärke ist nicht, 20 Sprachen oder Server zu beherrschen, sondern mit 4 Dingen und einem 3-Personen-Team tausend Leute hinter sich zu lassen.
Ich glaube nicht, dass die Leute etwas gegen die Existenz von Tools an sich haben; sie stören sich eher an der Stimmung, dass alle sie unbedingt verwenden müssten.
Jeder Tutorial- oder YouTube-Titel klingt wie „Der MONGOOSE-Stack, den du unbedingt nutzen musst!“, sodass es viele Anfänger gibt, die sogar in einen Backblog krampfhaft redis einbauen wollen.
Tatsächlich kommen die meisten Websites auch ohne speziellen Stack bestens aus.
Aber weil das niemand bewirbt, wissen viele Junior-Entwickler das in der Praxis gar nicht.
Ich stimme zu, dass das Lernen der Basistechnologien Priorität haben sollte, aber zwischen all den Firmen, die ihre Dienste bewerben, ist diese Botschaft schwer zu vermitteln.
Ich bin in Rails ziemlich unerfahren, habe aber rund 10 Jahre Erfahrung mit anderen Sprachen.
Zusätzliche Tools einzuführen ist in Ordnung, wenn man sie braucht (ob sie wirklich nötig sind, steht auf einem anderen Blatt).
Aber Rails ist ursprünglich bereits ein riesiges Allzweck-Framework, das alles von ORM über Konsole bis zur Generierung von Scaffold-Code umfasst.
Wenn zusätzliche Tools nötig sind, sollte man dann nicht eher Rails selbst noch einmal überdenken?
Vielleicht wäre etwas Modulareres besser.
Der Ausdruck „Vanilla Rails“ wirkt auf mich wie ein Warnsignal. Wie kann man ein derart schwergewichtiges Framework „vanilla“ nennen?
Der Punkt des Artikels ist, dass viele von Anfang an gar nicht hinterfragen, ob sie wirklich eine „moderne Webanwendung“ brauchen, und gar nicht wissen, dass schlichtes Rails schon ausreicht.
Es fehlt an dem Versuch, die Standardentscheidungen von Vanilla Rails selbst zu verstehen.
Von der „Komplexität moderner Webentwicklung“ zu sprechen, beschreibt nur eine Problemsituation; es ist keine notwendige Voraussetzung.
Wenn man für eine Website, die nur aus einer Datenbank und ein paar SQL-Abfragen besteht, Tausende npm-Pakete heranzieht, macht man eindeutig etwas falsch.
Ich schreibe seit 2007 Rails-Code.
Dass der Stack komplexer geworden ist, hat seine Gründe, und Teams, die es nach dem Maßstab des Artikels „richtig“ gemacht haben, gibt es in der Praxis kaum.
Das Problem eines Omakase-Frameworks (also eines Frameworks, das wie Rails die meisten Dinge vorgibt) ist nicht nur die anfängliche Entscheidung, sondern dass man auch alle späteren Entscheidungen mitgehen und das ganze Team mitziehen muss.
Rails ist mächtig, aber auch seine Maintainer können nicht perfekt in die Zukunft sehen.
Deshalb gibt es heute fast keine Apps mehr, die zu Vanilla Rails zurückgekehrt sind.
Früher, vor Docker, war Rails-Deployment wirklich umständlich. Statt rsync oder tarball brauchte man Deploy-Systeme wie Capistrano.
Docker oder k8s sind bequem, aber verglichen mit früher nicht wirklich schlechter.
Wenn du dich an Rails-Deployment in der Zeit vor Docker als „rsyncen und ein tarball entpacken“ erinnerst, dann war das ein wirklich chaotisches Setup.
Mit dem „alten“ Capistrano zu deployen war deutlich besser.
Ich hätte gern genauer erklärt, was konkret so problematisch daran war, „mit rsync oder tarball auf mehrere Instanzen zu deployen“.
So schlimm klingt das für mich ehrlich gesagt nicht.
Deshalb hatte ich immer eine Schwäche für Sinatra.
Es ist schade, dass die Out-of-the-box-Utilities von Rails in der JS-Welt noch immer nicht wirklich ersetzt werden können.
Die meisten JS-Entwickler wissen das nicht.
Aber JS ist eben seit jeher ein Ökosystem, in dem ständig das Rad neu erfunden wird.
Ein großer Vorteil von JS ist, dass jeder die Chance hat, eine neue Plattform zu bauen.
Dass man mehrere JS-Plattformen gleichzeitig kombinieren kann und irgendwie alles trotzdem läuft, ist sehr skalierbar und hackbar, und man kann alles lokal dauerhaft bauen, um eine statische Site zu erzeugen.
Aber diese Freiheit braucht auch Disziplin.
Das Team muss notfalls Kollegen bremsen, die jederzeit noch ein neues Framework einführen wollen.
Ember.js ist ein All-in-one-Framework („batteries included“), das von großen Namen aus dem Rails-Lager gebaut wurde.
Dass es nicht so erfolgreich war wie andere Frameworks, hat vermutlich seinen Grund.
Auch im JS-Ökosystem gibt es mit AdonisJS ein Backend-Framework, das alles mitbringt.
Das NodeJS-Ökosystem entstand allerdings aus einer Gegenbewegung zu den stark vorstrukturierten Frameworks wie Rails oder Django und startete daher mit Mikroframeworks.
Das Konzept von Express war ebenfalls, Dinge „schnell und grob“ zusammenzubauen.
Auch in JS gibt es mehrere Full-Stack-Frameworks, die Rails ähneln.
Es gibt zum Beispiel auch ein Framework namens Sails.
JS löst jedoch andere Probleme als Rails, deshalb sehen die Frameworks zwangsläufig anders aus.
Rails hat zwar viele Utilities, aber auf lange Sicht kann es ermüdend sein, die Codebasis regelmäßig zu aktualisieren und den Rails-Trends ständig folgen zu müssen.
Stimulus und Hotwire haben sich inzwischen als „Rails Way“ etabliert.
Selbst wenn man die Dokumentation sorgfältig liest, ist es immer noch sehr verwirrend.
Es fühlt sich an, als würde man ständig JS-Komponenten von Hand neu bauen.
Meiner Meinung nach sorgt die Kombination aus Rails 8 + Inertia.js + React eher dafür, dass man das Rad weniger neu erfindet, besonders wenn man shadcn-Komponenten nutzt.
Dem stimme ich zu.
Wir haben unser Hotwire-Frontend ebenfalls durch Inertia ersetzt, und der Unterschied ist gewaltig.
Außer man arbeitet wirklich zu 100 % allein an einem kleinen Projekt, wird Hotwire sehr schnell zu einem Chaos, das im Team niemand mehr anfassen kann.
Ich mochte Stimulus so sehr, dass ich es aus Rails direkt in eine Phoenix-App mitgenommen habe.
Das Problem ist aus meiner Sicht aber ein Missverständnis dieses Tools.
Stimulus ist keine React-Alternative.
Wenn man an JS-Apps mit Zehntausenden Zeilen Code gewöhnt ist, passt React vielleicht besser.
Aber wenn in einer serverseitig dominierten App die UX mit ein paar Dutzend Zeilen JS verbessert werden soll, ist Stimulus genau richtig.
In Phoenix ist es eine minimalistische Lösung, die perfekt zwischen statisches HTML und dynamische LiveViews passt.
Niemand hat je gesagt, man solle mit Stimulus ein SPA bauen, und ich denke, dann gerät man zwangsläufig in schwieriges Fahrwasser.
Stimulus ist wirklich klein, ein Event-System mit HTML-Hooks, und passt gut zum Request-Lifecycle von Rails.
Ich frage mich, ob jemand schon einmal erfolgreich etwas wirklich Komplexes mit Stimulus gebaut hat.
Mein Eindruck war, dass das ziemlich schwierig wäre.
Ich bin selbst ein ziemlicher Rails-Fanboy, aber ich finde den aktuellen Zustand von Stimulus und Hotwire schade.
Das Konzept ist großartig, und die Implementierung ist vielleicht auch gut.
Aber die Dokumentation ist so erschreckend dürftig, dass man kaum anfangen will, und es gibt kaum Informationen, mit denen man die Frage beantworten könnte: „Wenn ich damit starte, lande ich später in einer Sackgasse?“
Ich habe Stimulus zusammen mit Symfony für kleine Interaktionen verwendet, und dank der kleinen, gut gestalteten API war das ziemlich gut.
Turbo/Hotwire als Ganzes habe ich noch nicht genutzt, und für komplexere oder zustandsbehaftete Seiten verwende ich normalerweise Vue.
Greenfield-Projekte gibt es heute ohnehin fast nicht mehr.
Außer bei Gründern sind echte Greenfield-Projekte selten, und wenn man etwas verkauft, wird es zu 99 % als Shopify-Wrapper oder etwas Ähnliches umgesetzt.
Auch in Großunternehmen ist Greenfield an allerlei Anforderungen und interne Frameworks gebunden, sodass man nicht einfach mit „rails new“ startet.
Diese Diskussionen haben wenig Sinn, und ähnliche Debatten und Artikel wiederholen sich seit 10, 15 oder 20 Jahren immer wieder, was ermüdend und langweilig ist.
Statt neuer Artikel hätte ich lieber, dass tatsächlich etwas Neues gebaut wird.
Stimme voll zu.
Ich habe 10 Jahre lang mit Ruby/Rails gearbeitet, und selbst die „neueste“ Codebasis war immer schon über 5 Jahre alt.
Ehrlich gesagt habe ich zwar neue Greenfield-Rails-Apps gebaut, aber das waren API-only-Microservices, bei denen es gar kein Frontend brauchte.
In größeren Firmen wird die Rails-Frontend-Lösung komplett ignoriert.
Hotwire-Entwickler findet man kaum, aber React- oder Vue-Entwickler jederzeit.
Der FE-Stack von Rails ändert sich zudem ständig, ist schwer nachzuverfolgen (ich erinnere mich noch an die CoffeeScript-Zeit), hat kaum brauchbare Dokumentation und realistisch gesehen wenig Einfluss.
Deshalb sind solche Diskussionen von der tatsächlichen Realität abgekoppelt.
Ich kann der Aussage „Greenfield-Projekte gibt es außer bei Gründern nicht mehr“ nicht zustimmen.
Wenn man nur alte Enterprise-Monolithen oder Fortune 500 betrachtet, schaut man auf eine winzige Minderheit außerhalb des Durchschnitts.
Im Gegenteil finde ich es beeindruckend, wie viel Mühe in „rails new“ steckt, damit die Defaults vernünftig und sofort nutzbar sind.
Dieser Ansatz schließt die Lücke zwischen Hello World und allzu simplen API-Dokumentationen sehr gut.
Selbst wenn man Rails nicht verwendet, ist das etwas, von dem man lernen kann.
Es ist zwar niedlich, aber es verschweigt die Realität, dass sich eine Rails-App im Lauf ihrer Entwicklung immer wieder durch bundler, webpacker, sprockets, Propshaft, importmaps, jsbundling usw. bewegen musste.
Vom autoloader zu zeitwerk, von Turbo zu Hotwire und so weiter: In Wirklichkeit hat sich enorm viel verändert.
Sogar in Rails-Newslettern sieht man in der Werbung ständig „Experten helfen beim Upgrade von Rails-Apps“.
Danke, dass das angesprochen wird.
„Nutzt einfach Vanilla Rails“ ist leicht gesagt, aber in Rails hat sich in den letzten 5 Jahren mit jeder Version der Umgang mit JS komplett verändert.
Es gibt immer noch viele gems, die auf sprockets angewiesen sind, sodass man selbst auf dem Rails-Weg zwangsläufig in komplexem JS landet.
Gerade ist das wirklich verwirrend. Vielleicht wird es irgendwann besser, aber Rails trägt definitiv einen Teil der Verantwortung.
CoffeeScript darf man auch nicht vergessen.
Bis vor Kurzem hat die Firma, in der ich gearbeitet habe, die Portierung von CoffeeScript immer noch aufgeschoben, während neuer Code bereits in Vue geschrieben wurde.
Aus eigener Erfahrung habe ich gelernt, dass man die zusätzliche Komplexität einer Trennung von Frontend und Backend nicht braucht, solange nicht mehr als 30 Entwickler aus verschiedenen Fachbereichen gleichzeitig an einem Projekt arbeiten.
Als Freelancer habe ich sogar in Teams von 1 bis 2 Personen unnötig überengineert; inzwischen nutze ich meist einfach Django mit etwas Tailwind.
Wir haben dieses Jahr Django-Entwickler eingestellt, und fast alle Bewerber bauten nur ein dünnes API-Backend mit Django und ein großes React-Frontend darum herum (oft war sogar die Geschäftslogik ins Frontend verlagert).
Fragt man nach dem Grund, kann es fast niemand erklären.
Am Ende blieben nur die wenigen Bewerber übrig, die rein auf serverseitiges Rendering gesetzt hatten.
Wenn man wirklich ein stark interaktives Frontend braucht, muss man sich vielleicht überlegen, wie man das angeht.
Da stimme ich zu.
In den meisten Bereichen der Branche ist es den Kunden ziemlich egal, ob man hyperskalierbare Systeme und Microservices braucht oder ob ein Monolith mit PostgreSQL völlig ausreicht.
Es wirkt, als würden viele nur den neuesten Trends hinterherlaufen und ihre Setups auf unendliche Skalierung ausrichten.
Tatsächlich ist Rails auch mit einfachem Design sehr nützlich, und oft wird aus Langeweile oder weil es „mehr Spaß macht“ überengineert.
Rails ist wirklich ein batteries-included Framework, und wenn man mit Overengineering aufhört, funktioniert es einfach.
Irgendwann merkt man, dass Produktivität der wichtigste Wert ist.
Heute ist es zwar komplexer geworden, aber die Grundidee ist nicht neu.
Als ich vor 15 Jahren Django gelernt habe, verlangten Tutorials auch schon die Installation bestimmter Versionen von Vagrant, VirtualBox und Chef, und ich wäre fast wahnsinnig geworden.
Ich mag Django immer noch und nutze es weiterhin, aber um solche Tools kümmere ich mich nicht.
Auch Django Rest Framework war eher etwas, das den Fokus verwässert hat.
„Tooling-Müdigkeit in der Webentwicklung“ ist sehr real.
Vor 10 Jahren war sie das auch schon, und dieses Chaos ist meist das Ergebnis davon, dass Entwickler ihre Hobby-Vorlieben mit zur Arbeit bringen.
Und ergänzend: Nicht nur im Frontend ist das so, bei DevOps sieht es ganz ähnlich aus.
Das führt dazu, dass man sich in einem Bereich nur noch bewerben kann, wenn man alle Tools kennt und dazu noch 10 Jahre Erfahrung, diverse Backends, SQL und Docker mitbringt.
Wenn man das beruflich macht, richtet man es einmal ein und fertig, aber bei Einmalprojekten oder wenn Webentwicklung nicht die Hauptaufgabe ist, ist es definitiv ermüdend.
Man kann das aber auch vermeiden.
Ich habe eine Website mit dem Framework Fresh(https://fresh.deno.dev/) gebaut, und das allein war völlig ausreichend.
Insgesamt war das viel einfacher als die übliche Node/Webpack-Kombination, und ich konnte trotzdem Typescript und TSX verwenden.
Wenn mehrere Leute daran gearbeitet hätten, hätte ich vielleicht noch ESLint ergänzt, aber auch ohne ließ sich sehr leicht loslegen.