Bashing React

I’ve been a long-time casual detractor of React.js. The occasional snide remark here & there, or long rant in the internet that nobody ever reads.

The gist of my complaint is that it’s overly complicated — while at the same time not doing enough to help developers.

Other frameworks (like Angular) are complex, but they aim to provide a more complete solution in a coherent form. To be effect (read: develop something beyond a toy app) With React, you need a whole lot of other things with React that you have to piece together. Redux, React Router, etc. While with other frameworks (like Svelte) both radically simplify and improve performance but don’t have the pretension of solving complex developer problems.

Recently, I decided to get professional about bashing React. Not more professional in my behavior, but I wanted to go pro as an anti-React troll.

I decided I needed to learn more about it. To, you know, criticise it more effectively.

So I turned to ChatGPT to start asking clarifying questions. When I diss something, I like to really get my facts straight — usually after flying off the handle and getting them all wrong.

Do I ever publicly apologise or issue a retraction / correction?

HAHAHA.

I used to joke that React feels like it was written by AI.

See, even a couple years ago, when we (normal people) talked about AI, we meant machine learning analyzed uncategorized data and neural network pieced together an algorithm that develops a hueristic for determining if something is, in fact, a picture of a kitten.

(Apparently AI couldn’t figure out how to identify street lights, or crosswalks, or busses — and outsourced the job to us.)

Anyway, the algorithms developed by AI algorithms are often surprising and usually inscrutable. But they worked (for the most part) with a few surprisingly strange exceptions. Which a good reason to use AI to inform, but not make decisions.

What I was saying is that React feels like it was developed organically, without a plan, by a large group of people working independently and it coalesced into something that may be useful for developing web applications, but it is bizarrely confusing to someone looking at it from the outside, and doesn’t have a coherent organizing structure. In other words, it was a cobbled together complex system that came out the unique boiler-room of Facebook’s needs and evolved with additional layers of complexity as it was adopted and adapted by a broader community.

Compared to something like Angular, which has a clear design (even if it was designed by committee and is too rigid and too heavyweight for most projects) that is logical, and it’s largely a matter of taste and (need for complexity and structure) that determines if you want to use it.

I recently watched the React.js documentary:

And was going to say that I feel like I was right, except that React came out of the mind of one person, Jordan Walke. Which is not quite true, because it didn’t take off until a core team of collaborators and contributors and evangelists pitched in. So it wasn’t really a gradual organic design from a large organization, but was a more deliberate design led by a single visionary to replace the organic jumble of tools used by that large organization, Facebook.

In a rare fit of humility, I decided (before watching the documentary) that there must be a reason so many thousands of developers find React so compelling, beyond the fact that it’s promoted by Facebook.

And coincidentally, I was experimenting with building a website out of components using Svelte.js, and feeling quite productive, despite not doing any real development, other than building the (mostly static) site out of composable compents.

The header contains the logo, menu, and login components.
The menu takes the topics (About, Blog, Contact, etc) as data properties.
The login component has two states (logged in, not logged in) and affects the menu (whether admin menu is displayed).
Each page contains the header, main, and footer sections and so forth.

Being able to compose a site from components really helps with structuring your code. But I still didn’t understand all the additional complexity.

Being happy with my progress using Svelte, I thought it would be worthwhile trying React for this simple scenario. And possibly even try to learn a bit about Next.js for server side rendering a static site. The main case I want is to be able to pull content from other sources (CMS, database, or git repo) and render them into a static site, but be able to update page and sections of pages by editing plain text (or markdown) files. In other words — like
a blog.

Perhaps someday, someone will invent a useful tool for this.

So I started exploring React as a way to structure HTML. I’ve long suspected that majority of React fans (and users) use it only for this. The claim of React without JSX was disingenuous, because JSX is the primary reason for using React.

People say that React is easy to learn because has a simple interface, but that’s nonsense. React has the most complex interface of any UI framework. Things like componentDidUpdate and componentWillUnmount that only make sense at the most low level for the most complex interactions — and details that almost nobody knew existed in JavaScript at all. I submit that it was actually the complex low level hooks (that React has, but nothing else did) that made it popular for complex sites like Facebook where lots of things are happing below the surface that users aren’t even aware of.

And people talk about the Virtual DOM and how it improves performance. While that may be true for extremely complex DOM interactions (hundreds or thousands of elements changing), but for most sites and applications, it doesn’t. In fact, for most cases, the virtual DOM is slower than just finding and replacing real DOM nodes in place. React’s DOM diffing strategy is actually very basic, and doesn’t (or didn’t) handle things like a <div> tag changing to a <span> tag and everything underneath it stays the same. Or (earlier) adding or removing elements from a list.

While the concept of a virtual DOM was a technical marvel, the implementation left a lot to be desired — and came at a big cost, both congnitively, and code complexity wise, as well and framework size and performance. “Lightweight” frameworks like Preact were create to replace the supposed lighweight React.

Which get’s to the real complexity. React is pretty complex. But it’s benefit comes from not needing to understand the complexity hidden inside — until you need it. Most frameworks can’t compete, not in simplicity, but in being able to adapt to the real complexity when needed.

Reacts “simplicity” comes at the additional cost of React not having a an answer to state management, routing, server side data, and a bunch of other things that are needed for creating a real web “application”. These are all either “extras” or “roll your own”. And you bring in things like Redux, React-Router, Apollo GraphQL, etc to handle these. Which then makes you wonder why you’re using React at all in the first place.

Most people are happy using JSX to compose UIs, and occasionally dip in to properties for passing data, and gradually let the React “expert” handle the complexity of state, lifecycle hooks, and the rest. And that’s probably the Facebook use case. Someone is working on the HTML and CSS for a small widget (like advertisments, or like buttons) and need to 1) make sure it works consistently in all sorts of displays and device. And someone else handles the lifecycle and state interaction.

That means using React, by itself, to compose UIs, is a perfectly acceptable solution.

Except JSX isn’t a good solution. It can’t handle looping, because it can’t handle statements, so you need to use map() it iterate over arrays, and inspecting arrays of object that have arrays can become a nightmare in React, which is actually pretty easy with a straightforward templating solution.

JSX was a nightmare to use for the first few years, because that meant setting up Babel transpilers, Grunt/Gulp tasks, and Webpack, and configuration. Thankfully, create-react-app (created by Dan Abramov) made this simplier, and now tools (like VS Code) can detect JSX and render it properly. Debugging was another major challenge that has improved.

But, I didn’t come here to criticize React, even though I’ve been doing that for a long time. I came here to praise it. Or rather, to explain that it may have it’s uses, and I want to better understand them. And understand why the decisions made to make React work the way it does were made. For that, I need to understand them better myself.

Earlier, I talked about how React felt like it was inscrutably designed by an AI system.

Part of the appeal of React (and many complex modern technologies) is their complexity. It’s that they are hard to learn, and it is a puzzle to figure them out, and you feel like an initiate into a secret society once you finally have obtained your hard-won knowledge. And people want to be like the esoteric experts, so they adopt their fashions.

What I’ve found is that, while I have been unable to understand React by going through tutorials and looking at sample code, part of that is failing to realize that you don’t need to understand it all.

Most uses of React don’t need to use Redux, and most well designed apps won’t use React-Router. And the less shared state that an application has, the better (usually). So a lot of the complexity associated with React applications (that are outside of React itself), are actually unneccesary for the majority of use cases (rendering content and layout on the screen).

What really clicked for me (after spending some time doing due diligence giving React a fair shake) came after reading this post by Dan Abramov (the creator of Redux) a core React team member.

View at Medium.com

Perhaps ironically (and perhaps not — depending on your opinion of Alanis Morriset or high school English teachers), the thing that really helped me to understand React, was that it was the AI system ChatGPT (which really just sythesizes existing content) that enabled me to understand (and appreciate) React better.

Maybe only an AI can explain a framework allegedly created by AI.

I’m going to be going through my interaction with ChatGPT as I learn, research, experiment, complain about, and use React. Look for more posts and videos. And if you’d like to study React with me, reach out.