PHP: Die Kakerlake unter den Programmiersprachen (Und warum das ein Kompliment ist)

Unsterblich, unmodern, unbestreitbar beschäftigt

2011 machte ein Artikel mit dem Titel „PHP is Dying“ die Runde. Der Autor prophezeite, dass PHP innerhalb von fünf Jahren nur noch für Legacy-Wartung taugen würde. Das war vor 15 Jahren. PHP betreibt immer noch 73,3% aller Websites mit erkennbarer Server-Technologie (W3Techs, Januar 2026).

Ich schreibe PHP seit 2002. In 15 dieser Jahre war es mein Haupteinkommen als Freiberufler. Mit Symfony arbeite ich seit Version 2. Und alle paar Jahre erzählt mir jemand selbstsicher, dass meine Berufswahl am Sterben ist.

Sie liegen immer noch falsch. Aber ganz ohne Punkte sind sie nicht.

Die Kritiker haben teilweise recht

Seien wir ehrlich: PHP hat echte Probleme. Sie anzuerkennen macht uns zu besseren Entwicklern, nicht zu illoyalen.

Die Standardbibliothek ist Chaos. Die Parameterreihenfolge ist inkonsistent (strpos($haystack, $needle) vs array_search($needle, $haystack)). Namenskonventionen sind überall anders (str_replace vs substr vs string_starts_with). Das ist nicht zu verteidigen. Es ist historischer Ballast aus dem rasanten, Community-getriebenen Wachstum der frühen Jahre.

Unicode-Handling ist angeflanscht. Du brauchst mb_*-Funktionen für ordentliche Multibyte-Unterstützung, und wenn du sie vergisst, entstehen subtile Bugs. 2026 ist das immer noch nicht erstklassig gelöst.

Legacy-Code gibt PHP einen schlechten Ruf. Viel PHP da draußen ist wirklich furchtbar. Ungepflegte WordPress-Plugins, Spaghetti-Code von 2008, überall rohes SQL. Wenn Kritiker sagen „PHP-Code ist schlecht“, schauen sie oft auf Code, der in jeder Sprache schlecht wäre. Aber PHPs niedrige Einstiegshürde bedeutet, dass mehr davon sichtbar ist.

Das sind legitime Kritikpunkte. Wer sich darauf konzentriert, ist fair.

Warum der Mythos sich hält

Wenn PHP also echte Probleme hat, warum nenne ich „PHP stirbt“ einen Mythos? Weil die Vorhersagen nicht zur Realität passen. Die „PHP stirbt“-Erzählung läuft durchgehend seit mindestens 2004 (Slashdot-Diskussionen) über 2007 (frühe Blogposts) bis 2011 (Mainstream-Tech-Presse) bis heute.

Survivorship-Bias funktioniert in beide Richtungen. Kritiker erinnern sich an den furchtbaren PHP-4-Code, den sie gesehen haben. Sie sehen nicht die modernen Symfony-Anwendungen mit strikter Typisierung, 100% Testabdeckung und sauberer Architektur. Diese Anwendungen laufen einfach still in Produktion.

Der Hype-Zyklus bevorzugt Neues. Node.js sollte PHP 2012 „killen“. Go 2015. Rust 2018. Jede neue Sprache bekommt atemlose Berichterstattung. PHP liefert weiter Features und baut sein Ökosystem aus. Ohne den gleichen Rummel.

Engagement-Farming. „PHP ist tot“ generiert Klicks und hitzige Diskussionen. „PHP 8.4 bringt Property Hooks“ trendet nicht auf X (das Twitter ersetzt hat).

Die Mythen, die nicht sterben wollen

Lass mich die konkreten Behauptungen ansprechen, die ich ständig höre:

„PHP ist langsam.“ PHP 7 (2015) war etwa doppelt so schnell wie PHP 5.6. PHP 8.0 (2020) brachte JIT-Kompilierung, wobei für typische Web-Apps OPcache wichtiger ist als JIT. Modernes PHP mit OPcache ist nicht dein Flaschenhals. Deine Datenbankabfragen sind es. Es ist in der gleichen Performance-Liga wie Ruby und Python, und obwohl Node.js bei I/O-lastigen Aufgaben schneller ist, zählen PHPs Einfachheit und Deployment-Modell oft mehr.

„PHP skaliert nicht.“ Wikipedia bewältigt Milliarden monatlicher Anfragen mit PHP. Etsy läuft auf PHP. Meta und Slack bewältigen Milliarden Anfragen mit Hack, einer von PHP abgeleiteten Sprache auf HHVM. Klar, Skalierung erfordert Architektur: Caching-Schichten, Load Balancer, Async Workers. Aber das gilt für jede Sprache. PHP hindert dich nicht am Skalieren; es macht es nur nicht für dich.

„PHP ist unsicher.“ PHP hatte Sicherheitsprobleme in den frühen 2000ern. Jede andere Sprache auch. Moderne PHP-Frameworks haben CSRF-Schutz, Prepared Statements und XSS-Filterung eingebaut. Die OWASP-Top-10-Schwachstellen sind sprachunabhängige Probleme, bei deren Vermeidung PHP-Tooling aktiv hilft.

„PHP bedeutet Spaghetti-Code.“ PHP verhindert keine gute Architektur. Es erfordert sie nur nicht. Du kannst Spaghetti in jeder Sprache schreiben. Der Unterschied ist, dass PHPs niedrige Einstiegshürde bedeutet, dass mehr Anfänger Code veröffentlichen. Das ist ein Community-Problem, kein Sprach-Problem.

Das Ökosystem ist erwachsen geworden

Das PHP-Ökosystem von 2026 ist nicht wiederzuerkennen im Vergleich zu 2010.

Composer hat alles verändert. Vor 2012 hieß PHP-Dependency-Management: phpclasses.org durchstöbern, Zip-Dateien herunterladen und Code mit manuellen include-Pfaden zusammenkleben. Deployment hieß Dateien per FTP hochladen und chmod 777 configure.php ausführen. Wer jemals osCommerce installiert hat, kennt das Ritual: per FTP hochladen, Schreibrechte für alle setzen, Web-Installer starten und dann das install/-Verzeichnis löschen, bevor jemand den Shop kapert. Jetzt haben wir Packagist mit über 380.000 Paketen (Stand Anfang 2026), semantische Versionierung und deterministische Builds.

Paketqualität zählt. Das npm-Ökosystem hat mehr Pakete, hatte aber auch left-pad (2016): ein 11-Zeilen-Paket, das Tausende Builds kaputt machte, als sein Autor es entfernte. Composers Design und PHPs Kultur bevorzugen weniger, dafür substanziellere Pakete. Ein typisches PHP-Projekt hat dutzende Dependencies; ein typisches Node-Projekt hat Tausende.

PSR-Standards haben das Ökosystem vereinheitlicht. PSR-4 (Autoloading), PSR-7 (HTTP Request/Response Interfaces), PSR-11 (Dependency Injection Container). Frameworks, die 2010 inkompatibel waren, teilen jetzt Komponenten. Du kannst ein Laravel-Paket in Symfony verwenden. Das war vor fünfzehn Jahren nicht möglich.

Statische Analyse ist Mainstream. PHPStan und Psalm (denk: TypeScript-artige Typprüfung, aber für PHP) finden Bugs vor der Laufzeit. Level-9-Strenge erreicht TypeScript-Garantien. Typ-Deklarationen, die in PHP 7 optional waren, werden jetzt durch Tooling in den meisten professionellen Codebasen erzwungen.

„Langweilig“ ist ein Feature. PHPs Deployment-Modell hat sich nicht verändert: Dateien hochladen, Webserver konfigurieren, fertig. Keine Runtime zu managen, keine Prozessüberwachung nötig (bei traditionellen Deployments), keine package-lock-Konflikte in Produktion. Vorhersagbar ist wertvoll.

PHP in 2026

Modernes PHP macht wirklich Spaß zu schreiben. Property Hooks in PHP 8.4 bringen berechnete Properties ohne Boilerplate. Asymmetrische Sichtbarkeit ermöglicht sauberere öffentliche APIs. Das Typsystem findet Fehler beim Schreiben, nicht zur Laufzeit.

Async-Programmierung mit Fibers (leichtgewichtige Nebenläufigkeit), ReactPHP und Swoole beweist, dass PHP gleichzeitige Workloads bewältigen kann. Du musst PHP nicht mehr für eventgetriebene Architektur verlassen.

Ist PHP perfekt? Nein. Würde ich ein Greenfield-Realtime-Gaming-Backend in PHP starten? Wahrscheinlich nicht. Da würde ich zu Go oder Rust greifen. Aber für Webanwendungen, APIs und Business-Software? PHP bleibt eine exzellente Wahl, gestützt auf Jahrzehnte von Praxisbewährung.

Rat an Junior-Entwickler

Wenn du neu in der Entwicklung bist und PHP in Betracht ziehst, hier ist, was ich dir sagen würde:

Lass nicht Twitter deinen Tech-Stack bestimmen. Die lautesten Stimmen haben oft die wenigste Produktionserfahrung. PHP betreibt erfolgreiche Unternehmen, beschäftigt Hunderttausende Entwickler und hat einen Arbeitsmarkt, der nirgendwo hingeht.

Lerne das moderne Ökosystem. Lerne PHP nicht aus 2010er-Tutorials. Starte mit einem Framework (Symfony oder Laravel), nutze Composer, aktiviere strict_types, führe PHPStan von Tag eins an aus. Moderne PHP-Entwicklung sieht nicht aus wie der Spaghetti-Code, an den sich Kritiker erinnern.

Verstehe die Tradeoffs. Jede Sprache hat welche. PHPs Ballast sind die stdlib-Inkonsistenzen und der Legacy-Code da draußen. Seine Stärken sind Ökosystem-Reife, Deployment-Einfachheit und eine riesige Community. Das ist ein vernünftiger Tradeoff für Webentwicklung.

Schau, was Unternehmen nutzen, nicht was Influencer tweeten. WordPress, Shopify (Admin), Slacks API-Layer, Etsy, Wikipedia. Das sind keine Hobby-Projekte.

Ich habe erlebt, wie PHP von einer belächelten Skriptsprache zur Enterprise-Plattform wurde. Ich habe zugesehen, wie der „PHP stirbt“-Artikel alle paar Jahre mit neuen vorhergesagten Killern neu geschrieben wurde. Und ich habe weiter meinen Lebensunterhalt verdient, indem ich Systeme gebaut habe, die echten Traffic für echte Unternehmen bewältigen.

PHP stirbt vielleicht. Es macht das nur schon seit 24 Jahren, und ich vermute, es wird noch weitere 24 Jahre sterben, während wir anderen Code ausliefern.