I should remind that in a similarly cheerful mood FB dumped support of Jest and a bunch of other libraries. They have a long history of killing successful projects.
Worse, Vercel is involved, and I literally don't remember anything good about that company.
I'd recommend to be very cautious with such news, and use older versions of React for the next couple of years.
This announcement mentions they are separating business and technical governance, I suspect they are trying to limit Vercel's influence, and prevent them from taking it in a direction that only benefits them.
Looks to me it will be dead soon if they don't figure out how to handle ESM imports. More and more libraries stop packaging commonjs for their new versions. I've been bitten first by d3, then by graphql-request (now graffle), then by msw, then by faker-js. Faker-js, for god's sake! They write in their docs that since version 10, they are incompatible with Jest [0]. Jest seems to be going the way of Enzyme and dodo.
The maintainer of MSW has been screaming for years for people to drop jest [1]
I think keeping it unsupported for a couple of years, and reluctantly pushing it off to volunteers who barely have enough technical experience to support it is quite close to "was killed".
Until recently Jest had a bug that made it crash due to sl (yes, the famous steam locomotive) running under the hood. This gives a hint at, ahem, the sophistication of its architecture.
The project is long in its EOL, and the only reason for its use is inertia, the jQuery kind of it.
Being generally employable and paying your bills? I don't like Angular one iota but I'd assume people who still choose it have legit reasons. What do you think we should all be using?
It feels like React generally has an ongoing trajectory towards increasing complexity and features. For something that's effectively become the standard for frontend that's unfortunate. It would be great to have a simple reliable base, with extensions & addition complexity layered on top or included optionally. This announcement doesn't fill me with hope for that direction unfortunately, it mostly seems like Vercel getting more control, and they're driving a lot of that movement.
Being able to ignore parallel rendering, RSC, hooks, etc, and just write simple code for simple sites again would be fantastic.
Unfortunately all the major competition I've seen seems so significantly different that migrating any kind of non-trivial application would basically be a full rewrite. Is Preact or similar offering much promise here?
> Being able to ignore parallel rendering, RSC, hooks, etc, and just write simple code for simple sites again would be fantastic.
I don't understand this statement. You can use the basics without involving yourself with anything complex. You can even still use class components. You can build components that are framework agnostic.
When you're new it can be hard to tell what to ignore; it makes it tempting to pick a simpler framework that you can entirely grasp. Also any published examples, chatgpt etc won't be aware of the subset you've chosen to use when they're providing examples; they're gonna draw from the full set.
Last time I looked, their own docs didn't even tell you how to create a basic SPA, merely that it was possible and scary. That doesn't inspire a lot of confidence.
yes, but literally everyone will tell you to move away from that. It's like saying if you're not physically violated then you should put up with verbal harassment because it doesn't matter in any real way.
At the very least whoever using class components would have to routinely defend their decision every quarter when confronted by colleagues who understandably just wanna write conventional code.
I tried to wrap my head around hooks, to effectively use them, and have a complete grip over the app, but I kept falling into the "magic" pit.
Things work, But I no longer know how they work.
Frustrated, I shifted to angular with signals, and now my cognitive load to understand data and events happening in the app are clearer and I feel I know what exactly is happening.
Not sure if this feeling is common, of helplessness with react.
I had exactly this problem. In my experience, the documentation over-simplified things to the extreme. Why are hooks not normal function calls? Where do they get their state? Why are they not functionally pure? "Functional purity" has been muddied too. It used to mean a function whose output depends only on its parameter values. But hooks are not pure, and thus components that depend on them are not either. But react still uses this language.
None of the official docs helped, but I found myself required to use it for work. And I faced confusing behavior I could not explain with the documentation. So I went on a deep-dive for a month or so. I didn't learn everything about react, but I got an intuition for how hooks work. That's not to say I like them. I'll use them now only if I have to, but at least I can. To my mind, hooks present a surface that's difficult to make sense of and hard to use.
> It feels like React generally has an ongoing trajectory towards increasing complexity and features. For something that's effectively become the standard for frontend that's unfortunate.
Is that not every software development effort, ever? Isn't that why "todo" apps, search engines, etc, constantly get "recreated". Live long enough to become the enemy and get replaced by a bare bones app that'll bloat itself into oblivion and repeat the cycle?
Oh, dear. Yet more ways of dealing with React that coders will be forced to deal with. But in a way this might be good for engineers because the quantity of foot guns available in various flavors and versions of React appears to have already scaled far beyond the capabilities of available LLMs to handle.
In one of my recent doomed interviews I explained that I had been following React for a while and was practiced at a number of ways of using it. Developers in the group then kindly informed me that the reason I had learned multiple ways of using React is that I had not yet found the one true way which of course they were using. Got no offer from them which is probably good for all of us.
Most companies don't really need the majority of React's power. There is room for a low to mid level complexity library/framework to fill the space that the majority of sites really need (like, that brochureware site should be statically generated and needs none of what React offers and the site that deals with dozens of requests per minute can be greatly simplified). What we need is a low complexity tool that has a fantastic DX. Of the many projects that deal with this none has taken hold in the way that React has.
One is the DX as you mentioned; eg Hugo is nice, but editor integration for autocomplete, warnings, etc is basically non-existent that I’ve seen. Templating is also really clunky relative to React.
The second is Reacts omnipresence means there’s usually pre-built stuff I can pull in if I just want to iterate fast.
The third is that typically the best way to get a low complexity and good DX static site generator is just to roll your own with only the features you need. They get a lot simpler when you aren’t dealing with an ever-expanding list of feature requests and usecases. You decide whether you want types or editor integrations or whatever by duct taping together a few libraries.
I don't have experience from any larger application, but from my smaller usage Preact seems like a drop in replacement. It's been compatible with the react libraries I've tried. It also works great with ES modules. So for simple stuff, I think it's worth a try.
After seeing all the comments here I'm a bit relieved.
I don't care about the CEO's political stance, but Vercel's involvement with React has rubbed me the wrong way since the start of development of RSC. The development was basically behind half-closed doors, pretty much tied to Next.js (i.e. Vercel) and with zero specs except a high level description of what they were and their public API.
I don't care that they were WIP: the community should've been involved, not Vercel as a benevolent dictator guiding their design from start to almost finish. Such a huge paradigm shift shouldn't have been dictated by any particular entity... and IMO much less Next's team which I think are prone to overengineering and bad decisions.
IIRC there were points in time (maybe even currently?) where you had to use packages that were published to NPM but not even on any public repo.
I love the idea of RSC but that's where my love ends.
I like React a lot... but tbf, I never really quite agreed with the RSC push in general. I think most web-based apps are fine with client-render against an API/GraphQL/WebSocket backend. RSC is just a few steps too far in both Pure-Fucking-Magic (PFM) and rigidity in approach.
If there was a component library as complete as MUI for Yew/Dioxus/Leptos I'd have likely already switched to Rust/WASM.
Personally I really wanted RSC because I have a DIY SSG based on React.
It's dead simple but only supports static components. Something like RSC would allow me to automatically cook a bundle with only the interactive parts (think e.g. a custom dropdown or whatever) while still remaining fully static.
Now I'm not so sure given how they're developing...
Increasingly bloated and complicated frameworks with intangible benefits used for webpages that are now just training data for LLMs is much more important.
Happy to see a clear path for React going forward. React is under-appreciated in some circles of the fast-moving JavaScript world, where people are somehow expected to rewrite all their code from scratch every couple of years or so, after somebody starts shouting "framework X is dead", and everybody starts focusing on the new hotness. I'm not sure how that is economically viable, I know I couldn't afford that kind of approach.
I have a Clojure/ClojureScript app using React that I've been maintaining for the last 10 years. I don't use all the features of React, in fact I could probably use a much smaller library — the biggest advantage is that it provides a "re-render the UI based on app state change" model that fits Clojure very well. But I'm very happy that React is there and that it's been maintained with relatively little code rewriting necessary over the years.
> React is under-appreciated in some circles of the fast-moving JavaScript world, where people are somehow expected to rewrite all their code from scratch every couple of years or so, after somebody starts shouting "framework X is dead", and everybody starts focusing on the new hotness.
Has this ever really been the case in the past 10 years?
No, and not before that either. It’s a bizarre thing to say, honestly. React is used near universally, despite there being alternatives that are better in almost every way. That is the opposite of being under appreciated. Hype about a new technology, deserved or not, doesn’t mean that everyone is throwing their old code away, especially not their jobby job code.
It’s funny, personally I regard React as one of the frameworks requiring regular updates. So many teams that have spent so many hours shifting from class components to hooks based ones…
That seems like an impression you may want to update given the years that have passed. Hooks are coming up on 7 years old, and weren’t a breaking change anyway.
IMO a better description than “one of the frameworks requiring regular updates” would be “an old, stable framework that adds new features every 5 years or so without breaking changes.”
That's one way to sell a open source project I guess. Not only did Vercel really fight to not have any mention on the React docs about using React _without_ Vercel, but downright to using wording to imply that if you do then you're using it wrong. All clearly states the direction that Vercel is taking React. Soon enough it'll be Vercel-only software.
Yea Vercel being included in this also is a bummer to me - but honestly if history told us anything if they are making some stupid decisions, like completely vendor locking it, it wouldn't take long until a community maintained fork will be created. Same story as Valkey, OpenTofu, MariaDB, NextCloud and so on.
Oh yeah, and there already is (preact, for example). I'm not worried about losing front-end SPA libraries. If anything, I'm just annoyed at the endless greed of VC funded firms.
Is it me, or does $600,000 a year (presuming that $3M is over the 5 year period) seem a bit of a weak contribution from a company with a $1.8 trillion market cap that's regularly making $100M-$250M TC pay packages for AI scientists?
Like, I get that nothing is _owed_ here, but this feels like more of the same tragedy of the commons open source problem we see: tools that millions of apps depend on, barely propped up, and in this case, the child of a megacorporation that could easily create a proper evergreen endowment rather than a milquetoast token contribution to save face.
Somehow because Meta has released a popular OSS library and dedicated over 10 years of engineering resources to it (that has generated immense value for the wider ecosystem), that they should've shelled out more than the $3M they're contributing in order to give its ownership away to a non-profit.
Maybe it's just me but I think they've contributed more than enough. I'm grateful for what they've already contributed and anything else they choose to contribute in future.
You're right, $3million is a lot for an open source project, with no other context.
But in the context of who that $3million is coming from, how much they have available, how much responsibility they have for the state of it, and how much value it provides to everyone who isn't them, I think it's fair some people might have expected a little more.
They also have a team of full time react devs they are paying for. That seems to me more than sufficient.
$600,000/year just to run a governance board and organize a conference seems extraordinarily generous to me. In fact I think it's more likely the $3M is more likely to form an endowment for the foundation that will fund it's expenses running forward.
> They also have a team of full time react devs they are paying for.
For now. My guess is they will be included in the next round of layoffs. Money for $100 Million pay packages for AI researchers has to come from somewhere!
I do think I read that as being _part_ of the $3M, not in _addition_ to, which absolutely increases the overall value of the contribution, likely materially.
The post said they would also still pay for their own internal team that would keep contributing code to React, so it feels more like their throwing in $600k in addition to what they already do. And they have brought inn other companies who hopefully also contribute money, seems like a lot more of an healthy situation than before.
Let's round their yearly revenue at around $160 billion, then assume they've spent $3 million a year on React. That would put the cost at 0.002% of revenue, or to put it another way, if they dedicated just 1% of revenue to philanthropy, they could fund 500 React sized projects indefinitely.
It's not scary. It's a pretty small API surface. Lots of time is spent on component styling and all that stuff, which isn't React-specific.
Web components tech such as Lit might be part of the future, replacing JSX, and then React purely becomes a middleware tool for DOM diffing and shuffling events up and data down.
Would you still say it's a small API surface? State, memos, callbacks (which are just memo functions), effects, effect events, reducers, context, external stores, special handling for any tags that go in the `<head>`, form actions, form status, action state, activities, refs, imperative handles, transitions, optimistic updates, deferred updates, suspense, server components, compiler, SSR?
Or maybe it's a small enough API but a lot of concepts. Or maybe I'm just grumpy that the days of "it's just a view layer" feel long ago.
IMO OP is correct that the bootcamp devs are scary, not React itself.
I’ve interviewed a number of engineers who have very little grasp of what the DOM is and how it works because React abstracts the whole thing away. Server components are another are where some niceties mean a bunch of developers aren’t really understanding what’s going on with underlying HTTP requests.
While React’s API surface is small the average app will come with a chunk of extra stuff: Redux, next.js, yadda yadda. People take entire courses that never leave that bubble.
They are not. Extending JavaScript with an XML-like syntax that transpiles down to composable function calls feels far more natural. In contrast, extending HTML with a template syntax feels limiting and less intuitive in practice — thats why these frameworks are unlikely to ever reach the same level of traction as React.
I think the point is not that there aren't alternatives—there were plenty of jQuery alternatives—but that React is the dominant force, and this too shall pass.
while jquery had a gajillion of exotic apis to do pretty much everything, react is, frankly, pure js with handful of apis: jsx (html with pure js), useState/useEffect/useMemo (rarely you need more), and initial hydration function. Rest is utility libraries, bundler, and all the wondeful things that brings you endless headache and depression because without them fulfilling yet another business req would take 10x more time
Governance by mega-corporations working in a cartel. Having read this recent article [https://lithub.com/how-american-tech-cartels-use-apps-to-bre...], I fail to see how this is a good thing. Gatekeepers with self-interests at the heart of the decision making process.
It's extremely worrying on how they had to use a private "foundation" rather than using existing, more democratic, organizations like OpenJS foundation.
Don't expect user input, don't expect changes that go against their wants over the community's needs, and don't expect things to get better.
Readit News
Worse, Vercel is involved, and I literally don't remember anything good about that company.
I'd recommend to be very cautious with such news, and use older versions of React for the next couple of years.
https://react.dev/community/team
This announcement mentions they are separating business and technical governance, I suspect they are trying to limit Vercel's influence, and prevent them from taking it in a direction that only benefits them.
The maintainer of MSW has been screaming for years for people to drop jest [1]
[0] - https://github.com/faker-js/faker/blob/428ff3328b4c4b13ec29d...
[1] - https://x.com/kettanaito/status/1746165619731382351#m
Until recently Jest had a bug that made it crash due to sl (yes, the famous steam locomotive) running under the hood. This gives a hint at, ahem, the sophistication of its architecture.
The project is long in its EOL, and the only reason for its use is inertia, the jQuery kind of it.
I cannot for the life of me understand why anyone would intentionally pick it in 2025 unless there were serious constraints that forced them to.
Deleted Comment
Dead Comment
Being able to ignore parallel rendering, RSC, hooks, etc, and just write simple code for simple sites again would be fantastic.
Unfortunately all the major competition I've seen seems so significantly different that migrating any kind of non-trivial application would basically be a full rewrite. Is Preact or similar offering much promise here?
I don't understand this statement. You can use the basics without involving yourself with anything complex. You can even still use class components. You can build components that are framework agnostic.
yes, but literally everyone will tell you to move away from that. It's like saying if you're not physically violated then you should put up with verbal harassment because it doesn't matter in any real way.
At the very least whoever using class components would have to routinely defend their decision every quarter when confronted by colleagues who understandably just wanna write conventional code.
Things work, But I no longer know how they work.
Frustrated, I shifted to angular with signals, and now my cognitive load to understand data and events happening in the app are clearer and I feel I know what exactly is happening.
Not sure if this feeling is common, of helplessness with react.
None of the official docs helped, but I found myself required to use it for work. And I faced confusing behavior I could not explain with the documentation. So I went on a deep-dive for a month or so. I didn't learn everything about react, but I got an intuition for how hooks work. That's not to say I like them. I'll use them now only if I have to, but at least I can. To my mind, hooks present a surface that's difficult to make sense of and hard to use.
Is that not every software development effort, ever? Isn't that why "todo" apps, search engines, etc, constantly get "recreated". Live long enough to become the enemy and get replaced by a bare bones app that'll bloat itself into oblivion and repeat the cycle?
https://en.wikipedia.org/wiki/Unix_philosophy
Oh, dear. Yet more ways of dealing with React that coders will be forced to deal with. But in a way this might be good for engineers because the quantity of foot guns available in various flavors and versions of React appears to have already scaled far beyond the capabilities of available LLMs to handle.
In one of my recent doomed interviews I explained that I had been following React for a while and was practiced at a number of ways of using it. Developers in the group then kindly informed me that the reason I had learned multiple ways of using React is that I had not yet found the one true way which of course they were using. Got no offer from them which is probably good for all of us.
I think the signals integrations are great added value to the "classic React" formula.
Light weight bundles too, can't recommend it enough.
One is the DX as you mentioned; eg Hugo is nice, but editor integration for autocomplete, warnings, etc is basically non-existent that I’ve seen. Templating is also really clunky relative to React.
The second is Reacts omnipresence means there’s usually pre-built stuff I can pull in if I just want to iterate fast.
The third is that typically the best way to get a low complexity and good DX static site generator is just to roll your own with only the features you need. They get a lot simpler when you aren’t dealing with an ever-expanding list of feature requests and usecases. You decide whether you want types or editor integrations or whatever by duct taping together a few libraries.
(I'm not entirely sold on Svelte 5 for the same role - I think it gives up some DX - although maybe I just like the thing I'm used to.)
I don't care about the CEO's political stance, but Vercel's involvement with React has rubbed me the wrong way since the start of development of RSC. The development was basically behind half-closed doors, pretty much tied to Next.js (i.e. Vercel) and with zero specs except a high level description of what they were and their public API.
I don't care that they were WIP: the community should've been involved, not Vercel as a benevolent dictator guiding their design from start to almost finish. Such a huge paradigm shift shouldn't have been dictated by any particular entity... and IMO much less Next's team which I think are prone to overengineering and bad decisions.
IIRC there were points in time (maybe even currently?) where you had to use packages that were published to NPM but not even on any public repo.
I love the idea of RSC but that's where my love ends.
I thought I was alone on this.
If there was a component library as complete as MUI for Yew/Dioxus/Leptos I'd have likely already switched to Rust/WASM.
It's dead simple but only supports static components. Something like RSC would allow me to automatically cook a bundle with only the interactive parts (think e.g. a custom dropdown or whatever) while still remaining fully static.
Now I'm not so sure given how they're developing...
[0] https://github.com/alvaro-cuesta/alvaro.cuesta.dev/tree/mast...
Dead Comment
Dead Comment
I have a Clojure/ClojureScript app using React that I've been maintaining for the last 10 years. I don't use all the features of React, in fact I could probably use a much smaller library — the biggest advantage is that it provides a "re-render the UI based on app state change" model that fits Clojure very well. But I'm very happy that React is there and that it's been maintained with relatively little code rewriting necessary over the years.
Has this ever really been the case in the past 10 years?
Its gotten so bad that when I read FE dev I interpret it as "React Dev".
backwards compatibility is underrated
IMO a better description than “one of the frameworks requiring regular updates” would be “an old, stable framework that adds new features every 5 years or so without breaking changes.”
You don't need React for this. Vanilla JS is all you need, along with JSX and Web Components. If you are wondering how maintainable that would be see this example: https://github.com/wisercoder/eureka/tree/master/webapp/Clie...
Like, I get that nothing is _owed_ here, but this feels like more of the same tragedy of the commons open source problem we see: tools that millions of apps depend on, barely propped up, and in this case, the child of a megacorporation that could easily create a proper evergreen endowment rather than a milquetoast token contribution to save face.
Or should we just be grateful?
Somehow because Meta has released a popular OSS library and dedicated over 10 years of engineering resources to it (that has generated immense value for the wider ecosystem), that they should've shelled out more than the $3M they're contributing in order to give its ownership away to a non-profit.
Maybe it's just me but I think they've contributed more than enough. I'm grateful for what they've already contributed and anything else they choose to contribute in future.
But in the context of who that $3million is coming from, how much they have available, how much responsibility they have for the state of it, and how much value it provides to everyone who isn't them, I think it's fair some people might have expected a little more.
$600,000/year just to run a governance board and organize a conference seems extraordinarily generous to me. In fact I think it's more likely the $3M is more likely to form an endowment for the foundation that will fund it's expenses running forward.
For now. My guess is they will be included in the next round of layoffs. Money for $100 Million pay packages for AI researchers has to come from somewhere!
is probably worth more in practice. The $3m will basically just cover 'founding the foundation' I guess.
I do wonder whether this is a sign Facebook may no longer develop new stuff in React.
React is obviously the "new jquery", and something else will come one day. So many specially boot-camp devs are "react only" devs.
Scary stuff.
Web components tech such as Lit might be part of the future, replacing JSX, and then React purely becomes a middleware tool for DOM diffing and shuffling events up and data down.
Or maybe it's a small enough API but a lot of concepts. Or maybe I'm just grumpy that the days of "it's just a view layer" feel long ago.
I’ve interviewed a number of engineers who have very little grasp of what the DOM is and how it works because React abstracts the whole thing away. Server components are another are where some niceties mean a bunch of developers aren’t really understanding what’s going on with underlying HTTP requests.
While React’s API surface is small the average app will come with a chunk of extra stuff: Redux, next.js, yadda yadda. People take entire courses that never leave that bubble.
"Something else" is already here and has been for a long time. Vue and Svelte are both excellent alternatives.
Why? When jQuery went away nothing happened. People just learned the new frameworks.
And it might never unless browsers implement better DOM apis.
The current DOM API implementation reminds me of that quote:
"look what they need to mimic a fraction of our power"
Dead Comment
Don't expect user input, don't expect changes that go against their wants over the community's needs, and don't expect things to get better.