A friend sent me the headline this week with a single word attached: 'finally?'. The Swoole team has open-sourced TypePHP, an ahead-of-time compiler that takes PHP-looking source, emits C++, and hands you a native binary, and the benchmark table tops out around 150x over the interpreter. My answer to his 'finally?' is no, and also yes. No, because this will not make your Symfony app 150 times faster, and the maintainers never said it would. Yes, because something quietly important just happened: the barrier to writing a native PHP extension dropped from 'learn the Zend C API' to 'run Composer'. That second story deserves the headline, and it is the one I want to argue for.

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

First, what the thing actually is. TypePHP started life inside Swoole as an internal AOT compiler and got renamed when the team admitted what they had built: a strongly typed language that reads like PHP but never touches ZendVM opcodes. The bootstrap story is the kind of detail compiler nerds live for. The compiler is written in PHP, and the tpc binary you run is the compiler's own source pushed through an earlier version of itself. A self-hosting PHP compiler was not on my 2026 bingo card, and I say that with genuine affection.

Where do the big numbers come from? From refusing to pay PHP's flexibility tax on code that never needed the flexibility. Stock PHP boxes every value so its type can change mid-flight, which is wonderful when you are gluing an API response to a template and pure overhead when you are summing sixty million floats. Drop use native_types; at the top of a TypePHP file and int, float and bool become int64_t and double, so a tight loop compiles down to plain CPU arithmetic. Arrays get the same treatment: instead of PHP's do-everything hashmap you can reach for containers modeled on std::vector, std::array and std::map, typed up front. The published benchmarks pit PHP 8.4 against TypePHP built with -O3, and even the maintainers caution that the results will wobble with your CPU, compiler and PHP build. Fine. Even if you mentally divide every figure by five, a hot numeric loop landing near hand-written C++ territory is a different sport than opcache tuning.

Now the part where I have to be honest with you, because the project is honest too. TypePHP compiles a defined slice of PHP, not PHP. Top-level code in a file can hold declarations only, the standalone binary mode insists on a main() with a fixed signature, and a long tail of dynamic tricks, from variable variables to most reflection gymnastics, is rejected by design. The team keeps the full refusal list in docs/INCOMPATIBLE_PHP_FEATURES.md, and reading that file against your codebase is step one of any evaluation. Your Laravel app will not compile. Your Doctrine entities will not compile. Anyone who tells you otherwise has not tried.

And here is the counter-argument I take seriously: we have seen typed PHP dialects before, and the memory stings. Hack forked the language, pulled one giant company into its orbit, and left the rest of us with incompatible code samples on Stack Overflow for a decade. A subset language risks splitting libraries, tutorials and hiring pools in two. Add the practical friction: TypePHP wants PHP 8.4 or 8.5 with dev headers, GCC 9 or newer or a C++17-capable Clang, CMake 3.24+, and the embed SAPI for binary builds, plus it ships under GPL-3.0, which your legal team will want to read before you distribute a compiled artifact. That is a real toolchain and a real license conversation, not a checkbox.

So why do I still land on the optimistic side? Because of one flag: -m ext. TypePHP can compile your module into a loadable PHP extension, and a bridge layer called PHPX lets the compiled world call into and coexist with normal Zend-land, including plain require of ordinary .php files. Think about what that replaces. Until now, if your fuzzy-matching scorer or your CSV normalizer was eating 40 percent of a worker's CPU, your options were rewriting it as a C extension, bolting on FFI, or carving the whole job out into a Go sidecar and inheriting a second deployment. Now the pitch is: keep it in PHP syntax, add types, compile that one file, load the .so, done. The fragmentation risk shrinks a lot when the dialect lives at the edges of your app instead of replacing its core.

There are side dishes worth a glance too. Arbitrary-precision types arrive batteries included, with bigInt on GMP, bigFloat on MPFR and decimal on libmpdec, which anyone who has done money math in PHP will appreciate. Attributes like #[Getter] and #[Constructor] generate typed boilerplate at compile time. And the target list reaches past Linux, macOS and Windows on x64 and ARM64 to WASI 0.2 and the browser, though today Linux x64 is the only path I would call production-shaped. The version number, 0.6.6, is doing a lot of expectation management on its own, and it should.

My position, then: ignore the 150x, keep the tool. TypePHP is not a faster PHP, it is the first extension toolchain that speaks our language, and I would rather see the community sharpen that use case than chase full-app compilation dreams. But I have my blind spots, and most of my hot paths really are SQL-shaped, so tell me: what is the one pure-PHP loop in your production system that genuinely burns CPU, and would you buy it a C++ toolchain in CI, or does that job belong outside PHP no matter how familiar the syntax looks?