some basics and nothing else to start. then you can go as deep as you want down the rabbit hole :)
but it's completely on you
If you need to write a web application, on the other hand, you absolutely need all these things, because your mutable state will become a mess after a short while, your event handlers will call your components in a thousand tangled ways and you will want to navigate your code and your types using your IDE. But, again, if you just want to show content with minimal javascript, you don't need to worry about that. Leave all that stuff to web application developers, instead of looking at that stuff, concluding it's too complex for you and ranting against it on the Internet. It's not made to solve your problem.
Technology choices are institutional decisions. They are reached largely via defensibility to non-technologists, to whom (and indeed to most technologists) boils down to appeals to authority rather than to reason.
Nobody is trying to stop this, and indeed many are trying to increase it so they can sell products with more features that virtually none of their customers need.
Blogs, influencers and educational platforms push what is new so that they have more content.
All of this is self reinforcing and we suffer because of it.
The DOM is scary.
I’m getting more and more jaded about React and would rather stick with server side rendered html, but I’d definitely stick with JSX at least.
I've found dotnet with Razor and Blazor to be the exact SSR experience I was looking for. And the performance vs JS is so much better. I did a benchmark recently and got about 7x improvement.
If you're used to React/JSX you'll hate templates, though. Look for a HTML component rendering library instead.
Now they're recommending you use frameworks? That are presumably built on top of React?
So what is React exactly these days? Feels like it's a shadow DOM renderer that's become a defacto API?
Like, you could use a component written for one React based framework, in another React based framework, and it'll just work?
Does React still provide routing and/or state management? Or has that been devolved to frameworks?
Wait a minute, has React become the J2EE of front-end?
No surprise NextJs gets more popular
How many days?
Roughly that many days.
You'll always be using a React routing library, a React data fetching library, a React state management system, and so on.
No you do not need NextJS or any other server side JS for most of the projects. Let's not pretend SPA is dead. Most of you do not need server side rendering and all the complexity it brings.
Just use Vite. You can decide whether to add Tailwind etc later. React should be left bare bones, and it can recommend frameworks, not make them sound default.
npm create vite@latest my-app -- --template react-tsBut 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
I don’t support React pushing a wholesale shift to NextJS as a starting point for every project, given it’s mostly directed by a single private company (Vercel) that have positioned themselves as the default deployment platform for NextJS apps, publish the documentation, and do not shy away from claiming it as their own.
It has become extremely difficult to distinguish between NextJS features that are community-driven vs profit-driven e.g. api route functions (putting your backend in your React project, so now you will pay them for compute) and NextJS image optimization (famously expensive, and NextJS literally throws warnings if you don’t use it).
- React 19 broke CRA
- I griped about it loudly on Bluesky (https://bsky.app/profile/acemarke.dev/post/3lggg6pk7g22o) and that started a long debate
- I filed an umbrella issue describing the specific breakage and recommending an actual official deprecation announcement (https://github.com/facebook/create-react-app/issues/17004)
- The React team finally took action to fix the CRA breakage, then wrote the blog post, updated the setup docs page, and redid the docs SEO to get Google to stop showing the legacy docs as a search result.
So, kudos to the React team for making meaningful changes here!
(It's not _exactly_ what I was hoping for, and I gave them some additional review feedback that they didn't include, but gotta give credit for the actual changes and steps forward!)
I was given word back in 2019 while I was working on CRA that the React team was cozying up to the Next team and was going to be pushing Next as the future of React. That never sat well with me and I stopped contributing the following year.
This post took way too long to be sent to the community, but I’m glad they finally did something. It’s been dead for years.
May I ask about the feedback you provided and they didn't include?
- At least _mentioning_ Vite directly on the "Create a Project" page _is_ genuinely a step in the right direction. That said, they're going out of their way to still not just directly say "creating a basic SPA with Vite is a valid option for using React", and at this point it just looks pretty ridiculous. (Someone pointed out that the Svelte docs start with "Use SvelteKit"... and then the very next thing is "or add Svelte to a basic Vite project with this template". That's what's needed here.)
- I get the _intent_ of the "Build Your Own Framework" phrasing (ie, "choosing to self-install a router, data fetching lib, etc, results in a poor self-created framework"). That said, the "BYOF" page is the opposite of what's needed. It needs to be concrete steps to guide beginners into setting up an app with Vite or Parcel and recommending specific tools to add and techniques to use. Instead, it's "Step 1: Install Vite or Parcel"... and then multiple sections of "Look how hard routing, data fetching, and rendering are, you'll _never_ get this right yourself, use an existing framework instead, DON'T DO IT YOURSELF!". The content would be great if it was on a page titled "Web App Perf Basics", or "Framework Capabilities". But given that this is linked from the "Create" page with the hint of "follow steps here to get going DIY", this is the wrong content entirely.
- Similarly, the repeated use of "framework" to mean "a pre-existing thing someone else built" vs "a set of libs you added yourself" is confusing. Along with that, the overall tone generally comes across as "we don't want to acknowledge the breadth of ways that people use React in practice, and we're going to keep repeating the word 'framework' because we don't trust users to know how to make decisions themselves and we know what's best for you".
- I understand why they tried to emphasize "Next/RR/Expo can all export plain SPAs with no server needed!". That knowledge is genuinely not widespread. But, I don't think a bright green callout with that info should be the _first_ thing on the "Create a Project" page. _Somewhere_ on the page, sure, but it's not the most critical thing to show right away.
So, actual genuine improvement... and yet still kinda frustrating to read and see the phrasing and messaging so far off from what it _ought_ to be.
Seems like they are responsible for it, so .. it react.
I don't think so, so CRA is not react.
And the first suggestion for this extra abstraction layer is NextJS, developed by a company with a vested interest to make it hard to run your app on anything else than their own service.
Seems to me that the time is ripe to disrupt frontend development yet again and introduce a simpler stack.
You definitely do not need any framework for react, you don't even need a build step. And react is not a framework. Not that it has objective meaning, but I think these frameworks are not abstraction layers on react, they are tools sitting along side it to make things easier or give more features. You still interface the same with writing the same old jsx.
You're not going to be popular if you write React code with React.createElement() instead of JSX. I know this from experience.
Here comes the controversial part: I feel all this sentiment against "frontend complexity" is essentially non-frontend developers wanting cool, highly interactive web apps for their backend and getting bummed when they discover it's hard, specialized work. It is, the browser is a beast, all the layers are backwards compatible and web apps are essentially i/o heavy programs responding to a huge number of async events, trying to render a complex state in response on millions of slightly incompatible platforms. There's no silver bullet for that: it's complex, and the complexity shows in the tooling. But if you don't need that complexity because you just need the browser's lower-interactivity presentation layer, nobody in the world forces you to write an SPA. The problems normally start when you want to "just add a comment section" to your content but then you don't want to reload the page and you discover that it becomes complex soon and writing SPAs comes at a cost.
Sorry for the rant.
Maybe it is hard and specialised, but from the viewpoint of someone who just wants to deliver an app, exactly what would I need a client side router for? Or a virtual DOM?
Until I am in need of an interface that has the needs of Facebook, I need convincing that these things are adding value.
> But if you don't need that complexity because you just need the browser's lower-interactivity presentation layer
That's sufficient for 999 out of every 1000 web apps. In practice I see the opposite ratio.
Just this past month I yanked out the entire reacy front end from a project and replaced it, functionally, with plain html, js and CDs and the junior tasked with working on it was able to iterate much faster than he had been doing before.
At a previous larger contract I just kept the react and powered through, but I kept having the team run into problems because like it or not, the cognitive burden of react very often outweighs any benefits it brings.
Why won't it scale? The point of static content/client side work is that the load server side is minimal. It will scale as high as the webserver supports.
> The problems normally start when you want to "just add a comment section" to your content but then you don't want to reload the page and you discover that it becomes complex soon and writing SPAs comes at a cost.
We've had `XMLHttpRequest` since the early 2000s. It would be incredibly easy to add this in vanilla JS.
You could build 95% of websites out there on a standard LAMP stack from 2004 using vanilla JS or at a push jQuery.
The sentiment against frontend complexity (from my observation) seems to be mostly from greybeards who look at big, bloated, high dependency and complex to build solutions for simple web content.
Although I don't personally feel forced, the way markets and industries work you may be "forced" based on what the status quo is in industry at the time.
The webpack (and CRA) mess started countless attempts at improving the situation. Of which, Vite (+ rollup/rolldown) seems to have won. It's easy to use, fast, supports basically every framework/library in the JS ecosystem.
It's also particularly why Next exists. It gives you a mostly easy to use react setup with Server Side Rendering. Of course, Vercel being Vercel they don't use Vite. Instead, it's a choice between webpack or it's rewrite Turbopack. This is why you get rust-level build times for an interpreted language. Incredible achievement.
To keep CRA working, this would need to be added. Rather than go down that road, I guess the react maintainers preferred to recommend Next.js which offers RSC support.
I’m probably missing some details. This is my general understanding
My tendency is to have an easier life in the future. So I'd probably prefer not using an universal rendering framework like Next, Nuxt, SvelteKit or SolidStart in client side mode and just use the core SPA framework. In case of Vue, it's even easier (but without those QoL features Nuxt provides).
Give svelte(kit) a go, I enjoy it
I think at work when the next project comes along I'll try and see if we can not do React anymore. I hear good things about Vue.
But TBH I'm not really happy with vite. It seems to be made with a big flagship SPA in mind. If you just want one page, or if you want to include some react in a plain website, it is overkill. It creates dozens of files with potentially hundreds of configuration options. I guess this is typical for the entire JS ecosystem. But sometimes I wish the stuff around React was simpler and more opinionated: Just throw the .tsx files in src, run reactc, and include the output script in your HTML. Maybe add a flag to watch for code changes / hot reload.
We have several React apps (created with CRA) to support, embedded deep inside ASP.NET Web Forms apps (its legacy all the way down).
We decided to switch from CRA to Vite. It has worked great so far.
I am happy to see these docs recommend Vite as an option for adding React to existing apps, because at the time this decision was made on my team, it wasn’t very clear what the correct path was for replacing CRA. I don’t think we could have as easily switched to a framework like Nextjs.
If you are in a similar situation, I would recommend Vite.
I really really hope Astro will not go because that's what I chose to invest in for a while now... but the fear is real.
Edit:
Maybe it just stopped being a recommendation in the React Docs?