Das ewige PHP-Bashing – ein erstaunlich lautes Zeichen von Ahnungslosigkeit
In der IT gibt es ein erstaunlich zähes Ritual: PHP wird belächelt – oft von genau den Entwicklern, deren eigener Code weit entfernt von sauberer Architektur, guter Performance und Wartbarkeit ist. Dieser Text ist ein persönlicher Blick darauf, was hinter dem ewigen PHP-Bashing wirklich steckt.
Zurück zur Startseite1. Warum PHP immer wieder zur Zielscheibe wird
Viele der gängigen Vorurteile gegen PHP stammen aus einer anderen Zeit – aus den frühen 2000ern, als „PHP" oft bedeutete: ein paar Skripte quer durch HTML-Dateien, ohne Architektur, ohne Tests, ohne Frameworks. Das Problem: Genau dieses Bild wird bis heute wiederholt, obwohl es mit modernem PHP nichts mehr zu tun hat.
Heute sprechen wir über eine Sprache, die:
- strikte Typisierung und moderne OOP-Konzepte bietet,
- mit Enums, Traits, Attributes und sauberem Exception Handling arbeitet,
- über Composer professionelles Dependency-Management nutzt,
- mit Frameworks wie Laravel und Symfony Standards setzt,
- und in unzähligen Unternehmen stabile, kritische Business-Anwendungen betreibt.
Viele, die heute noch lautstark „PHP ist veraltet" rufen, haben seit Jahren keinen ernsthaften Blick mehr auf moderne PHP-Projekte geworfen. Sie kritisieren nicht die aktuelle Sprache, sondern ihre Erinnerung an PHP 5 – und das ist, freundlich formuliert, fachlich dünn.
2. Das Muster hinter der Kritik: fehlende Architektur, fehlende Performance
Spannend wird es, wenn man sich anschaut, wer besonders laut gegen PHP schießt. In der Praxis sieht man immer wieder dasselbe Muster:
Je lauter das PHP-Bashing, desto schwächer ist oft der eigene Code – unabhängig von der Sprache.
Typische Merkmale dieser Art von Kritikern:
- Business-Logik und Datenzugriff quer durcheinander im Controller oder in riesigen Klassen,
- Methoden, die sich über Dutzende oder Hunderte Zeilen ziehen,
- Copy-Paste statt klarer Abstraktionen und Wiederverwendung,
- kaum oder gar keine Tests,
- keine klare Trennung von Schichten, kein Domänendenken,
- und Systeme, die unter Last einknicken, obwohl sie auf dem Papier „modern" wirken.
Genau diese Performance-Nieten sind es dann, die mit dem Finger auf andere zeigen und reflexartig sagen: „PHP ist schlecht." Das ist bequem – aber selten ehrlich.
Eine unbequeme Wahrheit lautet: Nicht PHP ist das Problem. Das Problem sind Entwickler ohne Architekturverständnis.
3. Die Ironie: PHP-Projekte laufen – Hype-Projekte stolpern sehr oft
Während in manchen Teams endlose Diskussionen darüber geführt werden, ob eine bestimmte Sprache „noch zeitgemäß" ist, passiert im Hintergrund etwas ganz anderes:
- PHP-Systeme laufen seit vielen Jahren stabil in Produktion,
- Updates werden kontrolliert und planbar ausgerollt,
- Monitoring, Queues, Worker und Cronjobs laufen unauffällig im Hintergrund,
- und der Fokus liegt auf der Fachlichkeit – nicht auf dem nächsten großen Hype.
Gleichzeitig gibt es Projekte, die in vermeintlich „besseren" Stacks entwickelt wurden: ein Verbund aus Microservices, sieben separaten Deployments, komplexen Orchestrierungen und einem Overengineering, das bei jeder Änderung Schmerzen verursacht.
Das Ergebnis ist dann nicht selten:
- hoher Ressourcenverbrauch,
- langsame Antwortzeiten,
- Fehlerbilder, die niemand mehr nachvollziehen kann,
- und ein System, das nur noch von wenigen Eingeweihten verstanden wird.
Und mitten in dieser Situation wird dann ausgerechnet auf PHP gezeigt. Die Ironie ist offensichtlich.
4. Gute Entwickler schreiben guten Code
Ein Punkt, über den kaum jemand offen spricht, ist eigentlich ganz banal:
Gute Entwickler schreiben guten Code – unabhängig von der Sprache.
Schlechte Entwickler schreiben schlechten Code – ebenfalls unabhängig von der Sprache.
Die Fähigkeit, Software zu entwerfen, lässt sich nicht an einem Logo oder einem Framework festmachen. Sie zeigt sich daran, wie jemand:
- Domänenlogik versteht und strukturiert,
- Verantwortlichkeiten trennt,
- Datenflüsse klar modelliert,
- Lesbarkeit und Testbarkeit priorisiert,
- und Performance nicht an letzter Stelle betrachtet.
Wer all das beherrscht, kann mit PHP exzellente Systeme bauen. Wer all das nicht beherrscht, wird auch mit Go, Rust, Java oder Python keinen hochwertigen Code hervorbringen – nur einen anders verpackten.
5. Warum ich nach über 25 Jahren weiterhin gerne mit PHP arbeite
Ich arbeite nicht mit PHP, weil ich keine Alternativen kenne. Ich arbeite mit PHP, weil es sich in der Praxis als effizientes, stabiles und wirtschaftlich sinnvolles Werkzeug bewährt hat – gerade in komplexen, langfristigen Projekten.
Typische Einsatzszenarien, in denen ich PHP nutze:
- Backend-Systeme für geschäftskritische Anwendungen,
- REST-APIs und Backend-Services für Web und Mobile,
- Monitoring-Lösungen wie Uplinkr,
- Queue- und Worker-Systeme mit Laravel, Redis und Supervisor,
- containerbasierte Deployments mit Docker,
- intern genutzte Tools, die über Jahre wachsen und gepflegt werden.
In all diesen Bereichen schätze ich an PHP vor allem:
- die Kombination aus Geschwindigkeit in der Entwicklung und Stabilität in der Laufzeit,
- die ausgereifte Tooling-Landschaft,
- die große Verfügbarkeit von Know-how und Infrastruktur,
- und die Möglichkeit, Projekte sauber zu strukturieren, ohne sie unnötig aufzublasen.
Kurz gesagt: PHP ist für mich kein Notbehelf, sondern eine bewusste Entscheidung.
6. Fazit: PHP ist nicht das Problem
PHP ist nicht „tot". PHP ist nicht „schlecht". PHP ist auch nicht das eigentliche Problem.
Das eigentliche Problem ist eine Branche, in der es oft leichter ist, über eine Sprache zu lachen, als die eigenen Defizite in Architektur, Lesbarkeit und Performance ehrlich anzuschauen.
Wer modernes PHP kennt, weiß:
- Die Sprache ist weiter, als viele ihrer Kritiker wahrhaben wollen.
- Das Ökosystem ist stabil und ausgereift.
- Mit dem richtigen Ansatz lässt sich damit Code schreiben, der auch in vielen Jahren noch verständlich ist.
Am Ende bleibt: PHP ist modern, performant und stabil. Wer das bestreitet, liefert oft weniger ein Argument gegen PHP – als ein Argument gegen die eigene fachliche Tiefe.