Vanilla PHP vs. Laravel vs. Symfony 2026 — wann nimmt man was?

Die ehrlichste Antwort auf die häufigste Frage in PHP-Entwickler-Communities. Kein Framework-Fanboy-Bias, keine gesponserten Empfehlungen — nur drei Szenarien, drei ehrliche Urteile, und ein Entscheidungsbaum der dir in 2 Minuten sagt was du brauchst.

Die Frage die niemand ehrlich beantwortet

Tippe "Laravel vs Symfony" in Google. Was du bekommst: Artikel von Leuten, die entweder ihr Laravel-Kurs-Affiliate-Link promoten oder die Community-Punkte auf StackOverflow farmen. Die echte Antwort — "es kommt drauf an, und manchmal brauchst du gar kein Framework" — schreibt niemand, weil sie sich nicht gut verkauft.

Also schreiben wir sie jetzt.

Die unbequeme Wahrheit vorab: In 2026, nach Jahren des Framework-Hypes, schreiben erfahrene PHP-Entwickler zunehmend wieder Vanilla PHP. Nicht aus Nostalgie. Aus Kalkül.

Was wir vergleichen — und was nicht

Dieser Vergleich geht nicht um Features-Listen. Die haben alle drei. Er geht um Kosten — Lernkurve, Overhead, Komplexität, Wartbarkeit — und wann welche Kosten gerechtfertigt sind.

Die RAM- und TTFB-Werte sind real gemessene Werte auf einem VPS mit 4 GB RAM, PHP 8.3, OPcache aktiviert, kalter Cache. Sie variieren je nach Konfiguration — aber die Verhältnisse bleiben konsistent.

Vanilla PHP in 2026 — der unterschätzte Allrounder

Lass uns das Offensichtliche aus dem Weg räumen: "Vanilla PHP" bedeutet nicht "PHP aus dem Jahr 2005 mit globalen Variablen und mysql_query()". Es bedeutet: PHP 8.3 mit modernen Standards, PSR-Konventionen, Composer für das was nötig ist — aber ohne Full-Stack-Framework.

Was modernes Vanilla PHP heute kann

<?php
// PHP 8.3 — das ist nicht dein Opa's PHP

// Readonly Properties & Constructor Promotion
class BlogPost {
    public function __construct(
        public readonly int    $id,
        public readonly string $title,
        public readonly string $slug,
        public readonly \DateTimeImmutable $publishedAt,
    ) {}
}

// Named Arguments — klar wie Dokumentation
$post = new BlogPost(
    id: 42,
    title: 'Vanilla PHP in 2026',
    slug: 'vanilla-php-2026',
    publishedAt: new \DateTimeImmutable('2026-01-15'),
);

// Enums (seit PHP 8.1)
enum PostStatus: string {
    case Draft     = 'draft';
    case Published = 'published';
    case Archived  = 'archived';
}

// First-Class Callable Syntax
$slugs = array_map(fn(BlogPost $p) => $p->slug, $posts);

// Fibers für einfache Async-Muster (PHP 8.1+)
$fiber = new Fiber(function(): void {
    $value = Fiber::suspend('first');
    echo "Received: " . $value . "\n";
});

Wann Vanilla PHP die klügste Wahl ist

Szenario 1: Bekannte Domäne, bekanntes Team
Du kennst das Problem, dein Team kennt PHP, die Anforderungen sind klar. Ein Framework fügt hier nur Indirektion hinzu — du lernst Laravel statt dein Problem zu lösen.

Szenario 2: Performance ist nicht verhandelbar
APIs die unter Last <20ms antworten müssen. Microservices. Webhooks mit hohem Volumen. Das Laravel-Bootstrapping kostet dich 40–80ms pro Request — das ist kein Bug, das ist ein bewusstes Design-Entscheidung. Wenn du das nicht bezahlen kannst oder willst: Vanilla.

Szenario 3: Lange Lebensdauer, kleines Team
Ein System das 10 Jahre laufen soll, gewartet von 1–2 Entwicklern. Laravel 10 → 11 → 12 bringt jedes Jahr Breaking Changes. Symfony hat klare LTS-Zyklen (3 Jahre). Vanilla PHP: ein PHP-Versionsupgrade ist dein einziges externes Kompatibilitätsproblem.

Szenario 4: Du willst wirklich verstehen was passiert
Das klingt nach Lernkurve, ist aber ein echtes Argument für Produktionscode: Mit Vanilla PHP verstehst du jeden Stack-Frame in einem Fehler-Trace. Mit Laravel liest du häufig: Illuminate\Foundation\Http\Kernel → Pipeline → Stack → ... und weißt immer noch nicht wo dein Code sitzt.

Die ehrliche Schwäche von Vanilla PHP

Du baust Infrastruktur die andere schon gebaut haben. Ein sauber entworfenes Routing-System, ein Dependency-Injection-Container, ein ORM — das alles ist lösbar, aber es ist Arbeit die nichts mit deinem eigentlichen Problem zu tun hat. Wenn dein Team diese Arbeit nicht einmalig investieren kann oder will: Framework.

Laravel — das richtige Werkzeug für die richtige Aufgabe

Laravel ist das meistgenutzte PHP-Framework der Welt aus gutem Grund: Es ist extrem produktiv für einen bestimmten Projekttyp. Aber genau dieser "bestimmte Projekttyp" wird in Laravel-Tutorials selten klar benannt.

Wofür Laravel wirklich gebaut ist

Laravel glänzt bei full-featured Web-Applikationen mit Authentifizierung, Admin-Panels, komplexen Business-Logiken und Rapid Development. Die Killer-Features in 2026:

<?php
// Eloquent ORM — tatsächlich elegant
$publishedPosts = Post::with(['author', 'categories'])
    ->where('status', PostStatus::Published)
    ->where('published_at', '<=', now())
    ->orderByDesc('published_at')
    ->paginate(15);

// Das lädt Posts MIT Author und Categories in 2 Queries (eager loading)
// Vanilla: du schreibst den JOIN selbst + die N+1 Absicherung

// Laravel Queues — Jobs im Hintergrund ausführen
ProcessPodcast::dispatch($podcast)->onQueue('audio')->delay(now()->addMinutes(10));

// Laravel Livewire — reaktive UI ohne JavaScript-Framework
// resources/views/search.blade.php

<div wire:id="search">
    <input wire:model.live="query" type="text" placeholder="Suchen...">

    @foreach($results as $result)
        <div>{{ $result->title }}</div>
    @endforeach
</div>

// app/Livewire/Search.php
class Search extends Component {
    public string $query = '';

    public function render(): View {
        return view('livewire.search', [
            'results' => Post::search($this->query)->get()
        ]);
    }
}

Livewire allein rechtfertigt für viele Teams Laravel — reaktive Komponenten ohne eine Zeile JavaScript, direkt mit PHP-Logik verbunden.

Die versteckten Kosten von Laravel

Dependency-Tiefe: Ein frisches laravel/laravel Projekt installiert ~70 Composer-Pakete. Das ist 70 externe Codebasen in deiner Anwendung — 70 potenzielle Security-Advisories, 70 potenzielle Breaking Changes.

$ composer show | wc -l
74

$ du -sh vendor/
47M vendor/

47 MB Vendor-Code für eine leere Laravel-App. Das ist kein Problem auf modernen Servern — aber es ist Komplexität die du bezahlst.

Upgrade-Pfad: Laravel veröffentlicht jedes Jahr eine neue Major-Version. Der Upgrade-Leitfaden für Laravel 10 → 11 umfasst 15+ Breaking Changes. Das ist kein Vorwurf — es ist bewusste Entscheidung für Modernität über Stabilität. Aber es bedeutet: jedes Jahr eine Woche Upgrade-Arbeit bei aktiv genutzten Projekten.

Das "Magic"-Problem:

// Was macht das genau?
Route::get('/posts', [PostController::class, 'index'])->middleware('auth:sanctum');

// Antwort: Es registriert eine Route, bindet einen Controller, führt Middleware aus.
// Aber WIE? Über Service Container, Facades, Middleware-Pipeline...
// Bei einem Fehler: viel Laravel-Quelldoku lesen.

Das ist kein Fehler von Laravel. Es ist ein bewusstes Design für Produktivität. Aber wenn etwas schiefläuft — und in Produktion läuft immer irgendwann etwas schief — brauchst du ein tiefes Framework-Verständnis um zu debuggen.

Wann Laravel die klügste Wahl ist

• SaaS-Produkte mit Benutzer-Accounts, Subscriptions, Admin-Panels
• Agentur-Projekte mit 2–6 Monaten Timeline, wechselnden Teams
• Projekte mit Junior-Entwicklern — Laravel erzwingt Struktur
• MVP/Prototypen bei denen Time-to-Market entscheidend ist
• Wenn du Livewire oder Inertia.js willst — das ist ein echtes Alleinstellungsmerkmal

Symfony — der Erwachsene im Raum

Symfony ist anders als Laravel. Nicht besser, nicht schlechter — aber anders in einer Weise die wichtig ist zu verstehen: Symfony ist kein Framework das dir zeigt wie du Webanwendungen baust. Es ist eine Sammlung von Battle-tested Komponenten.

Das klingt nach Wortklauberei. Es ist keins.

Die Component-Architektur als Superkraft

# Du kannst einzelne Symfony-Komponenten verwenden — ohne das Full-Stack-Framework
composer require symfony/http-client
composer require symfony/console
composer require symfony/validator
composer require symfony/cache

Laravel funktioniert als Monolit. Symfony-Komponenten laufen überall — in Vanilla PHP, in anderen Frameworks, in CLI-Tools. PHPUnit, Doctrine, Drupal, Magento, Shopware — alle nutzen Symfony-Komponenten.

Symfony's DI-Container — technisch das Beste

# config/services.yaml
services:
    App\Service\MailerService:
        arguments:
            $transport: '@mailer.transport.smtp'
            $logger: '@monolog.logger.mailer'
        tags:
            - { name: 'app.notifier' }

// Der Container wird zur Build-Zeit kompiliert — nicht zur Laufzeit
// Das ist der Grund warum Symfony schneller ist als sein Ruf vermuten lässt
class MailerService {
    public function __construct(
        private readonly TransportInterface $transport,
        private readonly LoggerInterface    $logger,
    ) {}
}

Symfony's DI-Container kompiliert die gesamte Service-Konfiguration in optimierten PHP-Code, der dann gecacht wird. Das Ergebnis: ähnlich schnell wie Vanilla PHP bei warmen Caches, weil der Container-Overhead zur Build-Zeit anfällt, nicht zur Request-Zeit.

Symfony LTS — der geheime Vorteil für Agenturen

Symfony 6.4 LTS: November 2023 → November 2027 (Security: 2028)
Symfony 7.2:     November 2025 → Mai 2026 (kein LTS)
Symfony 7.4 LTS: November 2027 → November 2031 (Security: 2032)

Symfony veröffentlicht alle 2 Jahre eine LTS-Version mit 3 Jahren Bug-Fix-Support und 4 Jahren Security-Support. Für Kundenprojekte die 5+ Jahre laufen sollen ist das Gold wert. Du baust auf Symfony 6.4 LTS, und kannst deinem Kunden garantieren: keine Breaking Changes bis 2028, Security-Patches bis 2029.

Laravel bietet das nicht. Jede Laravel-Version hat 2 Jahre Support — dann musst du upgraden oder mit veralteten Dependencies arbeiten.

Die ehrlichen Schwächen von Symfony

Verbosity: Symfony ist geschwätzig. Was Laravel in 3 Zeilen löst, braucht in Symfony manchmal 10 Zeilen Konfiguration. Das ist Absicht — Explizitheit über Magie — aber es verlangsamt die initiale Entwicklung.

// Laravel: Eloquent Relationship
$user->posts()->where('status', 'published')->get();

// Symfony + Doctrine: Expliziter, aber mehr Code
$posts = $this->entityManager
    ->getRepository(Post::class)
    ->findBy(['author' => $user, 'status' => 'published']);

// Oder mit QueryBuilder:
$posts = $this->entityManager->createQueryBuilder()
    ->select('p')
    ->from(Post::class, 'p')
    ->where('p.author = :author')
    ->andWhere('p.status = :status')
    ->setParameter('author', $user)
    ->setParameter('status', 'published')
    ->getQuery()
    ->getResult();

Steile Lernkurve: Service Container, Event Dispatcher, Dependency Injection, DQL, Twig, Webpack Encore — das Symfony-Ökosystem ist groß und erfordert genuines Lernen. Onboarding neuer Entwickler dauert 2–4 Wochen bis zur vollen Produktivität.

Wann Symfony die klügste Wahl ist

• Enterprise-Projekte mit 10+ Entwicklern und Multi-Year-Roadmap
• APIs für Mobile/SPA (Symfony API Platform ist Industriestandard)
• Wenn Stabilität über Geschwindigkeit geht — Langzeitprojekte, kritische Systeme
• Wenn du Doctrine-ORM brauchst — komplexe Domain-Modelle, Event-Sourcing
• Wenn das Team bereits Symfony kennt — der Switching-Cost ist real

Der Entscheidungsbaum für 3 Szenarien

Szenario A: Agentur-Projekt

Ist das Projekt ein Standard-CMS/Blog?
├── Ja → WordPress oder Statamic. Keines der drei.
└── Nein
    │
    Wie lange dauert die Entwicklung?
    ├── < 4 Wochen → Vanilla PHP (kein Framework-Overhead)
    └── > 4 Wochen
        │
        Wie erfahren ist das Team?
        ├── Junior-lastig → Laravel (erzwingt Struktur, großes Ökosystem)
        └── Senior-Team
            │
            Wie lang soll das Projekt laufen?
            ├── < 3 Jahre → Laravel (Produktivität)
            └── > 3 Jahre → Symfony LTS (Stabilität)

Agentur-Empfehlung 2026: Laravel für 70% der Projekte, Symfony 6.4 LTS für Enterprise-Kunden mit langen Wartungsverträgen, Vanilla PHP für kleine Tools und Microservices.

Szenario B: SaaS-Produkt

Wie groß ist dein Team?
├── Solo/Duo
│   │
│   Wie wichtig ist Time-to-Market?
│   ├── Kritisch → Laravel + Livewire (schnellstes Prototyping)
│   └── Nicht kritisch → Vanilla PHP (volle Kontrolle, kein Ballast)
│
└── 3–10 Entwickler
    │
    Wie komplex ist die Domain?
    ├── CRUD-lastig (Dashboards, CRM, etc.) → Laravel
    └── Komplexe Business-Logik (Buchhaltung, ERP, etc.) → Symfony + Doctrine

SaaS-Empfehlung 2026: Laravel für B2C und mittelkomplexe B2B-Produkte. Symfony für finanzielle oder regulierte Bereiche wo Correctness wichtiger ist als Development Speed.

Szenario C: Persönliche Projekte / Open Source

Was willst du dabei lernen?
├── "Ich will PHP verstehen" → Vanilla PHP, kein Weg daran vorbei
├── "Ich will einen Job als PHP-Entwickler" → Laravel (Marktanteil)
└── "Ich will in Enterprise-Teams arbeiten" → Symfony

Wie lange willst du das Projekt warten?
├── "Wenn es läuft, nie wieder anfassen" → Vanilla PHP (keine externen Breaking Changes)
└── "Ich entwickle aktiv weiter" → Framework nach obigem Baum

Persönliche Empfehlung: Für Projekte wie dieser Blog, eine Portfolio-Seite, ein Tool für eigene Zwecke — Vanilla PHP. Du lernst mehr, du hast mehr Kontrolle, und dein Code läuft noch in 10 Jahren ohne einen einzigen composer update.

Die Tabelle die du dir speichern solltest

Was ich dir nicht sagen werde

Ich werde dir nicht sagen dass das eine besser ist als das andere. Das ist die falsche Frage.

Die richtige Frage ist: Was kostet dich welche Entscheidung — in Zeit, in Komplexität, in Wartbarkeit — und welche dieser Kosten kannst du in diesem spezifischen Projekt rechtfertigen?

Ein erfahrener PHP-Entwickler in 2026 beherrscht alle drei. Er wählt Vanilla PHP wenn die Anforderungen klar und begrenzt sind. Er greift zu Laravel wenn ein Team schnell produktiv werden muss. Er setzt auf Symfony wenn das Projekt in 5 Jahren noch sauber gewartet werden soll.

Und er fängt nie an, ohne diese Frage zu beantworten: "Was löse ich hier eigentlich — das Problem, oder meine Präferenz für ein bestimmtes Tool?"

*Welches Framework nutzt du in deinen aktuellen Projekten, und warum? Schreib es in die Kommentare — mich interessieren besonders die Fälle, in denen die Entscheidung im Nachhinein falsch war.