The React Foundation
engineering.fb.com
engineering.fb.com
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.
The maintainer of MSW has been screaming for years for people to drop jest [1]
[0] - https://github.com/faker-js/faker/blob/428ff3328b4c4b13ec29d...
The ultimate win, of course, would be to use the native Node test runner. See the sourse of the Node.js website - I think they have pulled it off despite running a Node.js app.
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.
If you've ever used any other test runner, you'll find Node's is woefully inferior. I'd say "but maybe it will get better", except I've seen the maintainer responses to several issues, and it seems they are wedded to bad architectural decisions that keep it that way.
But I wasn't using a lot of Jest features anyway, generally preferred Mocha even during the height of Jest's popularity, and Node's test runner is sufficient for most of my needs (and Deno's starts to seem more and more the path forward as I come to prefer deno.json in a lot more types of projects than package.json).
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.
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.
And so in that sense, the answer is web components. I know everyone hates the API but it was intentionally designed to be a low level thing to build a developer experience on top of and the best implementation of that right now is Lit. It’s also a pleasure to use and incredibly lightweight and designed to become even more lightweight overtime as new capabilities come to the web like signals in JavaScript or talk of native templating etc.
There is another option that I really like for certain kinds of applications which is Flutter which might sound contradictory to my original point because it skips the idea of the DOM entirely and brings its own rendering engine to a canvas element.
But it’s set to be the first serious Wasm and WebGPU based UI library on the web and has no problems spitting out 120fps (this is before even they have actually added WebGPU support and their newest rendering engine to the mix by the way) while keeping its rendering engine to I think about 1.5-2mb in size. It also gets you a single codebase that will run literally anywhere as an AOT compiled app.
That’s to say nothing of Dart itself which I cannot even begin to describe what a huge improvement it is over JavaScript and Typescript. If you haven’t tried it yet, do yourself a favour.
I’m just making the point that JavaScript and the DOM are no longer the only players in town and when you’re not trying to mix abstractions of a document markup language and an application a whole lot of problems just disappear like does this look different in different browsers or can I use this new feature etc.. it just works… everywhere… on the web.. on a desktop.. on a phone or an IoT device.
But my point stands. I haven't seen a single job posting in 2 years that isn't using React, Vue, Angular, or (a tiny bit) Svelte. So Web Components just aren't being widely used, it seems.
The only exception is about job postings and react, I’m not making the argument in any way shape or form that that isn’t the overwhelming majority of jobs out there, but that wasn’t what I was talking about I was saying it’s an actively bad choice for a project in 2025.
I think maybe you might be mixing up some things here which is that there was once many years ago a version of Angular which was written in Dart which exists internally and powers AdWords but no longer exists publicly. Perhaps that is why you’re thinking of?
A Flutter and Firebase developer who goes by the name xeladu wrote that after a discussion with an unnamed “Google developer expert,” the developer wouldn’t recommend learning the language, but added it’s not time to port Flutter projects just yet.
“I’d rather say no to be totally honest. Only do it if you just want to play around. Then it will be fine,” xeladu wrote. “But becoming a serious professional Flutter developer could probably be a waste of time.”
https://techcrunch.com/2024/05/01/google-lays-off-staff-from...
I'm also not trying to be rude but you said a lot about React and offered a myriad of Google solutions to fix it, most of them got downgraded by Google itself and are on their way to the famous Google graveyard. Telling us about a problem and that Google knows how to fix it is indeed rude.
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?
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?
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.
And you may have to work with developers who have a different preferred subset.
Hooks do not work as real functions. They are magic. Why are they magic? I don't know, they certainly don't need to be. What state do they change? I don't know. Why do they look pure but actually mutate the application states? I don't know.
Why is react not reactive? Why is it if I change state the entire website rerenders? I don't know. React has a virtual dom. It knows when I change state because I have to tell it, manually. And then... It doesn't use those.
But it's okay, because you can `useMemo`. Why do I have to do that? I don't know.
Evidently I don't have to do that, because react has a compiler that does it automatically now. Why can't react just do it? I don't know. Clearly it's possible. And also every other framework does it.
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'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.)
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.
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.
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.
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...
(conveniently ignoring that they're likely two of the only platforms that will ever want to take on the complexity of a non-toy RSC deployments)
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?
It is absolutely true that companies were rushing to rewrite their code every few years when the new shiny JS library or framework came out. I was there for it. There was a quick transition from [nothing / mootools?] to jQuery to Backbone to React, with a short Angular detour about 13 years ago. If you had experience with the "new" framework you could pretty much get a front-end gig anywhere with little friction. I rewrote many codebases across multiple companies to Backbone during that time per the request of engineering management.
Now, is React underappreciated? In the past 10 years or so I've started to see a pattern of lack of appreciation for what it brings to the table and the problems it solved. It is used near universally because it was such a drastic improvement over previous options that it was instantly adopted. But as we know, adoption does not mean appreciation.
> React is used near universally, despite there being alternatives that are better in almost every way.
Good example of under-appreciation.
However 0 of the typescript projects (front and back end) I've worked one (unless I was there when they started) used strict mode so the Typescript support was effectively wasted.
I agree that there was a period where many organizations did rewrite their apps from scratch, many of them switching to React, but I think very few did it ”every couple of years”, and I think very few are doing it at all today (at least not because of hype - of course there might always be other reasons you do a big rewrite). We should not confuse excitement about new technologies for widespread adoption, especially not in replacing existing code in working codebases.
> despite there being alternatives that are better in almost every way.
This right here is the under appreciation. The new way to signal to others on forums that you are a really really great dev seems to be to bring up how much better some bizarro templating engine that abuses a niche JS language feature is.
Have you tried building anything with Vue or Svelte recently?
Can you provide some concrete issues you ran into beyond them being “bizarro”?
<script>
let numbers = $state([1, 2, 3, 4]);
function addNumber() {
numbers.push(numbers.length + 1);
}
const sum = numbers.reduce((x, y) => x + y, 0);
</script>
<p>{numbers.join(' + ')} = {sum}</p>
<button onclick={addNumber}>
Add a number
</button>If I learn Vue's templating language, then I'm spending my time learning a system with no wider applicability, a much narrower tooling space, that doesn't utilise my previous or future experience from JS. That's not a good calculus for me.
Vanilla
<script>
const form = document.getElementById("form");
form.addEventListener("submit", event => event.preventDefault())
</script>
<form id="form">...</form>
<form onSubmit={event => event.preventDefault()}>...</form>
<form @submit.prevent="onSubmit">...</form>
Vue's API has reinvented the wheel. There's one place this syntax is useful and one place alone - Vue itself. It hasn't used my existing knowledge, or pushed me to become more familiar with the platform upon which I'm building. That's not sugar, that's a new language.
I've probably got the vanilla example wrong - when you don't do it frequently it's not the most ergonomic thing in the world. React takes that API, doesn't deviate far from it, and makes it easier to use. Sugar.
The .prevent modifier in Vue is completely optional, you can call .preventDefault() yourself. Note that React also uses a kind of modifier but only for capturing events (onClickCapture etc). It does not have any way that I know to add a passive event, for some reason.
Vue is the one that actually offers syntax sugar, and does so much more consistently, with the semantics identical to the browser. React changes the semantics for unclear, historical reasons, and then adds half-baked syntax sugar on top.
- horrible performance characteristics
- needless complexity
These are not tradeoffs, these are bugs. We don't gain anything from them.
That's why React introduced a compiler. Because problem 1 is a big deal. But it's not a code problem, it's a React problem. Other tools simply do not have that bug. Which is why the exact same react code can be compiled and run much faster.
More importantly, I don't have a React performance problem. I don't really need "much faster".
Sure, but ultimately you're using a library with performance bugs that lead to orders of magnitude more rendering than necessary.
If you don't mind the buggy software, that's fine. It's still buggy.
AngularJS was pretty popular at the time, Angular 2 migration was looming, backbone still existed, jQuery (standalone or paired with both) was going strong, Polymer hit 1.0 and it looked like Web Components might actually be something and useful, React was gaining a lot of popularity, Vue was gaining a small amount of popularity, svelte an even smaller amount, Meteor was somewhat popular and had its own front end library.
Of course in addition to all that, traditional server rendered sites were more popular then than now and there were even more options there.
However, React quickly became pretty much the default. Not that there's 0 churn there. The "right way" to do React has changed quite a bit in the last decade. And early on before all the libs people liked to glue together somewhat matured/settled it was common to have to replace stuff that just got abandoned.
More than once I had to pick up someone's old unmaintained project to do a bug fix only to find I couldn't even get the project to install/run because it was in the pre auto lock file era and nobody ever ran `npm shrinkwrap`
Its gotten so bad that when I read FE dev I interpret it as "React Dev".
Its very hard to keep up with the frequent changes to programming models, new frameworks, CSS libraries (why the heck are they soo many?!) when you also have to design O(Log n) backends, IaC, Observability, LLMOps, etc.
I have come to a compromise and have started advocating for React/Redux/TS/NextJS as the default CRUD application stack so that I can focus on solving real CS problems in the backend that I’m passionate about.
These dependencies are the root of the issue.
FWIW, I've only ever professionally work with react on the frontend. For nearly 10 years too. My first job I was doing react.createElement() before classes were shortly introduced afterwards.
It's time that we move on to something better, and the react foundation being controlled by private entities while not being an actual democratic foundation is a good omen of what to expect.
By weird happenstance I got a job writing in a half-dead, compiles-to-JS language 5 years ago. There's one way to handle state in it. My view on the libraries you need to handle everything-but-view in React has been "I'll come back to these when the dust settles" and it just never settles.
Why? How?
>> but I'm sure people thought similar thoughts when jquery or angular were popular
I loved jQuery back in the day, and it helped bringing some native APIs to life thanks to its popularity.
Says who? There are plenty of choices: vanilla, Lit, Vue, Svelte, Angular, Riot, etc. Some of the alternatives are very good.
backwards compatibility is underrated
As it turns out you shouldn't use them because they were essentially deprecated a long time ago. But in terms of comparing the merits in a more theoretical sense, there are simply tradeoffs between the two.
Reacts insistence at the time on everyone should use hooks was hands down one of the dumbest things I’ve seen in all my time.
Not only was it on extremely shaky grounds technically but now you have huge swaths of developers have this extremely React specific mental model of building apps that translates poorly to almost everything else out there.
There is a reason why almost nobody else out there followed that trend. Classes are actually the ideal abstraction for building a component based on UI.
import React from 'react';
class WindowWidth extends React.Component {
state = { width: window.innerWidth };
handleResize = () => {
this.setState({ width: window.innerWidth });
};
componentDidMount() {
window.addEventListener('resize', this.handleResize);
}
componentWillUnmount() {
window.removeEventListener('resize', this.handleResize);
}
render() {
return <p>Window width: {this.state.width}px</p>;
}
}
export default WindowWidth;
import React, { useState, useEffect } from 'react';
function WindowWidth() {
const [width, setWidth] = useState(window.innerWidth);
useEffect(() => {
const handleResize = () => setWidth(window.innerWidth);
window.addEventListener('resize', handleResize);
return () => {
window.removeEventListener('resize', handleResize);
};
}, []);
return <p>Window width: {width}px</p>;
}
export default WindowWidth;
Why do I need to pass in an empty array? What could even go in there? What happens if I omit it (it is empty).
Where is the unmounting and mounting? What order do things happen in and when?
These have answers of course. The function runs according to the dependency array (prop, state, etc) and just on mount if empty. And the callback runs on unmount, if any. But you have to learn them. Before you do, it's magic. And when you step away, you have to re-learn it. And when it gets a bit more complicated, you're going to have to sit down and learn it better.
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?
They threw the resources behind RSC to make React, a framework for frontend reactivity, force opt-in for frontend reactivity. Meta is needed more than ever at this point, before React fully becomes a framework for burning compute on Vercel's infra.
I know almost nobody that even uses server side components. It's right out if your backend isn't node..
https://www.cnn.com/2025/04/25/tech/chan-zuckerberg-primary-...
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.
$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!
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.
If this went the other way where say FaceBook let people freely create accounts and talk to everybody and then later on either charged 10$/month, plastered the site with ads, or started to selling user data people would be upset about a bait and switch.
If you release something for free as you shouldn't be expected compensation for it. People also shouldn't expect anything beyond the terms that you've released it underneath as well.
Pro-tip: LICENSE files are just text! you can edit them. The license is the license, and if someone fucks that up, well, they fucked up. Don't want Amazon to use your lib? Just say that. I have very little pity for those that complain about this sort of thing. "Gratitude" has little legal standing, and expecting a corporation to be ethical is absurd as apologizing to your tapeworm.
If you really want a non-corporate license, there is always Baba Yaga, which no corporation's lawyers will want to touch. https://smallandnearlysilent.com/baba-yaga/LICENSE.txt
Let me try again to explain the view that you 2 are saying you can't see:
I don't have an obligation to donate anything to anyone ever - like you said nobody does.
However, I think people are entitled to hold the expectation and opinion that I'm a bit of a jerk if I'm super rich and choose to donate virtually nothing.
$3million is virtually nothing to a $3 trillion org.
Meta only has 1.8T Market Cap, but that number is meaningless and doesn't represent what they own or can spend, from last report they only have $12B cash on hand and have released over 600 OSS projects [1]. If they donated $3M to each of their OSS projects it would cost them 6.67% of their cash war chest.
But the point is, why should they? What benefit is it to their mission or their shareholders? Why should anyone be entitled to more than the decades of development effort and the $3M they're prepared to donate in order to hand the project to another foundation to take over?
I don't think you should be entitled and expect anything more, and we should all be grateful for what they've already contributed to OSS and what they will contribute in future.
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.
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"
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.
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.
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.
That abstraction was always leaky, in that it begged many more questions that had to be answered.
Part of the appleal was that it was limited in the perimeter, and part of the curent situation is that the community around React-the-library created the tools to answer these other questions, which means that React-the-ecosystem is much more complex than React-the-lib.
"Something else" is already here and has been for a long time. Vue and Svelte are both excellent alternatives.
You want to topple react, you need to solve a problem that’s as big as state management used to be in a way that react can’t also just copy/absorb, and you have to do it so well that developers will push to use it at work. You need to have a ux as clean as what React offers to its devs, and you probably need to come close enough in benchmarks to not get instantly shot down.
Why javascript, though? That preference, again, seems based on what you’re used to.
The actual goal is to manipulate the DOM based on state changes using a declarative representation.
Javascript seems more like something that was available rather than a good fit. (In fact, they felt like it was a bad enough fit that JSX had to be added to the mix.)
Setting aside any particular framework, HTML seems like a better fit to me… it’s inherently declarative and, of course, has a well understood, well supported relationship with the DOM. Extensions to bind state can be pretty well contained.
Subjectively I am extremely in opposition to the fact that XML anything with composable functions is more intuitive than HTML templates by any stretch of the imagination.
That makes sense, but that's not what react does. Components are functions of their "prop"s. The rest of the state comes from a memoized cache in a fiber. Which fiber? That's determined from a reconciliation algorithm. Does it do the right thing? Usually.
You can tell if it's "a function of state" by whether the state is in the parameter list.
Hard disagree. React became popular because it was much better than its predecessors like Backbone, and also better than its contemporaries like the first Angular. I was still learning JavaScript, when I was doing a browser app for my thesis, and I used Backbone as a framework. Awful experience, using React was much more intuitive. While Backbone was imperative, React was declarative, with composable components, no custom HTML template syntax. Using React made web development fun for me.
> extremely in opposition to the fact that XML anything with composable functions is more intuitive than HTML templates
And I hate HTML templates. I think there are just two groups with different preferences and therefore it's somewhat useless to argue about this stuff.
I like to argue about it because I like knowing why people think the way they do about React. I'm a long-time React hater and still look for ways to change my mind, so there's a point for me I guess?
Why would I choose to write html in js over writing it in html?
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.
-Sent from my 1T parameter LLM
This tends to happen with frameworks. A new one arises (next / react) and then over the course of many major version updates tends to just scope creep and try to do too much, or is monetized (next) and needs to find ways to justify people spending money on what was previously just free open source code.
At this point, I'm not interested in what they're doing anymore. I'm not starting new projects with React, and I'd move away from it for anything small.
And then you still can end up with stale closures.
The fact they are over-engineering the server-side rendering is a cherry on top. React used to prize itself as the minimalistic solution but now they invent abstractions just to feel smart it seems.
I don't understand what is so complicated about hooks. It's a good abstraction with specific trade-off s.
I think people forget that when React came out, it was awesome. Declarative, fast, and composable. I immediately wrote my own VDOM-based library ([1]), faster than React (probably with a lot more bugs, but my apps didn't have the same requirements as Facebook) - that's how inspiring React was. So many UI libraries :D
Also it's funny that some people think that it's just a big cartel that will force developers to use React forever, and others think it's inevitable that something better will come up.
There is a growing but already big third group of ex-React developers, even ex-React evangelists. You can see them in this thread and I think it is the majority of people talking about React's problems.
Hmm, I'm not sure. I would say the majority thinks React is fine, and that majority isn't writing angry comments on HN.
Feel free to jump in the Discord [2] with any questions.
Some other kids (and esp their parents) think this is terrible, that Marky is being cheap and Vicky only wants control of the playground. They don't like Marky and Vicky and try to hurt them every chance they get.
Also, for the new version of the toy you'll have to learn to play a new game as the old way to play with it'll become half-working.
At least that's what parents are afraid of.
We can feel nostalgia but the world is moving.
It is hard to predict how everything will be in 5 years.
Edit to add a simple example:
Musk's wealth is mostly tied up in Tesla -> You think Musk uses his wealth to wield political power, political power that makes the world a worse place -> You still think Teslas are good cars -> Even though you think that, you don't want to spend your money on buying a Tesla, because this will make Musk more wealthly -> Start at the beginning
Exactly, it is a human behind the company that does every decision. Company is just legal shield. Every decision is affected by what they really are or think.
This is called micromanagement :-)
I am sure there are organizations where the actual work that people do day to day is unaffected by who the people at the top are or what they think on matters other than the business (people at the top are often rather unpleasant anyway). I can't say whether such organizations are common or whether Vercel is one; but I believe I worked at such.
Whenever there is a decisions to be made about increasing profits, for example, someone needs to judge based on moral weight. Outsource to India? Do something gray and think legal matters later? Maybe there is no moral, and the company should operate based on the risk assessment of fines breaking the law and negative PR. In all cases, "what person is", highly influences the outcome of these decisions.
Let me give you a couple of different examples for comparison. Github blocked all users from Iran. Pnpm cut all traffic from Russian ips, whereas Linus Torvalds affirmed the removal of Russian maintainers of the Linux kernel. These are real adversarial actions, the like of which could impact my decisions about a company or a technology, if I were on the receiving end of those. Cowtowing to people in power and taking photos with hateful people is just an undignified behavior that is ultimately just noise.
It's only natural to think that way because these particular decisions are based on ones moral framework. It isn't like choosing a favourite tea. People will be pissed at each other when moral frameworks don't match.
> Cowtowing to people in power and taking photos with hateful people is just repulsive noise.
It comes down to what you said before. People have different views. It's noise to you. It isn't noise to others.
Vercel wants to own React, its been obvious about it for years now.
NextJS is a pile of garbage, and their platform is absurdly expensive and leans heavily on vendor lock in.
I hope this isnt the way that React as a whole will go in the end.
But fortunately there are enough alternatives about.
- inconsistent behavior between hosted and self hosted versions of the same code
- horrible build times, like laughably bad multi-minute builds for trivial code bases
- crappy directory based routing system with lots of weird gotchas
- schizo identity JAMstack -> serverless -> ssr -> now its microvms + ai
- multiple hilariously long running GH issues where the dev team is thrashing around trying to debug their own black box framework
- "framework" that barely provides any of the primitives necessary to build web apps
- major breaking changes around core features like routing that require painful migrations
- general sloppiness, churn, and insecurity that comes from being part of the nodejs ecosystem
Thats not even getting into all of the shady patterns vercel uses to lock you into their overpriced hosting.
I've been a part of multiple teams that decided to build apps using NextJS, and while the FE is not my responsibility I typically got pulled in to help troubleshoot random issues. It was a complete waste of time in almost every case, and in one case resulted in the entire FE team being let go because they were unable to ship anything on time.
I like the simplicity of Hono and use their html helper to write good old HTML that is send to the client.
"State management" really isn't that much of an issue on the server. Only on clients, when you need to map state changes to DOM updates.
The real issues were the super tight coupling with MongoDB and their decision to roll their own package ecosystem instead of just using npm from day one.
Lots of apps are still stuck in Meteor 2.x hell because of the dependency on Fibers though.
I won't repeat what the sibling poster said, but I can tell you, I've been using NextJS from v12-v15 and in that time we've had:
- The catastrophic (and, at the time, UNDOCUMENTED) "aggressive, opt-out caching of all fetch calls", which confused the living daylights out of everyone who suddenly couldn't retrieve updated data from their servers. Like, don't override a native JS function that's supposed to work in an expected way, with black-box magic that adds caching behaviour that then needs to be overriden _per route_ with directives on each route. Cache headers can be added to fetch calls and are easy to configure globally via axios if needed. If you're going to do black magic, call it "nextfetch" or something
- The app router / page router transition was shockingly badly handled, with so much missing documentation around dynamic routes
- I don't know how many different ways of fetching / setting metadata / <head>-related techniques I've had to learn by now. It seems to change all the time. BUT, that isn't the worst part....the worst part was / is:
- You couldn't, for the longest time, fetch metadata for a page without duplicating fetch requests. I think this is where their fetch-deduping thing came from. But again, black-box magic on a native JS function with very inconsistent behaviour, so for a while, all pages in our app just had to make two fetch calls per page that needed specific metadata added to the <head>
- Vercel as a platform not allowing to set billing limits (have fun with your DDoS that they don't recognise as such)
- Middleware is one file. That's what you get. No chaining, nothing. One god-function for everything. Just think about the anti-pattern that is
- I don't know whether it's clever or terrible, but if you want to add a sitemap, you do so by defining a route by creating a folder called sitemap.xml (yes, a directory), where you then put your route.ts which is in keeping with the way the new router should work. But somehow it just doesn't sit right with me. Folders with file extensions. But it also adds a lot of ability to make the sitemap highly customisable and dynamic, so maybe it's ok
- You suddenly needed to start awaiting url params, cookies, etc. which is sort of fine, but was a huge change causing warnings all over the compiler for months and months
Anyway, those are just a few things off the top off my head. I already find React to be quite counter-intuitive and non-deterministic, but NextJS just adds a layer of pain on top with very, very few advantages.
I am dying to get my hands on an alternative, but also don't want to rebuild all of the apps I built when I was still optimistic about NextJS.
Whoever implemented that has no idea how middleware is supposed to work.
I only vibe code in my Metaverse open office by thinking with my Beta NeuralLink.
I kept wondering if there's something wrong with me or if a framework recommended in so many places can really be this shitty, until I read your comment.
CVE-2025-29927 – Authorization Bypass Vulnerability in Next.js: All You Need to Know
https://jfrog.com/blog/cve-2025-29927-next-js-authorization-...
Vercel and Next.js have been the main testing ground during the development of React server components as well.
How much has Vercel contributed to the development of react over the past years?
The last truly useful react feature for me was error boundaries in React 16 (2017?) and I think hooks was react 16 too?
These days if I need ui components for an existing SSR app I just use web components or lightweight libs like mithril.
It also alienated a huge part of the userbase that decided to move away from React.
the official recommendation we got was to just run it on vercel
I would go as far to say that nextjs is not self-hostable in its current state if you expect high traffic and low latency.
It's designed to be deployed on Vercel. Production-ready hosting part of the Framework is not Open Source nor well documented.
https://github.com/vercel/next.js/discussions/59167 https://www.netlify.com/blog/how-we-run-nextjs/
He is a programming prodigy, and that's it. Not a nice person.
Nevertheless, my anecdote should only be taken with a grain of salt... After all, the only person that probably has backups of foropelle is Rauch himself. And who cares what a teenager had to say back in 2006?
1. Vercel / Next are complete technical trash wrapped in egregious vendor lock-in. This directly influences their desire to steer the react foundation in a direction that aligns with their roadmap for Vercel/Next.
2. Their CEO thought it would be a good idea to have a photo op with perhaps the most controversial figure in world politics. This just means he's not nearly as smart as he thinks he is and likely needs a handler.
moreover, this entire initiative looks like a way to reduce vercel's influence, so if you want to be mad, then be mad in 5 yrs, not now.
…people paying for react.
Which is fair, but do we have bend knee and suggest they have the best interests of the react ecosystem at heart? They don’t.
They are invested in: people using next.js and hosting it on vercel.
If that’s not what you’re doing, their interests probably don’t align with yours.
Far too many smart people are putting their energies into such discussions that add a lot of drag to the process of society and humanity moving forward for no net gain at all.
The CEO's politics are just icing on the cake.
Edit: apparently there's some confusion about my comment. I neither use, like, or support Next. I just found it suspicious that a bunch of new accounts showed up making generic comments in support of OP, which to me was a red flag.
your comment would be a lot more interesting if you attempted to pose a counterpoint besides "BOT!".
I think a somewhat neutral summary (of someone still annoyed by Vercel/Next) would be like this (Notice the distinctions between Site and App, not always clear cut but a dividing line imho):
- React was created by FB to solve real technical issues as their frontend became larger and more complex.
- Site creators liked it as it was one of the solutions of a real issue of reconcilliation of state and view (that often wasn't so bad in the big picture) but React was often a bit heavyweight, App creators really loved it as state reconcilliation took away that entire class of bugs that just became so much worse quickly as Apps grew (and React allowed for more people to create larger apps).
(Angular and Vue has always done this also, they are parallel developments)
- Pressure from those doing sites has always pushed development of React to be "simpler", often good for most parties (even if I think that Redux was mostly thrown overboard prematurely).
- Part of simplifications was bootstrapping, create-react-app became one of the recommended ways to start projects (and was also incorporated into other toolchains such as .NET templates)
- Heavy builds, disabled JavaScript and SEO issues was teetering issues (especially for public site builders), not entirely sure of the inspirations but Next did solve that (perhaps not always entirely elegantly initially)
- React internals start to change to better support these scenarios, nobody really has objections since changes in React has seldomly been for the worse (functional components, hooks, etc). Vercel gains traction as a "do-good" choice.
- After all troubles of OpenSSL, Node finally adopts OpenSSL 3.0 thus breaking create-react-app that had been "deprecated" by the React team (it's easily shimmable but it sent people looking).
- People looking for options find that the only "official" way to use React according to the site is to use Next, so many start adopting it out of fear of being left behind again.
- The Next model however is quite different and tailored to "site" builders and/or people running the full stack in JS
- React however is quite popular outside of the JS only world for enterprise SPA and/or mobile apps where trying to shoehorn in a Next "frontend-backend" becomes overkill and extra complexity. (We used it for one or two projects but have now abandoned it for our regular work).
- The React site is updated slightly, Vite and similar are now mentioned but the perception damage is there and hasn't let go (and last I checked using f.ex. Vite was not "recommended" as being an inferior option to Next for React usage)
- A very popular option for CSS-in-JS (styled) becomes deprecated due to React internals changing for Next and requiring significant rework that the original author had no interest in (no really clear successor with support across the board for Next, SPA and React-Native scenarios hadn't appeared last we checked).
Now this is my perception of events and I'm pretty sure that I'm not alone in this, the Next/React authors felt like it was the way forward due previous feedback for those that hurt (site builders) but probably misjudged or didn't appreciate how much React was used in other workloads(apps) that got disturbed while they were improving their thing.
That Vercel has managed to alienate people in other ways like billing (or politics?) certainly doesn't seem to have helped either.
Seen a lot of people in my professional circles shit on Next/Vercel over beers, but then go to work every day and bang out Next because it's what their manager chose 5 years ago.
Vercel can only ride that wave until the people who hate their product are the decision makers.
I thought I dreamt (nightmared?) this, but it happened? Hoe did they pull it off?
The React site recommends a full-stack framework for most users getting started, but Next, React Router v7, and (for native apps) Expo are all highlighted options, and two other additional frameworks are also described as up-and-coming options.
The site also describes a from-scratch options for “if your app has constraints not well-served by existing frameworks, you prefer to build your own framework, or you just want to learn the basics of a React app”, with specific instructions for Vite, Parcel, and RsBuild.
There's a legitimate debate to be had, I guess, about the whether the getting started should be optimized toward the lowest-distraction approach to learning basic React or toward what is expected to be the most common production use case, but they seem currently to have decent coverage, concerns about order of presentation aside, of a range of options.
Just that before those specific instructions is again a big "deep dive" box that recommends "consider using a framework".
And yes, I can get the arguments about a easy to get started focus but React is also a more foundational library that has many uses outside of frameworks. Should cppreference.com recommend using QT or MDN and Node.js homepages recommend using Next because "it's easier to get started" ? sure, a tad hyperbolic examples but on the same par.
They have made egregious mistakes that go far beyond "move fast and break things" and well into "we should have the lawyers join this call".
I've also built commercial apps in other stacks and they also have their warts.
What I've noticed from the other stacks, however, is that the frequency of entirely unnecessary issues is simply lower. React and NextJS aren't going anywhere and one can hope that these things will improve over time.
Ultimately, it's also a great employment guarantee, as companies will need people to maintain the apps that are constantly changing.
I think applying scepticism to Vercel and its motives is healthy, still.