I’ve been using Next.js for a long time. Long enough to have shipped real products with it, migrated between major versions, rewritten parts that were “best practice” just a year earlier, and defended it in arguments like it was part of my identity.
Years ago, I remember calling a former classmate back in Kazakhstan. I asked him what he was working on. He said it was some large corporate project built on Java Spring Boot.
I laughed.
I literally said something like: “Bro, that’s ancient. That’s boring. Why would you build anything new on that? Why not Next.js?”
At the time, it felt obvious. Spring Boot sounded slow, verbose, old-fashioned. Next.js felt modern, fast, elegant. Everyone online was building with it. The ecosystem was exploding. The DX was addictive.
But over the years, after building, breaking, migrating, and maintaining real systems, that memory started to bother me.
Not because Spring Boot suddenly became cool. But because I slowly understood why those companies chose it.
After enough back-and-forth, enough upgrades, enough rewrites that weren’t supposed to be rewrites, something clicked:
They weren’t optimizing for excitement. They were optimizing for survival.
That’s when I realized something uncomfortable: I wasn’t laughing because Spring Boot was bad. I was laughing because I didn’t yet understand what “long term” actually means in software.
This article isn’t written by someone who hates Next.js. It’s written by someone who used it, trusted it, and then zoomed out far enough to see the trade-offs clearly.
I share this sentiments and complaints about NextJS and Vercel. I would add they prioritize designing everything for their edge paradigms, so if you don't use their products or preferred architecture, it becomes that much harder to do things.
I'm on TanStack now, very happy with the decision after more than a year.
I’ve been using Next.js for a long time. Long enough to have shipped real products with it, migrated between major versions, rewritten parts that were “best practice” just a year earlier, and defended it in arguments like it was part of my identity.
Years ago, I remember calling a former classmate back in Kazakhstan. I asked him what he was working on. He said it was some large corporate project built on Java Spring Boot.
I laughed.
I literally said something like: “Bro, that’s ancient. That’s boring. Why would you build anything new on that? Why not Next.js?”
At the time, it felt obvious. Spring Boot sounded slow, verbose, old-fashioned. Next.js felt modern, fast, elegant. Everyone online was building with it. The ecosystem was exploding. The DX was addictive.
But over the years, after building, breaking, migrating, and maintaining real systems, that memory started to bother me.
Not because Spring Boot suddenly became cool. But because I slowly understood why those companies chose it.
After enough back-and-forth, enough upgrades, enough rewrites that weren’t supposed to be rewrites, something clicked:
They weren’t optimizing for excitement. They were optimizing for survival.
That’s when I realized something uncomfortable: I wasn’t laughing because Spring Boot was bad. I was laughing because I didn’t yet understand what “long term” actually means in software.
This article isn’t written by someone who hates Next.js. It’s written by someone who used it, trusted it, and then zoomed out far enough to see the trade-offs clearly.
And once you see them, you can’t unsee them.
You don't need to copy-paste the first section as a comment, it's generally frowned upon
I share this sentiments and complaints about NextJS and Vercel. I would add they prioritize designing everything for their edge paradigms, so if you don't use their products or preferred architecture, it becomes that much harder to do things.
I'm on TanStack now, very happy with the decision after more than a year.