
Frameworks: Häufig mehr Ballast als Hilfe
2026, PHP-Projekt mit Framework? Wird gemacht. Muss aber nicht. Im Alltag zeigt sich immer öfter: Der große Baukasten bringt selten das, was versprochen wird. Stattdessen: Trägheit. Deployment wird zum Mini-Release. Plötzlich braucht es drei Tools für ein simples Patch-Update. Klassischer PHP-Code, sauber und modular – läuft. Kein Korsett, weniger Kopfzerbrechen.
Frameworks sind nicht grundsätzlich schlecht. Nur: Nicht jedes Projekt ist ein Konzernportal mit 40 Entwicklern. Bei vielen kleinen bis mittleren Anwendungen reichen ein paar saubere Strukturen. Noch besser: Weniger Ressourcen, weniger Pflege. Moderne Features? Gehen auch ohne Framework-Ungetüm. Wer schlank bleibt, spart Nerven.
Performance: Overhead oder echte Geschwindigkeit?
Das Framework bringt alles mit – und noch mehr. Autoloading, Dependency Injection, Routing, Events. Klingt nach Komfort, zieht aber an jeder Ecke Leistung.
Was hängt dann am Server? Jede Anfrage jagt durch mehrere Schichten, initialisiert Klassen, die nicht gebraucht werden. OPcache und PHP 8.4 helfen, aber Wunder gibt es selten. Wer noch auf Shared Hosting setzt, merkt’s besonders deutlich: Jede Millisekunde zählt.
Klassisches PHP – also: eigener Routing-Handler, eigene Klassen, sauber getrennt – läuft merklich flotter. Weniger Initialisierung, weniger RAM, weniger CPU. Debugging? Klarer. Keine Framework-Fehler, die erst nach drei Stunden Google-Suche Sinn ergeben.
Stichwort Composer: Einzelne Libraries? Gerne. Komplett-Framework? Muss nicht sein. Für die meisten Projekte bringt das genug Tempo, auch 2026.
Wartung: Weniger Magie, mehr Übersicht
Frameworks predigen: Trennung, Wiederverwendbarkeit, Best Practice. Klingt gut. Realität: Nach ein paar Jahren wuchern Abhängigkeiten, eigene Helper-Klassen, Dutzende Konfigurationsdateien. Besonders in Agenturen, wo Teams wechseln, führt das zu Frust. Einarbeitung dauert. Wer was wann gebaut hat – oft unklar.
Klassisch aufgebaute Projekte: Da ist die Logik sauber von der Darstellung getrennt. Weniger Boilerplate, mehr Durchblick. Funktionen und Klassen: überschaubar, nachvollziehbar. Jeder neue Entwickler findet schneller rein. Änderungen? Gehen auch ohne Framework-Detektivarbeit.
Oft wird vergessen: Framework-Upgrades sind ein Zeitfresser. Gerade bei älteren Projekten. Wer modular bleibt, hat weniger Stress.
Praxis: Relaunch ohne Framework-Fesseln
Typischer Fall aus der Agentur: Website mit Framework, seit Jahren gewachsen. Erweiterungen, Patches, Eigenkonstrukte. Ergebnis: Unübersichtlich, langsam, keiner kennt sich richtig aus.
Beim Relaunch die Reißleine gezogen. Entscheidung: Kein Framework mehr. Zentraler Router, eigene Templates, Datenzugriff als schlanke Klasse. Composer nur für einzelne Pakete. Kein Full Stack, kein Overhead.
Was hat’s gebracht? Seitenaufbau: merklich schneller. Deployment: simpel, keine Abhängigkeiten, keine Überraschungen. Neue Kollegen? Nach zwei Tagen drin. Wartungskosten? Runter. Und keiner vermisst das Framework.
Meine Einschätzung nach 30 Jahren Webentwicklung
Frameworks glänzen bei Großprojekten. Viele Entwickler, viele Jahre, viele Features. Da lohnen sich feste Strukturen – aber selbst dann wird’s irgendwann zäh.
Erfahrung zeigt: Kleine bis mittlere Teams, Agenturen, Freelancer – Frameworks bringen selten echten Vorteil. Es bleibt beim Overhead. Disziplin in der Architektur zahlt sich aus: Schlanke PHP-Projekte sind schneller, flexibler, einfacher zu pflegen. Composer und aktuelle PHP-Versionen reichen. Einzelne Pakete? Kein Problem. Komplettes Framework? Nur, wenn’s wirklich sein muss.
Wer Kontrolle will, bleibt klassisch. Weniger Magie, mehr Durchblick. Spart Zeit, Nerven, auch Geld.
Konkrete Folgen für Entwickler, Agenturen, Selbstständige
- Setup und Deployment: Kurz und schmerzlos, keine Framework-Kette
- Performance: Spürbar besser, selbst auf Billig-Hosting
- Code: Verständlich, ohne Framework-Vorkenntnisse
- Einstieg: Neue Leute finden sich schneller zurecht
- Anpassungen: Flexibel, keine Framework-Regeln im Weg
Wer sich Frameworks ohne echten Grund ans Bein bindet, zahlt drauf. Längere Entwicklung, höhere Kosten, mehr Ärger. Gerade für Agenturen und kleine Teams: Klassische Architektur macht vieles leichter.
Weiterführende Artikel
- Back to Basics: Klassische PHP-Architektur 2026 – oft der pragmatischere Weg
- Back to Basics: Warum 2026 klassische PHP-Architektur in vielen Webprojekten wieder vorne liegt
Fazit
Nicht jedes Webprojekt schreit nach einem Framework. Wer mit klassischem PHP arbeitet, spart 2026 oft Zeit, Geld und Nerven. Schneller, übersichtlicher, besser wartbar. Erst aufräumen, dann modernisieren – das bleibt die beste Strategie. Und manchmal reicht ein bisschen Ordnung im Code völlig aus.
bye
mo