Sunsetting Create React App
react.dev
react.dev
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-tsThere 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.
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.
I'm not sure if I would do it again though, but we'll cross that bridge when we get to it.
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
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.
The goal however is to create a minimal setup to get started with React SPA. And vite's starter template does better
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.
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
- 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!)
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.
For the type of app that React excels at, or at least the type I like to build, the performance issues with a SPA aren't a big deal.
I don't know why they're so resistant to do treat SPAs as a completely valid way to use React in 2025. The majority of devs still use React primarily as a SPA. Recent State of React has it at 85% for SPA and 63% for SSR (1). Probably they know their answer is unpopular and thus we get a lot of deflection and phrases like "you should only consider a SPA if you have unusual constraints" whatever that's suppose to mean.
I've said it before, but changes don't happen when random devs like me complain, because I'm easy to ignore. So I really appreciate you specifically bringing this topic up, it really helps to get things going.
Many React of the core devs work for Vercel, so they have to promote Next and anything that leads people towards their platform.
Seems like they are responsible for it, so .. it react.
Compared to Angular or Vue, it's the wild west. I don't understand why anyone puts up with it.
I don't think so, so CRA is not react.
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.
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).
Also, the image optimization on the default Next.js server, for example deployed to a $4 VPS, also works without Vercel.
[0]: https://www.npmjs.com/package/next-image-export-optimizer
If you're used to React/JSX you'll hate templates, though. Look for a HTML component rendering library instead.
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.
The DOM is scary.
That’s unfortunate because back in the day when I started doing this work frontend developers were expected to do more than this.
The real reason is that the web started to become serious business, and that meant javascript had to become a serious language, which led to all of the nonsense it accreted over the years from startups and enterprise. Everyone uses frameworks and compilers and a package manager because a serious language uses frameworks and compilers and a package manager, and all of these look good on a resume.
But the good news is: you can do without all this. You can manipulate your mutable DOM manually, send and receive messages via native DOM events and mutate your state inside a big vanilla object. You can do without tooling, just Notepad or Vi and a browser. You don't even have to need type completion. You don't even need const or Promise, you can use var and callbacks, everything is still there. If you think tooling is startup-fueled scam (and probably some of it is), there's literally nobody in the world to force you use tooling. The web is entirely backwards compatible, you can do whatever you think is best!
No, but only because I used other backend languages and frameworks for that, because there are much better languages suited to those tasks than JS. Especially in the browser. SPAs exist to serve a specific business case, they aren't qualitatively better than what came before.
>And no bundling, so you have tens of <script> tags in the right dependency order to support older browsers? It becomes quite fragile very soon.
Or just use JQuery and some modules.
You make it seem way more complicated than it was, it was never that complicated. It was never nearly as complicated as the current JS ecosystem. Talking about "tens of scripts" when the current status quo is a brittle dependency tree of hundreds, if not thousands, of scripts for even the simplest task is silly.
>The web is entirely backwards compatible, you can do whatever you think is best!
Yes. This is technically true, but unfortunately tech culture has years of ingrained social pressure leading people to believe javascript is a dangerous language that they don't dare approach without ten layers of abstraction protecting them, and the nonexistent business value in doing so, because the ecosystem is dominated by capitalists. The fact that "vanilla js" even exists as a term demonstrates how pernicious this fear has become - there is no "vanilla x" any other language. Only javascript needs a special term for just using the language because of the deep cultural taboo against doing so.
Good luck writing highly interactive apps backend-only! (Like Figma or Google Docs). Even with frameworks like Phoenix and runtimes like WebAssembly, you still need a lot of Javascript to get there.
> Or just use JQuery and some modules
This is incredibly ignorant :) jQuery solves maybe 10% of the problems I listed, and does that imperatively, so you get in the exact same issues, but with a marginally better interface to the DOM. Which is not even true nowadays, as the js DOM interface got a lot better.
> The fact that "vanilla js" even exists as a term demonstrates how pernicious this fear has become - there is no "vanilla x" any other language.
Wait, do you normally write Java with no frameworks? Handle request / responses / queues / threads from scratch?
That's exactly the point. 99% of websites don't need to be "highly interactive apps" like Figma or Google Docs. The modern JS pipeline and ecosystem exists for those applications, as it was developed by Facebook, Google and the like, but it's far more complex than most people actually need. The baseline for web development shouldn't be "install NPM and node and n frameworks, learn test suits a,b,c and this completely different language."
>jQuery solves maybe 10% of the problems I listed, and does that imperatively, so you get in the exact same issues, but with a marginally better interface to the DOM. Which is not even true nowadays, as the js DOM interface got a lot better.
I was specifically making a comparison between using JQuery and script tags versus NPM dependencies, but JQuery still solves far more than 10% of the problems most people actually have. Because again, most websites aren't startups trying to optimize to compete against FAANG.
>Wait, do you normally write Java with no frameworks? Handle request / responses / queues / threads from scratch?
I think you're being purposely obtuse here.
People write Java frameworks in Java. It's still programming in Java. You're still expected to understand the Java language to use Java frameworks.
Javascript is primarily compiled from other languages which use their own idioms, often imitating far more strictly typed languages. JS devs are primarily people who hate javascript and wish they were using another language, and much of the unnecessary complexity of the modern JS ecosystem exists to capture the labor market by catering to that desire.
Which is why "vanilla js" is a phenomenon unique to Javascript. Other ecosystems don't have the same culture of alienation and aversion to actually using their language.
That's what I said n comments ago. If you don't need a highly interactive app, you can do with HTML and CSS only.
> People write Java frameworks in Java. It's still programming in Java. You're still expected to understand the Java language to use Java frameworks.
I hate to break it to you, but React is 100% written in javascript and you interact with it writing javascript. It's a library, not even a framework.
I'm not sure which languages are you referring to. Typescript? It's Javascript with types (minus enums, which are discouraged). Elm, Purescript, Clojurescript, Gleam? Great languages, but they represent a tiny fraction of the real world fronted applications
> JS devs are primarily people who hate javascript
Modern javascript? Are you sure you're not projecting the fact that you hate it?
Admittedly, I also don't like a lot of the more recent features added to the language like classes and templates, because I'd prefer javascript remain simple and avoid feature creep.
[0]https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
That's highly conservative; of all the react apps I have come across professionally exactly zero needed React.
You really don’t need to write JS directly to make a UI like Google Docs with Phoenix LiveView. You can write the whole thing in Elixir. Thanks LiveView.JS, there hasn’t been a need to write custom JS or hooks to avoid a round trip to the server for UI-only interactions for quite a while, either.
Can you give me an example of when you would need a LiveView app to spawn a thread or set up an observer via JS?
Spawning a thread sounds particularly odd given that JS isn’t running on the server. Are you speaking of web workers? Or do you mean doing something from JS code to send a message to the Phoenix server to get it to spawn a process (i.e., a green thread) on the server?
Whether or not writing to the DOM directly is easy is entirely beside the point. Their professional existence is tied to an unnecessary process and removing that process leaves them embarrassed, exposed, and extremely insecure.
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.
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.
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?
Hooks came as no surprise to anyone who paid attention, as the recommended way to write components since at least 2016 was in the stateless functional style whenever possible, and many of us used recompose[1] to simulate hooks long before their introduction.
[0] https://github.com/reactiflux/q-and-a/blob/master/jordan-wal...
https://web.archive.org/web/20190105060636/https://reactjs.o...
Although they were mentioning function components at the time in the documentation, I can't say how mainstream that was. Hooks were introduced in Feb. 2019.
No surprise NextJs gets more popular
You'll always be using a React routing library, a React data fetching library, a React state management system, and so on.
That's like saying "you will always use js in backend" while ignoring every other backend language.
i certainly don’t use a react data fetching library, i just use fetch. i don’t use special react state management, just use redux. i did build a router that works primarily with React in order to support JSX in the components, but it wouldn't be any harder to adapt it to another framework or setup.
the problem is exactly the same as those memes making fun of people asking on stack overflow "how do i add two numbers with jQuery?" eg 'how do we add two numbers with React'
the problem is there are always new developers making silly mistakes, and making that an indictment of some technology is a fallacy.
How many days?
Roughly that many days.
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.
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
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
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.
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 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.
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.
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.
Wrong purpose. The extra layer provides things React never had, like URL routing.
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.
Edit:
Maybe it just stopped being a recommendation in the React Docs?