Tagged “nextjs”

1. Life after Next.js: A New and Sunny Start

   felipestanzani@blog ~ ~ cat "Life after Next.js: A New an"~ cat post << 06-20-2025

   

   A few weeks ago, I posted about my decision to move away from Next.js and the reasons behind that choice. Since projects can't just halt, I couldn't dwell too long on my decision. I had to consider several requirements for my new stack, including:

   • Using React as the frontend library.
   • Support for Server-Side Rendering (SSR).
   • Server-side functions.
   • Middleware support.
   • Enough flexibility to integrate libraries like React-Hook-Form and Axios.
   • A caching mechanism independent of the REST library.

   Initially, I was torn between Remix and TanStack Start. However, Remix lacks middleware support, which would necessitate significant architectural changes and a less ideal way to manage route access. Furthermore, in recent weeks, the Remix project announced a substantial shift in direction for its V3 version. While this new direction appears very promising, it would eventually mean I'd have to rewrite everything again, and that's definitely not something I want.

   TanStack Start, on the other hand, is currently in beta. Yet, it meets all my project's requirements and is built on Vite, making the project far more flexible and independent. Beyond what I've already outlined, the TanStack libraries have an excellent reputation, and this point deserves a small digression:

   Utah probably isn't the first place you'd pick to catch a tan, but if your name is Tanner and you have a good sense of humor, you might just call your TypeScript library stack "TanStack." This textual detour is about him: Tanner Linsley is a programmer renowned for his profound commitment to the open-source community, developer experience, and type safety. TanStack libraries are used by hundreds of thousands of developers and adopted by everyone from startups to Fortune 500 giants. This alone lends significant credibility to TanStack Start, which, at least for me, weighs heavily in my decision for a long-term project.

   Getting back on track, despite its beta status, the development team is now focused on stabilizing the framework rather than building new features, so no breaking changes are expected anymore.

   Still, you might argue that adopting a beta framework for my project carries a high risk, and I agree. However, there are other valid points to consider for my project's current stage. As I've already explained, including in the previous post, going with a no-framework approach would demand a massive effort. Staying with Next.js under Vercel's grip was out of the question. This left me with Remix, which I've already discarded, and TanStack Start, which was my choice. And here's the unexpected upside for me: working with a beta framework also has its advantages.

   As soon as I ran into the first development hurdles, I was directed to the TanStack Discord server. There, numerous developers exchange information and answer questions about the libraries. The project's own developers actively respond to queries, report bugs, ask for new issues to be opened, etc. Even Jack Herrington is there, participating actively!

   Continue reading...

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

   felipestanzani@blog ~ ~ cat "Don't Marry Next.js: My Warn"~ cat post << 05-27-2025

   

   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?

   Continue reading...

See all tags .