The Subtle Case For and Against React

• What are the hidden downsides of React?
• What if React makes everything much harder and more complex?
• Why do we bother to use it at all, even if we know there are these major disadvantages?

A friend in a Slack group that I'm part of recently posted an evaluation of React as a staple of many software teams today. Essentially they said:

"Why is React everywhere, when..."

1. It is extremely complex. It adds complexity on top of javascript, which is already a nightmare of learning cliffs. React now recommends using Next.js so you truly have to become an expert in html->js->react->nextjs to work in the space.
2. It is huge and probably slow compared to pure js and HTML, so why would we inflict that on ourselves?
3. It makes development slow because the thinking and planning require so much hard work to build things with it, so shouldn't we avoid it?
4. jQuery was the way to go before SPA frameworks, and it worked well, why trade down to something that's both slower and less stable?
5. Are people trying to get work done in React because it's standardized and common, not because it's effective?

Essentially we can summarize the negative experience with the meme image that they posted alongside:

(That friend's rough concerns)

Fair Accusations give pause

This all gave me pause. These are not small concerns, and I agree with all of them and have the same concerns on the face of them. So how could I still like or recommend React? In fact I am even in the process of refactoring a personal legacy project away from jQuery and towards React. Why am I trying to do this if I can't articulate counterarguments to the above very apt points?

The Subtle Case for React

So let's run through the points and see if I still can recommend React with a straight face at all, despite generally agreeing with the underlying concerns 1 - 5 against it.

1 - React complexity weighed as if it was ballast

Complexity is usually a good argument in software. "That pull request will highly increase complexity." That is a valid rationale to give it another look and think through the cost. But complexity in the case of React is also a double-edged sword. We can look at React, nextjs and say "That is too complex to learn and maintain" because we are actually silently weighing it against the strawman of how easy we imagine it would be to do on our own solo from scratch. It's just a button with a spinner, how hard can it be to just create my own, Michael?

I have spent hours tweaking a single button. Not a calendar widget (god forbid) or a cool custom widget, just the button that comes in html, which by default has this beautiful look:

And here it is as rendered in a few different browsers: (Chrome, Edge, Old IE 11, Safari)

The foundations of the web are pretty shaky to create UI on top of, we need all the help we can get, in the form of standing on the shoulders of giants (UI component libraries) and having componentization.

2 - HTML+JS vs React fight

Html is a breeze. CSS is... ...I can barely think of a worse way to make UI, but with tailwind it's passable. React is a pain. You build an application and it's thousands of lines of code and hundreds or thousands of underlying npm packages as well. In the end, you may have an application that is prone to errors (components within components) and browser errors (rendering complexities in different browsers are real). So then here is my question:

If someone hired you to create a webpage (no framework involved), would you take the job? Can you even find work where companies are looking to hire people to create webpages anymore?

For my personal answer to the above, if someone offered me my current salary to only work on web pages... simpler and easier work than what I currently do, I would... turn them down. Not due to ego, but because I have been down that road already. As the meme image hinted, you can work on web stuff, web pages, visual design, and be kept out of the full stack engineering space. It sucks. The engineering space, complete with companies that want engineering done, while a ton harder than the raw web page space, is also a very creatively rewarding space to be within. That is the space that React lives in, and the space that pure js apps can get out of. The expectations are for speed and "you're just creating a webpage, that should only take a day, right?"

[ lucille bluth how much is a banana file footage not found ]

I'll go a step further and say that 99% of people who work with React are engineers, not designers or webpage creators. So you'll be working in an engineering space, with other people who are truly engineers as well.

As far as work at companies, I haven't seen people looking for just webpage edits in a long time. That space has been eaten up by WordPress, squarespace, themeforest, 5 html templates for 0.000004 bitcoins, etc etc. The game is over there. The space is saturated. If you think it's difficult to compete with the tons of other people who also write React better than you and I, try competing with some of the people who make webpages out there. It's insane what beautiful stuff they can visually create and how fast html pages can be created.

So React filters over from page creation space into the engineering space, and that's good for me, because I don't want to compete with what's out there in the non-engineering space. There there be dragons.

3 - It makes things take longer to plan... ..isn't that bad?

I would say that it takes longer to plan and execute building things in React than without React. That's irony. That seems like a bad outcome for the speed metric. Imagine the headlines:

However, reality takes so much more work and expertise to generate high quality than it seems. We think we can and should take shortcuts, but we're better off letting go of that expectation for an easy win early on and settling in.

I recently learned that contrary to my ego, it takes mastery to cut a hedge shrubbery correctly without dropping the clippings into the body of the hedge and making an ugly mess later. It takes months to grow a carrot and we love to grow plants. Why do we want software to be done as fast as possible? Good companies and good teams can absorb the stark reality that good stuff takes a long time and a lot of iterations. You probably don't want to work for the companies that can't accept that.

4 - jQuery and JS vs React, why bother if the first one will get the job done?

I worked with jQuery back in the day, and I work with it on a legacy project today. jQuery still has a place in my heart, only because I have a deep-rooted mistrust of browser compatibility due to being burned so many times in the past. The main things that I needed jQuery for have been replaced by document.querySelectorAll() and a domready wrapper. So we have the best bits of jQuery in browsers today. But it's still not powerful enough. Building the basic foundations is so difficult that people routinely think that they can rebuild Facebook over a weekend. We think we can build a simple carousel component on our own (but we forget about the invisible accessibility non-functional requirements (http://web-accessibility.carnegiemuseums.org/code/carousels/) ).
We need... dun dun dun, something as powerful as a framework to harness the full potential of what we could build.

5 - Are people hiring for React because they want cogs in a machine?

A lot of companies hire with React as a skill keyword, and a lot of those teams at the companies are spending a lot of time on React projects, but is React just a lowest common denominator, a keyword matching mechanism? A person in the thread made the astute observation that if a role lists all the frameworks "Must know at least one of (React/Angular/Vue)" then the writers may effectively mean "must know javascript" because those frameworks are not the same at all anyway.
In a way React/Angular/Vue are not just a technology, but a clique or community; a way of thinking about engineering on the web that didn't exist in the 90s. It also involves engineering for problems that didn't exist in the 90s. The web interface for the spotify player and other web apps with subtle tweaks and requirements cannot be aggregated from a collection of jQuery plugins. So React(/angular/vue/svelte) is about the clique and the methodologies taught by the community more than the technology.

So for now I'm still moving that project to React, but let me know of any great alternatives I should check out

So I am currently still planning to move my legacy project from jQuery+js to React. jQuery and js alone is just not powerful enough to get done what I want to get done (creating a lexicon of UI words to build from, and UI tools that are custom to my app, mainly). There may be other alternatives out there with good component systems, and I'm happy to hear of them, but the conceptual component is a crucial piece, and being able to build on the shoulders of (ui) giants who are better than me is the other crucial piece. I don't want to spend another day building a good button. How about you? Where are you sourcing your grain-fed free-range buttons from these days?

Honorable Mentions

Alternatives to React to consider:

• https://swup.js.org/ single-page-app but with minimal framework, still along for the feel of an SPA
• HEC no-framework approach: https://medium.com/@metapgmr/hex-a-no-framework-approach-to-building-modern-web-apps-e43f74190b9c
• Astro to use every framework at once instead of just react? https://astro.build/
• What about a little boilerplate repo that I am working on myself as a result of this article, (WIP) called lazier: https://github.com/tchalvak/lazier/tree/main