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 <script> and <style> tags flow naturally together. To me, JSX is an incomplete language for UI development, as it doesn't even handle styles. How is that superior?

developers don't actually like templating languages and they add an unnecessary build step.

Some developers prefer a more natural templating language over JSX, hence the popularity of frameworks like Angular, Vue and Svelte. This topic is very dear to me and I do believe that Svelte or Vue for example are much more approachable for never devs, enabling more diverse people to be in the field. The most baffling thing from this comment is that JSX also adds a build step, if we don't want to ship Babel to the client.

[EthanStandel]

As opposed to a well-made DSL like Svelte, Marko or Imba

@SarcevicAntonio I feel that out-of-language DSLs like Svelte, Angular, or Vue don't really hold up. They're forced to recreate language features in ways that will never be as ergonomic as just programming in a real programming language. But JSX and Imba giving you the full power of their respective languages make them far more powerful. This being said, I also think that fully programatic templating like you see in Flutter, SwiftUI, and Jetpack Compose are also steps in the right direction.

Now we need fragments

Is <></> really that bad? I see people outside of the React ecosystem complain about this all the time but I think the complaint comes more from a place of trying to find something to be mad about than an actual problem. Fragments fulfill a purpose. Would it have been nicer if the JSX language model was designed slightly more thoughtfully as to not require them and instead assume that adjacent elements are in a shared fragment/array, yeah sure (like Imba, which again I do absolutely adore). But they make sense and they work.

ternaries for conditional rendering

Or if/else statements, or any other control flow available in the langauge. Imo this will always be better than something that is framework-specific.

CSS-in-JS or Tailwind just to style our components

Not true at all. You can use CSS/SCSS modules or just load in CSS/SCSS as a global stylesheet. This, again, feels like you're listing stuff off to complain but... what's your alternative. What would you prefer? React will let you use whatever you want for a styling engine, so this sounds like you're grasping at straws for something to not like about React.

straying further and further from good ol HTML, where <script> and <style> tags flow naturally together

This is just opinion... which I disagree with. If you're writing an SPA then the programming language should be in control. I don't see the point of making the false model that "oh this is actually all just HTML." It's not. It's JS interactively updating the DOM. Unless you're using SvelteKit (or Next for React, or Nuxt for Vue, or Angular Universal for Angular), you're not actually shipping any HTML to the client. You're shipping a JavaScript application loaded in from a barebones HTML shell.

JSX also adds a build step

This is the ultimate in "pot calling the kettle black," and shows a heavy misunderstanding of how any of these frameworks work. JSX is far closer to the code that gets run than Svelte, Vue, or Angular templates. JSX compilation is a direct translation between the JSX & JS, where <lowercasesomething/> compiles to React.createElement("lowercasesomething") (lowercasesomething is a string name for a DOM element type in this case) and <UppercaseSomething /> compiles to React.createElement(UppercaseSomething) (UppercaseSomething is a name of a component class/function in this case). JSX isn't much farther from JS than TS is from JS. Svelte, Vue, and Angular templates are incredibly non-perfomant when run directly because they are just strings. If that code was run directly on the client then these string templates would have to be loaded on to the client which would then have to compile them at run time. Svelte has always had a mandatory compilation step, Angular used to run directly in dev builds but now always does full compilation, and Vue has always had a mandatory compilation step. In Svelte & Vue, this should be pretty obvious seeing as *.svelte & *.vue files aren't valid HTML or JavaScript at all.

I do believe that Svelte or Vue for example are much more approachable for never devs

I agree with this. React is just a library, and has no magic compilation. It's a little closer to the metal, which can be annoying to work with (see the end of my original comment). But that's what I think has allowed it to have such a powerful ecosystem. Its underlying mechanisms that make it work are a lot more accessible than the underlying components for other frameworks that are tucked away in some compilation step. Because of this, React devs have to have a far better understanding of how the framework works for better or for worse.

[bezvoshchuk]

Sounds very much like story of Java.
I believe React won't leave the market (if only Facebook won't kill it in some way).
But I also looking forward to see the next game-changer.