TypePHP, the compiler that turns PHP into a native binary

Recently, the Swoole team open sourced a project that caught my attention: TypePHP, an AOT (Ahead-of-Time) compiler for PHP.

For anyone unfamiliar with the term, AOT means the code gets compiled before it runs, turning into a ready-made binary, unlike traditional PHP, which interprets the code (or compiles bits of it on the fly, in the case of JIT) on every execution.

The idea is simple to explain: you write PHP, and it compiles that code into native code, going through C++ along the way. In practice, this lets you generate executables, PHP extensions, and shared libraries.

And the question that remains is: what does this change for those who already develop in PHP?

Contents

• PHP that becomes an executable
• A worker that keeps running
• What about PHP extensions?
• Where does this actually make sense?
• What about performance?
• What it still isn't
• Who is TypePHP interesting for?
• Is it worth following?
• In short
• Final thoughts

PHP that becomes an executable

We're used to running PHP like this:

php app.php

Or, in a web application:

HTTP Request
     ↓
   Nginx
     ↓
  PHP-FPM
     ↓
  PHP code
     ↓
 Response

With TypePHP there's another possibility:

PHP
 ↓
TypePHP
 ↓
C++
 ↓
native compiler
 ↓
executable

For example:

<?php
function calculate(int $n): int
{
    $result = 0;
    for ($i = 0; $i < $n; $i++) {
        $result += $i * $i;
    }
    return $result;
}

echo calculate(1000000);

Instead of distributing the .php file, the idea is to compile this code into an executable that runs directly with ./app.

TypePHP has its own CLI, tpc, with different compilation modes: bin, ext, and lib.

That opens up a possibility we don't usually associate with PHP: distributing an application as a native program. Imagine a tool:

mytool backup
mytool migrate
mytool analyze

Instead of the user having to install PHP, Composer, dependencies, and extensions, you distribute a single executable.

A worker that keeps running

Another possibility is building programs that stay alive continuously. For example, a worker:

RabbitMQ
    ↓
┌──────────────────────┐
│     my-worker         │
│                       │
│  picks up a job       │
│  processes it         │
│  saves the result     │
│  waits for the next   │
│        ...            │
└──────────────────────┘

Instead of thinking only in terms of PHP scripts run on demand, you get a ./my-worker running around the clock.

This gets a lot closer to the model we already know from Go, Rust, Node.js, or Java applications.

Of course, TypePHP doesn't automatically turn any PHP application into a concurrent server: networking, event loop, concurrency, and communication still depend on the runtime and libraries you use. Even so, being able to generate a persistent native process written in PHP already changes the game quite a bit.

What about PHP extensions?

TypePHP can also generate native extensions. For example:

<?php
function hello(string $name): string
{
    return "Hello, {$name}!";
}

Compiling in ext mode:

tpc hello.php --mode=ext -o hello

The result is a native extension, hello.so, loaded like any other PHP extension:

php -d extension=./hello.so -r "echo hello('Marcos');"

That creates a bridge between the PHP world and native code, without having to write the whole implementation in C or C++.

Where does this actually make sense?

I don't see TypePHP as a way to take an entire Laravel application and turn it into an executable. The scenario that makes the most sense to me is different:

              PHP Application
                    │
        ┌───────────┴───────────┐
        │                       │
   business logic            heavy
   HTTP / ORM / etc.        processing
                                │
                                ▼
                             TypePHP
                                │
                                ▼
                          native code

You keep using PHP where it's excellent, but experiment with compiled code in specific parts, such as:

• processing large volumes of data;
• parsers;
• algorithms and numeric processing;
• workers;
• CLIs;
• agents;
• infrastructure tools;
• components that need to be distributed as binaries.

And there's an extra advantage for commercial software: the customer doesn't have to receive your original PHP source code. The project itself lists source code protection as one of the advantages of AOT compilation. That doesn't make a binary impossible to analyze (reverse engineering is still a thing), but it's quite different from handing over a folder full of .php files.

What about performance?

It's the first thing that comes to mind when the subject is native compilation, but I'd temper expectations here.

That doesn't mean "Laravel + TypePHP = a 10x faster application".

If your application spends most of its time waiting on MySQL, Redis, or external APIs, compiling the PHP won't fix that bottleneck. The real potential gain is in code that actually burns CPU:

for ($i = 0; $i < 100000000; $i++) {
    $result += $i * $i;
}

TypePHP also works with native types, like int, float, and bool, and typed containers, giving the compiler more information to generate native code.

I see performance as a real advantage of the project, but not as the main reason to follow it.

What it still isn't

TypePHP is still under development and works with a defined subset of the PHP language.

That happens because PHP is extremely dynamic:

$method = $foo;
$object->$method();
call_user_func($callback);

The more dynamic an application is, the harder it becomes for the compiler to determine ahead of time what that code will actually do. So don't expect to take any existing PHP project, especially a large one full of dynamic features, and just spit out an executable.

TypePHP still isn't "Go written in PHP." But it might be quite a path toward the future of the language.

Who is TypePHP interesting for?

If you work exclusively with Laravel, Symfony, and traditional APIs, TypePHP might not change much in your day-to-day, at least for now.

But it starts to make a lot of sense if you build:

• CLI tools;
• workers and queue consumers;
• file processing;
• parsers;
• infrastructure tools;
• agents that run on the machine;
• commercial software that needs to be distributed;
• PHP extensions;
• CPU-bound code.

In those cases, TypePHP stops being a curiosity and becomes one more tool in the box.

Is it worth following?

I think so. Not because you should ditch PHP-FPM, Laravel, or Symfony tomorrow, but because the project is exploring a possibility that historically wasn't very common in the PHP ecosystem:

             PHP
              │
       ┌──────┼──────┐
       │      │      │
       ▼      ▼      ▼
      Web   Worker   CLI
       │      │      │
    PHP-FPM  binary  binary

A PHP developer can keep using all the experience they already have in the language and, in specific scenarios, start producing native software.

Given my experience with PHP extensions and command-line tools, I already have a few ideas in mind to test TypePHP and build my first native binaries.

In short

• You keep writing PHP.
• TypePHP compiles it to native code.
• You can generate binaries, extensions, and libraries.
• Typed code can benefit from native optimizations.
• The project is still under development.

Final thoughts

The core point of TypePHP isn't making PHP run faster. It's the possibility of changing the kind of software we can build and distribute using the language.

Today, when we think of a:

• CLI;
• daemon;
• worker;
• agent;
• infrastructure service;

it's very common to reach for Go or Rust.

With a compiler like TypePHP, we start asking a different question: do we still need to switch languages, or can we keep using PHP and compile that part into native code?

It's still early to answer that. But, as a PHP developer, that's exactly why I'll be keeping an eye on TypePHP.

The project is open on GitHub: TypePHP.

See you next time, and cheers! 🐘