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.
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.
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
I'm using the React Router v7 in framework mode, fetching data directly from the database in server-side components. So far, it works reasonably well as long as we avoid mixing server code with client components. However, although it offers the convenience of writing frontend and backend code together, the mental burden added by this approach makes me feel it is not worth it more and more often.
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?
> 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.
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.
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?
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.
I noticed the author mentioned the stack they are currently using is NextJS + Hono, and according to the code in the blog, Hono is used as the API backend to provide data for NextJS through calls like `fetchUserInfo`. This is where I really got confusing, why is it designed like this? NextJS is already a full-stack framework, not to say you used RSC, you can directly get user data from the database in NextJS. If you decide to use Hono for HTTP API, which is fine because it's more light weight and adaptive, then why RSC rather than making the frontend a SPA? Even if you use NextJS to write SPA it would looks much reasonable to have both NextJS and Hono used together.
For a project at work we chose next because the team knew react and other people in the company know react. It is quickly becoming the worst architectural decision in my whole carrier. I wish we would've picked anything else...
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.
"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.
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.
The horror of needing to replace a routing layer. Why is this not a solved problem?
This is an undervalued advantage of using steady frameworks like Rails that in essence is the same as 20 years ago, but with lots of extras. I don’t remember any big changes in the routes at least. Nor in any of the other basic building blocks.
You could come back to rails after a 10 year break and pick up pretty quickly where you left off
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.
I've used the app router and it is fairly nice once you understand how all of it works. But its a bucket load of complexity nobody really needs. A normal react SPA using vite + wouter + react-query works brilliantly.
>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.
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.
Appreciate it! We're still on nextjs. Will def put a blogpost together as we optimize / move away. Thankfully, AI makes large-scale mostly repetitive migrations like these much simpler.
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.
> 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
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.
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.
Thought I've enjoyed the code-splitting and access to SPA/SSR/SSG/etc strategies that come with the "framework" mode
[0] https://reactrouter.com/start/modes
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.
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.
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?
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.
This is an undervalued advantage of using steady frameworks like Rails that in essence is the same as 20 years ago, but with lots of extras. I don’t remember any big changes in the routes at least. Nor in any of the other basic building blocks.
You could come back to rails after a 10 year break and pick up pretty quickly where you left off
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.
Is Wouter better in this regard?
Anybody passing by please share too
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.
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