Frameworks: Komfort, aber oft zu viel Gepäck
PHP-Frameworks sind bequem. Laravel, Symfony, was auch immer: Struktur, Routing, ORM, alles dabei. Klingt nach einer guten Idee – und bei großen SaaS-Projekten ist das nicht falsch. Nur: Im Alltag sieht es selten so aus. Wer mit Frameworks loslegt, zieht sich meistens einen halben Zoo an Paketen rein. Jede Kleinigkeit will noch ein weiteres Composer-Dependency. Irgendwann läuft die Update-Orgie. Irgendwas ist immer inkompatibel. Oder es bremst einfach.
Kleine Projekte? Firmenwebsite, ein paar Admin-Tools, Mini-API. Da ruft keiner nach Event-Dispatcher und Service-Container. Trotzdem wird oft das ganz große Besteck ausgepackt. Klar, Standardisierung ist nett. Aber nach dem dritten Paket-Konflikt fragt man sich: Wofür eigentlich?
Schlankes PHP: Weniger Zauberei, mehr Kontrolle
Klassisches PHP: index.php, ein paar Includes, vielleicht Autoloading, fertig. Keine Magie, keine Blackbox. Fehler sind meistens schnell zu finden – keine 17 verschachtelten Stacktraces durchs Framework. Kein „woher kommt das jetzt wieder?“. Wer das mal bei einem Relaunch oder Kundenprojekt hatte, weiß: Übersicht schlägt Komfort-Magie.
Neues Teammitglied? Muss sich nicht erstmal durch 40 Framework-Configs kämpfen. Ein Blick in die Datei, kurzer Check, läuft. Dokumentation? Zwei, drei Seiten, keine Bibel. Besonders bei Agenturen mit ständig wechselnden Leuten ist das Gold wert. Und: Die meisten Kundenprojekte sind nach zwei Jahren eh reif für den nächsten Relaunch. Da will niemand fünf Stunden in Abhängigkeitslisten versenken.
Frameworks: Wo sie Sinn machen – und wo nicht
Natürlich, es gibt Ausnahmen. Wer einen kompletten SaaS-Monolithen oder eine API mit x Spezialfällen baut, will Auth, Routing, ORM, am liebsten alles aus einer Hand. Dann lohnt sich das Framework. Spart Fehler, spart Nerven – meistens jedenfalls.
Aber das sind 2026 vielleicht 10% der Fälle. Die meisten Projekte: klassisches Firmenportal, internes CRM, Anmeldeformular. Da macht das große Framework-Paket mehr Ärger als Freude. Die Deployments dauern länger, die Updates werden zur Glückssache. Und die Entwickler? Werden zu Paket-Detektiven – statt einfach mal einen Bug zu fixen.
29 Jahre Webentwicklung: Ein paar harte Wahrheiten
Fast drei Jahrzehnte PHP. Das Muster wiederholt sich. Sobald das Projekt klein bis mittel bleibt, spart klassisches PHP Zeit, Geld und Schimpfwörter. Shared Hosting, Agentur-Server mit RAM-Limit, laufender Betrieb – da bringt ein Framework keinen Vorteil. Im Gegenteil: Weniger Dependencies, weniger Update-Stress, schnelleres Debugging. Admin-Tool? Einfache Datenbank-App? Da reicht ein bisschen altes PHP, vielleicht PDO, fertig. Kein Composer, keine Paket-Explosion.
Agenturen profitieren am meisten: Neue Leute sind nach einem Vormittag drin. Freelancer können Fehler oder Wünsche direkt einbauen. Bei Problemen: FTP hoch, Datei tauschen, fertig. Rollback? Einfach. Wer schon mal eine Live-Seite nach einem Laravel-Update zerlegt hat, weiß das zu schätzen. Ehrlich.
Konkret: Was bringt der klassische Ansatz?
- Kaum Abhängigkeiten – weniger Lücken, weniger Update-Alarm
- Geringerer Ressourcenbedarf, gerade auf Shared Hosting nicht zu unterschätzen
- Neue Leute finden sich schnell zurecht
- Skripte und Libraries bleiben unter Kontrolle
- Fehler sind oft in Minuten statt in Stunden gefunden
Ein Beispiel aus 2025: Formular-Tool für einen Mittelständler. Zuerst Laravel. Nach einem Jahr: Dependency-Hölle, Paket-Ärger, Bugs ohne Ende nach Updates. Umstieg auf klassisches PHP. Plötzlich läuft alles stabil, Änderungen gehen in Minuten. Seitdem: Kein Stress mehr.
Wann lohnt klassisches PHP?
- Projekt ist überschaubar, keine Spezial-Prozesse
- Infrastruktur limitiert, Shared Hosting, wenig RAM
- Änderungen müssen jederzeit und schnell machbar sein
- Kein großes Entwicklerteam vorhanden
Falls das Projekt wächst, kann man immer noch einzelne Komponenten (Router, Template, Auth) nachrüsten. Niemand zwingt zu Komplett-Framework.
Weiterlesen
Wer tiefer einsteigen will:
Back to Basics: Klassische PHP-Architektur 2026 – weniger Framework, mehr Übersicht und Klassisches PHP 2026: Warum Frameworks oft nur bremsen.
Mein Fazit: Weniger Framework, mehr Klarheit
2026 ist klassisches PHP kein Retro-Trip, sondern gesunder Pragmatismus. Frameworks sind Werkzeuge, keine Religion. Wer Übersicht mag, wenig Ressourcen hat oder einfach keine Lust auf Dependency-Schlachten, bleibt besser beim klassischen Ansatz. Spart Ärger, spart Zeit. Manchmal auch ein bisschen Stolz, wenn der Kunde nach drei Jahren immer noch keine Update-Katastrophe erlebt hat.
bye
mo