Don't Marry Next.js: My Warning from the Trenches

Choosing the right development stack is a thoughtful decision. While selecting the right stack might not offer immediate, tangible benefits, picking the wrong one can lead to significant challenges. I learned this the hard way, and my advice is clear: don't marry Next.js.

My initial foray into Next.js, a proof of concept, failed miserably. Though I had some React experience, I was still searching for the ideal frontend framework. I explored Svelte, but was put off by .svelte file extensions, the need to explicitly declare lang="ts" in every TypeScript block, and the co-mingling of TS and HTML in the same file. The ongoing transition from Svelte 4 to 5, with significant changes and deprecations on the horizon, also contributed to my decision to eliminate it as a contender – a decision I now regret.

Pure React, however, wouldn't meet my needs. I disliked the idea of client-side fetching for backend APIs, especially since using JWTs in such a scenario isn't advised. Indeed, implementing a server-side solution from scratch felt like a significant time and effort investment. I also explored Angular and found it impressive, but noted fewer frontend component options compared to React. As someone who lacks web design talent, this was a substantial consideration.

The overwhelming hype around Next.js eventually convinced me to give it a try. Next.js 13, with its newly released App Router, seemed like the cutting edge. I could end the story here, but reality had other plans.

The Cookie Conundrum

Dealing with cookies proved to be a significant headache. Some requests couldn't even read cookies, despite my understanding that they needed to be set server-side. After countless hours debugging and searching for solutions to client-side requests failing to access cookies, I hit a wall. It was my first major disappointment. I reset the application, deleting the .next and node_modules directories. I scoured the documentation and the web for a solution, quickly realizing many other developers were grappling with the same unpredictable behavior. The solution? I wish I knew: the next day, it simply worked like a charm.

A few days later, I found myself replacing Next.js's native fetch API with Axios. The API's caching mechanism began to exhibit strange behavior. I can assure you, caching has a personality of its own. Even when seemingly inactive, it delivered unwanted results for requests that never even reached the backend API. Axios eventually solved that problem and allowed me to create an interceptor for JWT token rotation, but then… I started struggling with cookies again.

At this point, the only workaround I found was to create a POST method within the Next.js application (which otherwise had no endpoints) solely to store JWT tokens. This forced me to implement an API key and restrict service access exclusively to the Next.js application. Ugly.

Why Am I Still Using This?

After fighting Next.js for so long – grappling with its poor and obscure documentation, abandoning its native solutions, and adopting alternatives – a stark realization hit me: Why am I still using this?

The final straw, however, relates to what I've come to call the 'Vercel jail.' While Next.js promises to solve all your problems, Vercel conveniently omits that, today, there are barely two services that genuinely support Next.js hosting. One, of course, is Vercel itself. Posts like this one from Eduardo Bouças and this from Northflank highlight these issues. A quick search reveals a growing list of recent complaints about Next.js. One particularly egregious common complaint concerns a security vulnerability: Vercel reportedly concealed it from the public, providing a solution only for their 'beloved clients' before eventually revealing it days later.

What's Next?

I haven't yet decided on my next steps. I've already invested too much into existing artifacts to simply discard them. While I'm currently tied to React, several options are now in my sights. Specifically, I'm considering migrating my codebase to Remix or Tanstack Start. Remix is a more mature option, while Tanstack Start is a newer, promising framework backed by a reputable team. I find myself at the crossroads between maturity and modernity.

While I haven't made a decision, I'm certainly open to suggestions. What are your thoughts on these Next.js experiences? What do you believe would be the best replacement? Share your comments below!

Originally posted in my blog