[seph-reed]

I stopped using it a while ago (2-3 years). I had central state management, and a few other bells and whistles.

I was the "go to" guy for when React didn't want to do something.

Most of my wrestling came in the form of:

- recycling html-elements

- "tweening" state. a friggin nightmare to have inbetween states

- performant animation stuff

- stateless node-to-node communication for stuff that would have not fit well in state

- keyboard navigation (think game ui)

Ugh. The more I learned about how it actually works, the more I came to hate it. And it kills me to see so many people who love it... like I'm an alien amongst the people (developers) who I once felt understood me.

[Aeolun]

React does not seem like a good fit for doing any of these things. Aside from keyboard navigation, which works just fine as far as I’ve seen.

I dunno, every time I see someone hating React they’ve been kind of stuck in doing things the jQuery way, and their components become this horrible frankenstein of modifying HTML both through React and directly.

[seph-reed]

Keyboard navigations as in up/left/right/down jumps around somewhat haphazardly placed items. Not tab/shift-tab accessibility.

And you are right that React is not a good fit for these things. That's why I say it's very limiting.

Also, for what it's worth, you might be mistaking "the jquery way" with "the vanilla way." As in:

- working with HTMLElements

- vs working with a superset (tsx) of a superset (ts) of javascript meant to look like html (sometimes), that creates js components that then create html that is then diffed with last html and finally applied to the appropriate innerHTML (and don't forget about all the hooks!).

[throwaway99997]

Yeah, React is a pain for when you need to interact with the DOM elements themselves. If you want to add some logic based on where the element happens to be placed, instead of where you have told React to place your element, you're in for a headache. Now the DOM is one source of state (positioning) and your store (Redux or otherwise) is no longer the single source of truth.

[seph-reed]

IMO, there's no way it lasts purely because of this.

We already have the DOM, and there's literally nothing that React can do that requires its complexity EXCEPT server side rendering. Which most people never use.

[vagrantJin]

> their components become this horrible frankenstein of modifying HTML both through React and directly.

I need to know what the problem is with modifying HTML inside a browser that knows and expects the HTML to be modified, even providing DOM APIs for this exact reason. What is the benefit of modifying a not the DOM besides the dubious claim of performace++?

I use react everyday now BTW. I needed to do something trivial like use something similar to setproperty to update CSS variable with JS returned values. This was part of a component that gets 3 colors and returns an array of RGB values which I need to change the background into a gradient. The one piece of advice I got from the internet is...

styled components.

FfS.

React is breaking every best practice from ~20 years ago of keeping concerns seperate. Sure Jqeury wasnt perfect but I could get a junior dev fresh out of school up an running in two weeks flat. There was no need to bend the time-space continuum with the black whole density of node_modules for every_single_thing.

[seph-reed]

Nothing at all. I've been using a custom made framework for 3 years that does everything React does and more. I could write the whole thing in a weekend. It's not hard, you just cache some functions that create HTML Elements, keep track of what state variables are used inside those functions, and rerender whenever those variables change.

React was a dumb idea from the very beginning, and anyone who knew vanilla js well could tell you that.

[Aeolun]

> I need to know what the problem is with modifying HTML inside a browser that knows and expects the HTML to be modified

Nothing. As long as you’re not using React and value your sanity.

[gentleman11]

By tweening and animation, you mean shifting an element from one part of the screen to another? What part of react fights against this? I’ve been using react for 3 weeks and I’m just curious what I might run into later on

[seph-reed]

If you're animating using just css classes (or transitions), you'll be fine.

Some animations need to be run in javascript though, and doing that through state is a bad idea. You can use ref, and sometimes that's fine, but if the data is changing (hitting a moving target), then you need communication. Think coach-marks and scrolling at the same time.

And "tweening" views means showing the last view fade out while the next one fades in (or scrolls in, etc). This means displaying an old state, and a new state at the same time. The trick is to recycle your html elements, but it'll fight you for it.

[codethief]

> The trick is to recycle your html elements, but it'll fight you for it.

No, the trick is not to use React for animations in the first place.

It's simply not a good a idea to use regular React state for very short-lived data (like animation state) as React will end up re-rendering everything all the time, leading to a significant performance penalty. Instead, I would rather decouple the animated DOM elements from React's state & change handling and just use e.g. d3 to control them. (Yes, it's not pretty but animations have never been pretty in the first place.)

Speaking of (not) using React for short-lived data, this reminds me of another common pitfall: Forms. Many tutorials online blindly recommend binding every HTML input's value to a React state variable using onChange, usually causing the entire form to get re-rendered upon every single key press(!) No wonder the Web is so slow these days…

[buchanaf]

Really the trick is to use react-spring or react-transition-group and leverage powerful community tools that have solved these complex use cases.