Really, why React?

I'm not a "React advocate" or anything like that, I just use React at work a lot and I also worked with Angular (the old AngularJS and the newer versions as well), Backbone, Vue, Svelte, jQuery, MooTools and so on. Still, I feel that your rant might be slightly biased because maybe you have more experience with other libs/frames like maybe Vue, or Angular for the looks of it. I'll go item by item with my responses, not to engage or anything like that, more to add other point of view to your post:

• Excessiveness: Besides the fact that you can literally start a project by running npm init react-app, if you want to do things manually, without a build step, you can also create a project, add react, react-dom and htm, and done. You can even import them from SkyPack if you don't want to use npm because of reasons.
• JSX: I use to hate JSX, because I had experience with stuff that had "template separated from implementation" and I saw JSX as an abomination. The thing is, it actually makes coding components way simpler and more expressive when working with "hyperscript based" libraries".

// This...
const imageAnchor = h("a", {
    href: "https://example.com",
    children: h("img", { src: "example.jpg" })
});

// Is kinda harder to read than this...
const imageAnchor = (
    <a href="https://example.com">
        <img src="example.jpg" />
    </a>
);

// And that's a really simple case.

About attributes like class, and for that are turned into properties like className and htmlFor, that becomes obvious when you understand that JSX is just JS, and that you're not setting attributes, but actually JS properties of the element. If you want to set the class of an element from JS, you use the className property (you could also do element.setAttribute("class", "..."); or element.classList.add("...")). If that's annoying for you, you could use preact instead, which supports using attribute names.

• Too many options, patterns, ideas: This is, in my opinion, the best thing about React, or any library. If you prefer to write stuff with classes, you have an option for that with HOCs and all that Jazz. If you prefer a more functional approach, you can also write your components like that, using hooks when needed. There are certain things that are a constant, like avoiding two-day data bindings for example, avoiding mutations, and so on ... but those are just good practices pretty much anywhere.
• Synthetic events: No argument here. Synthetic events are horrible. I understand why they were made (in order to get a consistent event type in any React app, react-native, react-dom, etc.), but I still don't like them at all. The approach preact had with events is far better (but also, preact is mainly for web, not for native).
• Styles: Again, love to have multiple options. Do you prefer the classic approach with global CSS? Go with it ... maybe a CSS modules? Sure thing! ... having CSS directly in your components is what you like? Then you can have that CSS-in-JS. I understand that for folks coming from frameworks were every question has a single answer this can be confusing, but having the freedom of choosing whatever approach you prefer is something that I see as a pro, not a con.
• Developer Experience: When folks that work with React tell you "is just JavaScript", is mainly because if you want to solve something with react, generally you can google it as a solution for vanilla JS, and most probably that will work with React. You don't have to do a v-for to loop trough a list, you can just use a map. You don't need a ng:show to avoid rendering something, you can just use a ternary. The solutions generally are things that you can have in vanilla JS. The thing that is more "react heavy" is the actual interaction with the DOM, because React uses a VDOM abstraction in top of it, so you need to use stuff like ref to have access to those elements.
• Lack of respect for web standards: In this one again, I agree with you. React generally sucks at web standards ... but if we are honest, web standars kinda suck as well.
• Performance: VDOM will never be as performant as not VDOM, but still if you write your component with performance in mind (memoizing, no internal state, and so on) then that performance difference is barely noticeable in a real world scenario. You can achieve bad performance in pretty much any framework/library, so this is not unique to React.
• StrictMode: This is optional, and is there to enforce things like not using the deprecated stuff (all frameworks and libraries have deprecated functions and methods, so is ok). I don't see why you say that this is something worthy of push React into the sea.

I believe that's it. Cheers!

I've seen lots of anti-React sentiment lately and I just don't get it. React is an excellent framework. Just as the JS ecosystem reached some level of maturity with React, developers now seem to be rather keen on jumping ship and chasing whatever new toys the ecosystem has to offer. Framework frenzy appears to be back in full swing and it's not healthy at all.

Excessiveness

You didn't actually mention any problems here. Instead, you referenced other libraries and technologies like jQuery. What in particular about React do you feel is excessive?

JSX
What kind of library adds one weird solution so you can get out of having to use their other weird solution?!

A good one. It's called syntax sugar. You create a library with low-level utils that allow developers to programmatically hook into your system and do low-level things if they need to. In the case of React, those low-level utils are just wrappers around native DOM methods: React.createElement instead of document.createElement, for example. But as a library maintainer, you also acknowledge that most users won't need to get their hands dirty and that the most natural way to create UIs is declaratively. Hence JSX.

Too many options, patterns, ideas

Well, for one, this is true for nearly every conceivable framework. But more importantly, this isn't actually a bad thing. It's a sign of a healthy framework that's so usable and generic that it allows for myriad standards, patterns, and practices to emerge. Some are better than others. The point is that your team has the freedom to pick the patterns that suit your workflow and needs.

Synthetic events

Not an actual problem. Synthetic events are a key part of React's wrapper DOM. I've also never personally had to deal with them.

You mentioned custom events, but is there any practical situation where the code sample you showed would make sense? You usually won't rely on native DOM methods to get a particular node and dispatch an event like you showed here:

// Now make the div "bark" 
document.getElementById('dog').dispatchEvent(barkEvent)

You can use pubsubs, plain old callbacks/props, and other patterns to get around this, or just lean on a state management lib to dispatch events.

Styles

I don't see the problem here. React has lots of options for styling because it imposes absolutely no restriction on what you can or cannot do. Plain stylesheets, stylesheets and CSS Modules, styled-components, styled-components and CSS modules, inline styles as JS objects, and, my personal favorite, styled-jsx. It goes back to the "problem" of having lots of options and patterns. Every team is free to use what it wants. That's a good thing!

DX is lame

I'm not seeing any real arguments here. React is just JavaScript.

Standards, portability, and over-engineering

Ironically, the template string example you gave already exposes you to invalid HTML/escaping/XSS attacks that React mostly takes care of for you. If you want to build robust components, you're at some point going to have to reinvent the wheel.

Components like that are bad engineering. Button, headings, anchor, and the other 100+ HTML elements should not be recreated as React abstractions!

Why not? Every app is an abstraction in the sense that it takes atomic components and uses them to create bigger components. The beauty of creating custom components around native DOM ones is that you can style them and control their behavior consistently rather than always having to override those styles/behaviors on a case-by-case basis. Rarely do you ever take something that a library gives you and use it as-is, in its undecorated form—often, you need to customize the most atomic components and tailor them to your specific needs. There's absolutely nothing wrong with doing this, and it's not even a React-specific practice.

Bonus: StrictMode
When a framework has to introduce special “modes” to help you navigate the bad stuff, it’s done. Burnt. End-of-life. Time to cut it loose and push it out to sea.

developer.mozilla.org/en-US/docs/W...

JavaScript has a strict mode. It was introduced to help us write better code with fewer errors. Likewise, React's strict mode is specific to the framework and is intended to encourage good practices.

It's an impressive article and many kudos for it, so many good points.

My curiosity is to see in other comments what experience do React endorsers or evangelists have besides Reacts?! Also, what about experience with programming principles like KISS, SOLID, DRY and many others.

Hello, thanks for taking the time to write this rant.
I want to point at some missconceptions about React.
React is not a component templating library. Vue, Svelte, Marko,... are. So obviously JSX is is not an templating syntax and certainly not an HTML templating syntax. JSX is an extension of JS syntax to make writing JS to React Virtual DOM rendering easier.
So tour title JSX templates is missleading.

JSX is a JS extension, not an HTML template engine. This means JSX is precompiled to JS, then JSX knows nothing about component context, where a template engine does. Template engines are more powerfull to optimize what to render at a high level (before Virtual DOM merge) where JSX has to go all the way down the road to know if it should re-render a sub component by running it's JS code. Where a template engine, being declarative, can understand what to render before hand.

Although these are all good points, the majority of them fall on to us developers.

You can write a clean, elegant, well-structured react application. The problem is the majority of react devs don't know (or care?) how to.

The react documentation (which admittedly is not the best) is full of apologies; not for react being a terrible framework, but for people absolutely butchering it and writing awful code with it for years and years.

On other hand synthetic events are just terrible.

You make some good points, I for one would much prefer to use Svelte but then that's not actually Javascript. The React "it's just Javascript" is looking at the output of any React component - nothing gets parsed, it's just a function you can call. JSX isn't claiming to be html, it's as you point out, just some sugar and I'm glad of it existing when I'm coding in React, but it locks you in and that's "meh" to me too.

We did a trial a couple of years ago of Angular, Vue, React and Svelte to create our core template app. Of those Angular just couldn't support the dynamic feature set we wanted. Svelte was considered (by others, I'd released a Svelte app) too new and untested, Vue was way slower than React at supporting a core feature of our platform and so we ended up with React and I've learned to live with it. The biggest problems being the "14 ways to do everything".

I came to React after "Hooks" and apart from a side project years ago, I've never used class components and I don't like them. Reactivity works well with hooks but it's not Svelte. I do think you can organise a React code base well and I do think you can produce powerful and performant solutions by reasoning with a few simple hooks.

Synthetic events are a nightmare and massively add to the bloat of React - just look at Preact and the benefits it brings to size etc.

I agree that React has many issues. You've done a good job of pointing them out. But I have to ask you why you think React trying to improve itself is a bad thing. Yes, React has several ways to manage state and component lifecycle. The old ones had problems, and yes you'll have to learn about the new ones, but surely it's better to have them than be stuck on the old version? Especially with your concerns of legacy messes, these new capabilities allow developers to write new code and slowly convert the legacy code as needed. For new projects, you can just avoid the old techniques.

On compilation: I've never worked with Vue or Riot myself, so forgive me if I'm wrong, but my understanding is that Vue works with .vue files and Riot works by defining web components like in your example in the Styles section of your article (Checking the Riot docs, a compilation step is needed. It can be done in the browser, but that's a dev tool and not good for production.). Both of these require preprocessing. You can't act as though React is intolerable in this aspect if you use the same.

On your bonus strict mode point... you do know JS has a strict mode right? :P

HTML, CSS, and JavaScript are web standards. They will outlive every framework, library, . . .

I love this quote. This is exactly why nowadays I stray away from synthetic JS solutions. Turns out, I like having accessibility out-of-the-box and not reinventing HTML/CSS : P

Hello,

If you just want Javascript for your Frontend dev
try DML
Here is a simple counter with DML

import {button, idiv} from "./dml"; /* <sdtio.h> :-) */

function Counter () {
    let count = 0;
    let value = idiv("0", {style:"padding-right: 10px"});
    let binc = button("inc");
    let bdec = button("dec");
    binc.onclick = () => value.innerText = ++count;
    bdec.onclick = () => value.innerText = --count;
}

Counter();

You can test it here TinyCounter

Regards

What you don't understand is that I'm 100 faster then you building apps using react, so only because you can't grasp or learn JSX doesn't mean others can'. Another misunderstanding you have is JSX must be same as HTML but no! It's a new language that allows you to write JavaScript UI code compile it and spit out valid HTML thats why it is called JSX and not HTML. At this point it would for you be just easier to not use it instead of writing this post, or if you are soo mad that people build fast apps with it and make money but you aren't because JSX is so complicated then you should maybe buy a course take a shower again and try it one more time.

Thank you for putting to words everything I should be able to say when people ask me why I hate react.

I see no mention of lit-element in the post or the comments, you should check it out. It's more minimalistic than riot or svelte, and uses template literals to make web components.

And a shameless plug - if you want all that, with an even simpler API and no compilation steps works-as-it-is in the browser, feel free to check out my frontend library YoffeeJS :)

I have written an article like this 4 years ago. Finally, other people like yourself are also writing the same thing and I believe that slowly the community learns from their mistakes.
Every React project I was part in was a mess of spaghetti code and over engineering. I was in a startup where the lead front end was a resume/hype driven engineer type. His idea of a React project was so bad that other devs were saying "I don't know how the whole thing works I just write it and try to make it work." He also added TS, rxjs etc for a dashboard app which could be very easily be done with simpler tools. The lead wrote a 130 lines of code which in essence was an axios call of 5 lines.
React has made most devs I know completely oblivious to html/css, in such degree were I met mid level devs telling me they do not know how to style a checkbox without JS or React.
Funny thing is that all the pros of react various fans will throw at you are marketing text from the react site or the site promoting the new way of doing things because all these years we were doing it wrong e.g Redux, sagas, rxjs etc.
By the way hooks are actually crockford objects. But good marketing and a name change does wonders.
But as always if you need to provide for your family and need a job React will give you that.

You make some valid points. as I was reading it I was often reminded of those frustrating times when learning React and feeling the same type of way. After getting over those hurdles though I’ve come to realize, I love building in React. There’s just something about it, and then with typescript, ahh the code just starts writing itself. Also, I think when you look at some React code if it’s written the right way, it’s beautiful looking, artistic tic in a way as it sways back and forth down your page. And hooks? Those devilish looking things, letting you reach in at any point to do some side computing or whatever you can think of. Probably just my love for JavaScript/Typescript but I love it.

The examples related to Synthetic events are wrong or missing details that make them actually work.

For example:

• This

// Create custom "bark" event
const bark Event = new CustomEvent('bark')

// Bind to the bark event in your render function
render() {
  return <div id="x" onBark ={this.handleBark}></div>
}

// Now make the div "bark" 
document.getElementById('dog').dispatchEvent(barkEvent)

should be:

// Create custom "bark" event
const barkEvent = new CustomEvent('bark')

// Bind to the bark event in your render function
render() {
  return <div id="dog" onBark ={this.handleBark}></div>
}

// Now make the div "bark" 
document.getElementById('dog').dispatchEvent(barkEvent)

• This:

constructor(props) {
  super(props);
  this.x = React.createRef();
}

componentDidMount() {
  this.x.current.addEventListener('bark', this.handleBark)
}

render() {
  return <div id="dog"></div>
}

should be:

constructor(props) {
  super(props);
  this.x = React.createRef();
}

componentDidMount() {
  this.x.current.addEventListener('bark', this.handleBark)
}

render() {
  return <div id="dog" ref={this.x}></div>
}

I use react daily for work and generally like using it. I think some of the points in your article are interesting though. Out of curiosity what do you typically use instead of react when you need to write more complex web applications?

I have tried React, Vue and Angular (not AngularJS). I totally agree with your article about the complexity of implementing the React ecosystem. When using React, we need to learn a lot of libraries to create a full-feature front-end solution. When managing a team that developers use different React libraries for a specific solution, it costs a lot of time and efforts to debate and decide which library should be implemented.

Therefore, I decided to switch to Angular for my projects. Angular provides a full solutions for all problems that we can encounter with in front-end development. It is easier for new member to get started and quickly collaborate properly with the team. Experienced developers also could spend more time and efforts to improve user experience instead of wasting into debate about different tools that solve the same problem.

• Your JSX will turn into a PHP-like "unmanageable mess"

CommitStrip: A theory about PHP

They weren't kidding when they said "unmanageable mess".

As I stated elsewhere:

And it has never occurred to you that it's kind of strange that a "UI library" needs support for non-visual components?

My pet hypothesis on why React is popular: components are so darn familiar (and therefore comfortable).

"But React is so declarative/functional"

Meanwhile in Elm land:

Evan Czaplicki

@evancz

1) Components are objects!

components = local state + methods

local state + methods = objects

14:41 PM - 31 Aug 2017

and Component's don't work within the functional paradigm.

By replacing classes with "functions + hooks" React has merely traded object instances with closures.

Quote

Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object."

So today under the hood React is no more functional than back in the createClass() days.

Then of course components are reusable - though ReuseHasFailed - i.e. nothing is truly reusable unless additional effort makes it reusable (RuleOfThree).

And then the whole "component styles" fantasy. Layout and styling is not component-oriented. There is no "unified interface" between the layout and a block. Blocks are supposed to blend into the overall global layout (CSS Is Certainly Global And That’s Exactly The Point) - not assert themselves as autonomous entities. At most a block should dictate its structure but not its skin (separate structure and skin) - and most component styling solutions don't accommodate that.

There are so so many things wrong with this post, practically every paragraph I read (stopped reading after about 1/3) 🤦‍♂️

Hey man! Nice article, just want to share my opinions / thoughts re these frameworks / libraries war.

I've worked with Vue, I've worked with Angular 1.x, I've worked with React. There's only 2 types of Framework/Library, the one that sucks & the one that people complains.

I'm pretty much framework agnostic, I care about the result & the developer experience, I don't hate or love one specifically, I choose based on what the result needs.

I've used Vue, super easy to learn, but it has some limitations too (*cough; intellisense 2021, typesafe *cough; uh Vue 3.x). Don't get me wrong, I wasn't just trying out Vue, I was in a Core / Central non Product Team that develops internal libraries, wrappers, ui libs for our Product Web Engineers that uses Vue, I faced a lot of issues too, and it was annoying.

Angular 1.x was ok, I just follow their docs, but I wasn't doing complex programming tho. But hell, I was tired of writing boiler plates.

React, I've worked for companies that uses mainly React (with one of them while doing quick iterations uses Vue). Ugh confusing, jsx, whatever.

Svelte.. Riot.. I might try, but not sure if I can trust them to production with a goal of hundred thousands of users. Since it hasn't been adopted that deep yet and we don't know that corner cases they might produce.

So after the experience I got from using these framework / library is.

I look at them as my View Renderer. What does that mean? I have business logic, in typescript / javascript, have test-cases for them (simple test, expect, without testing the render view). I like Vue when it comes to non-complex application that doesn't go to hundreds of files because I hate working at year 2021 without autocomplete. I like angu... nvm. I like React because it has limitless customization, but what a hell learning steeeeepp they got there. But hey, what if I only write my stuffs using JavaScript / TypeScript, and easily uses them in my React that uses JSX with autocomplete out of the box with my beloved editor, sweet right? oh and we had hundreds of files, it still works.

If you want to get things done, lazy / got no time to learn more stuffs, go with Vue, ez, all in 1 file can do (oh and I love their documentations).
If you want to get.. nah, this one I skip.
If you know & understand javascript, and it weirdness, and you still write javascript, go with React, and go with "I just write my stuffs with JavaScript" then renders it with React.

I realize all my worships into specific frameworks / libraries gone with my experience using each of them in a meaningful way (if I break stuff I may lose my job). ✌️

I've tried to start a couple of new, even simple projects in React and usually after one day or so, at about 50%, I run into things that don't "just work", search for answers, and the answer seems so backward and alien an unintuitive that I feel like I've been falling and finally hit the bottom of that pit of despair. Really? The want me to pollute my code with that solution? Then I repeat the test with Vue or Svelte or Alpine or even Angular or something else and things tend to "just work".

I understand that React provides a lot of benefit but to me the cost is so high that I feel it is a net loss, especially given that there are plenty of alternatives that provide those benefits without the high cost. To me, React encourages technical debt, and deep lock-in on an approach that is ugly, for the reasons you outline in this article above.

React apologists will explain why they like it's awkwardness, those are features, but I honestly feel either they are new to webdev and just learned to deal with and ignore these problems, or there must be something else motivating that opinion, e.g. that they are required to use it for their full-time job, or they've invested so heavily that they must defend it now.

Frankly I don't understand why anyone who has learned all the lessons of software development would support React. Maybe most are actually aged younger than the 37 years that I've been a professional developer. I started a full decade before the first browser. I used Mosaic and then Netscape. React is a buzzword fad that will probably die a sudden painful death as more and more realize the cost outweighs the benefit. There are so many better choices. I've gotten to the point where I don't want to work at any company that has chosen React as their front-end solution in their development stack. It's a red flag that those making the decisions are doing so for the wrong reasons.

I've been learning react through courses for around 8 months (such a long time but it's like an hour a day thing) and I honestly don't really like how convoluted it is. The event/state bubbling can easily turn to mayhem (I'm very much a follower of our holy spaghetti god so I have a talent for chaotic coding which means if I ever use react it'll be chaaaos and the final fantasy guy will want to kill me) and honestly... I also feel like it's a huge barrier to get started with web development. It actually made me nostalgic for the old web. Nowadays normal people need to buy expensive courses to dip their toes in web development, before that you just needed notepad and a desire to create a fan site for The Rasmus with it's own visitor's signature book hahaha

Anyway, nice post ⭐ also good luck with all those comments and debates you're getting!

I have to say that when I started reading this article, at some point I thought hmm, are you mainly bashing React for the sake of it, and just nitpicking a lot - notably when you were going on and on about JSX and how terrible it is (which TBH I've never felt that much, personally - I've always thought that JSX was an interesting approach).

But later on there were some points (especially "Too many options, patterns, ideas") which I felt were really bang on - the whole "pattern" craze (HOCs, wrappers, mixins, render props, plus ten thousand different ways to do Redux) is something that has always irked me a LOT, about React ...

I mean:

Instead of just being a powerful framework (sorry, a "library" lol) that helps you building UIs, and gets out of your way, as I'd expect - but no, you need to become a "React expert" with a deep understanding of all this pattern junk and how and when to use it, rather than just being proficient as a web developer. "React expert", let that sink in for a moment.

All of this is arcane knowledge, which doesn't transfer well (or not at all) to any other frontend framework (ah, sorry ... LIBRARY) that I know of.

And just when you've mastered all of that, they tell you to forget it because now "Hooks" is the new holy grail.

That's really the aspect which I've always disliked the most about React - it looks like they offer you a half baked solution and then it's like "bye, good luck figuring it out". Contrast that with something like Vue, which is much more "batteries included" and opinionated, where they offer you standard solutions for routing, state management, two way binding, and so on. No endless discussions because there's consensus on how to do things (and Vue is at least equal, if not better, in terms of speed and bundle size).

On top of that, with React if you don't use all of these patterns (or nowadays that would probably be Hooks in most cases) "correctly", you'll end up with poor performance because of unnecessary re-rendering. Seems to me that React just makes me work harder as a dev, forcing me to manage all of this arguably low-level shit, and puts the onus on me to achieve good performance, instead of taking care of it for me, and allowing me to focus on the business logic of my app.

I don't like react for one reason that many devs would not even care about and its that every goddamn project i need to fix/patch has completely different stack of libraries in it, so instead of me doing some simple tasks i have 6 tabs of docs opened bcs its 5th form library that i need to know so i can fix some validation bug. The point is when i learn something in angular, and i dont refer to angularjs, after one year i can sit open that project and within about 5 or 10 mimutes i know where and why and how to do what i need to do. Why not react? Because i respect my time.