PHP 8.4 – schickere Syntax, ein bisschen Tempo, fiese Fallen für alten Code
Kaum ist man mit 8.3 halbwegs durch, steht schon der nächste PHP-Sprung an. 8.4 bringt ein paar nette Sachen: Komplett readonly für Klassen, also nicht mehr nur einzelne Properties. Fibers werden ausgebaut – endlich mal anständige Parallelisierung, ohne Callback-Spaghetti. Für APIs oder eigene Framework-Basteleien ganz nützlich. Im Alltag? Kommt drauf an, wie schräg der eigene Code ist.
Die JIT-Engine wurde wieder angefasst. In manchen Benchmarks sieht das nach mehr Tempo aus – aber meistens nur bei CPU-lastigen Jobs, viel Mathe, viel Parsing. Auf Shared-Hosting sieht man davon oft nichts, weil der passende Opcode-Cache fehlt oder die Hoster trödeln. Erstmal prüfen, ob was davon ankommt.
Update-Risiken: Was Altprojekte jetzt an die Wand fahren kann
Wer noch Projekte aus der PHP-7-Ära oder älter betreut, kennt das Lied. Neue PHP-Version, plötzlich knallt es an Stellen, die vorher „gingen“. 8.4 zieht die Typ-Prüfungen strammer, wirft hier und da statt Warnung jetzt gleich eine Exception. Einmal schief eingebaute Funktion? Zack, Fehler im Live-Betrieb.
Vor einem Update besser die Checkliste abarbeiten:
- Gibt’s alte Funktionen, die 8.4 rauswirft oder anders behandelt?
- Typ-Prüfungen: Sind Parameter und Rückgaben wirklich überall sauber?
- Fiber-Kram mal durchtesten, falls schon im Einsatz (Nebenwirkungen!)
- Libraries und Frameworks via Composer auf Stand bringen – da hakt es oft am längsten
Und wer immer noch ohne Tests arbeitet (kommt öfter vor als zugegeben): Jetzt wäre ein guter Zeitpunkt, wenigstens ein paar Unit- und Integrationstests einzubauen. Sonst wird die Fehlersuche nach dem Upgrade schnell zum Wochenendspaß. Oder Albtraum.
Was an der Syntax tatsächlich Alltag bringt
Ein bisschen Kosmetik, aber in der Praxis schneller lesbar:
- readonly für ganze Klassen – spart Tipparbeit
- Named Arguments + Spread-Operator: Endlich weniger Parameter-Chaos
- Match-Ausdrücke, die mehr als nur einen Wert zurückgeben können
- Bessere Attribute für Funktionen/Klassen, jetzt sauberer auslesbar über Reflection
Klingt alles harmlos, spart aber an manchen Tagen Nerven. Trotzdem: Wer einen Altbau pflegt, muss nicht alles sofort refaktorisieren. Neues Feature ist nicht gleich Pflicht – erst mal gucken, ob es im eigenen Code Sinn ergibt.
Performance: Wo das Mehr an Tempo wirklich ankommt
Die JIT-Schraubereien bringen in Zahlen: Mal 10, mal 15 Prozent schneller, aber nur bei bestimmten Jobs. Viele Webanwendungen merken davon wenig. Wer aber eigene Algorithmen, viel Zahlenschubsen oder Datenwälzen am Start hat, freut sich über weniger Wartezeit. Im Rest? Eher wenig.
Wichtig: Ohne passende Extensions oder aktuellen Opcode-Cache verpufft der Vorteil. Viele Managed-Hoster ziehen beim PHP-Update nicht direkt mit, da hilft nur Geduld oder eigener Server. Auf Root oder VPS: Möglichst schnell auf die neue Version umstellen, JIT aktivieren, dann sieht man auch was.
Meine Einschätzung nach fast 30 Jahren Webentwicklung
PHP-Upgrades fühlen sich immer wie ein Balanceakt an, vor allem bei Projekten, die über Jahre gewachsen sind. Neue Sprachfeatures sind nett, aber die echten Probleme liegen im Kleingedruckten: Libraries, Framework-Abhängigkeiten, Plugins, die irgendwo im Code schlummern und beim Update plötzlich streiken.
Für eine kleine Agentur (5–10 Leute): Ohne Testumgebung und saubere Versionsverwaltung ist Stress vorprogrammiert. Erst alles lokal oder staging durchprüfen, dann live. Einzelkämpfer mit WordPress/Shop-Systemen: Backup ziehen, Kompatibilität der wichtigsten Plugins checken, erst dann loslegen. Fehler finden sich meistens dann, wenn keiner erreichbar ist.
Das Update kostet Zeit. Lohnt aber, sobald der Code sauber läuft – weniger Wartungsaufwand, weniger Überraschungen beim nächsten Update. Wer eh aufräumen muss, kann die Gelegenheit nutzen, Altlasten endlich rauszuwerfen.
Aus der PHP-Serie
- PHP 8 Migration ohne Stillstand
- Composer in der Praxis
- PHP-Sicherheit: OWASP-Basics
Kurz: PHP 8.4 ist ein Upgrade mit Fangfragen
PHP 8.4 bringt spürbar lesbarere Syntax und ein bisschen mehr Geschwindigkeit. Aber: Wer alte Projekte pflegt, muss vor dem Update testen – und zwar gründlich. Für aktuelle Anwendungen lohnt der Umstieg, bei Legacy-Projekten ist es ein guter Anlass für Frühjahrsputz im Code. Sonst drohen die üblichen PHP-Überraschungen – und die sind selten lustig.
bye
mo
Zuletzt bearbeitet: