Why? I think mainly FOMO. When react was out with the blessings of Facebook people wanted to use the same library. Of course most people didn't really care/understand that their internal crud app for editing invoices wouldn't need that complexity.
I think my answer should answer your second question: This kind of complexity is actually needed on some apps but these apps are a minority.
Programmers love shiny new things and most managers aren't technically competent enough to lease them...
I disagree with this. Almost all front-end projects I've worked on in the last 10 years or so have had some requirement that made pulling in react a better choice than trying to push back on business and/or get buy in to do everything server side. Providing users the kind of tighter feedback loops for their workflows is only possible with JavaScript.
And this is why half of the internet is borderline unusable. Page layout jumping around for 5-10 seconds after what appears to be a full page load, buttons simply not functioning, and god forbid you try to use the back button. I know some expert will say none of those things have to happen and has nothing to do with react, but the reality of it is that these things are incredibly common in modern front end development, and I blame all the over-engineered frameworks.
> And this is why half of the internet is borderline unusable. Page layout jumping around for 5-10 seconds after what appears to be a full page load
This is not why half the internet is borderline unusable. React will happily do a full page render in under a second (including network load time). The primary reasons for that are:
1. People writing code that does many network requests in series. 5-10 seems to be not uncommon for many apps.
2. Adverts and as SDKs.
The app I inherited at my last job was a huge 2MB bundle (due to including both the firebase SDK and a large charting library), which I assumed was the cause of the slowness (it was taking ~3-4 seconds to load). But it turned out that was serial network requests that were slowing it down. The app is still 2MB (we made good progress on removing firebase, but hadn't quite gotten there when I left) but it now loads in around a second.
You don't need to do everything on the server side. You can use Svelte or Solid.JS and have the same DevX as a framework, while compiling down to lean and blazing fast JS code on the client.
It's a mix of this FOMO and a lot of people not knowing how to wire up AJAX well. I've seen entire teams reach for react just because there is a portion of the page where some AJAX was required and react is the only way this new crop of devs knows how to do DOM stuff with server side effects.
React today, Angular before that, JQuery, Knockout, All the gloriously bloated .net AJAX controls from Webforms, etc. There's been ways to wrap AJAX calls pretty much since XMLHttpRequest was implemented.
I'd argue "Wiring it up well" is a task better suited for these vetted and highly used libraries than rolling your own code in vanilla JS.
Difference being jQuery was well suited and really necessary back in the day. Browser incompatibility meant that pretty much any non-trivial DOM operation needed to be wrapped by jQuery to be done safetly. Now every browser is just chrome except for firefox and firefox and chrome have played nicely standards wise for nearly a decade now.
Vanilla JS being viable on the frontend without jQuery or some wrapper probably didn't happen until HTML 5 so around 2014 by my reckoning.
The GP is saying that people use react as an ajax abstraction library.
It does make some sense. People used to use jquery exactly that way, and react provides an even better interface for ajax. I wouldn't be surprised if most of the usage of react is there just because people don't want to query their servers by hand.
> react provides an even better interface for ajax
how does react provide an interface for ajax?
react does literally no calls at all...
I feel like 50% of the people complaining in this thread have never touched react or their last interaction with frontend code was jquery 15 years ago and they're still carrying those learned paradigms around and applying them to every new framework/ frontend lib they come across
Just want to highlight something from my original post:
> react is the only way this new crop of devs knows how to do DOM stuff with server side effects
DOM stuff with server side effects, they think they need react to do dynamic DOM stuff, especially if that dynamic DOM stuff affects server side state. So this isn't just about AJAX
I think my answer should answer your second question: This kind of complexity is actually needed on some apps but these apps are a minority.
Programmers love shiny new things and most managers aren't technically competent enough to lease them...