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]
Man we have started with Jest tests for our React Native App half a year ago and now we should already drop it? What should we use instead?? Vitest? How's the compatibility? I'm so exhausted man, glad I'm qutting JS dev soon hopefully.
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.
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.
Any idea what people have generally moved on to? Currently using jest but its definitely showing its warts often and is pretty slow. Curious if there is an obvious successor.
Vitest is the incumbent I would say, but there seems to be a lot of momentum behind the runtime-builtin test runners recently. Bun is gaining traction like nothing else, and node has put a lot of work into the test builtins lately.
Node's test runner is a non-contender, at least right now.
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.
The node test runner is perfect for small libraries without build where you pretty much ship the source code. The assertion library is actually superior to vitest’s if you don’t use spies etc. because unlike vitest’s assertions, the node ones do type narrowing correctly.
I moved back to Mocha with Chai for a while (both have great ESM support, quietly still well maintained, despite predating Jest) and then to Node's built-in test harness (and Deno's), sometimes still using Chai rather than `node:assert/strict` or `jsr:@std/assert`.
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).
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?
After doing this for so many years now and one thing I’ve really come to see as a fairly fundamental truth at this point is that the more you can align with the underlying platform you’re working with generally the better.
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.
I thought Google had already killed Dart once? Or was it Flutter? I'm not really touching any of their “open-source” projects; fool me once, you know.
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.
I’m not trying to be rude in any way here but literally everything you have posted here is incorrect. I don’t know where you’re getting your information from.
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.
Until they dump your startup for no reason, and you'll have to migrate off their undocumented proprietary infrastructure. Please read stories on HN. You're risking your business if you work with them.
> Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken.
This is just silly, Don. HN has gotten so mired in negativity that someone who's a genuine fan of a product, and dares to go against the narrative is now a "shill." Also: see definition of shill. I'm just a happy user that runs a startup, and my life is easier because of their existence.
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.
I feel like that's more of an issue with the examples and LLMs? Discounting a framework just because it has ever increasing, completely optional capabilities doesn't compute to me. I'm not convinced there's a real problem.
The problem comes in when the complexity is both not optional and not rational.
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.
There are real functional libraries like Effect, pretend functional library like React and just honest old style library like MobX. I think I know my preferred style.
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.
Every fiber has a parent. I suppose the behavior, although possibly not the implementation, is that the ancestry chain is walked up until the nearest context provider is found. That will be the fiber associated with rendering context that provided the context.
> 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...
RSC should never have made client support opt-in. During RFC it was identified as a problem, but Shopify and Vercel pushed for an intentional breakage "for the greater good" in driving adoption.
(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)
And not merely by contrast with the fact that React is such a depressing drag to work with -- Svelte is independently joyful and refreshing, in an of itself! The "oh thank God I'm not using React" feeling is just a bonus.
Increasingly bloated and complicated frameworks with intangible benefits used for webpages that are now just training data for LLMs is much more important.
Very fair! I only came back to edit it because right after leaving that comment I went to see if Best Buy had something I needed locally, clicked into search, typed, hit enter, and it fucking broke. Seemingly entirely, even the search button didn't work, so cmd+a, cmd+c, cmd+r, click in again, paste, enter, and that worked.
I just fucking loathe how common this experience is now. Amazon seems to be the only one that doesn't do it, but I've experienced this exact issue on Best Buy, Target, Etsy, Mercari, ebay, and it just DRIVES ME UP THE WALL.
In this case people are critical of other things also and want to voice those things for selfish reasons without getting into mud slinging contests with fanatics who are protecting everything shitty just because it's their favourite hater that is on one side.
Perfect is the enemy of good and an ally of fanaticism.
> Are you suggesting that vercels CEO is to be compared with Adolf Hitler
No, Netanyahu.
Who Vercel's CEO recently posted for a selfie with on X, wishing "greatness for Israel" without mentioning the genocide being committed by that person right now.
> For me, Vercels CEO statements made me realize I am ditching Deno Deploy for Vercel. Finally some tech ceo with good values
Hands down one of the cringiest things I've ever read on this site. And it's why people don't take HN seriously. It's filled with a bunch of 13 year-old "edgy" narcissists who can't code.
"Ok dude". Weird that I have been 13 for over 20 years by now and I guess I haven't learned to code while working for as programmer for more than 15 years. I must be the best con artist in the world since I've been getting a paycheck for all this time.
I think you're being way too charitable with Vercel's CEO. I don't doubt he came up with some way to justify to himself that what Israel is doing is completely necessary and reasonable. But I doubt you can get access to a press conference with Benyamin Netanyahu, then get close enough to shake his hand and take a selfie, then post the photo on social media with a tagline of the likes of "eternal glory to Israel" while having no idea of what is actually happening there. Either he's really that clueless about the world (in which case, how can he be CEO?), or he knows about the genocide and fully supports it.
> so I will give it exactly 0 seconds of thought when commenting on it.
You opened your post literally giving your thought about his political stance. Had you completely skipped this part, we'd be only discussing React and not Vercel's CEO stance.
Edit: Your quote can literally be understood as "His take doesn't bother me". If you didn't want to discuss this, you could (like someone else said) have worded it better to avoid confusion.
>Vercel's CEO political stance has zero impact on React's health
Sure it does! ReiserFS's popularity went way down after he murdered his wife.
And that's only from murdering one women and no children or men, so Reiser count of one kill (and holding steady) can't hold a candle to Netanyahu's mass murder kill count, which is rising fast by the day.
Why? Werner von Braun shouldn’t have been employed by the US, I think you’d agree. But also, his Nazi background didn’t preclude him from being a useful rocket scientist. Why does someone’s political ideas have any bearing on the merits of that person’s OSS technology (the thing this article is about).
>lol. The moment Guillermo posted that picture, the internet was awash with blogs and pieces about how to move away from Vercel (who everyone now sees as the stewards of React).
This is actually kinda hilarious to have to respond to and explain to.
>Just because you don't have principles, doesn't mean other people don't.
>Cmon. You can't possibly believe actions don't have consequences, do you?
That's not in the comment I replied to, but your quotes are a good example of why I'm asking you to give the guidelines a read through. This is an inappropriate way to express your disagreements.
> I don't care because I'm just analyzing Vercel's stewardship of React, and Vercel's CEO political stance has zero impact on React's health.
Just so that I'm following: You're saying that how the CEO is viewed does not in fact impact the company they are heading? And that the wave of people migrating from Vercel in light of Guillermo's post will not have any effect on React?
Obvious troll is obvious. I shouldn't have taken the bait but for a second I wanted to assume good intentions. You are obviously not asking in good faith and just want an excuse to act self-righteous.
lol. The moment Guillermo posted that picture, the internet was awash with blogs and pieces about how to move away from Vercel (who everyone now sees as the stewards of React).
This is actually kinda hilarious to have to respond to and explain to.
Just because you don't have principles, doesn't mean other people don't.
Cmon. You can't possibly believe actions don't have consequences, do you?
Commenters here are experts in react and have interests in technology, or are looking to understand more about these topics. No one reading here is an expert on geopolitical issues. You're just connecting on the wrong post, and probably the wrong website, if you want to talk about these things. There are places for that, but it's not here this comment section and if you keep trying to make it that you're just going to get down voted over and over.
But who has become the defacto steward of React over the last 5 years? Vercel.
Whose CEO has made a lot of news recently for their political views? Guillermo
What front-end framework library now needs to distance itself from Vercel as it's main steward? React.
IT'S ALL POLITICS. That's the entire point of the foundation. That's what this whole discussion is about.
> No one reading here is an expert on geopolitical issues. You're just connecting on the wrong post, and probably the wrong website, if you want to talk about these things
I don't know, I see a lot of posts and threads here of people discussing geo-political issues. Not just for the sake of it of course, but because politics is everywhere and affects everything, because technology is always going to have some form of politics attached, and because everyone is a political actor in their lives.
Separating fully any technology news and political happenstance is impossible. Now of course it doesn't mean every topic should devolve into identity politics, but having discussion about how and why things are they way they are is inherently political.
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.
I think it's because around 2015 or so there was a lot happening with front end frameworks, and the sentiment comes from then and people have just not updated their priors since.
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`
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.
Having worked in both over the years the main technical thing React had going for it over Vue, in my humble opinion, was much better Typescript support. Otherwise they are both so similar it comes down to personal preference.
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.
No, I was also around when React was new, moving to it from tangles of jQuery and Backbone. I absolutely know React brought several lasting innovations, in particular the component model, and I do appreciate that step change in front-end development. But other frameworks have taken those ideas and iterated on them to make them more performant, less removed from the platform, and generally nicer to work with. That is where we are today.
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.
I read parent's comment as an assertion that the current "fast-moving JavaScript world" expects everyone to rewrite their app. Personally I've never seen this, but since React became popular ~13+ years ago, I struggle to believe this has actually been true for others in any meaningful way.
React often gets lumped into general JavaScript hatred of the form “the entire ecosystem of tooling/frameworks/libraries changes every few months.” That’s despite React existing for one third the lifetime of the World Wide Web. React is older now than jQuery was when React was first released.
Although aside from JSX, so much has changed it could’ve been a new framework at least once, and part of its longevity is that it doesn’t bundle a router, form handling, etc, and the popular ones of these have changed many times.
> 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.
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.
You haven't described those "fundamental problems" that you call bugs, but I think these are irrelevant for me from a ClojureScript point of view. As an example, immutable data structures mean that equality comparisons are cheap and I can often avoid re-computing and re-rendering huge parts of the tree.
More importantly, I don't have a React performance problem. I don't really need "much faster".
JSX is just sugar around JavaScript, and interops nicely with it. I'm okay with that. The more I write JSX, the better I become at the programming language I'm using. Concepts and patterns in JS can be adopted in my components.
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.
React's API has guided the developer to learn about events. If they move outside the React ecosystem they have transferable knowledge. As someone unfamiliar with React, but used to the DOM you're surely comfortable here. Yes, the syntax isn't identical to how you might use this in vanilla JS, but it's clearly the same concept. It's just been made a little nicer to use - the sugar.
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.
Fun example! Strange conclusion. React actually uses a synthetic event system that is subtly different from the native one in all kinds of little ways. In reading the docs it’s hard to even get an overview of what’s different. Bubbling is a bit different, onChange works like the input event for some reason, various props and methods have been added. This is not the case for Vue! It just uses standard events.
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.
I'm not claiming React is perfect by any means, and like any popular relatively longstanding project is is bound by sometimes unwise historical decision. It just seems to be currently in vogue to take a pop at it. If you want to extol the virtues of Vue/Svelte/whatever then great, but React is still IMO a great option and deserves some defense.
The "in some circles of the fast-moving Javascript world" is important - they're not saying everyone or even most, they're saying proponents of the "better" systems (who do rewrite regularly) dismiss React's stability as unimportant or indicating it's dead when it's not.
Really feels like react has held back frontend development. The idea that everything on the web should be written in react is baffling but I'm sure people thought similar thoughts when jquery or angular were popular.
Forget the underlying language, the real shift was this idea that every website should be a single page application, which we are now moving away from again but seemingly everyone has forgotten how to do it, so it's being done "the React way".
This could be because of developer fatigue and the trend of forcing backend devs to do fullstack.
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.
But react is where developer fatigue is most endemic. Since it only does one thing, that typically means you have to import a dozen other libraries that are mostly "flavors of the month" captured in time. You can easily tell when a react project was started based solely on it's dependencies. This is bad because it typically means no two react projects will use the same dependencies.
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.
> Since it only does one thing, that typically means you have to import a dozen other libraries that are mostly "flavors of the month" captured in time.
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.
None of these have usage numbers that rival react, at least not in the US. I wish it were so because many react libraries can easily support other view libraries with minor modifications to decouple it from react.
Is that so bad though? The major alternatives to React are close enough to React that a competent React dev won’t have much troubling contributing. If you need to hire an expert in Vue or Svelte or even React, you should probably put that in the job description rather than hope that “FE dev” would somehow convey what you want.
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.”
Class components are criminally misunderstood. Most people cannot articulate why you should or should not use them. I'm sure plenty of informed people can give a good reason here, but I'm talking about my experience in the wild. It mostly boils down to "Yuck" and "It's not the new thing."
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.
I still think Class components provided an easier mental model for most developers compared to functional components. Hooks specially feel very error-prone by comparison.
Whats going on here? I see it adds and removes a resize event listener… okay, when?What happens with the function it returns?
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.
I’ve been doing web development since 1997 so I feel like I can have a few opinions at this point.
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.
I'm not sure if this still holds true, but I recall a time when you had to use them to create error boundaries. Of course, plenty of third-party hooks were made to bridge the gap.
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.
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.
Right! As long as the license is obeyed, who are you to complain? If the original developer has a problem with the results of something like the MIT License, well, they chose that, and licensing choices are very extensively documented in news.
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.
I get your points. Nobody owes anyone anything, life is hard, we should be grateful Meta gifted us React in the first place, licenses are a thing etc.
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.
I might have expected $1M/year, not $0.6M/year, just because it sounds cooler, but... OTOH, is there any analogous project that was better supported? Maybe, but I can't think of one...
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.
Please no. They don't have the best interests of React in mind.
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.
They might not have the conflict of interest but they also don’t have the business interest either. Meta is a spyware company who makes all of their money from collecting personal data to sell to advertisers. They have zero incentive to dedicate any kind of significant resources to supporting millions of websites using their internal UI library.
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.
> 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.
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.
Hard disagree. React is only popular because large companies made it so. There are few things that React is inherently better than Vue and none of them are its bundle footprint, page load speeds, nor the average time to learn one or the other.
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.
I get your point, but to me it is about composition, not popularity. Writing UI as pure functions of state feels far more natural — recursion, higher-order patterns, dynamic layouts, all come easily because React is just JavaScript. In Vue or Svelte, recursion and logic feel bolted onto an HTML templating layer, which makes complex patterns less fluid.
> Writing UI as pure functions of state feels far more natural
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.
What feels more "natural" is likely to be influenced by what you already know. I've always felt that JSX felt unnatural and Vue's and Svelte's way of doing it feels more natural.
fair — what feels natural usually depends on what you are used to. But even aside from preference, JSX aligns directly with how JavaScript itself works. You are not learning a new templating DSL — you just compose functions. That conceptual unity is what makes React approach click for for so many.
> JSX aligns directly with how JavaScript itself works...
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.
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.
React won’t topple for a while, because of none of the alternatives are different enough. React solved a real problem many developers faced by giving them a state management system with a rendering engine, whereas you were likely to make surgical cuts before in response to state change, you can now just write your ui assuming the whole thing rerenders in response to changes to that state. The component system also allowed for an easy way of sharing code as dependencies. Vue, Svelte, Solid and the rest have their individual pros and cons when compared to react, but they are essentially different attempts to do the same thing.
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.
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.
Small tangent: I noticed the HN in the share menu is the only one in color. They're unable to change it unless they host a copy of the icon themselves (they're hotlinking https://news.ycombinator.com/y18.svg). Surprised they don't have their own CDN/icon font at Facebook scale.
I still like React but I agree that it has lost its way somewhat. Hooks are very counter-intuitive and I don't think you can really call them a successful abstraction. You just get used to them over time. I don't use this react suspense stuff, nor have I kept up with the latest server side rendering with React tech. It doesn't appeal to me, I only use next + react with the pre-rendered export path and I think that niche still works fantastic. But at some point in the future they may take this away from me.
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.
I'd say React has become broken. The fact you have to by default wrap everything in a hook and cycle the boilerplate from one component to another is insane. useMemo, useCallback-use this and that. What are we even doing here in the first place? Playing whack-a-hook?
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.
React was such a simple and elegant solution when it started, and it's accreted so many quirks and weird behaviors that are clearly specific to the use cases of the companies leading development.
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.
The new foundation could be a turning point for React, but whether it truly decentralizes decision-making depends on how governance works in practice, not just on the list of corporate sponsors. Open source foundations have helped some projects thrive by formalizing community input, but they can also be slow to adapt if board dynamics favor stability over innovation. The real question is whether small developer voices and radical ideas will shape React's future, or if practical influence stays with the largest sponsors. Compared to one company's oversight, a well-run foundation can make React less vulnerable to a single vendor's agenda—but only if its structures actively foster broad participation and accountability. We'll see if React's evolution speeds up or settles into consensus-driven conservatism.
Are you implicitly complaining that React is not moving fast enough? What the JS ecosystem needs is for some big players to CHILL a bit and take backwards compat more seriously.
According to the React team page [0], five members of the team work at Vercel. This has been the case for several years. Vercel has been a major contributor in the development of React. How does the creation of the foundation make React more dependent on Vercel?
It seems that as usual, there are just two groups: people who for some reason didn't like React and its way of things, but now found something else they do like (which is good!), but now still have the need to shit on React; the second group likes React and never had serious problems using it.
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 are just two groups: people who for some reason didn't like React and its way of things, but now found something else they do like (which is good!), but now still have the need to shit on React; the second group likes React and never had serious problems using it.
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.
It’s natural for Vercel to have a strong influence on the project. That’s what happens when a framework grows large and fragmented without a defined board, group, or leadership focused on both short- and long-term goals. At least now, with the foundation in place, there are additional voices to help guide the project rather than letting it move entirely in line with Vercel’s direction.
If from this indeed follows more push for ssr and vercel related stuff as many seem to be projecting is there any credible fork that has some following already that aims to basically be React but without those elements as a focuspoint?
If you just want tools that work/make it easy to build apps and websites with JS (and you want direct access to the guy building them), you may find what I built after leaving React/Next interesting [1]. I built this because the creeping complexity and confusion of React's APIs combined with the stress of building a SaaS w/ Next.js became a giant ball of stress and time waste.
Feel free to jump in the Discord [2] with any questions.
I find it immediately off-putting that a I'd choose a framework based on whether or not I'm building a SaaS. Maybe it streamlines certain things but the lock-in to the frameworks set of features and way of doing things feels like a bad decision.
A SaaS is just the focus but it can build plain websites just fine. IMO, it streamlines everything. But people have to get out of their own way and try it—not form surface-level opinions from a quick scroll. I'm actually shocked how few people will even try it. They sit and bitch about React/Next, but when someone offers a solution, they poo poo it (usually for superficial reasons) and then go back to suffering. Joystick is for developers who are tired of that cycle and just want to build something that just works (and they actually understand why it works). Honestly, I'm surprised more people don't trust my way of doing things and continue to walk on to the kill floor that is corporate and VC-backed tech.
That's why I framed it as my immediate reaction. Of course 99.9% of people who read your comment aren't going to just go try it. It's totally fair to react to the elevator pitch.
I am surprised to see three react native focused companies on the list. Expo, Software Mansion and Callstack are by far the big dogs in the RN ecosystem.
Marky (FB) and Vicky (Vercel) are rich kids and are spending their tooth fairy money to buy every kid at your kindergarten a cool toy. Some kids don't like the toy, but that's okay there are other toys.
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.
But every kid at my kindergarten already had the toy. Any time they said npm install react, the new shiny toy was brought to them. I thought that's exactly what mattered to the kids, the toy. What do they care what shop the toy comes from or what Marky and Vicky are up to?
Soon current version of the toy will be deemed unsafe and start catching fire. You'll have to get a new version of the toy, still available easily but it'll only run on crazy expensive batteries you can get from Vicky. Or you could try to build your own batteries but specifications for those are hazardous, undocumented and changes over time.
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.
Because Markey called everyone dumbfucks back in 2004 and some people are still butthurt about it, so Mommy and daddy really don't like going to that particular store to buy things.
I am always surprised to see the anti-Vercel stuff here. NextJS has repeatedly solved every thing I wanted React to do beyond its out-of-the-box fearures. You can pry NextJS from my cold, dead hands.
I'm disappointed that Vercel is a part of this foundation. NextJS is on its way to its funeral, they have absolutely ruined it with things nobody asked for or cares about. I have been working on a large scale NextJS app which when I run locally consumes just over 8GB OF RAM on M4 Mac Mini. Brilliant. Slowly migrating the application to a Vite Based React SPA with a dedicated Hono backend and life is already looking already better.
Oh man, having Vercel on the board is a bummer. Not only because they want to take React a way I disagree with, but it's clear that the CEO is on the wrong side of history in other matters as well (lots of recent drama).
I am baffled by this take that I've been seeing all over the internet recently. A CEO is a person. He is human. Can't a human be on the wrong side of history on various matters, and what does it matter if he is? Can't he still do a decent job (whatever it is that CEOs do)? Why do we expect random entrepreneurs, celebrities, engineers, and so on to also be moral authorities or role models?
This is always the same age-old discussion: Can you separate the art from the arists? And unsurprisingly, different people have different views on it. Even if you disagree, you should be able to understand why people don't want to use a product if their usage of that product makes the owner and CEO more powerful (and they think them being more powerful is a bad thing for humanity).
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
> A CEO is a person. He is human. Can't a human be on the wrong side of history on various matters, and what does it matter if he is? Can't he still do a decent job (whatever it is that CEOs do)? Why do we expect random entrepreneurs, celebrities, engineers, and so on to also be moral authorities or role models?
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.
> 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.
Most people in the company do what they are told to, because they are there to get money for the living. That is just about shifting responsibility to the upper level in hierarchy. So they are definitely affected by the decisions of the upper management.
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.
In a well-functioning organization, the upper management set the vision and the goals for the company and for the product(s); and then let the people who do the actual work use their best judgement to move towards those goals. The upper management, of course, may decide that it would be more profitable to lay off the employees and to outsource to India; and that, of course, would have a direct impact on the work of those at the lower rungs; but I don't think that is the kind of concern that people have when they complain about Vercel's CEO.
It's just that if I were using Vercel or Next.js (which I don't), I would be viewing my relationship with Vercel on a solely transactional basis. If they were giving away for free something that I needed (React or Next), I would take it. If they were selling something that I needed (Vercel hosting, if I were reckless enough to tie myself to it), I would pay for the service. If they charged too much for the service, I would investigate alternatives. It wouldn't enter my mind that I were "supporting" them. I would rather imagine that they were "supporting" me. And I wouldn't give a monkey's who they have for a CEO.
Do you think a person of Palestinian origin should also continue seeing their relationship with Vercel on a solely transactional basis? Given that their families are likely affected and Vercel's CEO publicly supports it? I'm just trying to point out why people might have a different view on this.
I can't, of course, pretend to know what goes on in the mind of such a person; and of course I accept that people have different views; this is very plain to see. What I lament is that people with those views insist that everyone should cut ties with people with other views, rather than accepting that different people may have different views.
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.
> What I lament is that people with those views insist that everyone should cut ties with people with other views, rather than accepting that different people may have different views.
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 employs maybe half [correction, maybe a quarter] of the React core team. For example, at the keynote at React Conf 2025, it was mentioned that Andrew Clark, who, if I am not mistaken, is employed by Vercel, worked on resolving the rendering issue of React that was blocking the release of React 19 after it was discovered in the release candidate.
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?
Vercel is the primary driver of react SSR / server components, which has also led to an explosion of complexity in react and has made it less useful as a composable library imo.
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's just a tool. Are the people that run Makita terrible? Who knows, I just use their tools to fix cars. I use tools to build apps for businesses that pay me. There is far too much ideology based decision making in tech. Just build stuff with it or not.
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.
As someone who isn't too familiar with Next and Vercel (having primarily used Nuxt, the Vue equivalent), it's helpful for me to know what's going on in the React world. Discussions like the above are actually helpful in terms of helping people choose between the various frameworks and hosts.
that is your opinion, and is irrelevant to the choice. practically, vercel is a company which is heavily invested in react and react's future, so, they need to be present.
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.
It is also my opinion that 5 years from now Vercel will be out of business and their customers will have moved on the next hype driven VC cash laundry.
If there is only one thing you take from my post, then look up "NextJS middleware auth bypass" or something along those lines. Have fun reading about that and then never touch NextJS or anything Vercel ever again.
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.
As a mostly-backend dev I stumbled across the "metadata in <head>" issue in my first hour of using NextJS for a toy project.
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.
- fragile under load and very difficult to debug SSR issues
- 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.
Yeah matches my experience. It’s just so much complexity just to get SSR. I’ve worked at places that used it for b2b SaaS apps with no public web part, so the SSR is just a big liability… whyyyyy
I use it for my web site where SSR is critical for SEO. For app development I don’t use Nextjs. I think it is designed for web sites (as opposed to web apps) and it is great for this purpose
I think Meteor is finally starting to fully overcome the tech debt from the second half of the last decade. They're in a recent Node.js release, and the next version will integrate a modern bundler (Rspack) in its tooling.
Lots of apps are still stuck in Meteor 2.x hell because of the dependency on Fibers though.
I was pretty involved in their stack back in the day, it was a good alternative to Django at the time for simple plug and play admin apps, and to this day i think they had the simplest OAuth setup of any framework I've used.
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.
Not to mention their braindead decision to aggressively cache everything as much as possible, which they're now trying to undo, but still haven't shipped.
Used Astro for a pro bono project. Found it fantastic, well documented, provides solutions for the hard parts, gets out of the way for the easy parts. Documentation is well written, but I find I don't need it much because mostly it works how I would expect.
You lost me at React SSR. That is part of the complexity bs. React is a lib for mapping state to the DOM. There's no DOM on the server. So React on the server is 95% useless for that purpose and hence, overengineered to create a bit of HTML and send it down the wire.
I like the simplicity of Hono and use their html helper to write good old HTML that is send to the client.
Hono is a server-side framework like Express. So same way like you handle application state in most server-side multi-page web apps: You just fetch whatever you need from the DB per request.
"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.
I've heard good things, what would you say is the killer reasons to justify being the nodejs ecosystem vs something more purpose built for ssr like php?
I know Vercel has their fingers in a bunch of pies, but is there any significant vendor locking? I worked at a place where we just put nextJS in a docker container and hosted it ourselves, but maybe we would have got more on Vercel?
I often read that Next.js sucks. Meanwhile I and many other devs I've spoken to IRL find it does what we need it to do without any issues. Ya'll just some haters.
For all my criticisms of it, I built two commercial apps in it. I worked around the issues and it was fine.
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.
See the various other comments for concrete examples of why nextjs sucks and the team at vercel is incompetent when it comes to auth, middleware, caching, and just generally maintaining a usable framework without brutal migrations and api breakages.
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".
The people with money don't care, as the very next day Vercel got a series F. That is funny tho because I remember him being pretty anti-israel back in our High school on the long defunct semi-official foropelle.com.ar he owned and managed.
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.
Just from your comments in this thread I'm going to venture a guess that you support Palestine and oppose Israel. Correct, yes?
And also, you want me to believe that your throwaway account's "purely technical critique" of Vercel is unmotivated by politics? Just a complete coincidence that the CEO is politically opposed to your faction.
If he didn't want political commentary being brought into discussions about the company he leads he should have used his big CEO brain to determine that a photo op with a highly polarizing fascist world leader is not a good look.
What's a red flag is that there are 3 new accounts commenting on this reply and all are in agreement supporting your view.
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.
Maybe people are afraid to speak up? I've gotten a fair bit of backlash on my negative complaints about NextJS on Reddit, someone even necro-posting on a months old reply then continuing "debating".
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.
> 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)
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.
> 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.
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.
My experience is that a lot of people on this forum are afraid to voice negative opinions on tools they use at work.
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 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.
Vercel is already heavily involved, take a look at the core team:
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.
Jest is the most popular JS testing framework. It's wildly inaccurate to say it was killed.
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]
[0] - https://github.com/faker-js/faker/blob/428ff3328b4c4b13ec29d...
[1] - https://x.com/kettanaito/status/1746165619731382351#m
Man we have started with Jest tests for our React Native App half a year ago and now we should already drop it? What should we use instead?? Vitest? How's the compatibility? I'm so exhausted man, glad I'm qutting JS dev soon hopefully.
Vitest, yes. Compatibility with jest is great.
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.
Problem with vitest is that there's no first class caching if I recall correctly
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.
Any idea what people have generally moved on to? Currently using jest but its definitely showing its warts often and is pretty slow. Curious if there is an obvious successor.
Vitest is the incumbent I would say, but there seems to be a lot of momentum behind the runtime-builtin test runners recently. Bun is gaining traction like nothing else, and node has put a lot of work into the test builtins lately.
Node's test runner is a non-contender, at least right now.
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.
The node test runner is perfect for small libraries without build where you pretty much ship the source code. The assertion library is actually superior to vitest’s if you don’t use spies etc. because unlike vitest’s assertions, the node ones do type narrowing correctly.
I moved back to Mocha with Chai for a while (both have great ESM support, quietly still well maintained, despite predating Jest) and then to Node's built-in test harness (and Deno's), sometimes still using Chai rather than `node:assert/strict` or `jsr:@std/assert`.
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).
I've had a really good experience with vitest
There's always Mocha.
Vitest is what people have been suggesting to me.
They made it possible for Rich Harris to get paid while working on Svelte. Not sure what will happen in the future though.
It’s time to start moving away from React in general.
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.
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?
After doing this for so many years now and one thing I’ve really come to see as a fairly fundamental truth at this point is that the more you can align with the underlying platform you’re working with generally the better.
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.
I thought Google had already killed Dart once? Or was it Flutter? I'm not really touching any of their “open-source” projects; fool me once, you know.
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.
I’m not trying to be rude in any way here but literally everything you have posted here is incorrect. I don’t know where you’re getting your information from.
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.
[flagged]
Until they dump your startup for no reason, and you'll have to migrate off their undocumented proprietary infrastructure. Please read stories on HN. You're risking your business if you work with them.
"Monopolies aren't so bad, the company is treating me quite well" is not a good counter argument.
do you consider Vercel a monopoly?
lol this has got to be satire
[flagged]
I've been using Vercel for > 5 years. Suppose it's possible but that's true for any platform.
...no it isn't
If you host your non-nextjs SPA on Cloudflare and they do something you hate.. you move
Vercel has every incentive to lock everyone in as hard as possible and raise prices all they can. Not something I'd want to tie my business to
> "we could hire a team of devs for what we pay vercel"
It will be evenn worse when they see they need one, two, three more engineers to deal with the Next.js mess they created.
I've been using Next.js since 2017 (before dynamic routes were even a thing!).
The app router kinda sucks so we're staying with /pages. No complaints thus far with a team of 6 engineers.
[flagged]
> Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken.
Also: please don't shill!
This is just silly, Don. HN has gotten so mired in negativity that someone who's a genuine fan of a product, and dares to go against the narrative is now a "shill." Also: see definition of shill. I'm just a happy user that runs a startup, and my life is easier because of their existence.
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.
I feel like that's more of an issue with the examples and LLMs? Discounting a framework just because it has ever increasing, completely optional capabilities doesn't compute to me. I'm not convinced there's a real problem.
The problem comes in when the complexity is both not optional and not rational.
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.
There are real functional libraries like Effect, pretend functional library like React and just honest old style library like MobX. I think I know my preferred style.
Also you may have to maintain code bases that don’t use your preferred subset.
And you may have to work with developers who have a different preferred subset.
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.
They did just (re-)add a section on that in response to community request: https://react.dev/learn/build-a-react-app-from-scratch
> you can even still use class components
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.
Think of how context and useContext probably works.
Every fiber has a parent. I suppose the behavior, although possibly not the implementation, is that the ancestry chain is walked up until the nearest context provider is found. That will be the fiber associated with rendering context that provided the context.
Preact is great. It’s not 100% the same as React, but it’s close enough and good enough and has been excellent for my use cases (SPAs).
> 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?
No, there is an entire school of thinking that advocates the exact opposite.
https://en.wikipedia.org/wiki/Unix_philosophy
> We believe the best of React is yet to come.
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.
We moved a 8y/old React app to preact in a few lines of code, barely anything was needed.
I think the signals integrations are great added value to the "classic React" formula.
Light weight bundles too, can't recommend it enough.
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.
I think there are three holdups.
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.
Svelte 4, optionally with the static output mode ("adapter") fills this role quite well.
(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 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.
Absolutely agree. Leave well enough alone. If they keep adding features it is only going to get worse.
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 thought I was alone on this.
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...
[0] https://github.com/alvaro-cuesta/alvaro.cuesta.dev/tree/mast...
RSC should never have made client support opt-in. During RFC it was identified as a problem, but Shopify and Vercel pushed for an intentional breakage "for the greater good" in driving adoption.
(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 left for vue one year ago, life is much simpler and productive
Same, but I am pretty much sold on Svelte after getting a new job using svelte (Shipping react in production since 2014).
Ditto...Svelte is such a joy to work with
And not merely by contrast with the fact that React is such a depressing drag to work with -- Svelte is independently joyful and refreshing, in an of itself! The "oh thank God I'm not using React" feeling is just a bonus.
[flagged]
Increasingly bloated and complicated frameworks with intangible benefits used for webpages that are now just training data for LLMs is much more important.
[flagged]
Usually that's indicative of an ad blocker firing in my experience.
I mean if it was the ad-blocker, I don't see how a refresh would fix that? But I'm not terribly knowledgeable here so feel free to correct me.
Ah you hadn't mentioned a refresh fixed it. That sure sounds like some kind of race in the JS.
Very fair! I only came back to edit it because right after leaving that comment I went to see if Best Buy had something I needed locally, clicked into search, typed, hit enter, and it fucking broke. Seemingly entirely, even the search button didn't work, so cmd+a, cmd+c, cmd+r, click in again, paste, enter, and that worked.
I just fucking loathe how common this experience is now. Amazon seems to be the only one that doesn't do it, but I've experienced this exact issue on Best Buy, Target, Etsy, Mercari, ebay, and it just DRIVES ME UP THE WALL.
[flagged]
If it's protecting something then yeah it stinks.
In this case people are critical of other things also and want to voice those things for selfish reasons without getting into mud slinging contests with fanatics who are protecting everything shitty just because it's their favourite hater that is on one side.
Perfect is the enemy of good and an ally of fanaticism.
[flagged]
> Are you suggesting that vercels CEO is to be compared with Adolf Hitler
No, Netanyahu.
Who Vercel's CEO recently posted for a selfie with on X, wishing "greatness for Israel" without mentioning the genocide being committed by that person right now.
Except that the genocide part is basically bullshit. That could be the reason why he is not mentioning it.
Please read through the legal definition of a genocide, and then tell me that that's not what's happening right now:
https://www.un.org/en/genocide-prevention/definition
https://www.ohchr.org/en/press-releases/2025/09/israel-has-c...
> For me, Vercels CEO statements made me realize I am ditching Deno Deploy for Vercel. Finally some tech ceo with good values
Hands down one of the cringiest things I've ever read on this site. And it's why people don't take HN seriously. It's filled with a bunch of 13 year-old "edgy" narcissists who can't code.
"Ok dude". Weird that I have been 13 for over 20 years by now and I guess I haven't learned to code while working for as programmer for more than 15 years. I must be the best con artist in the world since I've been getting a paycheck for all this time.
Wait till you read their opinion on DOGE.
[flagged]
[dead]
[flagged]
"No basis in reality"
Do you really believe, he believes starving in Gaza is not real?
With all the top tier access to information he has in his position?
I think you're being way too charitable with Vercel's CEO. I don't doubt he came up with some way to justify to himself that what Israel is doing is completely necessary and reasonable. But I doubt you can get access to a press conference with Benyamin Netanyahu, then get close enough to shake his hand and take a selfie, then post the photo on social media with a tagline of the likes of "eternal glory to Israel" while having no idea of what is actually happening there. Either he's really that clueless about the world (in which case, how can he be CEO?), or he knows about the genocide and fully supports it.
[flagged]
[flagged]
To answer your first paragraph: neither.
I don't care because I'm just analyzing Vercel's stewardship of React, and Vercel's CEO political stance has zero impact on React's health.
This post is about React. Not about Gaza or politics, so I will give it exactly 0 seconds of thought when commenting on it.
> so I will give it exactly 0 seconds of thought when commenting on it.
You opened your post literally giving your thought about his political stance. Had you completely skipped this part, we'd be only discussing React and not Vercel's CEO stance.
Edit: Your quote can literally be understood as "His take doesn't bother me". If you didn't want to discuss this, you could (like someone else said) have worded it better to avoid confusion.
EXACTLY.
>Vercel's CEO political stance has zero impact on React's health
Sure it does! ReiserFS's popularity went way down after he murdered his wife.
And that's only from murdering one women and no children or men, so Reiser count of one kill (and holding steady) can't hold a candle to Netanyahu's mass murder kill count, which is rising fast by the day.
https://www.reddit.com/r/linux/comments/a8y1nn/whatever_happ...
> and Vercel's CEO political stance has zero impact on React's health
This might be one of the most naive statements I've ever read on this site.
Also, it's obviously not "just about React".
Why? Werner von Braun shouldn’t have been employed by the US, I think you’d agree. But also, his Nazi background didn’t preclude him from being a useful rocket scientist. Why does someone’s political ideas have any bearing on the merits of that person’s OSS technology (the thing this article is about).
[flagged]
You haven't explained how it impacts the health of React. As an aside, please give the site guidelines a read.
I literally did to the person who asked. lol.
>lol. The moment Guillermo posted that picture, the internet was awash with blogs and pieces about how to move away from Vercel (who everyone now sees as the stewards of React). This is actually kinda hilarious to have to respond to and explain to.
>Just because you don't have principles, doesn't mean other people don't.
>Cmon. You can't possibly believe actions don't have consequences, do you?
That's not in the comment I replied to, but your quotes are a good example of why I'm asking you to give the guidelines a read through. This is an inappropriate way to express your disagreements.
Are you really saying you couldn't connect Guillermo's actions with the health of the product he's overseeing?
[flagged]
Care to elaborate?
> I don't care because I'm just analyzing Vercel's stewardship of React, and Vercel's CEO political stance has zero impact on React's health.
Just so that I'm following: You're saying that how the CEO is viewed does not in fact impact the company they are heading? And that the wave of people migrating from Vercel in light of Guillermo's post will not have any effect on React?
> And that the wave of people migrating from Vercel in light of Guillermo's post will not have any effect on React?
If anything, a positive one.
wait so now you're admitting it has an impact?
Obvious troll is obvious. I shouldn't have taken the bait but for a second I wanted to assume good intentions. You are obviously not asking in good faith and just want an excuse to act self-righteous.
So I'll let you do that. Alone. Bye.
lol. The moment Guillermo posted that picture, the internet was awash with blogs and pieces about how to move away from Vercel (who everyone now sees as the stewards of React).
This is actually kinda hilarious to have to respond to and explain to.
Just because you don't have principles, doesn't mean other people don't.
Cmon. You can't possibly believe actions don't have consequences, do you?
thank you
I think OP means "regardless of the CEO's political stance." And yes, your comment does sound self-righteous.
[flagged]
Commenters here are experts in react and have interests in technology, or are looking to understand more about these topics. No one reading here is an expert on geopolitical issues. You're just connecting on the wrong post, and probably the wrong website, if you want to talk about these things. There are places for that, but it's not here this comment section and if you keep trying to make it that you're just going to get down voted over and over.
If this was an article on linting, I'd agree.
But who has become the defacto steward of React over the last 5 years? Vercel. Whose CEO has made a lot of news recently for their political views? Guillermo What front-end framework library now needs to distance itself from Vercel as it's main steward? React.
IT'S ALL POLITICS. That's the entire point of the foundation. That's what this whole discussion is about.
> No one reading here is an expert on geopolitical issues. You're just connecting on the wrong post, and probably the wrong website, if you want to talk about these things
I don't know, I see a lot of posts and threads here of people discussing geo-political issues. Not just for the sake of it of course, but because politics is everywhere and affects everything, because technology is always going to have some form of politics attached, and because everyone is a political actor in their lives.
Separating fully any technology news and political happenstance is impossible. Now of course it doesn't mean every topic should devolve into identity politics, but having discussion about how and why things are they way they are is inherently political.
> Separating fully any technology news and political happenstance is impossible.
AMEN!!!!
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.
I think it's because around 2015 or so there was a lot happening with front end frameworks, and the sentiment comes from then and people have just not updated their priors since.
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`
Let's not conflate the two things that were said.
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.
Having worked in both over the years the main technical thing React had going for it over Vue, in my humble opinion, was much better Typescript support. Otherwise they are both so similar it comes down to personal preference.
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.
No, I was also around when React was new, moving to it from tangles of jQuery and Backbone. I absolutely know React brought several lasting innovations, in particular the component model, and I do appreciate that step change in front-end development. But other frameworks have taken those ideas and iterated on them to make them more performant, less removed from the platform, and generally nicer to work with. That is where we are today.
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.
I read parent's comment as an assertion that the current "fast-moving JavaScript world" expects everyone to rewrite their app. Personally I've never seen this, but since React became popular ~13+ years ago, I struggle to believe this has actually been true for others in any meaningful way.
Mootools is still around! "Copyright © 2006-2025". I don't know anyone who uses it, but glad it see it's still going.
https://mootools.net/core
MooTools also features in the infamous SmooshGate:
https://developer.chrome.com/blog/smooshgate
React often gets lumped into general JavaScript hatred of the form “the entire ecosystem of tooling/frameworks/libraries changes every few months.” That’s despite React existing for one third the lifetime of the World Wide Web. React is older now than jQuery was when React was first released.
Although aside from JSX, so much has changed it could’ve been a new framework at least once, and part of its longevity is that it doesn’t bundle a router, form handling, etc, and the popular ones of these have changed many times.
> the opposite of being under appreciated
> 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.
React has fundamental problems that lead to both:
- 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.
You haven't described those "fundamental problems" that you call bugs, but I think these are irrelevant for me from a ClojureScript point of view. As an example, immutable data structures mean that equality comparisons are cheap and I can often avoid re-computing and re-rendering huge parts of the tree.
More importantly, I don't have a React performance problem. I don't really need "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.
I'm curious what makes a template language bizarro, and why JSX is or is not bizarro?
JSX is just sugar around JavaScript, and interops nicely with it. I'm okay with that. The more I write JSX, the better I become at the programming language I'm using. Concepts and patterns in JS can be adopted in my components.
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.
I don't understand how Jsx is syntax sugar in a way that vue templates aren't. Neither of them are valid JavaScript but they both compile to it.
A concrete example then. Commonly want to prevent form submission default behaviour.
Vanilla
React Vue React's API has guided the developer to learn about events. If they move outside the React ecosystem they have transferable knowledge. As someone unfamiliar with React, but used to the DOM you're surely comfortable here. Yes, the syntax isn't identical to how you might use this in vanilla JS, but it's clearly the same concept. It's just been made a little nicer to use - the sugar.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.
Fun example! Strange conclusion. React actually uses a synthetic event system that is subtly different from the native one in all kinds of little ways. In reading the docs it’s hard to even get an overview of what’s different. Bubbling is a bit different, onChange works like the input event for some reason, various props and methods have been added. This is not the case for Vue! It just uses standard events.
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.
I'm not claiming React is perfect by any means, and like any popular relatively longstanding project is is bound by sometimes unwise historical decision. It just seems to be currently in vogue to take a pop at it. If you want to extol the virtues of Vue/Svelte/whatever then great, but React is still IMO a great option and deserves some defense.
This seems like a very hostile and uninformed take on the alternative tools.
Have you tried building anything with Vue or Svelte recently?
Can you provide some concrete issues you ran into beyond them being “bizarro”?
I consider this example fundamentally broken, in a non-obvious way that reflects, in my opinion, a poor API choice.
The "in some circles of the fast-moving Javascript world" is important - they're not saying everyone or even most, they're saying proponents of the "better" systems (who do rewrite regularly) dismiss React's stability as unimportant or indicating it's dead when it's not.
well ironically it happened when react came on to the scene. Many react rewrite projects (from jquery with handlebar like templates, angular 1 etc)
No and I say it's actually the exact opposite.
Its gotten so bad that when I read FE dev I interpret it as "React Dev".
Really feels like react has held back frontend development. The idea that everything on the web should be written in react is baffling but I'm sure people thought similar thoughts when jquery or angular were popular.
Forget the underlying language, the real shift was this idea that every website should be a single page application, which we are now moving away from again but seemingly everyone has forgotten how to do it, so it's being done "the React way".
This could be because of developer fatigue and the trend of forcing backend devs to do fullstack.
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.
But react is where developer fatigue is most endemic. Since it only does one thing, that typically means you have to import a dozen other libraries that are mostly "flavors of the month" captured in time. You can easily tell when a react project was started based solely on it's dependencies. This is bad because it typically means no two react projects will use the same dependencies.
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.
> Since it only does one thing, that typically means you have to import a dozen other libraries that are mostly "flavors of the month" captured in time.
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.
>> Really feels like react has held back frontend development
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.
> The idea that everything on the web should be written in react
Says who? There are plenty of choices: vanilla, Lit, Vue, Svelte, Angular, Riot, etc. Some of the alternatives are very good.
None of these have usage numbers that rival react, at least not in the US. I wish it were so because many react libraries can easily support other view libraries with minor modifications to decouple it from react.
Agreed, its become its own terrarium like ecosystem at this point.
Is that so bad though? The major alternatives to React are close enough to React that a competent React dev won’t have much troubling contributing. If you need to hire an expert in Vue or Svelte or even React, you should probably put that in the job description rather than hope that “FE dev” would somehow convey what you want.
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…
its important to note that it wasn’t a breaking change, unlike many other frameworks
backwards compatibility is underrated
Wasn't a breaking change, and that was introduced like 7 or 8 years ago, I think? Been kind of a long time in Javascript-land.
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.”
We are still talking about class components these days? I haven’t even seen one in many years
Class components are criminally misunderstood. Most people cannot articulate why you should or should not use them. I'm sure plenty of informed people can give a good reason here, but I'm talking about my experience in the wild. It mostly boils down to "Yuck" and "It's not the new thing."
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.
I still think Class components provided an easier mental model for most developers compared to functional components. Hooks specially feel very error-prone by comparison.
Especially the lifecycle ones. The class based lifecycle methods are much more explicit and easy to reason about. Compare these for example:
and this Whats going on here? I see it adds and removes a resize event listener… okay, when?What happens with the function it returns?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.
I’ve been doing web development since 1997 so I feel like I can have a few opinions at this point.
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.
I'm not sure if this still holds true, but I recall a time when you had to use them to create error boundaries. Of course, plenty of third-party hooks were made to bridge the gap.
Did that turn out to be a good idea? Hooks are much reviled for a reason!
They're not reviled at all. They make logic encapsulation so much simpler.
Just know that that’s not a universally held opinion!
> where people are somehow expected to rewrite all their code from scratch every couple of years or so
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...
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.
Wasn't there push back to including Vite in the docs? Even when it was clear Vite was the new defacto way to setup a React project?
There was indeed. Took a whole bunch of us on GitHub to make them finally add it.
reminds me of "use effect considered harmful, instead use these library hooks that call use effect behind the scenes".
Hopefully the foundation will help balance that.
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.
Or should we just be grateful?
I don't understand the entitlement here?
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.
But why?
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.
Right! As long as the license is obeyed, who are you to complain? If the original developer has a problem with the results of something like the MIT License, well, they chose that, and licensing choices are very extensively documented in news.
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
I get your points. Nobody owes anyone anything, life is hard, we should be grateful Meta gifted us React in the first place, licenses are a thing etc.
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.
I might have expected $1M/year, not $0.6M/year, just because it sounds cooler, but... OTOH, is there any analogous project that was better supported? Maybe, but I can't think of one...
I think once the React community engine is working you need less budget because of third-party contributions.
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!
> dedicated engineering support
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.
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.
Most open source projects receive $0 a year from companies that use them.
I guess Vercel does the most lifting in non-native React these days? Didn’t they hire the core developers?
this, Vercel is at ~10B valuation with a business built atop React - they should and will probably take more of Meta space as stewards for it.
Please no. They don't have the best interests of React in mind.
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 agree with this. I’d prefer to have Meta be the steward for React instead of Vercel because Meta does not have a conflict of interest.
They might not have the conflict of interest but they also don’t have the business interest either. Meta is a spyware company who makes all of their money from collecting personal data to sell to advertisers. They have zero incentive to dedicate any kind of significant resources to supporting millions of websites using their internal UI library.
Because Vercel makes money when components are rendered server side not client side.
I know almost nobody that even uses server side components. It's right out if your backend isn't node..
That is exactly why I stopped using React 2 years ago
Multiply this by the number of multi billion mc companies that are built with it
Multiply this by the number of multi billion mc companies that are built on it
How do you value what they already put into it?
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.
Zuckerberg doesn’t have a good track record with philanthropy
https://www.cnn.com/2025/04/25/tech/chan-zuckerberg-primary-...
Didn't Meta donate $1m to Trumps bribery fund?
Spending 1% of revenue on developer tooling would be insane. Spending 100% of a philanthropy budget on developer tooling would be even MORE insane.
Its kind of amazing how big a single library (that does very little really) has become.
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.
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.
> 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.
Your list has convinced me that my understanding of React is out of date!
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.
> React is obviously the "new jquery", and something else will come one day.
"Something else" is already here and has been for a long time. Vue and Svelte are both excellent alternatives.
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.
Hard disagree. React is only popular because large companies made it so. There are few things that React is inherently better than Vue and none of them are its bundle footprint, page load speeds, nor the average time to learn one or the other.
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.
I get your point, but to me it is about composition, not popularity. Writing UI as pure functions of state feels far more natural — recursion, higher-order patterns, dynamic layouts, all come easily because React is just JavaScript. In Vue or Svelte, recursion and logic feel bolted onto an HTML templating layer, which makes complex patterns less fluid.
> Writing UI as pure functions of state feels far more natural
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.
> React is only popular because large companies
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.
What feels more "natural" is likely to be influenced by what you already know. I've always felt that JSX felt unnatural and Vue's and Svelte's way of doing it feels more natural.
fair — what feels natural usually depends on what you are used to. But even aside from preference, JSX aligns directly with how JavaScript itself works. You are not learning a new templating DSL — you just compose functions. That conceptual unity is what makes React approach click for for so many.
> JSX aligns directly with how JavaScript itself works...
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.
It feels much more natural to me to extend HTML for rendering HTML than to add an xml like syntax in my JavaScript.
Why would I choose to write html in js over writing it in html?
I come from mobile, and was surprised how nice svelte is. Felt so much more familiar patterns than 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.
React won’t topple for a while, because of none of the alternatives are different enough. React solved a real problem many developers faced by giving them a state management system with a rendering engine, whereas you were likely to make surgical cuts before in response to state change, you can now just write your ui assuming the whole thing rerenders in response to changes to that state. The component system also allowed for an easy way of sharing code as dependencies. Vue, Svelte, Solid and the rest have their individual pros and cons when compared to react, but they are essentially different attempts to do the same thing.
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.
The alternative that eventually beat out jQuery was just better native javascript, though.
> Scary stuff.
Why? When jQuery went away nothing happened. People just learned the new frameworks.
I don't think jQuery went away.
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]
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.
Small tangent: I noticed the HN in the share menu is the only one in color. They're unable to change it unless they host a copy of the icon themselves (they're hotlinking https://news.ycombinator.com/y18.svg). Surprised they don't have their own CDN/icon font at Facebook scale.
You don't even need to "host" it per se, just include the icon source in the webpage. It's 315B.
You think bandwidth is free?
-Sent from my 1T parameter LLM
Weirdest part is they are hosting all the other icons themselves, just not the HN one
I still like React but I agree that it has lost its way somewhat. Hooks are very counter-intuitive and I don't think you can really call them a successful abstraction. You just get used to them over time. I don't use this react suspense stuff, nor have I kept up with the latest server side rendering with React tech. It doesn't appeal to me, I only use next + react with the pre-rendered export path and I think that niche still works fantastic. But at some point in the future they may take this away from me.
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.
I'd say React has become broken. The fact you have to by default wrap everything in a hook and cycle the boilerplate from one component to another is insane. useMemo, useCallback-use this and that. What are we even doing here in the first place? Playing whack-a-hook?
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.
React was such a simple and elegant solution when it started, and it's accreted so many quirks and weird behaviors that are clearly specific to the use cases of the companies leading development.
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.
The new foundation could be a turning point for React, but whether it truly decentralizes decision-making depends on how governance works in practice, not just on the list of corporate sponsors. Open source foundations have helped some projects thrive by formalizing community input, but they can also be slow to adapt if board dynamics favor stability over innovation. The real question is whether small developer voices and radical ideas will shape React's future, or if practical influence stays with the largest sponsors. Compared to one company's oversight, a well-run foundation can make React less vulnerable to a single vendor's agenda—but only if its structures actively foster broad participation and accountability. We'll see if React's evolution speeds up or settles into consensus-driven conservatism.
Are you implicitly complaining that React is not moving fast enough? What the JS ecosystem needs is for some big players to CHILL a bit and take backwards compat more seriously.
React has had very few breaking changes.
when something is moving orthogonally to where you would like it to move, it might as well be not moving for you
With RSC it moved to the wrong direction
Does this make React more or less dependend on Vercel?
More, they are part of the foundation.
According to the React team page [0], five members of the team work at Vercel. This has been the case for several years. Vercel has been a major contributor in the development of React. How does the creation of the foundation make React more dependent on Vercel?
[0] - https://react.dev/community/team
Isn't the foundation a formal way for meta to step-out and let others take/share ownership?
It seems that as usual, there are just two groups: people who for some reason didn't like React and its way of things, but now found something else they do like (which is good!), but now still have the need to shit on React; the second group likes React and never had serious problems using it.
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.
[1] https://github.com/datanautika/ash
> there are just two groups: people who for some reason didn't like React and its way of things, but now found something else they do like (which is good!), but now still have the need to shit on React; the second group likes React and never had serious problems using it.
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.
> 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.
It’s natural for Vercel to have a strong influence on the project. That’s what happens when a framework grows large and fragmented without a defined board, group, or leadership focused on both short- and long-term goals. At least now, with the foundation in place, there are additional voices to help guide the project rather than letting it move entirely in line with Vercel’s direction.
If from this indeed follows more push for ssr and vercel related stuff as many seem to be projecting is there any credible fork that has some following already that aims to basically be React but without those elements as a focuspoint?
There's always preact, which is pretty much a drop in react replacement.
If you just want tools that work/make it easy to build apps and websites with JS (and you want direct access to the guy building them), you may find what I built after leaving React/Next interesting [1]. I built this because the creeping complexity and confusion of React's APIs combined with the stress of building a SaaS w/ Next.js became a giant ball of stress and time waste.
Feel free to jump in the Discord [2] with any questions.
[1] https://cheatcode.co/joystick
[2] http://discord.cheatcode.co
Welcome to the club! I built https://mastrojs.github.io after finding both Next.js and Astro to be too complex for my simple needs.
I find it immediately off-putting that a I'd choose a framework based on whether or not I'm building a SaaS. Maybe it streamlines certain things but the lock-in to the frameworks set of features and way of doing things feels like a bad decision.
A SaaS is just the focus but it can build plain websites just fine. IMO, it streamlines everything. But people have to get out of their own way and try it—not form surface-level opinions from a quick scroll. I'm actually shocked how few people will even try it. They sit and bitch about React/Next, but when someone offers a solution, they poo poo it (usually for superficial reasons) and then go back to suffering. Joystick is for developers who are tired of that cycle and just want to build something that just works (and they actually understand why it works). Honestly, I'm surprised more people don't trust my way of doing things and continue to walk on to the kill floor that is corporate and VC-backed tech.
That's why I framed it as my immediate reaction. Of course 99.9% of people who read your comment aren't going to just go try it. It's totally fair to react to the elevator pitch.
It's fair, but it's also doing you a disservice.
I am surprised to see three react native focused companies on the list. Expo, Software Mansion and Callstack are by far the big dogs in the RN ecosystem.
To anyone excited by this news, could they explain, like I'm five, what is it that makes it exciting? Why would developers (or non-developers?) care?
Marky (FB) and Vicky (Vercel) are rich kids and are spending their tooth fairy money to buy every kid at your kindergarten a cool toy. Some kids don't like the toy, but that's okay there are other toys.
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.
But every kid at my kindergarten already had the toy. Any time they said npm install react, the new shiny toy was brought to them. I thought that's exactly what mattered to the kids, the toy. What do they care what shop the toy comes from or what Marky and Vicky are up to?
Soon current version of the toy will be deemed unsafe and start catching fire. You'll have to get a new version of the toy, still available easily but it'll only run on crazy expensive batteries you can get from Vicky. Or you could try to build your own batteries but specifications for those are hazardous, undocumented and changes over time.
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.
Because Markey called everyone dumbfucks back in 2004 and some people are still butthurt about it, so Mommy and daddy really don't like going to that particular store to buy things.
This sound like positive news for the Dev community. I can imagine it took a lot of patience and intention to get Meta onboard with this.
I am always surprised to see the anti-Vercel stuff here. NextJS has repeatedly solved every thing I wanted React to do beyond its out-of-the-box fearures. You can pry NextJS from my cold, dead hands.
That's normal. Happy customers don't have the same need to post comments as the angry ones.
No matter the merits of NextJS, they are very valid political reasons why one might want to distance themselves from Vercel.
React 16 was released in 2017, the same year transformer-based models was announced.
We can feel nostalgia but the world is moving.
It is hard to predict how everything will be in 5 years.
That's good news for the project but having that many big corps in charge will for sure continue to bloat the software
Is there more information somewhere than in this short article, for example a timeline or the planned legal form?
Does this mean there is a chance we will get an ESM browser-compatible build of React after 10 years?
Happy to see more European(in this case Polish) companies getting involved.
I'm disappointed that Vercel is a part of this foundation. NextJS is on its way to its funeral, they have absolutely ruined it with things nobody asked for or cares about. I have been working on a large scale NextJS app which when I run locally consumes just over 8GB OF RAM on M4 Mac Mini. Brilliant. Slowly migrating the application to a Vite Based React SPA with a dedicated Hono backend and life is already looking already better.
Is that logo/banner AI generated?
Oh man, having Vercel on the board is a bummer. Not only because they want to take React a way I disagree with, but it's clear that the CEO is on the wrong side of history in other matters as well (lots of recent drama).
Do you believe board members Meta, Amazon or Microsoft and their CEO's are on the right side?
Their financial interest in react is less blatant.
Vercel wants to own React, its been obvious about it for years now.
I am baffled by this take that I've been seeing all over the internet recently. A CEO is a person. He is human. Can't a human be on the wrong side of history on various matters, and what does it matter if he is? Can't he still do a decent job (whatever it is that CEOs do)? Why do we expect random entrepreneurs, celebrities, engineers, and so on to also be moral authorities or role models?
This is always the same age-old discussion: Can you separate the art from the arists? And unsurprisingly, different people have different views on it. Even if you disagree, you should be able to understand why people don't want to use a product if their usage of that product makes the owner and CEO more powerful (and they think them being more powerful is a bad thing for humanity).
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
It is irrelevant whether we can separate the art from the artist, especially in this matter, when both the art and the artist are bad.
If you're baffled and you're seeing it all over the internet, could it be that you're the one with the wrong take? Food for thought.
Downright silly thing to say given how astroturfed the internet is in 2025
Sure :-) Being baffled doesn't make one right. Nor, for that matter, does sharing a common viewpoint.
> A CEO is a person. He is human. Can't a human be on the wrong side of history on various matters, and what does it matter if he is? Can't he still do a decent job (whatever it is that CEOs do)? Why do we expect random entrepreneurs, celebrities, engineers, and so on to also be moral authorities or role models?
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.
> 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.
Most people in the company do what they are told to, because they are there to get money for the living. That is just about shifting responsibility to the upper level in hierarchy. So they are definitely affected by the decisions of the upper management.
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.
In a well-functioning organization, the upper management set the vision and the goals for the company and for the product(s); and then let the people who do the actual work use their best judgement to move towards those goals. The upper management, of course, may decide that it would be more profitable to lay off the employees and to outsource to India; and that, of course, would have a direct impact on the work of those at the lower rungs; but I don't think that is the kind of concern that people have when they complain about Vercel's CEO.
I don't think it's out of line to refuse to support companies where the CEO buddy up to fascists.
It's just that if I were using Vercel or Next.js (which I don't), I would be viewing my relationship with Vercel on a solely transactional basis. If they were giving away for free something that I needed (React or Next), I would take it. If they were selling something that I needed (Vercel hosting, if I were reckless enough to tie myself to it), I would pay for the service. If they charged too much for the service, I would investigate alternatives. It wouldn't enter my mind that I were "supporting" them. I would rather imagine that they were "supporting" me. And I wouldn't give a monkey's who they have for a CEO.
Do you think a person of Palestinian origin should also continue seeing their relationship with Vercel on a solely transactional basis? Given that their families are likely affected and Vercel's CEO publicly supports it? I'm just trying to point out why people might have a different view on this.
I can't, of course, pretend to know what goes on in the mind of such a person; and of course I accept that people have different views; this is very plain to see. What I lament is that people with those views insist that everyone should cut ties with people with other views, rather than accepting that different people may have different views.
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.
> What I lament is that people with those views insist that everyone should cut ties with people with other views, rather than accepting that different people may have different views.
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.
That is known as "ignorant bliss".
You're all over this thread smearing people with the term "fascist". You do more to hurt your cause with histrionics like that than you understand.
[dead]
Is it just me or does this feel like peak React?
Peak react was React 16 imo.
Hooks were first introduced in 16.8. Make it 18 maybe?
I think that that was the point
Exactly!
You're this close to getting it.
Vercel being involved is a huge red flag.
NextJS is a pile of garbage, and their platform is absurdly expensive and leans heavily on vendor lock in.
Vercel employs maybe half [correction, maybe a quarter] of the React core team. For example, at the keynote at React Conf 2025, it was mentioned that Andrew Clark, who, if I am not mistaken, is employed by Vercel, worked on resolving the rendering issue of React that was blocking the release of React 19 after it was discovered in the release candidate.
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?
Vercel is the primary driver of react SSR / server components, which has also led to an explosion of complexity in react and has made it less useful as a composable library imo.
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.
Mithril rocks. I’ve been blissfully ignoring the new hotness for years.
> Vercel is the primary driver of react SSR / server components, which has also led to an explosion of complexity
It also alienated a huge part of the userbase that decided to move away from React.
How is lowering bundle size not a useful feature? Being able to render something once at build time instead of shipping it to users is great.
It's just a tool. Are the people that run Makita terrible? Who knows, I just use their tools to fix cars. I use tools to build apps for businesses that pay me. There is far too much ideology based decision making in tech. Just build stuff with it or not.
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.
Oracle is just a tool. WordPress is just a tool. But you may care about their involvement in something you use.
As someone who isn't too familiar with Next and Vercel (having primarily used Nuxt, the Vue equivalent), it's helpful for me to know what's going on in the React world. Discussions like the above are actually helpful in terms of helping people choose between the various frameworks and hosts.
I don't use nextjs because it's a steaming pile of unmaintainable black-box shit.
The CEO's politics are just icing on the cake.
that is your opinion, and is irrelevant to the choice. practically, vercel is a company which is heavily invested in react and react's future, so, they need to be present.
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.
Like Microsoft was invested in Web standards in the ie6 days... for their own interests. To own it.
Like chrome is doing nowadays
> vercel is a company which is heavily invested in
…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.
It is also my opinion that 5 years from now Vercel will be out of business and their customers will have moved on the next hype driven VC cash laundry.
Why is NextJS a pile of garbage?
It’s VC funded, overengineered crap, specifically designed to push people into using their overpriced hosting.
I hope this isnt the way that React as a whole will go in the end.
But fortunately there are enough alternatives about.
If there is only one thing you take from my post, then look up "NextJS middleware auth bypass" or something along those lines. Have fun reading about that and then never touch NextJS or anything Vercel ever again.
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.
For those lazy to search:
CVE-2025-29927 – Authorization Bypass Vulnerability in Next.js: All You Need to Know
https://jfrog.com/blog/cve-2025-29927-next-js-authorization-...
As a mostly-backend dev I stumbled across the "metadata in <head>" issue in my first hour of using NextJS for a toy project.
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.
Oh man I forget about their "middleware".
Whoever implemented that has no idea how middleware is supposed to work.
I'd just ask an AI model to move everything over to TanStack Start and see if it works
And what do you do next when it doesn't?
Do it by hand like the olden days of yester-last-week before Sonnet 4.5?
By hand? Ok Grandpa.
I only vibe code in my Metaverse open office by thinking with my Beta NeuralLink.
I tried that once. Had to downgrade my brain firmware to get syntax highlighting back.
- fragile under load and very difficult to debug SSR issues
- 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.
Yeah matches my experience. It’s just so much complexity just to get SSR. I’ve worked at places that used it for b2b SaaS apps with no public web part, so the SSR is just a big liability… whyyyyy
I use it for my web site where SSR is critical for SEO. For app development I don’t use Nextjs. I think it is designed for web sites (as opposed to web apps) and it is great for this purpose
yep this is how i use it and it has worked out really great...sometimes i wonder what people try to do that they have all these issues
Reminds me of VC backed framework Meteor that was attempting to do full stack JS and collapsed under its own tech debt.
I think Meteor is finally starting to fully overcome the tech debt from the second half of the last decade. They're in a recent Node.js release, and the next version will integrate a modern bundler (Rspack) in its tooling.
Lots of apps are still stuck in Meteor 2.x hell because of the dependency on Fibers though.
I'd honestly love to use something that delivered on Meteor's goals. Next.js ain't it though lol.
I was pretty involved in their stack back in the day, it was a good alternative to Django at the time for simple plug and play admin apps, and to this day i think they had the simplest OAuth setup of any framework I've used.
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.
Not to mention their braindead decision to aggressively cache everything as much as possible, which they're now trying to undo, but still haven't shipped.
Try Astro my friend. React SSR with none of that next bs
Used Astro for a pro bono project. Found it fantastic, well documented, provides solutions for the hard parts, gets out of the way for the easy parts. Documentation is well written, but I find I don't need it much because mostly it works how I would expect.
Astro is not tied to React. You can choose your framework.
You lost me at React SSR. That is part of the complexity bs. React is a lib for mapping state to the DOM. There's no DOM on the server. So React on the server is 95% useless for that purpose and hence, overengineered to create a bit of HTML and send it down the wire.
I like the simplicity of Hono and use their html helper to write good old HTML that is send to the client.
You can render html with astro without react. Plain old html templates with options
how do you manage the application state with Hono? I saw their home page and it didn't mention anything about it.
Hono is a server-side framework like Express. So same way like you handle application state in most server-side multi-page web apps: You just fetch whatever you need from the DB per request.
"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.
This is the vercelization of react peeking through, that people even associate react with ssr is an anti-pattern.
I've heard good things, what would you say is the killer reasons to justify being the nodejs ecosystem vs something more purpose built for ssr like php?
As easy as php for simple stuff. And can do complex SPA stuff.
I've been building loads of stuff with it for years and never experienced any of this. Sounds like a YOU problem.
multiple other comments sharing my experience and expanding on it.
If its so crappy how's it so popular?
The core React documentation explicitly points you to nextjs and says "this is how you should build react apps."
I mean, that's good enough for me.
They spend a lot of money on marketing.
I know Vercel has their fingers in a bunch of pies, but is there any significant vendor locking? I worked at a place where we just put nextJS in a docker container and hosted it ourselves, but maybe we would have got more on Vercel?
Try to scale Next.js globally. Try to keep up to date with new versions, changes in paradigms and the way the output is rendered.
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/
I migrated https://cartes.app from Vercel to Dokploy, everything is good and simpler.
running nextjs in docker is notoriously bug prone, there are multiple GH issues about this with no real resolution
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.
They have neglected many issues which would help on self-hosting until the public cry was big enough.
I often read that Next.js sucks. Meanwhile I and many other devs I've spoken to IRL find it does what we need it to do without any issues. Ya'll just some haters.
Just because you didn’t see the issues other people are encountering, everybody else’s experiences are invalid?
I'm saying the impression you'd get of Next from this thread is that it literally does not work. It works fine.
For all my criticisms of it, I built two commercial apps in it. I worked around the issues and it was fine.
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.
[dead]
See the various other comments for concrete examples of why nextjs sucks and the team at vercel is incompetent when it comes to auth, middleware, caching, and just generally maintaining a usable framework without brutal migrations and api breakages.
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".
Built 4 commercial projects with it now. Not had these issues.
I've had great experiences with NextJS.
Also their CEO's picture with Bibi is showing their values
Whoah. Wasn't aware that Guillermo Rauch openly embraces Benjamin Netanyahu
The people with money don't care, as the very next day Vercel got a series F. That is funny tho because I remember him being pretty anti-israel back in our High school on the long defunct semi-official foropelle.com.ar he owned and managed.
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?
Just looked it up https://www.middleeasteye.net/trending/developers-drop-verce...
[flagged]
Oh, I see. So this critique of Vercels' tech is at least somewhat influenced by politics, rather than tech.
Not at all, they are two different critiques.
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.
Just from your comments in this thread I'm going to venture a guess that you support Palestine and oppose Israel. Correct, yes?
And also, you want me to believe that your throwaway account's "purely technical critique" of Vercel is unmotivated by politics? Just a complete coincidence that the CEO is politically opposed to your faction.
[flagged]
[flagged]
It's a discussion about Vercel and he's the CEO.
If he didn't want political commentary being brought into discussions about the company he leads he should have used his big CEO brain to determine that a photo op with a highly polarizing fascist world leader is not a good look.
[flagged]
the very definition of genocide is international law. that is a political definition. that is a fact.
i do not care about what those 2 idiot nations do.
What's a red flag is that there are 3 new accounts commenting on this reply and all are in agreement supporting your view.
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.
Old account. Not with the same words but I share concerns on Vercel's involvement, even if it's not a new thing.
Old account here too, sharing my concerns about Vercel's involvement too
Old account here. I've had good experiences with NextJS though I didn't use like allll features for sure.
Old account here, in support of the GP's view.
Maybe people are afraid to speak up? I've gotten a fair bit of backlash on my negative complaints about NextJS on Reddit, someone even necro-posting on a months old reply then continuing "debating".
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.
> 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)
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.
> 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.
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.
> People looking for options find that the only "official" way to use React according to the site is to use Next
I thought I dreamt (nightmared?) this, but it happened? Hoe did they pull it off?
My experience is that a lot of people on this forum are afraid to voice negative opinions on tools they use at work.
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 could definitely have written that but my account is not that old too.
Been here seven years. Next is hot garbage and you couldn't pay me enough to work with it.
i make throwaways on this site regularly and use them until i say something to piss dang off and get shadowbanned.
your comment would be a lot more interesting if you attempted to pose a counterpoint besides "BOT!".