Forem: Filipe Silva

The PHP Criticism You've Never Actually Thought Through

Filipe Silva — Tue, 28 Apr 2026 12:49:13 +0000

TL;DR — I've been writing PHP for 15 years. I've tried Ruby, Groovy, and Java. I came back each time. This article goes through the serious criticisms of PHP — stdlib inconsistency, the stateless model, no real async — and where each one actually holds up, and where it doesn't.

I've been writing PHP for over 15 years. I've tried Ruby, Groovy, and Java — not out of curiosity, but because I genuinely questioned whether PHP was the right tool. I came back each time. Not out of habit, but because the arguments against PHP rarely survive contact with reality.

Let me go through the serious ones. And where PHP genuinely falls short, I'll say so.

First, some context most critics skip

The people who say PHP can't evolve stopped paying attention around 2005. The language kept moving without them.

PHP was created in 1994 by Rasmus Lerdorf. It didn't start as a programming language — it was a set of scripts to monitor visits to his online résumé. Built to solve a real problem, not designed by a committee with an architectural vision.

Critics use this against it: "No coherent design from the start." Fair. Growing organically has costs. But what followed was not stagnation — it was sustained evolution over three decades.

PHP 3.0 gave the language a proper modular foundation. PHP 4 brought the Zend Engine and the first real object-oriented support. PHP 5 made OOP actually usable — abstract classes, interfaces, exceptions, PDO. These weren't small updates. They were the language growing up.

PHP 7 was the version that changed things for me personally. Performance roughly doubled over 5.6. Memory consumption dropped. Scalar type declarations arrived. For the first time I could apply design patterns and architectural concepts — DDD, hexagonal architecture, proper interfaces — without fighting the language to do it. PHP 7.4 in particular felt like a turning point: typed properties, arrow functions, a language that finally matched the way I wanted to think about code.

PHP 8 continued from there — JIT compilation, union types, match expressions, attributes, named arguments. PHP 8.3 and 8.4 added typed class constants, readonly improvements, property hooks. The people who say PHP can't evolve stopped paying attention around 2005. The language kept moving without them.

The stdlib is inconsistent. Yes. But that's not the argument you think it is.

The inconsistencies are being removed, version by version. That's the cost of scale, and PHP pays it responsibly.

The standard library grew alongside the language — functions added at different times, by different contributors, with different conventions. The result is real: inconsistent naming, parameter ordering that flips between functions. needle before haystack in some, the reverse in others.

Some defend this by pointing to IDEs. I won't — that's pointing to a workaround, not answering the criticism. The real argument is simpler: the inconsistencies are being removed, version by version. Slowly — because PHP takes backwards compatibility seriously. A significant portion of the web runs on PHP. Breaking it carelessly is not an option. That's the cost of scale, and PHP pays it responsibly.

The share-nothing model is a limitation. It's also a structural guarantee.

The stateless model doesn't make you a better developer. It removes one category of mistake from the table by design.

PHP's execution model is stateless by default — each request starts fresh, no shared memory between them. The performance cost is real. JIT and caching address most of it in practice. But the cost exists.

What rarely gets mentioned is what you get in return. Stateless execution makes an entire class of memory problems structurally harder to produce. I've had a Groovy application stop completely because the JVM held on to state it should have released. Managing long-lived state is genuinely hard. The stateless model removes one category of mistake from the table by design.

A PHP setup is also notably lighter than a JVM or Node runtime. In environments where infrastructure costs matter — and they usually do — that's not a small detail.

No threads, no real async. Here's where I'll be honest.

Knowing where your tool's boundaries are is part of using it well.

PHP doesn't have native threads or true async execution. Fibers, added in PHP 8.1, are cooperative — not parallel. This is a real limitation.

If you're building long-running workers that need shared state and true parallelism — background processors, event-driven services, persistent connections — PHP is not the right tool. I'd use Java. Threads, shared state, long-lived processes: that's Java's territory.

But that's a specific problem. For web applications — APIs, sites, request-response cycles — native threads rarely come up. Apache manages concurrent connections. Queues handle background work. Most applications that think they need threads are actually describing an infrastructure problem. PHP delegates concurrency to the layer better suited to handle it. That's not a gap — that's a boundary. Knowing where your tool's boundaries are is part of using it well.

Java doesn't dominate the web. Nobody calls it dead.

PHP outlasted languages that came specifically to replace it.

Java is mature, strongly typed, has a massive ecosystem. By most objective measures it's an excellent language for web development. It never dominated the web the way PHP has. Nobody eulogises it for that.

PHP outlasted languages that came specifically to replace it. Ruby on Rails had its moment — around 2005 to 2010 — when it felt like it might displace PHP entirely. It didn't. PHP is still here, still powering a significant share of the web, still getting faster with each major version.

I tried to leave

The language that gets mocked is not the language I use.

Ruby taught me that convention over configuration is a real productivity gain. Groovy showed me a more expressive JVM. Java gave me appreciation for strict typing in complex systems — and it's still my choice for long-running processes with shared state.

What brought me back wasn't sentiment. PHP kept getting better at what it's actually for. What I write today in PHP 8+ — strict types, PHPStan at maximum level, DDD with hexagonal architecture — looks nothing like what people picture when they say "PHP is bad." The language that gets mocked is not the language I use.

The actual problem

No compiler catches logic errors. You catch them by understanding the problem deeply.

Most PHP criticism conflates three things: the language, the infrastructure around it, and the code people write with it. A poorly written WordPress plugin is not evidence that PHP is bad. It's evidence that accessible languages attract developers at every level. That's not a flaw — that's what happens when a language is approachable.

The hardest bugs aren't type errors or concurrency issues. They're logic errors — misunderstood requirements, wrong abstractions, bad domain models. No compiler catches those. You catch them by understanding the problem deeply, regardless of what's on the left side of your shebang line.

Dead or not, PHP is the language I choose for my projects and teach with conviction. Thirty years in, it's still shipping. So am I.

Migrating a PHP monolith in production: how I think about it

Filipe Silva — Fri, 24 Apr 2026 17:08:36 +0000

TL;DR — A security breach took down a site running on a 10-year-old Debian server with an obsolete LAMP stack. No access to the original infrastructure, no time to understand it. This is what I did, in what order, and why. The system is still in production. The migration is still ongoing.

The site went down because of a security breach.

Not a gradual degradation, not a performance problem we'd been ignoring. A breach. The system was offline, and getting back in meant dealing with infrastructure that hadn't been touched in over a decade — a Debian server, no longer receiving updates, running a LAMP stack that had been obsolete for years. No access to the original setup. No time to understand it properly. The only priority was getting it back up.

That's where this started.

What I was looking at

A system doesn't have to be old to become unmaintainable. Five to seven years of incremental pressure is enough.

The system was 5 to 7 years old, but the infrastructure underneath it was older. When you run something on a server for long enough without revisiting it, the server becomes part of the system — not explicitly, but in practice. Things depend on the exact PHP version, the exact MySQL version, the exact way that particular Debian release handled file permissions. Nobody documented any of it because nobody needed to. It worked.

Until it didn't.

The codebase itself was mixed. Some parts had structure — someone had clearly tried to impose order at some point. Around those parts, other things had grown organically: patches, workarounds, logic that existed because of a constraint that no longer applied. The kind of code that's perfectly explicable if you were there when it was written, and completely opaque if you weren't.

Adding a feature meant touching things you weren't sure about. Changing one module broke another. The system worked, but it had become fragile in a way that wasn't visible until something forced you to look.

What we actually did

The breach removed every argument against changing the infrastructure. Nobody could say "not now" anymore.

With the site offline, the immediate goal was obvious: get it back up. Not rewrite it — restore it. Continuity first.

But the breach also opened a door that had been closed. The second decision — taken at the same time, not later — was to migrate everything to Kubernetes. Not to modernize the application code immediately, but to get control of the infrastructure. The existing LAMP stack, obsolete versions and all, would be containerized and run on k8s. From there, new modules could be introduced gradually, sitting alongside the old system, routed through ingress rules, replacing behaviour piece by piece.

That's the Strangler Fig pattern. You don't kill the old system. You build the new one around it, redirect traffic module by module, and remove the old pieces when they're no longer needed. The fig grows around the tree.

The sequence

The order wasn't arbitrary.

Once the site was stable again, the work followed a specific order:

Performance — the components with direct user exposure. There's no point modernizing the backend if the frontend is slow.
Subscriptions and payments — migrating to Stripe, cleaning up a part of the business that had become technically fragile and commercially important.
Authentication — moving to OIDC and OAuth 2.0. Not urgent on its own, but without it, any future integration would be harder than it needed to be.
Everything else — the remaining modules, refactored into the new architecture as capacity and priority allowed. Each step could be shipped independently. Each one made the next one less complicated.

What the new code looks like

The decision was made once, at the beginning, and applied consistently. Introducing patterns gradually and inconsistently produces a different kind of mess.

Everything written after the decision to modernize runs on PHP 8.x, follows Domain-Driven Design principles, and is structured around a hexagonal architecture.

DDD has a cost. You have to understand the domain before you model it. You can't just translate old code into new patterns — you have to ask what the system is actually doing, what the real business rules are, where the boundaries between responsibilities should sit. Those conversations take time and they're sometimes uncomfortable.

But the alternative — introducing patterns gradually, inconsistently, module by module — produces a codebase that's modern in some places and legacy in others, with the boundary between them becoming its own source of confusion.

The thing I didn't expect

The technical debt was worse than it looked. It almost always is. Stop trying to understand why things are the way they are. Focus on what they need to do.

I knew the technical debt would be bad. Knowing it and finding it are different things. When you start pulling at a module, you find business logic in SQL queries, assumptions baked into the schema, side effects triggered by things that look like reads.

The system wasn't badly built because nobody cared. It was built under pressure, incrementally, by people solving real problems with the tools and time they had. That's how most systems end up where they are.

Once I accepted that, the approach changed. Instead of trying to understand why things were the way they were, I focused on what they needed to do — modelled that cleanly, and replaced the behaviour one piece at a time.

Where I am now

The system hasn't stopped. That's the point.

Some modules are fully on the new architecture. Others are still the original code, containerized but otherwise untouched, waiting their turn. New development happens almost entirely in the new structure.

It's not finished. I'm not sure when it will be.

If I were starting today, I'd do the same things in the same order. The one thing I'd add earlier is a testing baseline — not full coverage, just enough signal to know when something breaks that shouldn't. Without it, you rely on intuition more than is comfortable.

Why I wrote this

I looked for articles like this when I was in the middle of it. What I found was mostly theory — patterns described without context, case studies from companies with six months of runway and a dedicated platform team.

This started with a site that was offline and a server I couldn't get into. Every decision here came from that situation, not from an ideal setup.

If you're dealing with something similar — a system that works but has become the kind of thing nobody wants to touch — I hope some of this is useful. If you want to compare notes, my LinkedIn is in the profile.

I write about software architecture and PHP.