Next.js Is Just Fancy PHP for People Who Fear Simplicity
Yuki Nishikawa

Yuki Nishikawa @yukinisihikawa

About: 🧠 Indie Dev 🇯🇵 building Bevel.ts. 💡 From idea to app, in one file. 🚀 OSS / MVPs / Builders welcome I am 22-years-old DSL creater.

Location:
Saitama
Joined:
Mar 26, 2025

Next.js Is Just Fancy PHP for People Who Fear Simplicity

Publish Date: Apr 22
15 15

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)

Comments 15 total

  • Yuki Nishikawa
    Yuki NishikawaApr 22, 2025

    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.

    • Yuki Nishikawa
      Yuki NishikawaMay 1, 2025

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

  • david duymelinck
    david duymelinckApr 22, 2025

    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.

    • Yuki Nishikawa
      Yuki NishikawaApr 22, 2025

      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?

      • david duymelinck
        david duymelinckApr 22, 2025

        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.

        • Yuki Nishikawa
          Yuki NishikawaApr 22, 2025

          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

          • Yuki Nishikawa
            Yuki NishikawaApr 22, 2025

            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.

  • safsdgdfg
    safsdgdfgApr 22, 2025

    The GG4 strain, also known as Gorilla Glue #4, is a renowned indica-dominant hybrid cannabis strain celebrated for its potent effects and robust genetics. Originating from a cross between Chem’s Sister, Sour Dubb, and Chocolate Diesel, GG4 boasts a THC content ranging from 24% to 32%, making it a favorite among seasoned cannabis enthusiasts
    .​

    The strain's effects are characterized by a gradual onset of euphoria, leading to deep physical relaxation and a sense of being "glued" to one's seat. This makes GG4 ideal for evening use, particularly for those seeking relief from stress, pain, insomnia, or anxiety

    • Yuki Nishikawa
      Yuki NishikawaApr 22, 2025

      Ah yes — the true architecture killer: GG4.

      With 32% THC, I imagine even App Router starts making sense.

      Thanks for the unexpected pairing!

  • DevByJ
    DevByJApr 23, 2025

    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.

    • Yuki Nishikawa
      Yuki NishikawaApr 23, 2025

      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.

  • Ek Chanthorn
    Ek ChanthornApr 25, 2025

    This is great article

  • Roberto
    RobertoMay 1, 2025

    Great!

Add comment