PHP ist tot. Lang lebe PHP.

Breaking News:

PHP ist immer noch am Leben und sogar sehr lebendig!

Schauen wir uns die Zahlen an: Laut W3Techs läuft PHP auf 73,3% aller Websites mit erkennbarer Server-Technologie (Stand Januar 2026). Nicht 7%. Nicht 17%. Knapp drei Viertel des Webs. Dazu kommen 43% aller Websites, die WordPress nutzen – auch das ist PHP. Man könnte sogar sagen, dass die WordPress-Dominanz ein Argument für PHP ist: Die Sprache wurde so weit optimiert, dass selbst ein System wie WordPress ausreichend schnell betrieben werden kann.

Und die "PHP ist tot"-Prophezeiung? Die gibt es seit mindestens 2004. Damals waren es Java-Servlets, die PHP ablösen sollten. 2007 war es Ruby on Rails. 2011 Node.js. 2015 Go. 2020 Rust. Jedes Mal hieß es: PHP ist am Ende. Und jedes Mal hat PHP einfach weitergemacht – leise, zuverlässig und auf drei Vierteln des Internets.

Warum wird PHP so häufig eingesetzt?

Sicher nicht nur weil man Wordpress nicht loswird sondern weil es funktioniert! Es mag nicht das coolste Kid im Block sein, aber es erledigt seinen Job und es erledigt ihn sehr gut. PHP hat sich über die Jahre enorm weiterentwickelt und ist zu einer robusten Sprache geworden. Wer die objektorientierte Programmierung beherrscht, ist in der Lage gut skalierende Webapps zu schreiben.

PHP ist nicht mehr das PHP von 2005

Wer heute über PHP urteilt und dabei an PHP 4 oder 5 denkt, hat ungefähr 15 Jahre verpasst. Die Sprache hat sich fundamental verändert:

PHP 7 (2015) – Hat die Performance gegenüber PHP 5.6 verdoppelt. Nicht 10% schneller, sondern doppelt so schnell. Dazu kamen Scalar Type Hints und Return Types.
PHP 8.0 (2020) – JIT-Compiler, Named Arguments, Match Expressions, Union Types, Attributes. PHP begann, sich wie eine moderne Sprache anzufühlen.
PHP 8.1–8.4 – Enums, Fibers (für asynchrone Programmierung), Readonly Properties, Intersection Types, Typed Class Constants. Features, die vor fünf Jahren undenkbar waren.

Modernes PHP mit OPcache performt auf Augenhöhe mit Python und Ruby. Der Bottleneck in Webanwendungen ist fast immer die Datenbank oder ein externer API-Call – nicht die Sprache.

Das Ökosystem: 380.000 Packages und PSR-Standards

Eines der stärksten Argumente für PHP ist Packagist: über 380.000 Packages, verwaltet über Composer. Zum Vergleich – 2012 hat man PHP-Abhängigkeiten noch per ZIP heruntergeladen und per FTP hochgeladen. Composer hat das Ökosystem professionalisiert und eine Paketkultur geschaffen, die sich hinter npm nicht verstecken muss.

Dazu kommen die PSR-Standards (PHP Standard Recommendations), die Framework-übergreifende Interoperabilität ermöglichen. PSR-4 (Autoloading), PSR-7 (HTTP Messages), PSR-11 (Container) – diese Standards sorgen dafür, dass Packages zwischen Laravel, Symfony und anderen Frameworks wiederverwendbar sind. Das gab es 2010 nicht.

Und wer behauptet, PHP habe kein Typsystem, kennt PHPStan und Psalm nicht. Statische Analyse auf TypeScript-Niveau – für PHP. Diese Tools finden Typfehler, Null-Pointer-Probleme und logische Fehler, bevor der Code überhaupt ausgeführt wird. In Kombination mit den nativen Type Hints seit PHP 8 ist "PHP hat keine Typen" schlicht falsch.

Die ehrlichen Schwächen

Wer PHP verteidigt, sollte auch ehrlich sein. Die Sprache hat reale Schwächen, die nicht durch Community-Begeisterung weggeredet werden können:

Inkonsistente Standardbibliothek – strpos($haystack, $needle) vs. array_search($needle, $haystack). Die Parameter-Reihenfolge in PHPs Built-in-Funktionen ist historisch gewachsen und teilweise willkürlich. Man gewöhnt sich daran, aber es bleibt ein Designfehler.
Unicode-Handling – String-Funktionen arbeiten standardmäßig byte-basiert. Für korrekte Unicode-Verarbeitung braucht man die mb_*-Funktionen (mb_strlen, mb_strtolower). In einer Welt mit Emojis und internationalen Zeichensätzen ist das nicht mehr zeitgemäß.
Legacy-Code-Reputation – Der Ruf von PHP leidet unter Millionen von schlecht geschriebenen WordPress-Plugins und PHP-4-Spaghetti-Code, der noch in Produktion läuft. Das ist ein Community-Problem, kein Sprach-Problem – aber es prägt die Wahrnehmung.

Diese Schwächen sind real. Aber sie sind auch bekannt, dokumentiert und in der täglichen Arbeit mit Frameworks wie Laravel kaum spürbar. Die Abstraktionsschicht des Frameworks schützt vor den meisten Inkonsistenzen der Sprache.

PHP-Frameworks wie Laravel

Und was ist mit den Frameworks? Sprechen wir über Laravel. Es ist nicht nur umfangreich, sondern auch ausgereift. Nach der Installation von Laravel und einem Starterkit erhält man eine Webapp die bereits alle rudimentären Features enthält, die so gut wie jedes Projekt braucht:

Login und Registrierung
Passwort Änderung und Wiederherstellung
Zwei-Faktor-Authentifizierung
Team-Management

sowie zahlreiche Features die für die weitere Entwicklung relevant sind.

Welches Javascript- oder Rust-Framework kann das anbieten? Keines. In der Javascript-Welt könnte man die oben genannten Punkte sicher durch das zusammenführen von zahlreichen Paketen erreichen. Aber der benötigte Zeitaufwand steht in keinem Verhältnis zur Geschwindigkeit und Qualität in der wir das Bootstrapping eines Projekts mit Laravel (PHP) erledigen können.

In der Regel ist es doch so: Ein neues Javascript-Framework wird angepriesen weil es so viel schneller ist. Ja was ist denn schneller? Das hot-reloading? Wow. Und was bringt mir das? Wärend ich also das Rad schon wieder neu erfinden muss um die oben genannten Grundfunktionen zu implementieren, wird mir wenigstens die Wartezeit verkürzt. Danke.

Shots fired.

Mit Laravel (und PHP) überspringen wir das und gehen direkt dazu über, die Probleme unserer Kunden zu lösen. Hier entsteht der wahre Mehrwert. Nicht durch schnelles Hot-Reloading oder 2% mehr Requests pro Sekunde.

Microservices sind auch keine Lösung

Der Hype um neue Technologien ist oft verlockend. Microservices und Containerisierung und Serverless-Architekturen sind noch immer heiße Themen. Aber lassen wir uns nicht von diesem Hype blenden. Ja, für einige große Unternehmen und komplexe Systeme können Microservices sinnvoll sein. Aber für kleine Teams und Projekte ist ein monolithischer Ansatz viel besser.

Microservices mögen theoretisch Vorteile bieten, aber in der Praxis bringen sie auch jede Menge Overhead (= Kosten) mit sich. Die Entwicklung und Wartung von Microservices erfordern mehr Aufwand und Ressourcen. Es braucht spezialisiertes Personal (in Zeiten des Fachkräftemangels) und eine solide Infrastruktur, um sie effektiv zu betreiben. Für kleine Teams kann dies eine enorme Belastung sein, die sich negativ auf den Fortschritt und die Produktivität auswirkt.

Wenn man also nicht Netflix ist, kann man auch gut und gerne auf Microservices verzichten. Und selbst Amazon geht wieder zurück zu einer monolithischen Architektur und spart 90% seiner Kosten ein.

Laravel und Hochverfügbarkeit

Bis 2021 existierte Lumen als Microframework um für besonders Performance-hungrige Anwendungsfälle genug Geschwindigkeit bereit zu stellen. Das ist heute nicht mehr Nötig. Die Entwicklung von Lumen wurde eingestellt. Mit PHP-OPCache, Lösungen wie Octance oder Vapor als skaliertes Hosting via AWS, kann nahezu jeder Workload von PHP bewältigt werden.

Zweifel?

Aber wer bin ich schon, all das zu sagen? Der Gründer einer auf Laravel und PHP-spezialisierten Agentur? Ist das glaubwürdig? Natürlich habe ich diese Meinung.

Wisst ihr wer noch diese Meinung hat? Der Fullstack-Entwickler Adam Elmore. In seinem sehr sympathischen und unterhaltsamen Youtube-Video probiert er Laravel das erste Mal aus und ist sichtlich begeistert. 🎉

Laravel und PHP wird von Enterprise-Unternehmen genutzt

OpenAI, das im Moment führende Unternehmen im Bereich der künstlichen Intelligenz, hat sich für die Verwaltung ihrer Website mit Twill entschieden. Twill ist ein CMS, das speziell für die Laravel entwickelt wurde. Diese Wahl unterstreicht die Leistungsfähigkeit von Laravel und PHP als Basis für unternehmenskritische Systeme.