PHP has a bit of a reputation problem. It's been on the end of some developers' jokes for a couple decades — and honestly, some of that reputation was earned. The early days were rough at times. Bad tutorials, sloppy patterns, and security holes you could drive a truck through.
That was a long time ago.
I've been writing high quality PHP since 2003. I've also more recently shipped projects in React and Node.js. When I sit down to build a custom business application — a complex website, a native app, a database front end, a CMS, an API integration — I still reach for PHP more often than anything else. Not out of habit. Out of experience.
PHP 8 is a genuinely modern language
PHP 8.x added union types, named arguments, match expressions, readonly properties, and a lot more. The language has evolved more in the last few years than in the decade before that. It's fast, well-supported, and actively maintained. The "PHP is a toy" conversation ended years ago — some people just didn't get the memo.
More importantly, PHP 8 with OPcache is genuinely fast. Not "good enough" fast — actually fast. The benchmarks that show other languages winning in raw throughput are measuring scenarios that almost never apply to a custom business application. If your app is bottlenecked by PHP's execution speed, congratulations — you actually have a scale problem that most businesses would love to have.
The real bottleneck is almost never the language
In 20+ years of building and optimizing applications, the performance issue is almost never the language. It's an unindexed database query, an N+1 problem, a missing cache layer. Fix the query and the page that took four seconds loads in under a hundred milliseconds — regardless of what language is running it.
Choosing a "faster" language to solve a database problem is like adding another lane to a road in order to make a car faster. The car that's built is still the car that's built.
The hidden cost of the trendy stack
Every framework has a lifecycle. Perhaps you remember when everyone was building everything in Ruby on Rails? Meteor? The graveyard of "modern" stacks is long, and every entry represents a real application that someone eventually had to rewrite.
There's also a hiring and maintenance risk that small businesses rarely think about. If I build something and I'm not available down the road for whatever reason, finding someone to step in matters. The PHP developer pool is enormous. That's not a weakness — it's a feature.
When I'd reach for something else
Here's where I'll be honest, because that matters: PHP isn't always the right tool.
Real-time features — live chat, collaborative editing, push notifications — are genuinely better handled by a stack built around persistent connections. A public-facing API with extreme throughput requirements might call for something else entirely. If the project calls for it, I'll use the right tool.
But for the work I do most — complex business applications, custom CMSs, database-driven tools, API integrations — PHP fits the problem. It's mature, fast, supported everywhere, and I know it deeply after 20+ years of building real things with it.
Choosing a technology because it's exciting is how you end up rewriting a working application every few years. Choosing it because it fits the problem is how you build things that last.
