Back When PHP Was a "Revolutionary"

I’ve been touching some PHP code recently, and a thought hit me:

“Ah, PHP has fully become a ‘veteran language.’”

To today’s younger engineers, PHP probably looks like a “normal web development language” — one that has always had Laravel, always had Composer, where you properly write classes, do dependency injection, and so on.

But when I first encountered PHP, the impression was very different.

Back then, Java was king.

Enterprise JavaBeans, WAR files, application servers — heavy, large, formal. It was diligent and robust, and it suited large-scale development.

But honestly, from a developer’s perspective, it was heavy.

And then PHP showed up.

I still remember the shock of seeing it for the first time.

You just place a .php file on the server, and it runs.

That’s literally it.

“Wait, what about compilation?” “What about the deployment step?” “What about the config file?”

That was the feeling.

In today’s terms, it had the casualness and lightness of “I wrote a little code into some HTML and it became a web app.”

But that casualness was a revolution.

The chaos of early PHP

Of course, early PHP was pretty bad.

I can laugh about it now, but it really was chaos.

Function naming had zero consistency.

Underscores sometimes present, sometimes not.

Argument order all over the place.

Global variables flying around.

Plenty of security incidents.

And above all — “even sloppy code somehow worked.”

For beginners, this was the best thing ever. For the poor soul maintaining it three years later, it was hell.

Honestly, a PHP project from that era would often turn out to be one giant file with HTML, SQL, and business logic all mashed together.

Code that today would get blocked at a junior code review was happily running in production.

But that “works even when sloppy” strength is what blew the Web wide open.

WordPress was PHP. Facebook was PHP.

Engineers kept saying “PHP is garbage,” and yet in the real world, PHP was ruling the Web.

That period taught me something important: technically beautiful things don’t always win.

PHP grew up

After that, PHP gradually became “proper.”

Namespaces arrived. Types arrived. Composer arrived. Powerful frameworks like Laravel showed up.

For someone who knew old PHP, it was genuinely surprising.

“Wait, you can write this clean of code in PHP now?”

But around that time, a small sense of unease also started creeping in.

DI. Service containers. ORMs. Event-driven architecture. Complex directory structures.

Before I knew it:

“Hold on — how is this different from Java?”

That was the feeling.

Laravel is well-built, no question. Productivity is genuinely high.

But the “wild, handy little tool” feeling that old PHP had is gone.

The vibe of placing one file on a server and smirking at it doesn’t exist anymore.

PHP today is infrastructure

I personally spent a long chunk of my career with PHP.

I’m pretty sure PHP is the language I’ve written the most code in, in my entire life.

I stepped on tons of bugs, handled late-night production incidents, and fought with incomprehensible legacy code.

So there’s affection.

But if you ask me “Are you excited about modern PHP?” — honestly, not really.

Today’s PHP, in a sense, has reached the same position as Java or COBOL.

That is:

“A massive existing asset that supports society.”

It’s no longer the revolutionary.

It’s on the infrastructure side.

The side that supports banks, government systems, giant services — the things that cannot be stopped.

So I think demand for PHP engineers will continue normally going forward.

It may get less hype as a “new technology,” but as “the people who keep reality running,” it will be needed for a long time.

Old PHP projects still exist in huge numbers. And unless someone keeps fixing them, society stops.

The revolutionary became the establishment

The revolutionary that once tore through the Web world has, before anyone noticed, become a senior figure in the mainstream.

Feels strangely human.

Maybe I’ve just gotten older too.