PHP Isn’t Dead – It Just Stopped Caring About Being Cool

“PHP is dead,” this React developer announced at the coffee shop yesterday morning. He was working on his MacBook with about thirty Chrome tabs open, probably burning through his battery faster than his startup was burning through their Series A. I was trying to fix a bug in a WordPress plugin for some dentist office – glamorous stuff, I know.

Thing is, his React app probably crashed twice while we were talking. Mine’s been running the same code for three years.

But whatever. Let me tell you about last Tuesday.

I got this frantic Slack message from a CTO at some fintech startup. Their entire payment system was down. Again. Third time that month.

See, they’d built this beautiful microservices architecture. Node.js everywhere, GraphQL endpoints, serverless functions, the whole Silicon Valley starter pack. Looked incredible in their pitch deck. Problem was, it worked about as reliably as BART on a rainy day.

“I haven’t slept in 72 hours,” he told me on our video call. It was 2:30 AM his time, which should tell you something about the state of their infrastructure. Behind him I could see energy drink cans stacked like a small fortress around his monitor.

That’s when I mentioned PHP.

I know, I know. Suggesting PHP to a modern startup is like showing up to a Tesla meetup in a Honda Civic. But hear me out.

The thing about boring solutions

This team – all brilliant engineers, don’t get me wrong – had spent eight months building their payment processing system. Eight months! The JavaScript version still couldn’t handle more than fifty concurrent users without choking.

We rewrote the core functionality in PHP in… I want to say six weeks? Maybe seven. Hard to remember exactly because it was just so straightforward. Laravel, MySQL, Redis for caching. Nothing fancy. Definitely nothing you’d put in a Medium article about “revolutionary architecture.”

But it worked. Handled their Black Friday traffic without breaking a sweat. Their server costs dropped to like a third of what they were before. The CTO started showing up to our calls looking like he’d actually slept.

“Why didn’t anyone tell me about this earlier?” he asked me sometime in December. Good question. Maybe because admitting you use PHP at a tech meetup is like admitting you drive a minivan. Practical, but not exactly Instagram-worthy.

Actually, let me tell you about minivans for a second. My neighbor bought one last year. Thing is objectively ugly. Looks like a refrigerator on wheels. But you know what? It fits three car seats, a stroller, a week’s worth of groceries, and a golden retriever. When you actually need to get stuff done, ugly starts looking pretty smart.

That’s basically PHP in 2024.

Laravel changed everything (and nobody talks about it)

I remember when Laravel first came out. This was… 2011? 2012? I was working at this agency that specialized in WordPress sites for yoga studios. Exciting stuff. Taylor Otwell releases this new framework, and suddenly PHP development didn’t suck anymore.

Not that anyone noticed. Everyone was too busy arguing about whether CoffeeScript was the future of JavaScript. Remember CoffeeScript? Exactly.

But Laravel was different. Clean syntax, actual documentation that made sense, database migrations that worked. Revolutionary? No. It just took all the good ideas from Rails and Django and made them work in PHP.

I showed it to this Django developer once. She spent about an hour going through the docs, then built a working admin interface for her side project in an afternoon.

“This is… actually pleasant,” she said. Coming from someone who wrote Python for a living, that was basically a marriage proposal.

The funny thing about Laravel is it succeeded by being boring. No grand philosophical statements about web development. No manifestos about the right way to structure applications. Just solid conventions and tools that got out of your way.

Compare that to the JavaScript world, where apparently we need a new framework every six months to solve problems the previous framework created.

When I actually need custom development

Let me tell you about this project I worked on for a logistics company. They needed to integrate with seventeen different shipping APIs. Each one had its own authentication scheme, rate limits, error codes that meant different things depending on the phase of the moon.

The CEO wanted to use some shipping-as-a-service platform. Made sense in theory. Pay monthly, get all integrations handled for you. Problem was the monthly cost would’ve been something like $8,000, and they’d still need custom development for their specific workflow requirements.

We built them a custom PHP system instead. Took about three months, cost less than six months of the SaaS subscription. Does exactly what they need, nothing more, nothing less. Handles their peak holiday shipping volume without choking.

That’s what I love about custom PHP development. You’re not fighting against someone else’s assumptions about how your business should operate. You just build the thing that solves the problem.

Though I’ll be honest, explaining this to other developers is exhausting sometimes. “But what about scalability?” they ask. This company ships about 50,000 packages a month. Their “scalability” problem is hiring more warehouse workers, not optimizing database queries.

The performance thing that nobody talks about

JavaScript developers are obsessed with performance. Bundle sizes, render times, lighthouse scores. They’ll spend weeks optimizing their webpack configuration to shave 50ms off their page load time.

Meanwhile, their API endpoints are taking 800ms to return basic user data because they’re doing database joins in application code.

I inherited this Node.js project last year from a team that had been storing relational data in MongoDB and then doing the relationships in JavaScript. Every query was a nightmare of nested callbacks and in-memory filtering.

Migrated the whole thing to MySQL with proper foreign keys and Eloquent relationships. Response times went from 800ms to about 45ms. Amazing what happens when you let the database do database things.

But try explaining that at a JavaScript meetup. They’ll look at you like you suggested using Internet Explorer.

PHP never tried to be cool

Maybe that’s why it works so well. While JavaScript was busy reinventing itself every few months, PHP just kept solving problems. Not exciting problems, just the boring ones that actually make businesses money.

Forms over databases with some business logic in between. File uploads that don’t mysteriously fail. User authentication that works reliably. Email sending that doesn’t require a PhD in async programming.

I was at this conference last year – PHP[world], which is exactly as exciting as it sounds. The talks weren’t about revolutionary new paradigms or disruptive technologies. They were about things like “Optimizing Composer Performance” and “Database Migration Strategies.”

Boring stuff. But you know what? The companies represented there were actually profitable. Making real money from real customers. Not burning through VC funding while figuring out their business model.

There’s something to be said for that.

The framework wars ended (Laravel won)

Remember CodeIgniter? CakePHP? Zend Framework? Those were the days. Everyone had strong opinions about MVC purity and naming conventions. Forum threads would turn into philosophical debates about the nature of web development itself.

Laravel basically ended all that noise. Not by being perfect, but by being good enough for most things while staying out of your way for weird edge cases.

A colleague from an old WordPress agency put it perfectly: “Laravel optimized for developer happiness instead of architectural purity.”

That’s exactly right. The conventions make sense. The documentation doesn’t require a computer science degree. You can build a basic CRUD app in an afternoon, or architect something complex with proper queue management and event sourcing.

Same codebase, same mental model, same deployment process.

Oh, and speaking of deployment – when’s the last time you deployed a PHP app and had it break because of dependency conflicts? Composer just works. Semantic versioning actually means something. Your app that worked yesterday will work today.

Revolutionary concept, apparently.

Database relationships (remember those?)

Modern JavaScript developers seem to have forgotten that databases are good at being databases. Everything’s a JSON document, everything needs to be NoSQL, everything has to be “web scale” from day one.

Meanwhile, I’m over here using foreign keys and indexes like some kind of dinosaur.

That fintech project I mentioned? Their original Node.js setup was storing user data in MongoDB, financial transactions in PostgreSQL, and session data in Redis. Three different databases for what should have been a straightforward relational schema.

We moved everything to MySQL with proper relationships. Suddenly their data integrity problems disappeared. Query performance improved by an order of magnitude. The codebase got smaller and easier to understand.

But sure, let’s keep pretending that ACID compliance is just for old people.

The enterprise secret

Want to know something nobody talks about at tech conferences? Enterprise companies never stopped using PHP. They just stopped tweeting about it.

Banks run PHP. Insurance companies run PHP. Government agencies run PHP. They use it because it works, because it’s predictable, and because they can hire developers who understand it without offering $200k starting salaries to fresh bootcamp graduates.

I do consulting work for these types of organizations pretty regularly. The pattern is always the same. Some enthusiastic architect convinces management to “modernize” their stack. Six months later, they’re dealing with deployment complexity they didn’t expect, performance problems they can’t debug, and developers who are burned out from fighting their tools instead of solving business problems.

Another six months after that, they quietly migrate back to something boring and reliable. Usually PHP, sometimes Java if they’re feeling fancy.

When not to use PHP

Look, I’m not saying PHP is perfect for everything. Real-time applications? You probably want Node.js or Go. Machine learning? Python’s ecosystem is unmatched. iOS apps? Well, you’re probably going to need Swift.

But for the vast majority of web applications – the ones that are basically forms over databases with some business logic sprinkled in – PHP is fantastic. Especially when you need something built quickly, maintained easily, and scaled predictably.

The trick is recognizing when you’re building that 80% case versus when you actually need the complexity that modern JavaScript architectures provide.

Most of the time, you don’t.

Composer actually works

This probably sounds stupid, but one of PHP’s biggest wins is that dependency management isn’t a nightmare. Composer does what it says it’s going to do. Package versions mean something. Breaking changes happen in major releases, not patch updates.

I was helping this React team debug an issue last month where their image upload suddenly stopped working. Took them three days to figure out that one of their dependencies had pushed a breaking change in what was supposed to be a patch release. Three days of lost productivity because someone upstream decided to refactor their API without bumping the major version.

That just doesn’t happen in PHP land. Maybe because the community learned these lessons the hard way, back when PEAR was a thing and dependency management was basically manual labor.

Or maybe because PHP developers are just more boring and conservative about these things. Either way, my apps keep working.

The boring future

PHP 8.4 came out last November and brought some nice features – property hooks, asymmetric visibility, a bunch of performance improvements. The migration path was straightforward, as expected. My existing applications mostly just worked with minimal changes.

No ecosystem-shattering changes. No fundamental paradigm shifts. No religious wars about the right way to handle component state.

Just steady, predictable improvement.

In a world where JavaScript frameworks have shorter lifespans than Hollywood marriages, that’s actually pretty appealing.

Someone at a recent conference put it best: “PHP is like a Honda Accord. Nobody gets excited about it, but it’ll start every morning for the next 200,000 miles.”

I can live with that. Sometimes boring is exactly what you want.