Sollte man 2026 noch PHP wählen? Eine ehrliche Antwort

“Sollten wir 2026 noch auf PHP setzen?” Diese Frage hören wir von Gründern, die einen Stack für ein neues Produkt wählen, von CTOs, die entscheiden, ob sie ein funktionierendes PHP-System behalten oder neu schreiben, und von Entwicklern, die sich fragen, ob die Sprache weitere fünf Jahre ihrer Karriere wert ist.

Das ist eine berechtigte Frage, und die meisten Antworten im Netz sind entweder defensiv (“PHP ist okay, hört auf, draufzuhauen”) oder abwertend (“echte Entwickler sind weitergezogen”). Beides hilft nicht. Hier ist die fundierte Version, von einem Team, das produktives PHP für Kunden in der gesamten EU baut und denselben Kunden auch sagt, wenn PHP das falsche Werkzeug ist.

#Die kurze Antwort

Ja, für eine große und klar umrissene Menge an Anwendungsfällen ist PHP 2026 weiterhin eine ausgezeichnete Wahl, und für einige davon ist es die beste. Es ist zugleich die falsche Wahl für eine reale, spezifische Menge an Workloads. Der Fehler ist, “PHP” als eine einzige Entscheidung zu behandeln. Die ehrliche Antwort hängt davon ab, was Sie bauen, was Ihr Team bereits kann und worauf Sie optimieren.

Wenn Sie die Ein-Zeilen-Version wollen: modernes PHP ist eine schnelle, strikt typisierte, gut getoolte Sprache mit dem tiefsten Web-Ökosystem überhaupt, und der Hauptgrund, es zu meiden, ist ein Workload, für den es nie gedacht war, nicht die Sprache, an die man sich von 2012 erinnert.

#Woran man sich erinnert, wenn man an PHP zweifelt

Die meiste Skepsis gegenüber PHP zielt auf eine Version der Sprache, die in ernsthaften Codebasen praktisch nicht mehr existiert. Die Kritikpunkte, damals berechtigt, waren:

• Lose, überraschende Typ-Jonglage.
• Inkonsistente Benennung in der Standardbibliothek.
• Keine echte statische Analyse, sodass Bugs erst in Produktion auftauchten.
• Eine Kultur des “Snippet aus dem Forum in eine 3.000-Zeilen-Datei kopieren”.
• Langsame Ausführung pro Prozess und Request, bei der zwischen Requests nichts warm gehalten wurde.

Wenn Ihr mentales Modell von PHP auf diesen Punkten beruht, ist Ihre Skepsis nachvollziehbar und zugleich veraltet. Fast jeder dieser Punkte wurde in den letzten Jahren adressiert.

#Was modernes PHP heute tatsächlich ist

PHP 8.x ist eine andere Arbeitserfahrung als PHP 5 oder frühes 7. Die Teile, die zählen:

• Strikte Typisierung durchgängig. declare(strict_types=1), typisierte Properties, Union- und Intersection-Typen sowie never und readonly geben Ihnen ein Typsystem, auf das Sie sich tatsächlich stützen können.
• Echte Sprachfeatures zum Modellieren. Native Enums, Readonly-Klassen, First-Class-Callable-Syntax, benannte Argumente, Constructor Property Promotion und Attribute entfernen den Großteil des Boilerplates, der älteres PHP geschwätzig machte.
• Statische Analyse als Standard, nicht als Luxus. PHPStan und Psalm fangen auf hohen Stufen eine große Klasse von Bugs vor der Laufzeit ab. Teams, die sie einsetzen, behandeln “die Analyse läuft durch” als Teil der Definition of Done.
• Automatisierte Upgrades und Refactorings. Rector migriert Code mechanisch über Sprachversionen hinweg und wendet moderne Idiome an, was das Aktuellbleiben billig statt beängstigend macht.
• Ein Kulturwandel. Das ernsthafte Ende des Ökosystems schreibt typisierten, getesteten, analysierten Code. Die Forum-Snippet-Ära existiert am billigen Ende des Marktes weiter, ist aber nicht mehr das, was “professionelles PHP” bedeutet.

Das ist die am meisten unterschätzte Tatsache über die Sprache: die Kluft zwischen “schlechtem PHP” und “gutem PHP” ist heute enorm, und gutes PHP ist wirklich angenehm.

#Die Performance-Frage ist weitgehend geklärt

Das historische Argument “PHP ist langsam” hatte zwei Teile: die Laufzeit der Sprache und das Modell ein Prozess pro Request. Beide haben sich bewegt.

• OPcache, der JIT und Preloading bedeuten, dass die Laufzeit selbst für die Workloads, die die meisten Webanwendungen tatsächlich haben, schnell ist.
• Langlebige Laufzeiten (FrankenPHP, RoadRunner, Swoole) halten die Anwendung zwischen Requests gebootet, was die Bootstrap-Kosten pro Request entfernt, die PHPs Ruf geprägt haben. Wir haben separat aufgeschrieben, was sich ändert, wenn Symfony-State Requests überlebt, und die kurze Version ist: der Abstand zu langlebigen Node- oder Go-Services schrumpft für typische Web-Arbeit deutlich.

PHP wird Go oder Rust beim reinen CPU-gebundenen Durchsatz weiterhin nicht schlagen, und es ist nicht die Sprache für Latenzbudgets im Submillisekundenbereich. Aber für die request/response-, datenbankgestützten, geschäftslogiklastigen Anwendungen, die den Großteil des Webs ausmachen, ist Performance kein echter Grund mehr, es auszuschließen.

#Wo PHP 2026 die richtige Wahl ist

PHP ist ein starker Default, manchmal der stärkste, wenn:

• Sie ein content- oder commercelastiges Produkt bauen. Das CMS- und E-Commerce-Ökosystem (WordPress, Drupal, Shopware, Magento, Sylius) hat in keiner anderen Sprache seinesgleichen.
• Sie eine datenbankgestützte Geschäftsanwendung bauen: SaaS, interne Plattformen, Marktplätze, Backoffice-Systeme, Publishing. Das ist die Paradedisziplin, und Frameworks wie Symfony und Laravel machen sie produktiv.
• Sie bereits ein funktionierendes PHP-System haben. “Schreib es in etwas Modernem neu” ist meist die teuerste und riskanteste Entscheidung, die ein Team treffen kann, und modernes PHP beseitigt oft die Gründe, aus denen man neu schreiben wollte.
• Time-to-Market und Recruiting-Tiefe zählen. Der Talent-Pool ist groß und die Framework-Konventionen sind ausgereift, sodass Sie schnell ausliefern und das Team besetzen können.

#Wo PHP die falsche Wahl ist

Wir würden einem Kunden von PHP abraten, wenn:

• Der Kern-Workload echtzeitnah, latenzkritisch oder hoch nebenläufig im großen Maßstab ist: Trading-Engines, Game-Server, Hochfrequenz-Event-Verarbeitung. Go, Java, .NET oder Rust passen besser.
• Das Produkt daten-, analytics- oder machine-learning-zentriert ist. Python besitzt dieses Ökosystem, und es gibt keinen Grund, dagegen anzukämpfen.
• Sie schwere interaktive Frontends bauen und das Team ohnehin voll im TypeScript-Ökosystem steckt, sodass ein Node-Backend eine Sprache über den gesamten Stack hält. Das kann ein legitimer organisatorischer Grund sein, selbst wenn PHP die Aufgabe technisch erledigen würde.

Beachten Sie: das sind Workload- und Team-Entscheidungen, keine “PHP ist schlecht”-Entscheidungen. Genau diese Unterscheidung ist der Punkt.

#Die Realität von Ökosystem und Recruiting

Zwei Dinge machen PHP über die Sprache selbst hinaus zu einer sicheren Langzeitwette:

• Es betreibt nach wie vor einen großen Anteil des öffentlichen Webs, was bedeutet, dass Ökosystem, Hosting, Dokumentation und Library-Support nicht verschwinden.
• Der Recruiting-Markt ist tief, besonders auf Mid- und Senior-Niveau in der Symfony- und Laravel-Welt. Sie wetten nicht auf eine Nischensprache mit zehn Experten.

Der eine Vorbehalt, den man nennen sollte: die Qualitätsverteilung ist breit. “Wir nutzen PHP” sagt sehr wenig aus. Ob ein Team strikt typisiertes, analysiertes, getestetes PHP schreibt oder Forum-Snippet-PHP, ist weit wichtiger als die Sprachwahl. Wenn Sie eine Einstellung oder eine Beratung bewerten, ist das der Punkt, den Sie prüfen sollten.

#Also, sollte man 2026 PHP wählen?

Wenn Sie eine datenbankgestützte Webanwendung, eine Content- oder Commerce-Plattform bauen oder ein funktionierendes PHP-System pflegen, dann ja, mit Überzeugung. Modernes PHP ist schnell genug, strikt typisiert, außergewöhnlich gut getoolt und gestützt vom tiefsten verfügbaren Web-Ökosystem und Recruiting-Markt. Die Version von PHP, der gegenüber Skepsis angebracht war, haben die Teams, die es ernst nehmen, weitgehend in Rente geschickt.

Wenn Ihr Kern-Workload echtzeitnah, nebenläufigkeitsgebunden oder data-science-zentriert ist, dann nein, und eine gute PHP-Beratung sagt Ihnen das, statt Ihnen ein Projekt zu verkaufen.

Die eigentliche Entscheidung war nie “ist PHP gut”. Sie lautet “passt PHP zu diesem Workload und diesem Team”. Beantworten Sie das ehrlich, und die Sprachfrage beantwortet sich von selbst.

Wenn Sie PHP für ein konkretes Projekt gegen einen anderen Stack abwägen oder überlegen, ob Sie ein bestehendes PHP-System modernisieren statt neu schreiben sollten, sprechen Sie mit unserem Team. Sie bekommen die Antwort, die zu Ihrem Fall passt, auch wenn diese Antwort “nicht PHP” lautet.

#Referenzen

• W3Techs, Nutzungsstatistiken für serverseitige Programmiersprachen: https://w3techs.com/technologies/overview/programming_language
• PHP-RFCs und Release Notes (Sprachfeatures nach Version): https://www.php.net/releases
• PHPStan, statische Analyse für PHP: https://phpstan.org
• Stack Overflow Developer Survey (Baselines zu Sprachnutzung und Stimmung): https://survey.stackoverflow.co