We dismissed PHP years ago. Not loudly — we just quietly stopped considering it. The collective thinking had settled: PHP was legacy, messy, the language you apologised for knowing. We accepted that without questioning it.

Then we needed a front end for our build server.

Go is our primary language at uRadical, and we're not moving away from it. But when we needed a straightforward web interface — forms, server-rendered pages, quick iteration — reaching for Go felt like using a torque wrench to hang a picture frame. So we reached for PHP instead. Laravel, specifically.

Clean routing, Blade templates rendering HTML on the server, Eloquent handling the database without ceremony. No webpack config. No hydration issues. No shipping a JavaScript runtime to the browser so it could do what the server already did perfectly well.

That forced us to confront something uncomfortable: we'd written off a language that powers nearly three-quarters of the web, based on a reputation it earned a decade ago and has long since outgrown.

Earned, then fossilised

Old PHP deserved its bad reputation. Inconsistent function naming, SQL injection baked in by default, spaghetti mixing logic and markup in the same file. It was genuinely rough. But the reputation fossilised while the language kept moving.

PHP 7 delivered roughly a 400% performance improvement over PHP 5.6. PHP 8.x added another 18–42% on top of that, plus a JIT compiler, fibers, enums, union types, and named arguments. It's a different language now.

And Laravel gave it what it was always missing — opinionated structure. Proper MVC, dependency injection, migrations, a CLI developers actually enjoy using. It did for PHP what Rails did for Ruby, except PHP already had massive market share underneath it. JetBrains' State of PHP 2024 puts Laravel adoption at 61% of PHP developers. It holds over 77,000 GitHub stars and roughly 60% of the PHP framework market.

The longest detour in web development

Here's what makes this interesting. The JavaScript ecosystem spent the best part of a decade building increasingly complex abstractions to arrive back at a conclusion PHP developers never left: rendering HTML on the server and sending it to the browser is a sensible default.

React Server Components — running code on the server, sending HTML to the client — is what <?php echo $html ?> has done since 1995. Next.js server actions replicate patterns Laravel has had from day one. Islands architecture is what PHP developers just call "a webpage." HTMX formalises an approach that was never abandoned, only forgotten by everyone else.

The industry needed server components, edge functions, streaming SSR, and partial hydration to get back to where PHP started. Meanwhile, PHP developers were shipping working software the entire time.

The paradox nobody talks about

W3Techs puts PHP at 74.5% of all websites with a known server-side language. PHP 8 has now overtaken PHP 7 in production, meaning most of the PHP web runs on a modern runtime. WordPress alone accounts for over 43% of all websites.

Yet on the Stack Overflow Developer Survey, only 18.2% of developers report using PHP.

Think about that. A language used by fewer than one in five developers powers roughly three-quarters of the web. That's not a language in decline — it's a language so embedded in the infrastructure of the internet that most of the industry takes it for granted.

The elephant was always in the room. Everyone just agreed to pretend it wasn't there.

Right tool, right problem

We're not becoming a PHP shop. Go remains our primary language for backend services, CLIs, and systems work.

But PHP is back in our toolkit. Server-rendered web interfaces, content-driven applications, anything where the answer is "just send HTML to the browser." Laravel makes that clean and maintainable.

We spent years stepping around the elephant. Turns out it was the most practical thing in the room.