Ein Freund hat mir diese Woche die Schlagzeile geschickt, mit einem einzigen Wort dazu: 'endlich?'. Das Swoole-Team hat TypePHP als Open Source veröffentlicht, einen Ahead-of-Time-Compiler, der Quellcode nimmt, der wie PHP aussieht, daraus C++ erzeugt und dir ein natives Binary in die Hand drückt, und die Benchmark-Tabelle endet bei rund 150x gegenüber dem Interpreter. Meine Antwort auf sein 'endlich?' ist nein, und auch ja. Nein, weil das deine Symfony-App nicht 150-mal schneller macht, und die Maintainer haben das auch nie behauptet. Ja, weil gerade etwas leise Wichtiges passiert ist: Die Hürde, eine native PHP-Extension zu schreiben, ist von 'lerne die Zend-C-API' auf 'führ Composer aus' gefallen. Diese zweite Geschichte verdient die Schlagzeile, und für sie will ich hier argumentieren.

composer require --dev swoole/typephp
vendor/bin/tpc.php project.yml

Zuerst: Was ist das Ding eigentlich? TypePHP begann sein Leben innerhalb von Swoole als interner AOT-Compiler und wurde umbenannt, als das Team zugab, was es da gebaut hatte: eine streng typisierte Sprache, die sich wie PHP liest, aber nie ZendVM-Opcodes anfasst. Die Bootstrap-Geschichte ist genau die Sorte Detail, für die Compiler-Nerds leben. Der Compiler ist in PHP geschrieben, und das tpc-Binary, das du ausführst, ist der eigene Quellcode des Compilers, durch eine frühere Version seiner selbst geschoben. Ein selbst-hostender PHP-Compiler stand nicht auf meiner Bingo-Karte für 2026, und das sage ich mit echter Zuneigung.

Woher kommen die großen Zahlen? Daher, dass man sich weigert, PHPs Flexibilitätssteuer für Code zu zahlen, der die Flexibilität nie gebraucht hat. Standard-PHP boxt jeden Wert, damit sich sein Typ unterwegs ändern kann, was wunderbar ist, wenn du eine API-Antwort an ein Template klebst, und reiner Overhead, wenn du sechzig Millionen Floats aufsummierst. Schreib use native_types; an den Anfang einer TypePHP-Datei, und int, float und bool werden zu int64_t und double, sodass eine enge Schleife zu schlichter CPU-Arithmetik kompiliert. Arrays bekommen dieselbe Behandlung: Statt PHPs Alleskönner-Hashmap greifst du zu Containern nach dem Vorbild von std::vector, std::array und std::map, vorab typisiert. Die veröffentlichten Benchmarks lassen PHP 8.4 gegen TypePHP mit -O3 antreten, und selbst die Maintainer warnen, dass die Ergebnisse mit deiner CPU, deinem Compiler und deinem PHP-Build schwanken werden. Gut. Selbst wenn du jede Zahl im Kopf durch fünf teilst, ist eine heiße numerische Schleife, die in der Nähe von handgeschriebenem C++ landet, ein anderer Sport als Opcache-Tuning.

Jetzt der Teil, wo ich ehrlich mit dir sein muss, weil das Projekt es auch ist. TypePHP kompiliert einen definierten Ausschnitt von PHP, nicht PHP. Top-Level-Code in einer Datei darf nur Deklarationen enthalten, der Standalone-Binary-Modus besteht auf einer main() mit fester Signatur, und ein langer Schwanz dynamischer Tricks, von variablen Variablen bis zu den meisten Reflection-Kunststücken, wird per Design abgelehnt. Das Team pflegt die vollständige Verweigerungsliste in docs/INCOMPATIBLE_PHP_FEATURES.md, und diese Datei gegen deine Codebasis zu lesen ist Schritt eins jeder Evaluierung. Deine Laravel-App wird nicht kompilieren. Deine Doctrine-Entities werden nicht kompilieren. Wer dir etwas anderes erzählt, hat es nicht ausprobiert.

Und hier ist das Gegenargument, das ich ernst nehme: Wir haben typisierte PHP-Dialekte schon gesehen, und die Erinnerung schmerzt. Hack hat die Sprache geforkt, ein einziges riesiges Unternehmen in seinen Orbit gezogen und dem Rest von uns ein Jahrzehnt lang inkompatible Code-Beispiele auf Stack Overflow hinterlassen. Eine Subset-Sprache riskiert, Bibliotheken, Tutorials und den Bewerbermarkt in zwei Hälften zu spalten. Dazu kommt die praktische Reibung: TypePHP will PHP 8.4 oder 8.5 mit Dev-Headern, GCC 9 oder neuer oder ein C++17-fähiges Clang, CMake 3.24+ und die embed-SAPI für Binary-Builds, und obendrein steht es unter GPL-3.0, was dein Legal-Team lesen will, bevor ihr ein kompiliertes Artefakt verteilt. Das ist eine echte Toolchain und ein echtes Lizenzgespräch, keine Checkbox.

Warum lande ich trotzdem auf der optimistischen Seite? Wegen eines Flags: -m ext. TypePHP kann dein Modul in eine ladbare PHP-Extension kompilieren, und eine Brückenschicht namens PHPX lässt die kompilierte Welt ins normale Zend-Land hineinrufen und mit ihm koexistieren, inklusive schlichtem require gewöhnlicher .php-Dateien. Überleg mal, was das ersetzt. Bis jetzt waren deine Optionen, wenn dein Fuzzy-Matching-Scorer oder dein CSV-Normalizer 40 Prozent der CPU eines Workers gefressen hat: das Ding als C-Extension neu schreiben, FFI dranschrauben oder den ganzen Job in einen Go-Sidecar auslagern und ein zweites Deployment erben. Jetzt lautet der Pitch: Lass es in PHP-Syntax, füge Typen hinzu, kompiliere diese eine Datei, lade die .so, fertig. Das Fragmentierungsrisiko schrumpft gewaltig, wenn der Dialekt an den Rändern deiner App lebt, statt ihren Kern zu ersetzen.

Es gibt auch Beilagen, die einen Blick wert sind. Typen mit beliebiger Präzision kommen mit Batterien: bigInt auf GMP, bigFloat auf MPFR und decimal auf libmpdec, was jeder zu schätzen weiß, der in PHP schon mal mit Geld gerechnet hat. Attribute wie #[Getter] und #[Constructor] erzeugen typisierten Boilerplate zur Compile-Zeit. Und die Zielliste reicht über Linux, macOS und Windows auf x64 und ARM64 hinaus bis zu WASI 0.2 und dem Browser, wobei heute Linux x64 der einzige Pfad ist, den ich produktionsreif nennen würde. Die Versionsnummer 0.6.6 betreibt ganz allein schon eine Menge Erwartungsmanagement, und das soll sie auch.

Meine Position also: Ignorier die 150x, behalte das Werkzeug. TypePHP ist kein schnelleres PHP, es ist die erste Extension-Toolchain, die unsere Sprache spricht, und ich würde lieber sehen, dass die Community diesen Anwendungsfall schärft, statt Träumen von der Kompilierung ganzer Apps hinterherzujagen. Aber ich habe meine blinden Flecken, und die meisten meiner Hot Paths sind ehrlicherweise SQL-förmig, also sag mir: Was ist die eine Pure-PHP-Schleife in deinem Produktivsystem, die wirklich CPU verbrennt, und würdest du ihr eine C++-Toolchain in der CI spendieren, oder gehört dieser Job raus aus PHP, egal wie vertraut die Syntax aussieht?