That was actually a very small parts of the projects in the world at the time, and in fact, a very small part of the number of projects that adopted react at the time.
I remember above all that:
- React was hyped to the roof by facebook. They had a fantastic marketing machinery for that.
- React sucked for years, with a terrible doc, a crippling webpack experience and breaking compact all the time.
- The JS community was moving from koolaid to koolaid, never assessing the new tech for their cost. They solely inflicted on the world slow and brittle preprocessors left and right, thousands of stuff you had to integrate manually because "libs > frameworks", and jumped on react, redux, graphql, docker, spa, microservices.
So I would say it was a loooot of hype for react, just like it was for graphql.
I'm going to feel like spamming at this point, but, remember when XML was the future?
performance was the least attractive reason for adopting React. React introduced composition as the default way of thinking about UIs to the web. You created components and used them to build more complex components. Data was immutable and flowed in one direction (parent component -> child component).
Comparing the above to ng with its dependency injection, MVC style approach to UIs, that used HTML based annotations and tags to sprinkle in functionality (`ng-if` baby) -- it was a much more simple way to build web applications.
React's style of building UIs has largely won. Vue, etc. all follow this component with composition view of the world.
> React sucked for years, with a terrible doc, a crippling webpack experience and breaking compact all the time.
Webpack has nothing to do with React. React has always had good documentation. The reason the documentation was good in the beginning was because the API surface area was tiny compared to Backbone, Ember, ng, etc..
I'm not going to go point by point here. You sound like you have a very superficial understanding of the space.
I'm going to hard pass on clicking a marketing link to your blog.
> React has always had good documentation
Tells me you rewrite the entire history.
In fact, for years, react didn't even tell in the doc you could use it without a transpiler so people had to learn a whole build chain before even getting to the hello world.
At this stage it's not "superficial understanding of the space" this kind of comment is guilty of, it's total denial.
And by the way, we have been doing components for UI way before react was a thing. jQuery could do components. Backend frameworks could do components.
As for immutable data, I've seen more small projects die from the small cuts of trying to maintain that purity that I've seen those exploiting the benefits like free time travel.
I assume you've been living HN bubble for too long.
Webpack wasn't how it started, remember gulp?
Also don't forget the switch from class components to functions, then inventing "hook" functions to reintroduce functionality that already existed in the class components.
For the past few years I've been on a team that handles a legacy system from long before React existed (internal) that just renders HTML directly, a client website that uses Backbone, and a newer client website that uses modern React. The old internal one that doesn't use any frontend frameworks has been by far the nicest to work with, and Backbone the worst.
I think that's some missing context as well - React+Redux was much better than what came immediately before it, for complex web apps. But when you're not building something like that, yeah, both are worse. It just doesn't seem like the Backbone era encouraged people to use it for everything, unlike React.
React solved a very specific issue that was a pain in Angular, which is making it easy to write small, self-contained components and attach them to a mostly static site. That people decided to use it to make entire SPAs further illustrates how much easier they found it than other solutions.
I can't think of a case where JQuery code is ever simpler than React code, even for small things. If you need to worry about the order of rendered items or moving them into different categories on a page based on input, it's much simpler in React.
