Introduction

Why PHP in 2026?

It's fashionable to joke about PHP. It's also still one of the most practical ways to put a website on the internet — and modern PHP is nothing like the PHP of the jokes.

It runs everywhere#

Almost every hosting provider on Earth runs PHP: the $3 shared plan, the VPS you already have, managed panels like CloudPanel and cPanel, container platforms, a Raspberry Pi under the desk. You don't need a special runtime, a process manager, or a "deploy target." If it serves web pages, it very likely serves PHP.

That matters for the people Timber is for. "Drag it onto a server" only works if the server already knows how to run it.

Deployment is copying files#

There's no build, no server process to keep alive, no container to rebuild. The runtime executes your files on each request. Update a file and the next request uses it. That's why Timber's deploy story is "unzip and upload" — and why rolling back is just putting the old files back.

Modern PHP is a good language#

PHP 8.x has typed properties and parameters, union types, match expressions, enums, readonly properties, first-class callables, attributes, named arguments, fibers, and a fast engine with opcache. Timber targets PHP 8.1+ and uses strict types in its core. It reads like any other modern, pragmatic language.

It's fast enough that you stop thinking about it#

PHP's request model — start, run, finish, forget — is simple and predictable. With opcache, compiled scripts live in memory; a typical Timber page is a handful of file reads and some string output. There's no connection pool to warm up, no ORM, no query planner. For a content site, that's the right amount of machinery.

Stateless by default#

Each request stands alone, which is exactly what a content site wants. No in-process caches to invalidate, no long-lived memory to leak, no worker to restart after a deploy.

The ecosystem is deep, and you don't need it#

PHP has a giant ecosystem, but Timber deliberately uses none of it at runtime: no Composer packages, no framework. That's a feature. Fewer moving parts means fewer breakages, fewer updates, and a codebase you can read end to end. (If you want Composer packages in your own extensions, nothing stops you.)

Honest trade-offs#

The short version#

PHP is everywhere, copy-to-deploy, quick, and mature. For a CMS meant to be dragged onto a server, that's hard to beat.