"The freedom of React" is a hard statement for me to digest.
I stopped using React specifically because it was so incredibly limiting. And my life has been a lot better without it.
I stopped using React specifically because it was so incredibly limiting. And my life has been a lot better without it.
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.
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.
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!).
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.
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.
React was a dumb idea from the very beginning, and anyone who knew vanilla js well could tell you that.
Nothing. As long as you’re not using React and value your sanity.
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.
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…
Vue doesn’t have that. And yet it doesn’t lock you down the way Angular does.
Now, what that “area” is, remains up for discussion