Warum ich seit 2018 auf Laravel setze und nicht auf Symfony
Ich baue Kundenprojekte seit 2018 mit Laravel, weil ich damit für die Anwendungen, die Mittelständler typischerweise brauchen, schneller zu wartbarem Code komme als mit jedem Werkzeug, das ich vorher genutzt habe. Dazu kommt ein Umfeld aus Statamic, Livewire und Flux auf demselben Fundament. Symfony ist ein hervorragendes Framework, für meine Projekte aber nicht die erste Wahl.
PHP schreibe ich seit 2004, Laravel nutze ich seit 2018. Dazwischen liegen vierzehn Jahre, in denen ich viele Wege ausprobiert habe, Anwendungen zu bauen. Diese Erfahrung ist der Grund, warum ich mich so eng festlege: Ich weiß, was es kostet, wenn jedes Projekt auf einem anderen Fundament steht. Warum es Laravel geworden ist und was ich dafür in Kauf nehme, beschreibe ich hier. Die Stationen meines Wegs stehen auf meiner Profilseite.
Der Stand vor 2018: eigene Lösungen und CMS
Vor Laravel bestand meine Arbeit aus zwei Welten. Die eine waren CMS-basierte Websites und Portale, ab 2011 für Agenturen und deren Kunden, unter anderem auf TYPO3 und WordPress. Zwei Beispiele aus dieser Zeit stehen auf der Website: ein Bildermarktplatz für ein Fotografen-Kollektiv mit eigenen TYPO3-Erweiterungen und ein Portal, in dem TYPO3 und WordPress nebeneinander liefen.
Die andere Welt waren Anwendungen, für die es kein passendes CMS gab. Dort entstand vieles von Hand, etwa ein Workflow-Portal von 2012 mit selbst geschriebener Zustandslogik, Aufgabenverteilung und Protokoll. Das funktionierte, aber jedes dieser Projekte hatte seine eigenen Konventionen. Wer später daran arbeiten sollte, musste zuerst die Eigenheiten des Projekts lernen. Ab 2013 folgten Jahre in festen Anstellungen, zuletzt als Lead Developer bei LEVELS mit Teams in München und Las Vegas. Dort habe ich gesehen, welche Prozesse in Teams tragen.
Seitdem leitet mich eine Erkenntnis: Die eigentlichen Kosten eines Projekts entstehen in den Jahren nach dem ersten Bau, bei jedem, der den Code verstehen muss.
Was Laravel im Alltag besser macht
Laravel nimmt mir die Entscheidungen ab, die in jedem Projekt gleich sind, und lässt mir die, die zum Kunden gehören. Datenbankzugriffe laufen über Eloquent, Hintergrundarbeiten über Warteschlangen, Berechtigungen über Policies, Prüfregeln für Formulare über Form-Requests, Mails über eigene, testbare Klassen. Jede dieser Lösungen ist dokumentiert, und jeder Laravel-Entwickler erkennt sie wieder.
Was das praktisch bedeutet, zeigt Athena, ein API-Backend für die Agile Robots AG. Ich habe es von Oktober 2022 bis Juni 2023 aufgebaut, mit Anmeldung über die Microsoft-Konten des Konzerns und einer Build-Pipeline auf GitLab, und danach an die hauseigene Pflege übergeben. Der Code liegt seitdem beim Kunden. Eine Übergabe nach acht Monaten funktioniert nur, wenn das Team auf der anderen Seite die Struktur wiedererkennt, ohne mich anrufen zu müssen.
Genauso wichtig sind Tests. Laravel bringt Werkzeuge mit, um Anfragen, Mails und Warteschlangen im Test nachzustellen, ohne dass eine Mail verschickt wird. Für die Tests selbst nutze ich Pest oder PHPUnit. Damit gehören Tests auch in kleinen Projekten zum Standard, und sie machen den Wechsel auf eine neue Hauptversion zu einer planbaren Aufgabe.
Dazu kommt der Takt. Laravel erscheint einmal im Jahr in einer neuen Hauptversion, jede mit festen Zeiträumen für Fehler- und Sicherheitskorrekturen. Beim Planen hilft ein Blick auf zwei Kalender: Die Sicherheitskorrekturen für PHP-Versionen enden laut php.net jeweils am 31.12., neue Laravel-Hauptversionen erscheinen im ersten Quartal. Die PHP-Version einer Anwendung läuft deshalb oft früher aus als die Laravel-Version, auf der sie steht. Ich lege Upgrades in die Monate nach einem Laravel-Release und prüfe dabei zuerst die PHP-Version. Die konkreten Daten stehen in den Beiträgen zum Supportende von PHP 8.2 und zu Laravel 13.
Statamic, Livewire und Flux auf einem Fundament
Den größten Gewinn sehe ich nicht im Framework allein, sondern darin, was darauf aufbaut.
Statamic ist ein CMS, das als Paket in einer Laravel-Anwendung läuft. Website und Anwendung teilen so dasselbe Fundament. Diese Website läuft auf Statamic 6 und damit auf Laravel 13, die Gründe stehen im Beitrag Warum wir Statamic 6 gewählt haben.
Livewire macht Oberflächen interaktiv, ohne dass daneben eine zweite Anwendung in JavaScript entsteht. Bei Livewire bleiben Logik und Prüfregeln an einer Stelle, auf dem Server.
Flux ist die offizielle Bibliothek von Oberflächen-Bausteinen für Livewire, gebaut mit Tailwind CSS. Formulare, Tabellen und Dialoge sehen in jedem Projekt gleich aus und verhalten sich gleich.
Im Taxifahrer-Portal der Münchner Taxi-Genossenschaft, das ich seit Juli 2025 baue und betreibe, läuft die Oberfläche auf Flux Pro statt auf selbst gebauten Komponenten. Auf der Projektseite steht, was das gebracht hat: Wochen an Eigenarbeit gespart und eine Oberfläche, an die sich die Mitglieder ohne Schulung gewöhnen.
Warum ein enger Stack Kunden nützt
Laravel seit 2018, Statamic seit 2019, Tailwind seit 2020: Ich wechsle Werkzeuge nicht jede Saison, und Kunden spüren drei Folgen davon.
Schätzungen werden genauer. Wer dieselben Bausteine seit Jahren einsetzt, kennt ihre Grenzen und die Stellen, an denen Zeit verloren geht.
Übergaben werden möglich. Ein Laravel-Projekt, das den Konventionen folgt, kann ein anderes Laravel-Team übernehmen, wie bei Athena. Das senkt die Abhängigkeit von einer einzelnen Person, siehe den Beitrag zum Bus-Faktor.
Projekte werden alt, ohne zu veralten. Die Website von REVONEER, einem Ingenieur-Büro, betreue ich seit Februar 2016. Sie läuft inzwischen auf Statamic, Laravel und PHP in den aktuellen Versionen; allein im aktuellen Repository stehen mehr als 2.400 Commits, rund 113 pro Monat. Ein Stack, den ich jedes Jahr ohnehin pflege, lässt sich so Schritt für Schritt nachziehen, statt alle paar Jahre neu zu bauen.
Dazu kommt ein einheitlicher Betrieb: Die Laravel-Anwendungen, die ich betreue, laufen auf Hetzner-Servern in deutschen Rechenzentren, mit täglichen Sicherungen und einer Sicherung vor jedem Deploy. Mehr dazu auf der Seite zur Laravel-Agentur.
Was gegen Laravel spricht
Laravel ist nicht für alles die richtige Wahl, und das sage ich auch Interessenten.
Sehr große, modulare Plattformen: Für Plattformen mit vielen klar getrennten Modulen, sehr langer Lebensdauer und großen Teams hat Symfony mit seinen Bundles und seiner strengen Dependency Injection traditionell Vorteile. Laravel hat aufgeholt, der Unterschied ist aber nicht verschwunden.
Bestehende Symfony-Teams: Ein Team, das seit Jahren produktiv mit Symfony arbeitet, sollte bleiben, wo es ist. Ein Wechsel nur um des Frameworks willen kostet mehr, als er bringt.
Echtzeit und Rechenlast: Für sehr viele gleichzeitige Echtzeit-Verbindungen, rechenintensive Stapelverarbeitung oder eingebettete Systeme gibt es geeignetere Werkzeuge.
Abhängigkeit vom Hersteller-Umfeld: Das Framework ist quelloffen unter der MIT-Lizenz. Hinter Laravel steht aber ein Unternehmen, das 2024 eine Finanzierung von 57 Millionen US-Dollar erhalten hat und kostenpflichtige Dienste rund um das Framework verkauft. Ich nutze das offizielle Ökosystem, betreibe die Anwendungen aber auf eigenen Servern statt auf Plattformen, deren Preise ein einzelner Anbieter festlegt.
Laravel selbst baut übrigens auf Komponenten von Symfony auf, etwa für die Verarbeitung von Anfragen und für die Kommandozeile. Meine Wahl richtet sich also nicht gegen Symfony als Technik, sondern ist eine für einen Arbeitsstil. Einen neutralen Vergleich beider Frameworks finden Sie auf der Seite Laravel vs. Symfony.
Passt Laravel zu Ihrem Vorhaben?
Erzählen Sie mir, was Sie bauen wollen. Ich sage Ihnen offen, ob Laravel dafür das richtige Werkzeug ist.
Nachgefragt
Häufige Fragen
-
Für die meisten Anwendungen im Mittelstand ohne Einschränkung, von Kundenportalen über SaaS-Plattformen bis zu Schnittstellen mit hohem Datenaufkommen. Für die Größe zählt eher die Architektur innerhalb des Frameworks, etwa ein sauber in Module geteilter Aufbau, als die Wahl des Frameworks selbst. Bei sehr großen Plattformen mit vielen Teams ist ein Vergleich mit Symfony sinnvoll.
-
Laravel legt für jede Hauptversion feste Zeiträume für Fehler- und Sicherheitskorrekturen fest und veröffentlicht jedes Jahr eine neue Hauptversion. Die aktuellen Daten stehen in den Release Notes von Laravel. Wer jährlich oder spätestens vor dem Ende der Sicherheitskorrekturen wechselt, bleibt durchgehend im unterstützten Bereich.
-
Mit Symfony als Framework nicht. Symfony-Komponenten stecken in jedem meiner Projekte, weil Laravel sie für Anfragen, Kommandozeile und weitere Grundfunktionen nutzt. Anwendungen, die auf dem Symfony-Framework aufbauen, entwickle ich aber nicht; dafür ist ein Team mit Symfony-Erfahrung die bessere Wahl. Wer vor der Entscheidung steht, bekommt von mir trotzdem eine ehrliche Einschätzung, auch wenn sie für Symfony ausfällt.
Nachweise
Quellen und Stand
Stand: 13.11.2026, Angaben geprüft am 02.11.2026. Stationen und Projekte laut den Seiten dieser Website, Versionsdaten laut laravel.com und php.net.
Artikel teilen