PHP on the Desktop: Mastering BosonPHP for Ultra-High Performance Native Applications

For over twenty years, PHP has reigned supreme over the web backend. Its execution model was immutable: an HTTP request comes in, a process is born, generates a response, and then dies. But those days are over. The introduction and maturation of the FFI (Foreign Function Interface) extension have opened a breach into which new architectures are flooding.

Today, the BosonPHP project stands as the new frontier of the ecosystem. It is not just a localized web server, but a true open-source runtime (MIT licensed) designed to run PHP code as a native desktop application. Gone is the excessive weight of Chromium and Node.js inherent to the Electron ecosystem. Welcome to direct, ultra-lightweight, and lightning-fast execution.

#BosonPHP 0.19.5: Anatomy of a Desktop Kernel

The project’s official slogan on GitHub perfectly summarizes its philosophy: “Because it’s not an Electron!”.

The traditional approach to building desktop apps with web technologies involves embedding a full browser within each application. The result? A basic app often consumes over 200 MB of RAM at rest and carries significant weight on the disk.

BosonPHP takes the opposite path. In its current version 0.19.5, the system relies on high-level bindings to Saucer v6.0, an ultra-lightweight C++ library dedicated to creating smart WebView windows. BosonPHP wraps your code in the native WebView engine provided by the operating system (Edge WebView2 on Windows, WebKit on macOS and Linux). The final compiled application weighs only a few dozen megabytes.

The Strategic Choice of PHP 8.4

You might wonder if BosonPHP already uses PHP 8.5, which is starting to be discussed. The answer is no. Currently, the reactor’s core remains firmly anchored on PHP 8.4 (as confirmed by the php84 technical tag in their official repository).

Why stick to version 8.4? Because creating native interfaces via FFI requires complex manipulation of memory pointers in C. PHP 8.4 offers extremely well-documented stability regarding the asynchronous Garbage Collector and typed structures—vital elements to avoid memory leaks in a long-running process. Moving to a higher minor version would require revalidating the reliability of all underlying memory bridges.

#The ‘Zero HTTP Overhead’ Architecture and Framework Bridges

The real revolution of BosonPHP lies in the absence of a network. In previous attempts to port PHP to the desktop, a micro-web server was launched in the background, and the interface communicated with it via TCP requests on localhost.

With BosonPHP, the GUI communicates directly with the PHP process in memory. Events trigger PHP methods directly. But how can we use our favorite frameworks if the whole concept of an HTTP request has disappeared?

The Bridge System

This is where BosonPHP demonstrates its engineering prowess. The team has developed an ecosystem of Bridges that emulate HTTP behavior directly in RAM, without ever opening a network port.

The project offers official components to integrate your frameworks without modification:

• boson-php/laravel-provider and boson-php/laravel-http-bridge
• boson-php/symfony-bundle and boson-php/symfony-http-bridge
• boson-php/spiral-bridge
• boson-php/psr-http-bridge (for any PSR-7 compatible router)

When your application’s WebView attempts to load an internal URL or submit a form, the Boson Bridge intercepts the call, builds a native request object (e.g., an Illuminate\Http\Request for Laravel), and injects it into the framework in memory. The response is generated and returned to the WebView instantly.

#Developing with BosonPHP: A Practical Case

BosonPHP’s software structure is highly modular. To add native features, you install specific extensions via Composer.

Let’s take an example of an application that monitors network and battery status. We will use the boson-php/webview-ext-battery and boson-php/app-ext-alert components.

Copy<?php

use Boson\App;
use Boson\Window;
use Boson\Extensions\Alert\AlertExtension;
use Boson\Extensions\Battery\BatteryExtension;

class SystemMonitor
{
  private App $app;
  private Window $window;

  public function __construct()
  {
    $this->app = new App();
    
    // We register native extensions into the Kernel
    $this->app->register(new AlertExtension());
    $this->app->register(new BatteryExtension());
  }

  public function boot(): void
  {
    $this->window = new Window(
      title: 'Boson System Monitor',
      width: 800,
      height: 600
    );

    $this->window->on('ready', function (Window $win)
    {
      $this->checkBatteryStatus($win);
    });

    $this->app->run();
  }

  private function checkBatteryStatus(Window $win): void
  {
    // Calling the native Battery API via FFI bindings
    $battery = $win->native->getBatteryInfo();
    
    if ($battery->percent < 20 &amp;&amp; !$battery->isCharging)
    {
      // Calling native OS message box without HTML/JS
      $win->native->alert(
        title: 'Warning',
        message: 'Battery level is critically low.'
      );
    }

    // Pushing data to the WebView DOM
    $win->executeJS('updateBatteryUI(' . $battery->percent . ');');
  }
}

$monitor = new SystemMonitor();
$monitor->boot();

In this code, we see the power of the API. The app-ext-alert extension does not create a fake HTML dialog box. It calls the actual MessageBox API of the OS on Windows or the NSAlert API on macOS via FFI bindings.

#Critical Memory Management in a Desktop Context

This is the major friction point for a backend developer transitioning to BosonPHP. In classic PHP (PHP-FPM), memory cleanup is not your primary concern because the process dies at the end of the request.

In BosonPHP, your application can stay open in the background for weeks. The development rules change:

1. Ban Infinite Global State: Arrays stored in $GLOBALS or static class properties that accumulate over time will cause a fatal memory leak.
2. Master Weak References: Boson provides the boson-php/weak-types component to manage data. A weak reference allows you to associate metadata with an object without preventing the Garbage Collector from destroying it when it is no longer used elsewhere.
3. Force Cyclic Cleanup: In complex applications, it is often wise to bind the gc_collect_cycles() function to an internal timer or a change in application state (such as minimizing the window to the taskbar).

#The Workflow: From Writing to Compilation

The project excels in its fluid deployment process. The Developer Experience (DX) is designed to be as simple as possible.

You initialize your project with:

composer create-project boson-php/app my-app

During development, you test the application by simply running:

php index.php

Once development is complete, the boson-php/compiler component comes into play. It consolidates your source code, front-end assets, and the internal PHP engine into a single, standalone executable.

php vendor/bin/boson compile

The generated executable contains everything needed. The end user absolutely does not need to have PHP installed on their machine. It is total plug-and-play.

#Conclusion

BosonPHP is no longer just an experiment. With a stable architecture based on PHP 8.4, the integration of Saucer v6.0, and robust framework support via native asynchronous bridges, version 0.19.5 offers high-level industrial tooling.

Capitalizing on BosonPHP means using your current technical knowledge to deploy ultra-lightweight and high-performance software on any desktop operating system. The elephant language is no longer just the king of the server; it now has a place on your desktops.

Frequently Asked Questions

Lionel Péramo

Web Performance & Eco-design Expert

Full Stack Developer and creator of the OTRA framework (PHP) and EcoComposer library. I write to make the web faster and more inclusive.

About me →