[CSSer]

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.

[theturtletalks]

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.

[qudat]

I would argue that unless your need SEO there is no reason to reach for Next.js or any other react framework.

The default should be vite and client only. Everything else only serves corporate interests.

[jmeyer2k]

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.

[theturtletalks]

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.

[qudat]

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.

[code_biologist]

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.

[leerob]

What direction would you prefer Vercel went in?

[stevebmark]

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.

[qudat]

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.

[stevebmark]

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.

[LudwigNagasena]

What if I don’t like preloaders and content flashes?

[qudat]

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.

[stevebmark]

I take it you don't write HTML because you don't want to use an "XML-like syntax"?