DEV Community

Yuki Nishikawa
Yuki Nishikawa

Posted on • Edited on

6 2 2 2 2

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)

Neon image

Next.js applications: Set up a Neon project in seconds

If you're starting a new project, Neon has got your databases covered. No credit cards. No trials. No getting in your way.

Get started →

Top comments (15)

Collapse
 
xwero profile image
david duymelinck • Edited

I would say it is a bit more convoluted than any backend framework, not just PHP.
The reason I think that is because Nextjs is a framework with heavy frontend roots.
The biggest difference between frontend and backend is that frontend has a visual focus. And backend is a connector between the storage of data and the frontend, whatever that frontend might be.

Another negative point is that is a single frontend framework. That is why Nuxt and Sveltekit exist.
Other javascript backend frameworks like Nest and Astro allow you to pick the frontend framework.

The biggest selling point of javascript on the server is a single language codebase. And that also makes it possible to use functions in the backend and frontend.

The reason I keep using "traditional" backend languages is that they are more robust and fit for the task than javascript.

Collapse
 
structax profile image
Yuki Nishikawa • Edited

Ah, that makes a lot of sense now — especially knowing you've been writing about PHP.

Honestly, I think we're on the same page: both PHP (and other classic backend stacks) and Next.js are trying to solve the same problems — just through very different cultural and tooling lenses.

Where I think it gets tricky is that modern frontend frameworks often try to subsume the backend — but without the maturity that backend ecosystems (like PHP’s or Rails') have built over decades.

In that sense, Next.js isn’t just “like PHP” structurally — it's like PHP in its early, chaotic days, but rebranded through React.

So yes — we may disagree on nuance, but I think we're both reacting to the same deeper truth: simplicity and robustness are being sacrificed for DX theater.

Would love to read more of your PHP pieces, btw. Got a link to one you'd recommend?

Collapse
 
xwero profile image
david duymelinck • Edited

I would not say Nextjs is as chaotic as early PHP. The javascript frameworks learned from the backend frameworks.

The biggest problem in the javascript community as I see it, is that most people live on their framework of choice island. Which gave us Next and Nuxt solutions, while Nest and Astro are more in tune with the common backend structure.

I'm not sure what to recommend, with my content I want to explore things that are less known or ideas I have and experiment with. Just pick something you like when you read the title.

Thread Thread
 
structax profile image
Yuki Nishikawa

Really appreciate your thoughtful take — and I totally agree that JS frameworks often drift into isolated paradigms.

That’s actually what inspired me to start working on something called Type.ts — a framework not based on freedom of expression, but on enforced correctness.

It’s not about flexibility. It’s about writing the only correct code, every time.

Here’s the core idea:

Type.ts isn’t a framework of freedom.

It’s a culture of correct structure — enforced through syntax, routing, CI, and thought.

  • One route = one file (user.post.ts = POST /user)
  • defineAPI() guarantees exact structure, types, and execution
  • Rust-style safe error handling (safe(), defineError())
  • CLI commands like type dev, type check enforce the philosophy
  • Even default export and let are forbidden — by design

It’s not just a tool. It’s a belief system embedded in code.

I’m experimenting with this not to compete, but to explore what happens when we make the structure the culture. type.ts github

Thread Thread
 
structax profile image
Yuki Nishikawa

Thank you so much for taking the time to respond so thoughtfully.

Your comment didn’t just challenge my perspective — it helped me grow.

You reminded me that real innovation isn’t just about critique, but about conversation, reflection, and curiosity.

It’s easy to fall into the trap of “provocative takes,” but your insight pulled me back into the kind of dialogue that actually moves us forward as developers.

Deeply grateful for that.

Collapse
 
structax profile image
Yuki Nishikawa

Hey everyone,

I know this post might sound controversial, especially for folks who love Next.js (I actually like it too).

But I couldn't help noticing how much of what we call “modern web architecture” today mirrors patterns from 15+ years ago — PHP, MVC, file-based routing, server-rendered pages... and somehow, we pretend it’s all brand new.

I wrote this not to bash Next.js, but to invite a conversation about how we define innovation, and whether we’ve maybe started to rebrand familiarity as progress.

Curious to hear your thoughts — especially from those who’ve lived through both eras.

Collapse
 
structax profile image
Yuki Nishikawa

Thinking about php and nextjs is thinking about the future of full-stack engineering

Collapse
 
devbyj profile image
DevByJ

Hi Structax!

First of all, your article summarizes the topic very well and hits the nail on the head.

In this context, I remembered the article Radical Simplicity in Technology (perhaps you already know it). It makes you aware once again (also visually) of how the complexity of web applications has increased over the years.

Collapse
 
structax profile image
Yuki Nishikawa

Thank you — truly — for this thoughtful reflection.

Yes, Radical Simplicity in Technology is a piece I’m familiar with, and it echoes something I find both unsettling and quietly profound:
that as we accumulate tools, abstractions, and paradigms, we often drift further from clarity — not because we must, but because we can.

There’s a strange comfort in complexity. It gives us the illusion of progress, the aura of modernity. But sometimes, beneath all that scaffolding, we’re simply reconstructing familiar ideas in unfamiliar shapes.

I wonder if what we call “innovation” is often just a more elaborate remembering — and if perhaps, the future of web development lies not in adding more, but in subtracting with intent.

Thank you again for reminding me of that piece. It’s a beautiful lens through which to view this ongoing cycle of reinvention.

Collapse
 
ek_chanthorn profile image
Ek Chanthorn

This is great article

Collapse
 
structax profile image
Yuki Nishikawa

Thanks I like you!

Collapse
 
afjsdkfdfkfds profile image
Roberto

Great!

Collapse
 
structax profile image
Yuki Nishikawa

Thanks!

Some comments may only be visible to logged-in visitors. Sign in to view all comments.