Ist PHP 2026 noch die richtige Wahl für E-Commerce? Eine ehrliche Bewertung

Die Debatte über PHP ist ungewöhnlich unproduktiv, weil beide Seiten von verschiedenen Dingen sprechen. Die eine Seite spricht über PHP 8.5 — typisiert, schnell, mit einem ausgereiften Ökosystem und zwei der besten Web-Frameworks, die es gibt. Die andere spricht über eine 2011 geschriebene Codebasis, die sie warten musste, und ihr Einwand betrifft in Wahrheit gar nicht die Sprache.

Wir entwickeln in PHP und in Node.js und haben kein Interesse an einer bestimmten Antwort. Das hier sagen wir Kunden tatsächlich, wenn sie fragen, ob sie sich um die Plattform sorgen sollten, auf der ihr Geschäft läuft.

Was sich tatsächlich geändert hat

Zwischen dem PHP, das seinen Ruf verdient hat, und dem PHP, das heute ausgeliefert wird, liegt ein Jahrzehnt Arbeit, das sich die meisten Kritiker der Sprache nie angesehen haben.

• Ein echtes Typsystem. Skalare Typen, Rückgabetypen, Union-Typen, readonly-Eigenschaften, Enums. Zusammen mit statischer Analyse auf hohem Niveau fängt eine moderne PHP-Codebasis zur Build-Zeit ab, was früher erst in der Produktion auffiel.
• Performance. PHP 7 hat den Durchsatz gegenüber 5.6 etwa verdoppelt, und 8.x brachte einen JIT und weitere schrittweise Zugewinne. Für eine Request-Response-Arbeitslast im Web — und genau das ist Commerce — ist es bequem schnell genug, sodass die Sprache selten die Grenze setzt.
• Frameworks, die ihre Konkurrenz geprägt haben. Laravel und Symfony sind wirklich ausgezeichnet, und vieles, was anderswo heute Standard ist, hat in einem von beiden angefangen.
• Moderne Werkzeuge. Composer, PHPStan und Psalm, PHPUnit und Pest — und ein Container-Setup, das im besten Sinne unspektakulär ist.

Nichts davon macht PHP zur richtigen Antwort auf jede Frage. Es macht den Ruf zu einer schlechten Grundlage für die Entscheidung.

Wo PHP weiterhin die richtige Antwort ist

1. Ihr Commerce läuft bereits darauf

Die größten Commerce-Plattformen der Welt — Magento, WooCommerce, Shopware, PrestaShop — sind PHP-Anwendungen mit ausgereiften Ökosystemen, Tausenden von Erweiterungen und einem tiefen Pool an Spezialisten. PHP zu verlassen heißt, dieses Ökosystem zu verlassen, und das ist eine sehr viel größere Entscheidung als ein Sprachwechsel.

2. Personalgewinnung zählt mehr als Benchmarks

Der Talentpool ist riesig, geografisch verteilt und vernünftig bepreist. Für die meisten Unternehmen ist das der mit Abstand entscheidendste Faktor — und zugleich der, der in Stack-Debatten die geringste Aufmerksamkeit bekommt. Ein theoretisch überlegener Stack, den Sie nicht besetzen können, ist nicht überlegen.

3. Die Arbeitslast ist Request-Response

Ein Käufer fordert eine Seite an, der Server baut sie, die Verbindung wird geschlossen. PHPs Prozessmodell passt dazu von Natur aus, und seine historische Schwäche — kein dauerhafter Zustand zwischen Requests — ist weitgehend belanglos, wenn die Arbeit ohnehin zustandslos ist.

4. Sie brauchen Tempo bei der Umsetzung

Besonders in Laravel lässt sich extrem schnell entwickeln, und das Deployment ist unkompliziert. Für ein Unternehmen, das in diesem Quartal funktionierende Software braucht und nicht nächstes Jahr eine elegante Architektur, ist das ein echter wirtschaftlicher Vorteil.

Wo PHP tatsächlich verliert

Drei Kritikpunkte, die weiterhin berechtigt sind — wer etwas anderes behauptet, verliert ein technisches Publikum.

1. Langlebige Verbindungen und hohe Parallelität

Echtzeit-Funktionen — Websockets, Live-Tracking, kollaborative Oberflächen, Chat — passen schlecht zu PHPs Prozessmodell. Es gibt Lösungen, und sie sind wirklich gut, aber Sie arbeiten gegen die Sprache statt mit ihr. Node.js wurde genau für diese Art von Problem entworfen, und das merkt man.

2. Das Machine-Learning- und Daten-Ökosystem

Wenn zu Ihrem Produkt Modelltraining, Datenpipelines oder wissenschaftliches Rechnen gehören, ist Pythons Ökosystem nicht einfach nur voraus — dort spielt sich das gesamte Feld ab. Eine Modell-API aus PHP aufzurufen ist in Ordnung; das Modell in PHP zu bauen ist eine Entscheidung, die niemand verteidigen sollte.

3. Legacy-Codebasen sind wirklich furchtbar

Das ist der Kritikpunkt, der alle anderen antreibt, und er stimmt. Die lange Geschichte niedriger Einstiegshürden hat in PHP eine enorme Menge an untypisiertem, ungetestetem, strukturell chaotischem Code hervorgebracht, von dem vieles noch läuft. Ein Entwickler, dessen einzige PHP-Erfahrung die Wartung eines solchen Projekts ist, irrt sich nicht über seine Erfahrung — er irrt sich darin, sie auf die Sprache zu verallgemeinern.

Wie Sie tatsächlich entscheiden

Lassen Sie den Ruf in beide Richtungen außer Acht und beantworten Sie sechs Fragen.

1. Was kann Ihr Team heute tatsächlich? Nicht, was es lernen könnte. Eine Stack-Migration ist ein Umschulungsprogramm mit einem angehängten Softwareprojekt.
2. Wen können Sie in Ihrem Markt zu welchen Kosten einstellen? Besorgen Sie sich echte Zahlen statt Eindrücke.
3. Wie ist die Arbeitslast beschaffen? Request-Response spricht für PHP. Dauerhafte Verbindungen, Streaming und hohe Parallelität sprechen für Node.js. Daten und Modellierung sprechen für Python.
4. Welches Ökosystem brauchen Sie? Wenn Sie Magentos Erweiterungsmarkt oder die Content-Werkzeuge von WordPress brauchen, ist die Sprachfrage bereits beantwortet.
5. Wie lange werden Sie das betreiben? Ein Produkt für drei Jahre und eine Plattform für fünfzehn Jahre verdienen unterschiedliche Antworten.
6. Was kostet die Alternative wirklich? Inklusive Migration, Umschulung, verlorener Roadmap-Zeit und dem Risiko, dass das Projekt scheitert. Diese Zahl wird regelmäßig weggelassen.

Die Versionsfrage ist dringender als die Sprachfrage

Für die meisten Unternehmen, die fragen sollten wir noch auf PHP setzen, lautet die ehrliche Umformulierung laufen wir auf einer unterstützten PHP-Version. Das sind sehr unterschiedliche Probleme, und nur eines davon ist dringend.

Eine nicht mehr unterstützte PHP-Version zu betreiben bedeutet keine Sicherheits-Patches, Inkompatibilität mit aktuellen Bibliotheksversionen und einen Upgrade-Pfad, der mit jedem Monat Wartezeit länger wird. Anders als eine Sprachmigration ist es zudem eine abgegrenzte Aufgabe mit planbaren Kosten.

• Finden Sie heraus, was Sie betreiben — in jeder Umgebung, auch auf dem vergessenen Cron-Server.
• Gleichen Sie das mit dem offiziellen Support-Zeitplan ab und notieren Sie das Datum, an dem der Support endet.
• Kalkulieren Sie das Upgrade auf die aktuelle stabile Version, nicht auf die nächstfolgende — der Aufwandsunterschied ist meist gering, der Unterschied an gewonnener Laufzeit beträgt Jahre.
• Tun Sie das, bevor Sie eine Sprachdebatte führen. Über eine moderne PHP-Codebasis auf einer aktuellen Version streiten Sie über etwas ganz anderes.

Über die Bewertung solcher Projekte haben wir in eine Legacy-PHP-Codebasis übernehmen geschrieben und über die schrittweise Migration in der Strangler-Fig-Ansatz für Laravel.

Unsere tatsächliche Position

PHP ist eine gute, langweilige, gut unterstützte Wahl für Commerce — und in der Infrastruktur ist „langweilig“ ein Kompliment. Für Echtzeitsysteme oder für alles, bei dem Modelle das Produkt sind, ist es nicht die richtige Wahl. Und das stärkste Argument dagegen betrifft im konkreten Fall fast nie die Sprache — es betrifft eine Codebasis, eine Version oder ein Team.

Wir entwickeln damit in unserer PHP-Entwicklung und unserer Laravel-Arbeit, wir modernisieren die schwierigen geerbten Projekte in unserer individuellen PHP-Entwicklung, und wenn die ehrliche Antwort ein anderer Stack ist, sagen wir das — dieser Vergleich steht in Node.js-Plattformökonomie.

Eine ehrliche Einschätzung zu Ihrem Stack

Sagen Sie uns, was Sie betreiben, was Ihr Team warten kann und was Sie bauen wollen — und wir sagen Ihnen, ob die Sprache wirklich Ihr Problem ist. Meistens ist sie es nicht. Sprechen Sie mit unserem Team; wir antworten innerhalb eines Werktags.