blog/self-fulfilling-prophecy-of-react

[utterances-bot]

The self-fulfilling prophecy of React - Josh Collinsworth blog

The only thing React is better at than other front-end frameworks is being popular. So how long will that self-perpetuating cycle continue?

https://joshcollinsworth.com/blog/self-fulfilling-prophecy-of-react

[rglover]

This is a great post! Thank you. To your point about what an answer might be, I think you'd enjoy Joystick: https://github.com/cheatcode/joystick.

[differentsmoke]

React has aged. And I don't think most people—particularly those using it regularly—realize how much or how poorly.

I don't know, when I began using it I used to write "React.createClass" and now I can get away with using only functions and hooks. There's always a next big thing coming,from class components to function components to hooks to context and now I believe Suspense and server components... seems to be a framework that's constantly updating itself.

To your individual points:

if your goal is to build the most performant thing you can

Seldomly anyone's goal? Premature optimization something something dark side.

JSX is a gotcha-riddled kludge to clumsily shoehorn HTML into a JavaScript function return.

Some people seem to believe this, I personally prefer JSX to using templates, and many a framework that isn't react has adopted it. I like turning HTML into programming rather than programming into HTML.

React definitely won’t lead the pack when it comes to small bundles. Again, much has already been written on this point, so I won’t harp on it.

I think a productive thing here would be to ask oneself why. I believe (I may be super wrong) that for instance the Synthetic Event is one of the reasons React has a large bundle size. Do people want it? Do we understand what are the trade offs of not having it?

While React certainly has the most companies and apps demonstrating its ability to perform at scale, I don’t think it’s fair to say quantity equals quality.

Much like the most performant thing, I think it is unrealistic to assume people want the most scalability when enough scalability will suffice.

[eomttt]

Good! And i think Next contributed to the popularity of React Next select React for make SSR site. And many people or company make want SSR site for SEO, and choose Next, so naturally React get more popularity.

[antialias]

(this is a quick sketch of thoughts, but I believe it makes a good attempt at answering your question)

"When and how does this change?"

Absorption - same way we switched to and from jQuery, Backbone, Angular, Core JS, and many others. Each had their time and complete buy-in from front-end engineering teams large and small, and it seemed implausible for large companies to take the risks on using anything else... until they were absorbed. There are a few ways libraries can get absorbed:

• big library gets broken apart into multiple libraries that can be used a-la-carte
  • underscore -> lodash -> lodash functions published as packages, (patterns implemented by tools like hydra make this practical for many libraries to get broken apart this way)
• functions of the library get baked into core JS
  • jQuery.ajax inspired fetch
  • map, filter, reduce from jQuery / lodash / underscore were ported to Array.prototype and Object literal notation + Object.entries / values / keys
  • _.template mostly replaced by template literal strings
• obsoleted by better approaches
  • Angular(JS)'s dependency injection was revolutionary at the time because we didn't have good bundlers (remember require.js?), but was replaced by webpack and later ES modules.
  • angular's state management via wrapping all functions that go async with state differs and view updaters turned out to be mostly problematic, but was still a neat trick at the time.
  • Angular had some core libraries that were nice and were factored out into well-maintained npm modules (e.g. axios (still based on XHR btw))
• massive investment from a large company causes fundamental shift in application architecture (many web app developers moved to iOS / Android and never looked back)

React has a few nice things that could be factored out into separate packages:

• nice set of built-in hooks - could easily be factored out into separate packages and adapted to anything that can attach state to DOM elements.
• Fibers, which allows rendering parts of an application asynchronously, could be factored out used in many react-like frameworks (like preact)
• virtual dom + diffing engine: could be (and has been) factored out and used in a variety of template engines that render to DOM nodes.

Much of this has already happened, and I'm seeing many of my favorite libraries, like react-router, all the tanstack stuff, and material offering support for a variety of front-end rendering libraries, basically making react a fungible piece of the front-end set of tools for getting a job done.

I do not think react, as you know it today, will be here for a long time. Maybe it'll look like NextJS using Svelte as a rendering engine :)

[Shunseii]

Even with the preface, I feel an overwhelming sense of bias in a lot of your points.

It's well-known that React has, by far, the most mature ecosystem, yet you downplay that and claim that it doesn't really matter. In fact, you actively try to point out supposed downsides of having a large ecosystem -- which arguably aren't even so bad that I personally would consider writing off a framework entirely.

Meanwhile, when you discuss performance you seem to have a completely different tune. A more balanced and consistent approach would be to say that, sure, React is not the fastest, but it doesn't need to be since squeezing out every bit of performance is not applicable to the vast majority of applications out there. It's fast enough which is what matters. This sentiment sounds familiar to what you say about anything that isn't React in all the other points.

In fact, I feel like if React had been the most performant out of all the options, the article would likely read something like: "While it's technically true React is the fastest framework, it shouldn't be the deciding factor because performance isn't everything. All the other options are fast enough where if you're building basically anything, then there's really no difference."

And regarding your point on scalability, what I got from it is that we can't say if anything is scalable ¯\_(ツ)_/¯

[EthanStandel]

Also commented this on the post shared on Reddit.

JSX is a gotcha-riddled kludge to clumsily shoehorn HTML into a JavaScript function return.

As opposed to what? JSX has strict rules that make sense and gives you the whole power of JS in your templating. It is far superior to any alternative templating language, and every other templating language ends up compiling to something very similar to JSX. I think this is just a straight up bad (bordering on arguably incorrect) take. Every other modern UI platform now has a framework that uses templating that's just based on functions and objects (see Jetpack Compose, SwiftUI, and Flutter), because developers don't actually like templating languages and they add an unnecessary build step.

It can mean too many packages to choose from, and too many different, competing opinions that you’ll have to decide between and take a stance on.

I still think this is a good thing. If you are building something new, then you may have to do some research, and that's okay because the size of the community ensures that there's a perfect solution to most problems.

React’s satisfaction and interest have been declining steadily for years, while its usage has flatlined.

This is just factually incorrect. React consistently has higher developer satisfaction then most JS frameworks (Svelte usually wins overall though). And in terms of growth, you couldn't be farther off. Though smaller frameworks tend to have faster growth, it's because they still have room to grow. Whereas React this week one year ago had 11.6 million downloads on NPM, this week it has 16.8 million downloads. That is a 44% growth rate. It's usage has not flatlined, that's just a lie.

I'm not a React fanboy, and I agree with some other points but these notes are either overly emotionally driven or straight up factually incorrect. It's not a great take overall.

[josh-collinsworth]

Whereas React this week one year ago had 11.6 million downloads on NPM, this week it has 16.8 million downloads. That is a 44% growth rate. It's usage has not flatlined, that's just a lie.

While NPM downloads is one measure of growth, it's a) a very specific one; and b) not a very useful one. A download on NPM may or may not be at all indicative of real-world project usage. And in any case, it wasn't the metric being discussed.

The "flatline" comment was geared more towards the percentage of developers in surveys such as state of JS who say they are using React, as the post stated—which has remained very consistent for several years.

[EthanStandel]

@josh-collinsworth

While NPM downloads is one measure of growth, it's a) a very specific one; and b) not a very useful one.

Too specific & less useful than an opt-in survey? The NPM data is just out there, and it is specifically not specific. Afaik, there's not even a way to opt your installs out of being a part of that data set. I would argue that while State Of JS is basically the only way to get preference data (in which React still generally shines), it's a far less effective way to identify growth when the actual data is just there. Also worth noting: the fact that React continues to hold an 80% stake in an environment where the amount of competing frameworks and active developers are growing is a sign of its growth, not stagnation.

I heavily agree with Shunseii that it definitely reads as if you made a conclusion & worked backwards to your arguments. I get not liking a technology. I have written about my disdain for modern Angular before. But you can just say what's bad about it. Its bloated and its kind of slow and hooks can be a footgun and its popularity can sometimes be a perpetual motion machine. These are all fair criticisms. But the community is great, JSX has turned more skeptics than it hasn't (see the love for SolidJS), there's no compilation step so what you write is what gets run (that's to say: JSX, like TS or Babel, is a syntax transform), and frankly hooks enable the community to build rendering plugin primitives that can solve so many different scenarios that can't easily be built without that construct. So maybe it's worth considering why it got so popular and continues to grow.

EDIT: Very unrelated but thank you for the discovery of utteranc.es. I just happened to be working on a dev blog and liked this so I'm going with it.

[NetOpWibby]

I've lost out on roles because my JS framework experience was only in Svelte. No regrets though.

[Nettsentrisk]

I think the next natural step is towards web component frameworks. That is, you write code that is more in line with straight up web components, and the role of the framework is to scaffold and let you write web components faster, provide state management, etc. Like, Lit plus a framework.

[pahlers]

Thanks for your post!

[SarcevicAntonio]

In reply to @EthanStandel's original comment:

As opposed to what? JSX has strict rules that make sense and gives you the whole power of JS in your templating.

As opposed to a well-made DSL like Svelte, Marko or Imba for example, languages made to describe UI. They also have strict rules that make sense and give us everything we need to build UI in a sensible way.

It is far superior to any alternative templating language, and every other templating language ends up compiling to something very similar to JSX. I think this is just a straight up bad (bordering on arguably incorrect) take.

I think Josh's original take is right on point. JSX forces everything to do with the UI inside a JS file, even when the ergonomics get thrown completely off. Now we need fragments, ternaries for conditional rendering, CSS-in-JS or Tailwind just to style our components, straying further and further from good ol HTML, where Githubissues.

Githubissues is a development platform for aggregating issues.