One year with Next.js App Router and why we're moving on
31 comments
·October 30, 2025PebblesHD
I have yet to reach the limits of doing a Vite create and installing react router myself for the several entirely client side apps we manage. It has sane build defaults and for whatever definition of ‘works’ is possible in JS, ‘just works’. If it becomes too complex for that basic setup it usually means we’ve over-complicated something.
Where we have a need for server side, nodejs just never felt natural for us so we stuck with java springboot or flask/fastapi as appropriate.
383toast
ever since react router got merged with remix to become react router v7, I looked around for simpler version, landed on Wouter which is fine.
culi
I'd love to hear more about what motivated the switch. All the additions to react-router are, afaict, opt-in. React-router has 3 "modes"[0] and the declarative mode seems pretty much exactly what the classic library is like with some extra components/features you don't have to use
Thought I've enjoyed the code-splitting and access to SPA/SSR/SSG/etc strategies that come with the "framework" mode
nozzlegear
I've been using wouter in all of my projects for years after being burned by some react router migration bullshit eons ago.
petralithic
TanStack is the sane option here, whether their router or their start product.
figassis
Around 8y ago, when Angular vs React was still a war worth reading, frameworks were I think in their final state. They gave you basic tools, and you could build applications with them. I felt like framework creators didn’t treat us like babies who needed handholding. Idk if a new generation of younger developers took over, but things started becoming too shiny. Blog posts were no longer about performance, ease of use, same solutions. I couldn’t even understand some post titles. There is just no bandwidth to follow these things anymore. Why is a router a thing that needs to be continually rebuilt and tinkered with. Did we not learn ages ago how routers should work? What innovation are we seeking? Is it just developers treating frameworks like their weekend experiments?
Swizec
> Why is a router a thing that needs to be continually rebuilt and tinkered with. Did we not learn ages ago how routers should work?
Nyes. The biggest innovation in the past 5 years has been routers that can coordinate loading data because they’re perfectly positioned to know what you’re about to access.
This is a hard problem that we’ve been solving forever. It feels like super tedious formulaic work to write an optimized SQL query or series of API requests that fetches all the necessary data with the fewest possible lookups. So we try to automate it with a sufficiently smart compiler of some sort. Query planners inside a database, ORMs, graphql, routers, memory managing compilers, it’s all chasing the same dream – what if the computer Just Knew the quickest way to grab just the right amount of data.
BoorishBears
I've re-read this comment at least 5 times and feel like I'm having a stroke reading it each time. And something similar happens really often when I enter the hype-driven side of React these days..
I do wish I had a more useful critique, and I'm not even trying to be mean (or boorish as it were) but you're rolling so many things up into each other that there's no useful way to interpret the statement. At least, not without ending up giving you a great chance to just say "no no no you completely missed what I'm saying" and then coming up with a new equally dizzying statement.
How you manage to drag query planners into routers into compilers, how are these chasing one dream or fungible or even barely correlated, I don't even know.
-
It's awful and sad how tech is one of the few fields that just insists on making things worse for itself. You can walk into McDonalds and ask how the process can be improved, and I guarantee every suggestion is targeted at making their jobs easier in a way that at least superficially aligns with making the service quicker, which is something the company does care about.
In tech you ask and someone goes on a poetic journey about how the paper cups, the drive-thru speaker, and the coffee machine are all chasing the same dream, and also we need a $100,000 espresso machine that takes 10 minutes of intense labor to brew a shot because then I'll be qualified to operate a $100,000 espresso machine at my next job which pays better than McDonalds.
We did not figure out how to brew coffee before, that was all wrong and we needed to make the process at least 10x more complicated.
sanskarix
You've captured something important here. There's been a shift from "solve problems" to "create novel patterns." The incentives are all wrong—framework authors get validation from innovation theater, not from boring reliability.
I think part of it is that the web developer community exploded. More developers = more people trying to make their mark = more churn. Everyone wants to be the person who "fixed React" or "reimagined routing."
But when you're actually building a product that users depend on, you realize how much of a tax this is. Every framework "upgrade" that breaks things is time NOT spent on features, user feedback, or actual problems.
The irony is that the best products are often built with "boring" tech that just works. Instagram ran on Django for years at massive scale. Basecamp is still Rails. These teams focused on users, not on having the hottest stack.
What frameworks/tools have you found that stayed stable and just worked over the years?
twicetwice
what's the moderation policy/etiquette for calling out obviously LLM-generated comments? doing so feels like more heat than light, but letting them pass by without saying anything feels like another step towards a dead internet.
sibeliuss
Our experience entirely. We replaced next.js with a simple router and everything in every sense got simpler, and FASTER. It was a remarkable education, replacing that crazy thing.
383toast
yeah RSC is totally unnecessary it turns out
terandle
It's a good idea in theory, the perf just needs to be better. Maybe with bun.
BoorishBears
"1 more step function in performance bro, V8 was cool but just 1 more and we'll have enough to make CRUD apps in JS, bro I promise"
Or you can use React Query/Tanstack Query, not waste cycles and bandwidth on RSC, get an app with better UX (http://ilovessr.com), and a simpler mental model that's easier to maintain.
zenethian
It feels like so much work has been done to just end up going full circle back to Django-style website applications. All of these frameworks have continually re-solved problems that were already solved in something other than Javascript, and then people write blogs about how they're surprised about it. It feels a bit uncanny to see.
aaronbrethorst
Promo packets are a hell of a drug
sanskarix
The issue is everyone's optimizing for blog post metrics, not actual problems. "Look at this new pattern!" gets clicks. "We kept it simple and it just works" doesn't. Same thing happened with microservices - everyone rushed in because it sounded cool, then spent years dealing with distributed systems hell.
bni
I use the Pages router. Doing it this way make sense to me in a way that SPAs never did.
chuliomartinez
Tanstack lack of back button handling is infuriating. Throwing away users data is simply not acceptable.
Is Wouter better in this regard?
Zaheer
The biggest facepalm moment I had was when we switched Levels.fyi from gulp.js to next.js. Our pagespeed, hosting costs, etc all took a significant hit. We're experiencing the same issues as described in the post and weighing our options to transition as well. Avoid next.js / vercel at all costs.
yieldcrv
Where would you prefer to deploy now?
Anybody passing by please share too
skeptrune
>This is because when Next.js loads the actual Server Component, no matter what, the entire page re-mounts. I was begging Next.js to just update the existing DOM and preserve state, but it just doesn't.
YES! YES! I FEEL SO SEEN RIGHT NOW! I find this behavior unbelievably frustrating. It's hard for me to understand why they ever even shipped RSC's without fixing this.
383toast
...or just not use server components :)
hdjrudni
I'm surprised so many people drank the RSC koolaid. I tried it for maybe an hour and it became painfully obvious very quickly how much harder it is to build something that used to be simple.
I just don't understand the use-case either.
Either you're building an SEO-optimized website and you want that initial page load to be as fast as possible. In this case, just build a static website. Use whatever technology you desire and compile to HTML+CSS.
Or you're building an "app" in which case you should expect users to linger around for a bit and that fat initial payload will eventually be cached, so you really don't need to sending it down on every click. So go full-on with the client-side rendering and simplify your stack a little. You can still do a lot of optimizations like code-splitting and prefetching and this and that, but we don't need this weird mixed modality where some things work in one place but not the other.
Which is pretty much what the author says and I'm glad to see people start to realize this.
culi
> Or you're building an "app" [...] So go full-on with the client-side rendering
I wish companies would take this a step further still and just build a PWA. This gives you access to so many web APIs that can further simplify your stack.
I agree that it's bewildering to see how many companies reach for Nextjs for webapps that don't need SEO optimization but some of the more complex rendering strategies can still be useful for web apps as well. Even for PWAs
mayaj47
have you tried Nuxt.js
Vercel has been a string of puzzling decisions since the introduction of the app router. Next could've become JS' Rails, instead it is a pile of confusing mess. Turbopack, caching, middleware (now called "proxy"), their layout components are silly, implementation of RSC, pushing for unfinished alpha versions of everything. Next is a conceptual mess of initialisms (RSC, SSR, PPR, SSG, ISG). Hosting integrations are semi-proprietary and they reliably break basic JS APIs like fetch and redirects.
And despite all of that, they don't ship the basics that every app needs, like i18n and auth.
Next should no longer be chosen under any circumstances.