Functional components and hooks were a huge innovation to class components and significantly improved the ergonomics of the library. That was only a few years ago.
The team is actively working on RSC (react server components) which will have a similarly large impact on react's capabilities.
Frameworks like remix and next will be able to leverage and build on this to create even better systems for building apps.
The whole signals blow up event is weird to me. Seems to be a loud and extremely small minority making a fuss around it.
IMO React continues to dominate over others (Vue, Svelte, Angular, Solid etc) because its just better - it embraces JS (no v-for, ng-for, non JS language) and strictly sticks to the idea that the view is a function of state.
React continues to dominate others because it meets baseline criteria for a js framework. And has corporate backing while Vue doesn't. Angular 1 was also popular because it was average js framework with google's backing before angular 2.
Implying that React remains popular for purely it's technical merit is utter nonsense. Because if react was really technically better, then no one would have migrated to Vue, solid and svelte or angular for that matter
We're engineers - we should be able to judge when something is silly.
We also should be responsible for avoiding bad patterns like what this article calls out - throwing from state into react state. It's 100% not necessary.
The reasons for not using other frameworks seems copycat without logic. For example vue uses v-for I don't want to have to learn a handful of obvious tags like v-if or v-else but then choosing react which has adopted jsx something that requires converting standard html and learning more to get you to the same place.
I continue to pick React for projects because it's better than the alternatives - not because others before me have picked it and I'm just copycatting.
I can understand why some dislike JSX. I happen to think it's a great abstraction that elegantly combines the declarative nature of HTML and the power of JS.
It's always worth noting JSX can and is used in libraries beyond React (hello Vue!) which further demonstrates its composable nature and flexibility.
Do you avoid JSX when using Vue or other libraries that support JSX? Are you invoking the library function directly - React.createElement or vue's equivalent instead?
div('#wrapper',
div('.container',
span('.big', `It's not that hard`),
button('.red', {route: home}, 'Home!')
)
)Those are part of React, not JSX itself. Compare Vue's use of JSX, for example, which just uses `class` and `for` instead of `className` and `htmlFor`.
More on that: https://stackoverflow.com/questions/52398380/why-react-wai-a...
https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...
https://developer.mozilla.org/en-US/docs/Web/API/HTMLLabelEl...
Take React form libraries for example [1], redux-form used to be the most popular by far, was followed up by react-final-form from the same authors so people naturally flocked to that. But that is now clearly seeing a decline as react-hook-form, a library that started from zero, is a lot more pleasant to use.
[1] https://npmtrends.com/final-form-vs-formik-vs-react-final-fo... (set to 5 years)
I mean, for a single version bump (Google called it Angular 2.0) to render not only the code not migrate-able, but the entire paradigms on which the framework was based on is basically unheard of in an enterprise-targeting framework.
That’s an egg-on-face technical fail.
React is not perfect, it's bloated, but the reason it took off is that it brought something new to the table as a general and programmatic way to construct UIs. Being a child of Facebook helped it achieve dominance but considering that before React we had angular (shudder) and jquery, React's success was well earned.
React will be replaced when something actually better comes along. The current contenders seem to want to return us to the technology of the past, it didn't work then and it doesn't work now.
The composition API is bliss.
What's more important with Vue and fine-grained reactivity is that it is very forgiving of mistakes and poor practices that in React would cause much more significant side effects and performance issues.
My current team is using Vue 3 with the Composition API and it is way more forgiving with mistakes than the Options API. I've helped transition 3 developers so far to Vue 3 and they all love what Vue has to offer when compared to React.
That said, as a low-level library it should not move fast; it should make sound design decisions while maintaining compatibility. It’s completely open to frameworks with more opinions and friendlier DX to be built on top of it.
I see this said a lot with particular regard to hooks, and to this day I just can't buy in.
For whatever problems class components have, they enforce a general layout of the component in a way that hooks don't. Reading some codebases that are all in on hooks feels like the wild west and is frankly nightmare-ish to untangle.
> it embraces JS (no v-for, ng-for, non JS language) and strictly sticks to the idea that the view is a function of state.
So does Solid No?
Not only can you componentise your UI code, but you can componentise your UI system meaning teams can develop independently of each other...
Usually people are not FB and people often do not have the same kind of strict development rules or enforced discipline, nor are they as many people as FB. Maybe the FB tool is not right for them.
Once you have state that needs to span your application and prop-drilling becomes too much of a drag, the misalignment between React's "pretend we're going to redraw everything" and "I'm only changing this one field in my state" causes most of the issues with React.
A junior dev isn't going to be build as fast or as clean as a more experienced dev, but a good framework promotes speed and provides guardrails to prevent mistakes.
To that end my experience with React -- same as the author's -- is that React does not have this characteristic and provides many ways to shoot yourself in the foot.
Having worked on 3 sizable React projects now (all started before I arrived), I can only conclude that beyond a toy phase -- once you have many hands working on React and *particularly* once you start managing sizable state -- there is only pain.
The most recent case resulted in spending quite a bit of time explaining to a peer why we were experiencing an unexpected side effect and redraw and explaining how `useMemo` and `useCallback` actually need to be used [0] and made me think of Stephen King's Langoliers.
It occurred to me that "React is the new IBM" [1] It has become so dominant in the market that no one can get away from it. But that also means that it can no longer innovate. Andrew Clark's twitter post *acknowledging* that signals and fine-grained reactivity would be better for performance but that the React team doesn't care pushed me over the edge of frustration.
I think that React finds itself not too far off from where IBM was at the micro-computing revolution. IBM had become too beholden to its market and too arrogant in their own success to see their own downfall.
The traffic and feedback on the second article is an indication that there are a lot of folks out there who are really, really dissatisfied with the state of React.
[0] https://chrlschn.medium.com/8eb7bb72c87
[1] https://chrlschn.medium.com/react-is-the-new-ibm-6af2f4b04e5...