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.
there was a hey day where react was concerned with client side stuff only - yeah redux was a little complex but you needed to learn it once, react router didn't change every two days. we built incredible enterprise stuff around that stack react (with classes), react-router, redux. that's the last time I enjoyed react.
everything else is now a hamster wheel. running but staying in one place. marketing and money now drives everything else. Maybe there's a fire & motion strategy going on some of the places.
You still can build websites this way. I was the first hire at my current company, I got to pick the stack of our frontend repo from the first commit. If you stay away from NextJS, things only improved since those heydays.
We're running tanstack-router, tanstack-query, and using vite underneath. That's about it. Each of these libraries are better and simpler than the standard redux/react-router/webpack from back in the day.
I've got lifelong backend developers reasonably (And somewhat happily) productive with the codebase.
Next.js isn't React. Plain React has been pretty stable, if you ignore server components. And it's quite easy to ignore them despite all the noise around them, they're entirely optional.
This is beside the point. And I can't imagine how anyone would want to write templates in anything other than JSX and yet here we are.
Rails and friends aren't about a single technical choice, but providing a complete and opinionated framework to build web apps that conceptually fit in to one person's head.
Rails is that. Django is that. Laravel is that. Next is the opposite, where Next-specifica around caching won't fit in to a single head, let alone the app you're building.
For the vast majority of cases there are many non-DIY alternatives within the React world and that is before asking the "do we even need React?" which if course one should.
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.
Kind of, when you have the influencer culture and startups that hire based on Github performance, one needs to standout somehow, e.g. building frameworks.
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 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’ve been using Wouter on multiple medium sized projects for 3-4 years now. I’m never going back to react-router if I can avoid it: a hellhole of API churn and self promotion
Dang, looks like wouter does the same thing as react router v6+ and nested routes don't get all params / paths of the route. ~~Also doesn't have react router v5's route-string typescript parsing.~~
I’m kind of agreed on this but — many times now I’ve also wanted static site components in my app too, and in a standard express+react app that gets awkward.
I think there must be a better way. I don’t think it’s next.js and I’m not convinced it’s Astro either. There’s still room for new ideas here, surprisingly
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.
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.
It was pretty clear from the beginning it wasn't necessary. It's funny how many junior developers will rant about how you must avoid shipping unnecessary code to the client all costs or you will die. Well, actually, I've been building React apps for over 10 years without any of this RSC shit and those apps made many millions of dollars, so it's actually not a problem.
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...
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
why would you go through the trouble of doing SSR on a user profile form?
it's not needed for SEO, caching it is pointless, the server won't render it faster than the client so you are not speeding up anything.
what's the point of complicating anything about it? seems that at least some of their suffering is a self-inflicted wound, maybe the author just picked a bad example.
Readit News
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.
everything else is now a hamster wheel. running but staying in one place. marketing and money now drives everything else. Maybe there's a fire & motion strategy going on some of the places.
things like inertia help, but not by much.
We're running tanstack-router, tanstack-query, and using vite underneath. That's about it. Each of these libraries are better and simpler than the standard redux/react-router/webpack from back in the day.
I've got lifelong backend developers reasonably (And somewhat happily) productive with the codebase.
Rails and friends aren't about a single technical choice, but providing a complete and opinionated framework to build web apps that conceptually fit in to one person's head.
Rails is that. Django is that. Laravel is that. Next is the opposite, where Next-specifica around caching won't fit in to a single head, let alone the app you're building.
We chose Next.js, exactly because they are the only option in many enterprise products as the extension SDK.
No one wants to land into a project and sell the customer that they want to use DYI framework instead of the SDK of the product they are paying for.
For the vast majority of cases there are many non-DIY alternatives within the React world and that is before asking the "do we even need React?" which if course one should.
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?
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
https://github.com/molefrog/wouter?tab=readme-ov-file#route-...
I think there must be a better way. I don’t think it’s next.js and I’m not convinced it’s Astro either. There’s still room for new ideas here, surprisingly
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
it's not needed for SEO, caching it is pointless, the server won't render it faster than the client so you are not speeding up anything.
what's the point of complicating anything about it? seems that at least some of their suffering is a self-inflicted wound, maybe the author just picked a bad example.