Yes, I find it disapointing how much they're pushing developers who might not know better that React is NextJS, which is not true. They're pushing people into the complex option first without understanding the tech along the way.

A lot of teams using NextJS end up creating things that are effectively SPAs where some part of the code run on the server, they gain no benefits but end up dealing with relatively long compilation times and have to deal with the confusing issues around client vs server components.

Most stuff ends up beeing Client Components - since what else do you really need react for?

If you want to optimise for SEO you might want your content to be rendered on the server, however: rendered on the server is not the same as being sent down in the initial HTML payload. Server components are not convenient to use, because they cannot be interactive, even code that you would expect to work does not work on the server.

There are good parts like server actions, however they are plagued with very strange limitations making them not so useful.

If you want to statically generate websites and want to use React, NextJS can be a good choice, however for complex web applications I find that it's not ambitious enough to justify even the extra compile time that I get from its tooling compared to Vite.

> If you want to optimise for SEO you might want your content to be rendered on the server

Why would you optimise for SEO on a webapp? What's the use-case there?

If you're not writing a webapp, then any server side rendering would do and client side components aren't needed anyway.

You wouldn’t but many of the largest users of these frameworks are actually e-commerce sites, not applications.

Can confirm, that was the last project I worked on that had SSR; fancy product website / e-commerce, combined data from a CMS-as-a-service and a webshop-as-a-service, rendered pages in one go using Gatsby, published it. I believe that was the best of both (SSR / webapp) worlds, in that it was both fast and indexable in a static context, and if the user had JS enabled and the page was hydrated, navigation was super fast and lightweight because only some JSON went over the line.

I'm not sure if I would do it again though, but we'll cross that bridge when we get to it.

Rsbuild is another nice replacement for CRA. They even provide guide to migrate from create react app. I used it for a small CRA application migration and it worked without any hassles.

Totally agreed. I ended up building my own router so I could just use React, Vite, and my router and have everything required to ship a SPA, while adding support for SEO. It's tiny compared to the competition: https://github.com/nerds-with-keyboards/routerino

In theory, yes Vite is webpack replacement. CRA is a different beast. So, what is CRA’s replacement? Vite + vite-plugin-react.

But that is quite a mouthful, so people shorten it to Vite. So, when they say switch to Vite, Vite-react plug-in is implied. No one is recommending rolling your own Vite plug-in for react

CRA does much more than just supporting jsx, which any bundler should be able to do without a "plugin".

What else does that plugin do? HMR? Equivalence to CRA is next, which is a set of opinionated loaders and config. But next also has the router and some react utils on top.

CRA also does not include router, and is not extensible. If the goal was to replace CRA with equally bad tool then next might be considered a viable alternative.

The goal however is to create a minimal setup to get started with React SPA. And vite's starter template does better

Next is nowhere near "equally" as bad as CRA, it's made by a company not a *community* of front end engineer wannabes. Try to make honest assessments instead of whatever works in favor of your argument.

Next is that minimal setup, that has everything you need. Saying vite is a "minimal setup" is like saying webpack is a minimal setup, if by that you mean an useless setup wherein you have to then add a bunch of libraries for basic needs. That directly contradicts with the idea of being minimal.

Next is being actively developed, that alone makes it great compared to CRA.

But when it comes to migration from CRA, next is very different from CRA, so much that you might as well call it “rewrite” instead .

Next by itself is a great option but not for migrating from cra

spa is defintely dying. a lost 10 years.

It's use case specific. At $job we have a SPA that is a heavyweight editor with 0 routing. No need to do any SSR there. It's certainly not dead for those use cases.

Millions of people doing admin/app/enterprise dashboards disagree.