A sunset notice

What if you never had to
leave PHP?

That was Leaf UI's pitch. Livewire-style components where your markup, state and event handlers lived in PHP classes, with Leaf wiring up the browser for you. As of Leaf 5, Leaf UI is officially retired. This page is the honest version of why.

The itch we were scratching

Making a button update a counter used to mean two languages, an API endpoint, a fetch call, and a state library, all to move one number. If PHP was where you thought, every interactive feature dragged you out of your own head. We wanted the whole loop in one place:

use Leaf\UI\Component;

class Counter extends Component
{
    public $key = 'Counter';
    public $count = 0;

    public function increment()
    {
        $this->count += 1;
    }

    public function render()
    {
        return "
            <button @click=\"increment\">+</button>
            <span>{$this->count} clicks</span>
        ";
    }
}

A real Leaf UI component. No endpoint, no fetch, no build step.

No API layer, no context switch, one language. And honestly, it worked. Leaf UI shipped real interfaces, and the people who used it loved what it stood for.

Then the problem dissolved

Two things changed since Leaf UI was born, and neither of them was Leaf UI's fault.

The frontend ecosystems matured, and Leaf grew first-class bridges to them. Blade gives you server-rendered views with almost no ceremony, and Inertia connects Leaf to React, Vue and Svelte without you writing an API layer. These stacks are better documented, better tooled and better tested than a PHP-only reactive layer could realistically become, and leaf view:install sets any of them up in one command.

AI-assisted development removed the itch itself. "Build interfaces without leaving PHP" mattered most when leaving PHP meant a real learning curve. Today your assistant writes idiomatic React, Vue, Svelte or Blade fluently, and Leaf 5's project context keeps it aligned with your app. Staying inside PHP is no longer the shortcut it used to be; using the tools the rest of the world tests and maintains is.

Maintaining a reactive component framework is an enormous job. We would rather pour that energy into the core, the modules and the tooling that make Leaf what it is. Retiring Leaf UI is not us giving up on the idea. It is us admitting the idea won: interactivity without ceremony is now everywhere, so a separate framework for it has nothing left to solve.

What to use instead

Depending on what you used Leaf UI for:

If you were building	Reach for
Server-rendered pages and forms	Blade (default in Leaf MVC), optionally with Tailwind
Reactive, component-driven UIs	Inertia + React, Vue or Svelte via `leaf view:install --react` / `--vue` / `--svelte`
Complete features (auth pages, landing pages, waitlists)	Scaffolds: `leaf scaffold:auth`, `leaf scaffold:landing-page`, `leaf scaffold:waitlist`
Small interactive islands on server-rendered pages	Blade + a sprinkle of vanilla JS or the lightweight library of your choice

If you have Leaf UI in production

The repositories are archived on GitHub: no new features, fixes or security patches will land. Leaf UI was never part of Leaf MVC's default setup, so most Leaf 5 apps are unaffected.

If you have a production app built on Leaf UI, plan a migration to one of the stacks above. The scaffolds are the fastest path: they generate working Blade or Inertia pages you can reshape, instead of leaving you with a blank file. If you get stuck, come talk to us on Discord and we will help you plan the move.

A thank you

Leaf UI taught us a lot about what Leaf developers actually want, and pieces of its DNA live on in the scaffolds and the view system. Thank you to everyone who built with it, filed issues and contributed code. Retiring a project we loved is easier knowing the ideas survive in better homes.