Vite is a direct replacement for CRA but corporate speak makes it sound you need a framework and that corporate speak is funded/influenced by Vercel.
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.
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.
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.
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.
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.
- 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!)
They are still going out of their way to not say Vite or similar SPA tooling is a completely viable path for a lot of projects. SEO is not critical for all projects like they make you think it is. I’m pretty disappointed by the direction they took in this post.
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.
- 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.
The React team really does not like SPAs, which I think is a bit of a shame. I'm not a big fan of the mish-mash approach of client and server components that Next et al now encourage.
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.
The hybrid server render, then hydration step is too magical for my liking. There's a bunch going on in there that would be very difficult to debug, if some mysterious error at this stage of the app were to present itself. I prefer either wholly SPA or serverside, can debug and understand the whole thing.
This perfectly captures my thoughts about the situation.
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.
You can say it in 10 threads if you want, that’s still not true. CRA is a template using React. The team working on React can work on a React template, that doesn’t mean they’re the same thing. It doesn’t even make sense.
This is true throughout the React universe. React itself does almost nothing useful. In order to build an app that does anything, you need routing, state management, API connections, etc. etc. Reactland is all just a grab bag of random half-maintained unofficial libraries that sort of work with each other.
Compared to Angular or Vue, it's the wild west. I don't understand why anyone puts up with it.
The article kindly phrases the alternative as “use a framework” and links to a page that has only one actual framework: NextJS.
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).
On top of that, NextJS doesn't even support the <Image/> component (and thus all their image optimization) when exporting to static output (unlike Gatsby). So you will be pushed even closer to pay them.
In your very link you can see that you can only add a handle to a third party loader. Their built in image optimization that works in vercel does not if you static export and host elsewhere.
If you do a static export, you don’t have a server to optimize images. It’s just a bunch of static files. The only way to optimize the image is to point to a service through the loader.
Also, the image optimization on the default Next.js server, for example deployed to a $4 VPS, also works without Vercel.
Next should have the same functionality that Gatsby had when doing a static export: pre-optimised images for different breakpoints that are created at build time. That would be a truly portable solution.
that is simply not true, there are static export, 3rd party image optimizers [0] (that re-use <Image />) - just vercel does not care about theirs for static export. Also, look at how gatsby does without cloud/server hosted images.
Vite is the replacement for CRA, I usually create new projects with their preact-ts template. Its very fast and just works. I would personally strongly advise against nextjs, but use whatever you prefer.
The complexity of frontend development now makes me want to return to a “back to basics” approach. I just want a server side rendered platform, serving templated html pages to the client, with minimal JS for interactivity. Most projects don’t really require more than this, and the level of unnecessary complexity that has developed over the whole stack, from devops to backend to frontend, is staggering and obviously more a social artefact than a technical necessity.
You might be interested in Astro (https://astro.build/), I've build my first project with it, and it's great to somewhat go back to basics, but without needing to set up my own server with templating and tasks for static assets, etc...
If you need minimal js, there's no need to use frameworks. I don't understand why we came to think the opposite, but you absolutely don't need state managing, effects and a build chain if your goal is to merely show some content on the web.
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 problem is not that the tools exist, or that complexity exists. The problem is that the community view, enforced by various incentives and supported by the creators of these tools, creates a situation where technology choices are driven by what sounds good or is trendy rather than solving the problem at hand in the most effective way.
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.
Children learned how to use it in the 90s from basic web tutorials and reading source code, it isn't that scary.
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.
Have you tried to write a really complex web app without router, state manager, type completion and declarative DOM? 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.
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!
>Have you tried to write a really complex web app without router, state manager, type completion and declarative DOM?
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.
> 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.
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?
>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.
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.
Anecdote for anectode, the majority of React apps I encountered needed React (or something equivalent). Lots of web replacements for corporate native applications, which of course are complex, highly interactive beasts with a lot of state and a lot of logic on the client (with the server being glorified CRUD)
> Javascript is primarily compiled from other languages which use their own idioms, often imitating far more strictly typed languages.
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?
By "modern javascript" I refer to both the language and the ecosystem of Node, NPM, Typescript, and related technologies that have become so ubiquitous as to be inseparable from the language to most people. I don't hate javascript, I'm not one of those "javascript delenda est[0]" people who go off on rants about the language whenever it comes up. However, I don't like what the language and ecosystem have turned into, and I don't like many of the incentives that brought those changes about. What used to be a community driven ecosystem has been captured by VC and corporate interests.
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.
> ”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.”
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.
For a canvas-based app, which to be fair none of my professional work has been, you’d need to write some JS or hooks to interface with external JS libraries.
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?
Yeah, I meant web workers. It's easy to find canvas and web workers in any sufficiently complex highly interactive web app. I'm not saying you always find them, but if you're doing some form of graphics you most probably use canvas at some point, if you do non-trivial computation you spawn workers, if you need sound you use the Web Audio API, if you have a complex layout you're better off with DOM Observers, and so on...
The DOM scares the shit out of most developers. Those developers then twist themselves into knots with all kinds of nonsense to justify their aversion. Take the framework away and they panic, like stripping a person of their clothes before they are to give a big talk in front of upper management. You can call that autism, trend chasing, resume padding, cognitive conservatism, or whatever. The result is the same.
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.
Same. I replaced handlebars with server-side generated JSX (not Next or anything like that, just renderToStaticMarkup) and it’s an infinitely better dev experience than any other templating language I’ve used before (hbs, jinja, django…).
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 don't like JSX but I enjoy how React/Svelte/Vue/etc do code colocation and composition compared to traditional templating systems with partials etc.
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.
React is primarily for intimidating the piss out of new employees and flexing on your teammates with esoteric hooks and composables. In essence, React is the job security framework.
Not primarily, as primarily it was just "we're the V in MVC", and people were using classes. The hooks came when the react team got on the "functional programming" wagon, and suddenly everything was about immutability, side effects, etc. and very little about giving control to the developers on their components life cycle.
React was literally first created in ML out of the author's dislike of MVC, who preferred functional programming and immutability[0]. For a long time, react aspired for its future to be in ReasonML.
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.
Maybe I was not paying attention, this is of course a possibility, but until at least early 2019 the react website's main page was only mentioning the class-based "stateful component" as the way to write components.
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.
React has never been a "framework", it's a "view library" that can be included in a framework. The benefit is you can pick your own pieces, like building your own computer. Also, React doesn't handle routing (I recommend wouter), and yes it does state management (I recommend zustand for additional state management). You seem pretty opinionated on something you don't know a whole lot about.
Your opinions here are the core of my gripe with React: everybody has their own favorite package for some functionality that comes in standard frameworks. You’re mentioning libraries I didnt know existed.
This makes every react app different, annoyingly for docs, help resources, and people.
Yeah, I was around back then, and the difference from then to now is equivalent to the difference between inventing the wheel and going to the moon. Not necessarily in a good way.
React itself was never a framework, just a library to render user interfaces. Routing, data fetching etc. have always been separate libraries (or built into frameworks).
developers often want those things, but they are certainly not required.
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.
and yet, every time I have a discussion about this with my frontend colleagues, they are soooooo far gone into the React pill, that it's impossible to talk to them. And they all happily migrate from one hype to the next, as the React gods dictate, burning funds for no reason. Funnily enough, the more time passes, the more bugs and regressions our frontend has.
I know this is highly controversial, but I don't understand all this sentiment against js frameworks. You can still write vanilla html + js if you don't need hashed assets, css isolation, routers, linting, types, complex state, etc. It won't scale much, but maybe you don't need to scale, you just need to show some simple content with a login page and a "back to top" button. You can absolutely do that without frameworks, and you're better off without.
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.
> 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.
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.
Agree with the wrong ratio, and the explanations I can find are two: 1) When starting a project, product people always exaggerate the scope, so tech people set it up for scaling from day 0 2) React is industry standard, so it's easier to say "here, this is a React component, you know how it works" rather than re-inventing your "component" pattern that mutates the DOM.
That said, complexity is a spectrum: scaling up and down is equally painful. Understanding how to calibrate efforts comes only after a lot of experience.
> You can still write vanilla html + js if you don't need hashed assets, css isolation, routers, linting, types, complex state, etc. It won't scale much
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.
It won't scale in complexity. At a certain point, your mutable state will become really hard to maintain, so you will need some form of state manager. Then your code will grow and accumulate a lot of bad practices, so you will need a linter. You won't be able to keep the whole codebase in your mind, so you will need more help from your IDE, and you'll end up using Typescript. Your teams will keep overriding each other's CSS, so you will introduce CSS Modules in your build step. The product managers will ask about deeplinking without reloading the page, so you will install a router. Your mutable DOM manipulation code will become full of ifs and special cases, so you will feel the need of abstracting out your components in a declarative way etc.
I'm not saying you need all of this from the start, but you will need parts of it pretty soon if your application is heavily interactive.
Not using React anymore, but it's generally not an easy decision whether to use a framework for a SPA or not. Currently I'm torn between Nuxt and Vue with Vue Router. Nuxt has many fun QoL features, but adds a significant layer of potential issues (bugs, maintainability, leaky abstractions over the core library).
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).
It’s not clear to me how using a framework replaces cra, or why cra is a hassle to maintain? I’ve always thought of cra as a way for beginners to quickly wire necessary stuff up to get a working, ”vanilla” react project, something that could be a done in a simple shell script
CRA existed to remove the setup/maintenance burden of webpack (software straight out of hell ...). It's biggest issue was that it was entirely unconfigurable. You took what was offered in CRA, or you ejected and now had to maintain a huge and brittle webpack config.
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.
My understanding is that features of react now require a meta framework to function. The main feature being React Server Components. There’s a bit of wiring things up required that doesn’t happen off the shelf when you add react as a dependency.
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
While you can run React without a compiler (at least last time I checked), it's really no fun without TSX/JSX, so you need a compiler. There's a bunch of choices in that category, and a bunch of loaders/plugins you can pile on top of that. Compilers and bundlers are not so fun to maintain.
I guess it is a good thing that they are now clear about the state of create-react-app. I used it about a year ago because it was still recommended on the React page, and got a lot of deprecation warings. After a lot of googling I realized that people now recommend vite, so that is what I went with (thinking popular = more likely to be supported in future and having more information on the net).
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.
CRA has been a maintenance burden for my team for the last couple of years due to security vulnerabilities and incompatibilities in old packages.
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.
Pretty sure CRA was dead a long time ago already and it's very upsetting how little the React team cares about its users. The unwillingness to act on the CRA being broken, the forceful promotion of a pretty locked-in framework Next.js (which is crap without Vercel, so clearly against the open source spirit) as the de-facto way of doing React (is it really? according to stats I've seen, most uses of React are for SPA's).
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.
The state of front end tool chains is absolutely nauseating these days. Sometimes I feel like most of what I’m getting paid for is simply my ability to jump through hoops, not to actually design or build stuff.
So now you need a framework on top of React - itself a framework. Has React really become so complex that mere mortals cannot comprehend it without another abstraction layer on top?
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.
>So now you need a framework on top of React - itself a framework.
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.
Nope, you can use React just including it in your html page. All the added complexity is to give you a better dev experience if you need a highly interactive web application. Routing, linting, types, server rendering, state managing, static files, etc. You don't need all this if you're not developing web applications. You can write html and js and be happy.
The state of React is so frustrating: plain React doesn't make much sense, but at the same time Next.js is a complete pain in the neck to use. Remix is promising, but young... At that point backend development is much more straightforward.
If one of the authors are here, can you please add Ian Sutherland to the thank you note at the bottom? He spent just as much or more of his personal time as Brody and myself. He deserves credit. Thanks
This type of comment doesn't contributing to anything. Rememebr most devs just code for work, and don't want to learn a new language/ecosystem _just_ so they can use a different framework.
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.