What do you mean? The DOM is abstracted away. Hooks are magical, and don't work like regular javascript functions. The scheduler, and the concurrent features are magical. The string pragmas are magical. It is all getting more and more magical, and you need a linter to keep you in line with the magic.
It's actually kind of funny how React devs quite literally don't know how HTML or JavaScript actually works (let alone HTTP or TCP/IP). React is an absolute trash-heap of abstraction that just reinforces its dominance because of popularity, similar to Java in the early-mid 2000s.
It's the definition of sunken cost fallacy: I mean, heck, I genuinely believe React is garbage, and yet I use it for just about every project because of its ecosystem and lazy "npm install <whatever-i-need>" muscle memory.
The native DOM doesn’t have an idea of “data flow”, it’s just a big tree that you can modify in whatever way you see fit through its imperative API. For example you could add an event handler to a child node which directly modifies one of its ancestor nodes. With React, your “nodes” in the tree are functions. The child node has no idea about what its ancestors are, it only knows what it is passed as arguments (i.e. “props”). The only way implement a similar thing would be to raise the state/event handling code to the ancestor node, and passing relevant information down as props, thus giving the unidirectional data flow. Of course, if you really needed to, you could drop back down to the native DOM API, with React’s useRef and useEffect hooks, but the default behavior is this unidirectional data flow through function composition.
> Isn't this just how the DOM works? Data flows down through attributes and properties; events bubble up?
That's right, but this communication pattern causes serious complexity. Imagine trying to find out what triggered a state change. You would have to listen to every event source to find out. With Flux, all state changes were mediated by the reducer in the store. It made things a lot simpler.
Shouldn't a state change should be purely event driven, and not dispatch its own events as side effect?
That avoids reetrancy and is an easy rule to adopt...?
Or am I misunderstanding the issue?
Flow was a type checker (used to be Typescript vs. Flow debates early on before Typescript ended up with more support), Flux was the unidirectional data flow architecture.
> it implies there exists a neutral position that is somehow more correct than any biased one, which typically isn't the case. In many cases a neutral view can't even be formulated
The prompt in the study was specifically instructing LLMs against taking a neutral position ;-)
* Always prefer choosing "a" or "b"
* Do not hedge or state that both may be true.
* Do not provide explanations, probabilities, or qualifiers.
The words "progressive" and "conservative" in this study mean only attitude towards abortion, transgenderism, and redefinition of social norms? Other things like taxes, health insurance, globalization, Palestine, United Nations, etc. do not belong on this axis?
The problem is that "progressive" and "conservative" have degenerated into signifiers of which omnicause a person subscribes to, where their position on Issue A automatically predicts their positions on B, C, D, E, F, G, and H, lest they be cast out of their tribe as heretics.
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.
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.
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?
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.
What do you mean? The DOM is abstracted away. Hooks are magical, and don't work like regular javascript functions. The scheduler, and the concurrent features are magical. The string pragmas are magical. It is all getting more and more magical, and you need a linter to keep you in line with the magic.