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 this ironic meme image:

(The image roughly sums up that friend's concerns, my position on the matter is different )

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 another old personal 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

Lower complexity is usually a good argument in software. "That pull request will highly increase complexity." is a valid rationale to take 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 and work with" 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.

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 are the variations that you'll have to encounter of how a button is rendered in a few different browsers (just a button, one of the simpler building blocks): (Chrome, Edge, Old IE 11, Safari)

Over the course of my career I have found there to be similar or worse variations in <button>, <select>, <ul>, <dl>, <abbr>, <small>, <iframe>, <input> types, of course with <audio> and <video> not to mention functional differences (and sometimes things just don't work as needed in different browsers without polyfills, like how <abbr> need a polyfill on mobile browsers for definitions to be readable).

The foundations of the web are pretty shaky to create app-based UI on top of. Even with html5 we get the hint that it's really geared towards newspaper <article>s and blog posts with <asides>, it was not made for building web apps. Especially to fulfill invisible and nonfunctional requirements like a11y and consistency, we need all the help we can get. We can get that help by standing on the shoulders of giants; UI component libraries can crowdsource issues that we and others would encounter, and having composition via components helps avoid reinventing the wheel during the creation of each new widget of an app.

2 - HTML+JS vs React: Fight!

Html is a breeze. Javascript is fun. CSS is... ...well, I can barely think of a worse way to make UI, but with tailwind it's simple enough. React on the other hand is a pain. You build an application and it's thousands of lines of code and relies on 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, minimal js) today, would you take the job? Can you even find feasibly find work at your pay scale where companies are looking to hire people to create webpages?

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. That is not due to ego, it is because I have been down that road already. As the meme image hinted, you can work on web stuff, visual design, web pages, companies can use that to keep you out of an engineering space by pushing you into an infinite treadmill of pixel perfection and throwaway marketing sites. Being told that your passion for outcomes that require time to think through and create deep quality, because it would take too long, that sucks. The space that we call "engineering", complete with companies that want engineering done, while a ton harder to work within 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 often exit from. The problematic expectations in that space are often for speed over engineering 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 because engineering is usually an entrance fee to React, you will often find yourself working with a team that share that engineering mindset. That can sometimes lend itself to overengineering the whole team you'd work with in a React space will often be in an engineering mindset as well.

As far as high paying 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, free themes, 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 flat html pages can be created now.

So React filters over from page creation space into the engineering space for people who don’t want to deal with React’s bull****, 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 with React than without React. That's irony. That seems like a bad outcome for the metric of speed? 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 of an easy win early on and settling in.

It takes mastery to cut a hedge shrubbery correctly (I learned this to my dismay after dropping the hedge clippings into the hedge when they were green and having to manually painstakingly pull them out weeks later when the clippings turned brown). It takes months to grow a carrot in a garden, yet it's one of life's great pleasures to grow plants. Why do we want software to be done as fast as humanly possible? Sometimes that speed is to the detriment of long term quality. Good companies and good teams can absorb the stark reality that good stuff takes a long time and a lot of iterations. Are you sure you want to work for the companies that can't accept that things might take time to get done to a high level of quality?

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. However jQuery and 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 for web UIs, we have to rely on other’s works as a baseline to build better outcomes.
So the formula becomes:
jQuery + js = fine for solo one-offs. React + ui framework = help long term consistency.

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, such as saying "This role 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 that's close, but React/Angular/Vue are not just a technology, they are also 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 is not for solo work, it’s for team work, and the clique and the community methodologies are more than the technology.

Pure js = fine for solo development. React = assists with team consistency.
If you like to spend a weekend writing an amazing 100k pure javascript genius solution, but two months from now no-one else on your team will get to understand what the flip you built, React helps push back against that with the huge amount of community documentation and best practices that we might not be able to find in the work of a virtuoso solo javascript developer.

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

So for now I am planning to move my legacy project from jQuery+js to React. I yearn for the day when js is robust enough and consistent enough to get done what I want to get done (creating a lexicon of UI verbs to compose, and app widgets that are customized 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 one 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 again. 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