I think part of what makes these recent gags so funny to me is that it illustrates how perilous mixing RSC with client code feels in practice. Worrying about teammates accidentally exposing environment variables was already bad enough. Debugging is now even more troublesome, and for what? So we can use some XML-like syntax everywhere? React serves a purpose but this doesn't feel like it. All these directives, the lookalike tree complexity, and overloading fetch just feels wrong.
I get what you’re saying, but you can use React without RSC just fine. Next.js might be pushing RSC, but using Vite and normal React is fine. Hell, even the pages directory still works in Next.js and it has no RSC.
From my experience, Next isn't great for SEO either.
Try setting up a redirect that preserves query params with server components.
Server components do allow redirects on the server-side, but they do not expose query params.
It's technically possible with middleware (single root file that runs for every request), or by setting up a client-side redirect, but that's not ideal.
Very true, but React is extensively used for landing pages and e-commerce where SEO is vital. If you’re using Next for those sort of apps in your company, why not use it for the dashboard? It’s seems like the natural progression instead of running Vite on internal apps and Next on external ones.
Yea I disagree. You’ll be fighting nextjs the entire time. It’s a tool for e-commerce sites. And honestly at this point you’d be better served with Astro.
Can you elaborate on why Astro is better or what type of fight with Next? Your type of post with strong opinions but none of the underlying _reasons_ are one of the reasons why JS framework wars are tiring. I'm really interested in alternatives to Next, but it's difficult to good, non-vitriolic, shop talk.
We bolted Next onto the React/Python application at work for SEO stuff. There's a number of self-inflicted problems with our integration but Next seems serviceable. Vercel's direction as a whole is not aligned with our needs though. The framework and paradigm churn is a huge time suck.
I don't really have a strong opinion. Vercel is a really loud voice in the React world, so I guess I'd like them to survive a post-zero interest rate policy world (many growth companies have struggled). Or at least, not push paradigms and features specific to their needs on the React world, then run low on cash, leaving those paradigms functionally unsupported and half adopted by other React libraries.
My needs that Next solved mid-2021 when I picked it: framework that can build on existing React code with strong SSR/ISR primitives + tools for bundle size control for SEO. Nice DX with hot reload was a big plus. My backend is Python and that's pretty set in stone.
Vercel seems to be very focused on solving full stack problems, with the app vs pages routing changes, RSC, server actions. It's clear they're listening to paying customers and I wouldn't tell them to stop. It's just not the problem I have.
The default should be SSR / SSG. Client only is a recipe for a slow web. Client loading is mainly appropriate for long running apps, like GMail, where users tolerate a slow initial load because they're keeping the tab open for a long time. There's a reason the Jamstack mascot is a loading spinner.
Maybe for public facing sites with minimal interactivity. But at that point just use something more basic. For web apps, client only is the way to go and way simpler to maintain. It’s not even close.
I agree, client only is choosing DX over UX. Slow loads, bad for mobile, loading spinners, flashing content. Which is why Next.js is awesome, it abstracts all of that away for you, so you still get fast sites without sacrificing DX.
I build web apps without loaders. There’s maybe a brief flash before content loads but it’s less than 1s ttl. People just want to slap loaders in front of everything because they have been duped into believing react-query is the state mgmt solution for react. It isn’t, it’s lazy programming.
