Leaf PHP, and the bet that global functions are enough

The argument against frameworks, and the answer

Leaf is described as a slim and lightweight PHP framework focused on developer experience, usability and high-performance code, introducing a cleaner and much simpler structure to PHP while keeping its flexibility. With a simple structure and a shallow learning curve, the claim is that it is a good way to rapidly build powerful and high-performance web apps and APIs.

The Why Leaf section is a critique of frameworks in general, and it is more specific than the usual complaints. While PHP frameworks speed up development, they come with challenges: a steep learning curve, potential performance overhead and stricter code maintenance. They can be rigid, limiting flexibility, and often tie you to a specific ecosystem, making it hard to use unsupported packages. And frameworks may introduce unused code, leading to bloat and reduced performance.

Each of those has a matching answer in Leaf's design. The steep learning curve is answered by global functions, so there is no class to look up before you can write a route. The rigidity is answered by modularity, where you install only the features you need while maintaining compatibility with other libraries and frameworks. The unused code problem is answered by not having a framework layer at all in the request path.

The scalability claim is that Leaf works from development to production with minimal configuration, and the audience is stated as both beginners and experienced developers.

It is worth being clear about what this is. Leaf is a small framework, not a micro framework in the strict sense of the term, and the pitch is a set of global functions and a router rather than a component model.

The whole application is one file and three calls

The basic usage example is the shortest possible Leaf application, and it is the clearest statement of the design.

<?php

require __DIR__ . '/vendor/autoload.php';

app()->get('/', function () {
  response()->json([
    'message' => 'Hello World!'
  ]);
});

app()->run();

Three things to notice. There is no configuration file, no directory structure and no bootstrap beyond the Composer autoloader. The route is registered with a method on the object returned by app(), the handler returns through response(), and app()->run() starts the server.

The global functions are the design decision, and they are what the Why Leaf section means by simplifying usage with global functions. Instead of resolving a response object from a container and injecting it, you call response() and get one. The result is that a file can be read top to bottom in a few seconds, and a new contributor can write a route without learning a container.

The cost is equally clear. Global functions occupy the global namespace, so two libraries that both define a helper() will collide, and the framework is harder to test in isolation than one where you inject the object you need. A reader who prefers dependency injection has to accept that this project decided otherwise.

Both are legitimate positions. The question for an adopter is whether the smaller surface is worth the loss of explicitness, and the documentation, the codelabs and the video tutorials exist to make that judgement easy.

Running it: the Leaf CLI or the built-in PHP server

The project gives you two ways to run the application, and both are one command.

The Leaf CLI is the first option, and it is the one the project points at.

leaf serve

The alternative is the PHP built-in server, which needs no extra tool at all.

php -S localhost:5500

The PHP built-in server is the more interesting of the two for anyone evaluating Leaf, because it demonstrates the framework's claim to have no runtime requirements beyond PHP and Composer. There is no extension to compile, no daemon to run and no environment file to fill in, and the default port here is 5500 rather than the 8000 the PHP server uses by default, so the port is passed explicitly.

The CLI, by contrast, comes from a separate package. The ecosystem table lists cli as its own project, described as a CLI for creating and interacting with your leaf apps, with its own repository and its own Packagist entry. That matters when you read the installation instructions, because the command leaf create is provided by a tool that is not part of the core framework.

For a quick evaluation, php -S is the path of least resistance. For a project you will work on daily, the CLI is what adds the create, serve and other conveniences, and it is worth installing separately.

Two installation paths: the CLI scaffolding and Composer

The installation section gives both routes, and they are not equivalent.

The first creates a new Leaf app with the Leaf CLI.

leaf create <project-name> --basic

The project name is the name of your project, and the --basic flag asks for the basic skeleton rather than a fuller template. The CLI is a separate package, so this is a tool you install before you have a project, and the flag is the only knob the documentation mentions here.

The second installs Leaf into a project with Composer.

composer require leafs/leaf

That is the route if you are adding Leaf to something that already exists, and it is the route that matches the basic usage example, since the example starts from the Composer autoloader in a vendor directory.

One detail in the installation text is worth flagging because it is out of date. The document says you can also use Composer to install Leaf 3 in your project quickly, and the command itself pulls the current version, so the reference to version 3 is a leftover in the prose rather than in the command. The current release line is v5, with the default branch of the repository named v5.x, and the tags are v5.0 from 2026-08-15, v4.4 from 2025-09-19 and v4.3 from 2025-09-06.

The releases also have names, which is a small charm worth mentioning, since they are flowers: v5.0 is Morning Glory, v4.4 is Black Pearl and v4.3 is French Marigold Burning Embers.

The ecosystem is a table, and the core is deliberately small

The Leaf ecosystem section lists three projects, and the table is a compact statement of what the framework is and what it is not.

leaf is the core, for creating websites and APIs quickly. leafmvc is an MVC wrapper for leaf. And cli is the command line tool for creating and interacting with leaf apps. Each has its own repository and its own Packagist entry with its own stable version and download count badges, which means the MVC layer and the CLI can move on their own schedule.

That is the modularity claim in practice. A project that wants plain routes installs the core. A project that wants controllers and models installs the wrapper. A developer who wants the scaffolding tool installs the CLI. None of them is forced on anyone, and the modules documentation page holds a full list of all modules.

The repository itself is small, and its layout says what the project is. There is a src directory, a tests directory, a composer.json, a CHANGELOG.md, a LICENSE, a README, an .editorconfig, and an alchemy.yml.

The last file is the one to notice. The Leaf ecosystem is described in the project description as a set of libs and frameworks, and alchemy.yml is the manifest for that kind of registry, so the project is organised around publishing many small packages rather than one large one.

That is also the answer to the framework bloat complaint in the Why Leaf section. The core does not contain the MVC layer or the CLI, and if you do not install them, you do not ship them.

Version 5, a sponsorship appeal, and a security contact on social media

The project is MIT licensed, and the current release is v5.0, tagged Morning Glory on 2026-08-15, with the default branch named v5.x and the last push on 2026-09-17. The repository is not archived.

The maintainers are explicit about the funding situation, and it is worth reading before you depend on the project. The team says it is committed to keeping Leaf open source and free, but that maintaining and developing new features now requires significant time and resources, that as the project has grown so have the costs which have been mostly covered by the team, and that to sustain and grow Leaf they need help to support full-time maintainers. Sponsorship runs through Open Collective, with a support page listing other ways to contribute.

That is a candid statement from a small project, and it is a factor in an evaluation. The code is permissively licensed and you can fork it, but a framework that runs on sponsorship is a different risk profile from one with a larger organisation behind it.

Security reporting goes through the maintainers on Twitter, and the project says it will coordinate the fix and eventually commit the solution. That is a workable process for a small project, though it is worth noting for a team with a formal disclosure requirement.

For learning, the project points at its documentation site with information on all operations in Leaf, a YouTube channel with video tutorials, and codelabs that you can also contribute to. Community happens on Twitter, a forum discussion thread and Discord.

Editorial conclusion

Adopt Leaf if you want a PHP API or small web application where the framework should stay out of the way, since a Leaf app can be one file with a route handler and a JSON response, and the modular design means you install only the parts you use. Do not adopt it if your team expects a conventional framework with a fixed directory layout and a configuration file, because the documented surface is deliberately thin. Before you commit, read the modules list and the ecosystem table, since Leaf MVC and the CLI are separate packages rather than part of the core, and check which major version your project pins, because the installation text still refers to Leaf 3 while the current release line is v5.

Frequently asked questions

Official sources

1. leafsphp/leaf on GitHub
2. License: MIT
3. Project website
4. README
5. Releases