Laravel vs. Rails: der Vergleich hat sich verschoben

Laravel begann damit, zu übernehmen, was Rails bewiesen hatte: dass ein Framework Meinungen haben darf, dass Konvention für die meisten Teams Konfiguration schlägt, und dass Entwicklerfreundlichkeit ein legitimes Engineering-Ziel ist statt eine Bequemlichkeit.

Das war vor fünfzehn Jahren. Sie heute auf diesen Begriffen zu vergleichen, verfehlt, was sie tatsächlich trennt.

Worin sie sich weiterhin einig sind

Beide sind Full-Stack und meinungsstark. Beide nutzen Active Record. Beide haben Migrationen, eine starke CLI, eine ausgereifte Testkultur und eine Verzeichnisstruktur, die man vor dem Öffnen des Repositorys vorhersagen kann.

Wer in einem sattelfest ist, liest den Code des anderen binnen einer Woche bequem. Das ist zwischen Ökosystemen ungewöhnlich und gehört vor die Unterschiede gesagt.

Hintergrundarbeit ist die größte praktische Lücke

Laravels Queue-System gehört zum Framework: Treiber, Wiederholungen mit Backoff, Batching, eindeutige Jobs, Ratenbegrenzung, eine Tabelle für fehlgeschlagene Jobs und ein Dashboard - gemeinsam dokumentiert und gemeinsam versioniert.

Rails hat Active Job als Abstraktion mit einem Adapter darunter, meist Sidekiq, das ausgezeichnet ist und ein eigenes Produkt mit eigenen Bezahlstufen für Funktionen, die Sie vielleicht wollen.

Beide Anordnungen funktionieren. Der Unterschied liegt darin, wie viele Entscheidungen und wie viele Systeme Sie besitzen, und für ein kleines Team zählt das mehr als die Funktionsmatrix.

Typisierung und Werkzeuge

PHPs Typsystem ist stetig gewachsen, und moderner Laravel-Code ist durchgehend typisiert. Statische Analyse über eine Laravel-Codebasis ist ausgereift und routinemäßig Teil von CI.

Rubys Typisierungsgeschichte ist jünger und in der Praxis weniger gesetzt. Wenn Ihnen ein Typprüfer wichtig ist, mit dem der Großteil des Ökosystems zusammenarbeitet, liegt PHP derzeit vorn - ein Satz, den vor einem Jahrzehnt niemand geschrieben hätte.

Hosting-Ökonomie

PHP läuft überall. Ein einzelner bescheidener Server betreibt eine Laravel-Anwendung samt Queue-Workern und Scheduler, und eigens dafür gebaute verwaltete Plattformen sind günstig.

Rails-Hosting ist gut unterstützt und kostet am unteren Ende im Allgemeinen mehr, vor allem über Speicher je Prozess. Bei kleiner Größe ist das eine echte Budgetzeile. Bei großer Größe hört es auf zu zählen, weil beide von der Datenbank und der Infrastruktur drumherum dominiert werden.

Einstellung, das Argument, das meist gewinnt

Der PHP- und Laravel-Kreis ist deutlich größer, weltweit und über mehr Erfahrungsstufen. Der Rails-Kreis ist kleiner und erfahrener - die Menschen sind also oft ausgezeichnet, es sind weniger, und sie sind teurer.

Das entscheidet mehr dieser Fragen als jeder technische Punkt in diesem Artikel, und es entscheidet sie richtig. Ein Framework, für das Sie niemanden einstellen können, ist ein Framework, das Sie in vier Jahren neu schreiben.

Wo Rails wirklich vorn liegt

Tiefe der Konventionen. Rails setzt seine Konventionen länger, und die Antwort auf "wohin gehört das" ist häufiger geklärt. Laravel gibt Ihnen mehr Freiheit, die große Teams selbst in aufgeschriebene Regeln übersetzen müssen.

Die Frontend-Geschichte. Hotwire und Turbo sind eine kohärente, ausgereifte Antwort auf interaktive Anwendungen ohne eigenen Frontend-Stack. Laravels Gegenstücke sind gut und es sind mehrere, also eine Entscheidung, bei der Rails einen Standard hat.

Reife des Upgrade-Pfads. Rails' lange Releasegeschichte bedeutet sehr eingelaufene Upgrade-Konventionen. Laravels jährlicher Takt ist vorhersehbar und verzeiht Zurückbleiben weniger.

Heute zwischen ihnen wählen

Haben Sie ein Team in einem davon, ist das die Antwort, und der Abstand ist nicht knapp.

Fangen Sie ohne Vorliebe neu an: Laravel, wenn Sie einstellen und wachsen wollen, wenn Hintergrundarbeit zentral ist, oder wenn Hosting-Kosten bei kleiner Größe zählen. Rails, wenn Sie die gesetztesten verfügbaren Konventionen wollen und eine Erstanbieter-Antwort für interaktive Frontends.

Erwägen Sie den Wechsel von einem zum anderen, gilt derselbe ehrliche Rat wie immer: Finden Sie zuerst heraus, was Sie tatsächlich kostet. In den meisten dieser Gespräche sind es das Schema, die fehlenden Tests oder die Weggegangenen, und nichts davon bessert sich durch einen Sprachwechsel.

Innerhalb von PHP spielt sich dieselbe Auseinandersetzung über Konventionen gegen Symfony ab, was der nähere Vergleich ist, sobald die Sprache feststeht. Und wenn der eigentliche Zweifel die Form des Frameworks ist statt die Wahl darin, gibt es dafür eine Seite.