[1] https://2023.stateofjs.com/en-US/libraries/front-end-framewo...

  * Components don't have exposed identities, but component state is based on identity.  Secretly they're fibers.
  * Everything is treated as if it's immutable.  Reference equality is used to infer no changes.  Working with array-based state, or almost anything really, is awkward and unnecessarily verbose.  Spread all the things.
  * The rules of hooks.  These are just implementation constraints based on the rest of the design decisions of react.
  * You can't use symbols as keys.  This is small, but particularly irksome for me.
  * The smallest unit of UI change is the component render function.
  * Effect dependencies need to be listed explicitly.

Immutability is a great callout; frontend ecosystem is quite divisive on it.

For my flavor, as React exploded, redux and the advanced state management frameworks came and made everything bananas[1]. "It solves real problems for advanced apps"; maybe but I could never shake that these problems are self-inflicted.

There's a mathematical functional purity that's nerd-snipe worthy; but reactivity with mutation observers just seems to model the real world of UIs better.

Anyway, https://mobx.js.org/README.html is the exact opposite take: mutate your state! Subscribe to changes to your heart's content.

The divisiveness is real, it's what makes staying up to date exhausting.

[1] Come on, no one seriously thinks "bind action creators" made intuitive, ergonomic sense.

[1] https://github.com/tomtheisen/mutraction

i loved react when it came out, it was magnitude improvement for rapid prototyping. jsx as an idea seems ridiculous, but in practice, might as well make everything js and use the programming language's full power—otherwise you get pseudo-code-in-html. html directives will never be a full programming language, I can't understand why frameworks go down this path, repeatedly!

"fuck it, everything is javascript" is react's great insight, for interactive applications.

The frontend ecosystem overall, i find very exhausting, yes. but that's not on react.

What don't you like about it?

I'd argue that jsx was react's great insight. But maybe that's the same thing. Anyway yes. But unfortunately, you can't use react without using the rest of its insights, such as all data must be immutable, and DOM updates are based on reconciliation.

> The frontend ecosystem overall, i find very exhausting, yes. but that's not on react.

That's true. React has more than enough of its own problems though.

In contrast, I can't understand how magic attributes on html nodes is more clear. What's your take on that?

For example in Vue's introduction:

    <div id="app">
      <button @click="count++">
        Count is: {{ count }}
      </button>
    </div>

Using native HTML nodes, templates, and tags makes it seem standard. This is the worst learning curve: the bait and switch vs being clear—albeit intense—that the component is 100% a JS programming env that yields the UI.

React component is not the UI it's a JS function that yields the UI.

Not saying that it's bad necessarily, but there are pros and cons to the JSX approach and the template approach (a lá Vue, or actually Mustache that Vue's template syntax partly comes from).

I think what's easiest/best comes down to: 1. Your background (ppl coming from BE tend to prefer to stay in a more full-blown programming language, people with a HTML/CSS background tend to prefer the template approach. 2. How junior you are. Generally people tend to say that React has more of a learning curve then Vue. 3. What your needs are. Full-blown web apps? Simple small enhancements of static websites? How much detailed/special control do you need or your components HTML output, etc.

PS. @click is actually very similar to the native click attribute. Furthermore, React has className as a special attribute that's definitely on a similar level same-but-not-really.

The special React-ism that bugs me the most in this area is that React elements map the "change" event to "input". There's no way to handle "change" without getting a ref and wiring it up yourself. As a consequence, most developers don't seem to remember or ever knew what "change" actually is.

I have done html templating syntax in many different languages and frameworks starting with Laravel Blade and it always felt much better than the native syntax of doing that e.g. with PHP.

I don't think it ks a worthwhile feature to have everything strictly JS. Use different tools as they are appropriate, why hinder yourself.

Ultimately there are some very frequent and limited patterns in defining interactive html elements so best to use the syntax that has the highest meaning to noise ratio.

The combination of useState, stateValue, setStateValue are simply unnecessary boilerplate that makes important things like the state variable itself hidden in a sea of noise.

> React component is not the UI it's a JS function that yields the UI

I don't think that is a good philosophy at all. The code should be about clarity not around an odd dogma about having to be a JS function that yields the UI. It in my view is a misplaced enthusiasm for something that really doesn't matter, but will hinder things since you have to constantly work and hack around those self posed arbitrary restrictions.

The "everything is JS" and "JS yields the UI" is 100% based on the constraints of the runtime.

Modern UIs need browser APIs, events, DOM management, and stying. We MUST use HTML/CSS/JS. My take is "everything in JS" _in this context_ is more reasonable, more integrated, and ultimately more intuitive, not that it's simple or easy, but that we're stuck with the runtime, we're going to need these all to integrate with one another, let's be clear on in the integration interfaces.

And the tag closing semantics are slightly different from HTML. And approximately no one understands how HTML tag closing works anymore because of it.