Laravel vs. Symfony: die Wahl und was sie kostet

Dieser Vergleich wird meist als Persönlichkeitstest präsentiert - Laravel ist pragmatisch, Symfony ist streng, nehmen Sie das, was nach Ihnen klingt. Das hilft nicht, wenn ein Budget daran hängt.

Der tatsächliche Unterschied: Symfony nimmt an, dass Sie entscheiden, und Laravel hat entschieden. Alles andere folgt daraus, in beide Richtungen.

Was "für Sie entschieden" bringt und kostet

In Laravel sind das ORM, die Queue-Abstraktion, die Mail-Schicht, das Test-Grundgerüst, das Authentifizierungs-Scaffolding und das Validierungssystem alle gewählt. Sie können sie ersetzen, und fast niemand tut es. Wer zu einem Laravel-Projekt stößt, weiß vor dem Öffnen des Repositorys, wo die Dinge liegen.

In Symfony sind die meisten davon Entscheidungen - Doctrine ist üblich, aber nicht vorgeschrieben, und dem Framework ist es recht, wenn Sie etwas anderes zusammensetzen. Der Preis ist eine Entscheidung je Projekt. Der Nutzen ist, dass bei wirklich ungewöhnlichen Anforderungen nichts gegen Sie arbeitet.

Die beiden Fehlermodi sind symmetrisch und beide real. Eine Laravel-Anwendung, deren Domäne nie zu den Annahmen des Frameworks passte, endet als große Menge Code, der um Eloquent herumarbeitet. Eine Symfony-Anwendung, in der niemand Konventionen durchgesetzt hat, endet damit, dass drei Teams dasselbe Problem auf drei Arten gelöst haben.

Das ORM ist der größte einzelne Unterschied

Hier liegt der Großteil der alltäglichen Abweichung.

Eloquent ist ein Active Record: Das Modell ist die Zeile, und es weiß, wie es sich speichert. Das schreibt sich schnell und liest sich gut - $order->customer->name ist für jeden offensichtlich. Der Preis ist, dass Persistenz sich durch Ihre Domänenobjekte zieht, und dass die Bequemlichkeit N+1-Abfragen leicht unbemerkt entstehen lässt.

Doctrine ist ein Data Mapper: Entitäten sind einfache Objekte, die nichts von der Datenbank wissen, und eine eigene Schicht ermittelt, was sich geändert hat. Das hält Persistenz aus der Domäne heraus, was genau das ist, was Sie wollen, wenn die Domäne kompliziert ist. Es kostet einen Entity Manager, eine Unit of Work, die man verstehen muss, und mehr Zeremonie für die neunzig Prozent der Fälle, die einfach waren.

Ist Ihre Anwendung überwiegend CRUD über ein relationales Schema, ist Active Record weniger Code für dasselbe Ergebnis. Hat Ihre Domäne Invarianten, die nicht davon abhängen dürfen, wie Zeilen gespeichert werden, verdient der Mapper seinen Aufwand. Das ist die ehrliche Trennlinie, und sie fällt stärker mit der Frameworkwahl zusammen als alles andere.

Wo jeweils die Antwort klar ist

Laravel, klar: ein Produktteam, das kontinuierlich Funktionen liefert; eine SaaS-Anwendung; alles, wo Queue, Scheduler, Mail und Broadcasting gewünscht sind und Sie nicht vier Bibliotheken integrieren wollen; ein Team, das durch Einstellungen wachsen wird, denn der Bewerberkreis ist größer und die Einarbeitung kürzer.

Symfony, klar: ein langlebiges System in einer Domäne mit echter Komplexität - Versicherung, Logistik, regulierte Finanzwelt -, wo die Modellierung wichtiger ist als die Liefergeschwindigkeit; eine Organisation, die bereits Symfony betreibt; ein Projekt, in dem das Framework am Rand einer bestehenden Architektur sitzen muss, statt sie zu definieren.

Beides, ehrlich: fast alles andere. Ein erfahrenes Team schreibt in beiden eine wartbare Anwendung, und der Unterschied im Ergebnis wird kleiner sein als der Unterschied, ob jemand Tests geschrieben hat.

Was es in der Praxis entscheidet

Nicht die Architektur. Die Menschen.

Der Bewerberkreis für Laravel ist deutlich größer, und der für Symfony verschiebt sich nach oben in der Erfahrung - was entweder ist, was Sie wollen, oder was Sie sich nicht leisten können. Ein Team, das eines davon bereits kennt, liefert darin schneller als im theoretisch besseren Fit, und der Abstand ist größer als jeder architektonische Vorteil.

Der zweite praktische Faktor ist der Markt für Agenturen und Support. Es gibt mehr Firmen, die eine Laravel-Codebasis übernehmen, und das zählt an dem Tag, an dem die Erbauer gehen. Das ist kein Argument über Qualität. Es ist ein Argument darüber, was im vierten Jahr mit der Anwendung passiert.

Was es nicht entscheidet

Performance. Beide verbringen ihre Zeit in Ihrer Datenbank. Wenn Ihre Anwendung langsam ist, ist sie es aus Gründen, die einen Frameworkwechsel unversehrt überstehen.

"Enterprise-Tauglichkeit". Beide laufen in großen Produktivsystemen mit echtem Geld. Die Anwendungen, die unter Last scheitern, scheitern wegen eines Schemas, einer unbeobachteten Queue oder fehlender Tests - in beiden Frameworks.

Lange Supportzeiträume. Symfonys LTS-Releases laufen länger, was ein echter Planungsunterschied ist. Er zählt, wenn Ihre Organisation nicht jährlich aktualisieren kann - und wenn das so ist, gehört der Grund dafür behoben, denn diese Einschränkung kostet Sie mehr, als die Frameworkwahl es je könnte.

Wenn Sie schon eines davon haben

Behalten Sie es. Fast jede Anfrage, von einem zum anderen zu wechseln, ist in Wahrheit die Bitte, etwas zu beheben, das nicht am Framework lag - eine Anwendung, die niemand sicher ändern kann, oder eine Version ohne Support. Beides lässt sich innerhalb des vorhandenen Frameworks angehen, für einen Bruchteil des Budgets, und die Migration hätte es nicht behoben.

Steht auf der Liste nicht wirklich Laravel gegen Symfony, sondern Laravel gegen etwas außerhalb von PHP, ist Rails das nächstliegende Gegenstück. Und wenn der Zweifel ist, ob ein Framework dieser Form überhaupt passt, steht das auf der allgemeineren Seite.