Next.js Is Just Fancy PHP for People Who Fear Simplicity
How We Rebranded MVC, Reinvented Routing, and Declared It a Revolution Every few years, we reinvent the web. Or at least, we like to think we do. Next.js is often praised as the "future of web development." It promises performance, scalability, and developer experience. But beneath the surface, it’s not revolutionary. It’s PHP — in a React costume — running on Node.js. And somehow, we all pretend it’s something new. The MVC We’ve Seen Before (and Denied) Model. View. Controller. We’ve seen this pattern before. Praised it. Then discarded it as “legacy.” But here we are again, rebuilding the same house with newer bricks: Model: Prisma, Drizzle, or your ORM of choice. View: React components. Fancy templates. Controller: getServerSideProps, middleware, server actions. In essence, it’s the same pattern PHP developers used in the early 2000s. Laravel did it better. Ruby on Rails made it elegant. Now we’re back to it — but with useEffect and cache invalidation hell. The structure never changed. Only the syntax, tooling, and branding did. Routing Isn’t Innovation — It’s Nostalgia Next.js’s file-based routing is praised for its “DX.” But PHP had this in the early 2000s. Laravel, CodeIgniter, and even plain index.php could handle this elegantly. What’s new? React-style folder naming. That’s it. It’s not innovation. It’s the past, wearing a hoodie. Good UX ≠ New Architecture People confuse user experience with actual technical evolution. Sure, Next.js provides great UX — but so did server-rendered apps in PHP, Rails, and Django. They rendered fast. They were easy to debug. They didn’t need a flight manifest, suspense boundaries, or streaming strategies. We’ve taken what was simple and abstracted it into complexity — and then called that complexity “modern.” Streaming, RSC, server/client boundary management, React compiler pipelines. All to serve HTML. Like PHP did. The Cult of Modern and the Fear of Legacy We fear being outdated. So we run from anything labeled “legacy.” PHP didn’t die because it was bad. It died because it wasn’t fashionable. Next.js is fashionable PHP. With TypeScript and an aggressive marketing team. When Vercel demos a fullstack app in 30 minutes, it’s not because of technical revolution — it’s because they’ve rebranded the past and made it slick. What you’re seeing is the same MVC structure with a modern DX wrapper. And that wrapper? It’s built on years of overcomplicated abstraction, often requiring senior-level devs just to achieve what junior devs did in 2005. Honest Web, Not Reinvented Web Let’s stop pretending every abstraction is progress. Let’s stop worshipping complexity for its own sake. Next.js is powerful, yes. But it’s not new. It’s not futuristic. It’s not revolutionary. It’s just PHP, with better branding and more GitHub stars. And maybe that’s okay — if we can just be honest about it. I also shared this on X (Twitter)

How We Rebranded MVC, Reinvented Routing, and Declared It a Revolution
Every few years, we reinvent the web. Or at least, we like to think we do.
Next.js is often praised as the "future of web development." It promises performance, scalability, and developer experience. But beneath the surface, it’s not revolutionary. It’s PHP — in a React costume — running on Node.js.
And somehow, we all pretend it’s something new.
The MVC We’ve Seen Before (and Denied)
Model. View. Controller.
We’ve seen this pattern before. Praised it. Then discarded it as “legacy.” But here we are again, rebuilding the same house with newer bricks:
- Model: Prisma, Drizzle, or your ORM of choice.
- View: React components. Fancy templates.
- Controller: getServerSideProps, middleware, server actions.
In essence, it’s the same pattern PHP developers used in the early 2000s. Laravel did it better. Ruby on Rails made it elegant. Now we’re back to it — but with useEffect
and cache invalidation hell.
The structure never changed. Only the syntax, tooling, and branding did.
Routing Isn’t Innovation — It’s Nostalgia
Next.js’s file-based routing is praised for its “DX.” But PHP had this in the early 2000s. Laravel, CodeIgniter, and even plain index.php
could handle this elegantly.
What’s new? React-style folder naming. That’s it.
It’s not innovation. It’s the past, wearing a hoodie.
Good UX ≠ New Architecture
People confuse user experience with actual technical evolution.
Sure, Next.js provides great UX — but so did server-rendered apps in PHP, Rails, and Django. They rendered fast. They were easy to debug. They didn’t need a flight manifest, suspense boundaries, or streaming strategies.
We’ve taken what was simple and abstracted it into complexity — and then called that complexity “modern.”
Streaming, RSC, server/client boundary management, React compiler pipelines. All to serve HTML. Like PHP did.
The Cult of Modern and the Fear of Legacy
We fear being outdated. So we run from anything labeled “legacy.”
PHP didn’t die because it was bad. It died because it wasn’t fashionable.
Next.js is fashionable PHP. With TypeScript and an aggressive marketing team.
When Vercel demos a fullstack app in 30 minutes, it’s not because of technical revolution — it’s because they’ve rebranded the past and made it slick.
What you’re seeing is the same MVC structure with a modern DX wrapper.
And that wrapper? It’s built on years of overcomplicated abstraction, often requiring senior-level devs just to achieve what junior devs did in 2005.
Honest Web, Not Reinvented Web
Let’s stop pretending every abstraction is progress. Let’s stop worshipping complexity for its own sake.
Next.js is powerful, yes. But it’s not new. It’s not futuristic. It’s not revolutionary.
It’s just PHP, with better branding and more GitHub stars.
And maybe that’s okay — if we can just be honest about it.
I also shared this on X (Twitter)