✳flâneur — a map of the web's best reading

One Year with Next.js App Router — Why We're Moving On

paperclover.net · 4,969 words · saved by 1 readers

As I've been using Next.js professionally on my employer's web app, I find the core design of their App Router and React Server Components (RSC) to be extremely frustrating. And it's not small bugs or that the API is confusing, but large disagreements about the fundamental design decisions that Vercel and the React team made when building it. The more webdev events I go to, the more I see people who dislike Next.js, but still get stuck using it. By the end of this article, I will share how me and my colleagues escaped this hell, seamlessly migrating our entire frontend to TanStack Start. The pitch of RSC is that components are put into two categories, "server" components and "client" components. Server components don't have useState, useEffect, but can be async functions and refer to backend tools like directly calling into a database. Client components are the existing model, where there is code on the backend to generate HTML text and frontend code to manage the DOM using window.docu

One Year with Next.js App Router — Why We're Moving On As I’ve been using Next.js professionally on my employer’s web app, I find the core design of their App Router and React Server Components (RSC) to be extremely frustrating. And it’s not small bugs or that the API is confusing, but large disagreements about the fundamental design decisions that Vercel and the React team made when building it. The more webdev events I go to, the more I see people who dislike Next.js, but still get stuck using it. By the end of this article, I will share how me and my colleagues escaped this hell, seamlessly

Explore this link on the map →

related reading