▲ | wk_end 18 hours ago | ||||||||||||||||||||||
I think (at least part of) the reason why React has been so successful is that is scales so well: it's actually a relatively simple tool that works well for small problems. Pair it with a Vite template or something and you can be up-and-running in minutes. But it continues working pretty well as your app gets bigger, too. But where React fails is actually in more complex scenarios. Prop drilling becomes tedious or intractable, so now we have all these different ways to manage state (Context, Redux, MobX, Recoil, Zustand, Jotai...). Your re-rendering gets slow, so now you need to start sprinkling React.memo() all over the place and adding reselect (or re-reselect!) queries and restructuring or denormalizing your store data, but then it turns out some of your props are objects that are regenerating each render cycle, so you need to memoize those too, and you end up on a wild goose chase there. Or your engineers were sloppy and accidentally put some side-effects into your components, so you've got subtle bugs you're not sure how to fix. And there's a lot of complexity or even unanswered questions around things like robustly fetching data your component needs, and maybe React Router answers them but then you end up down a whole other rabbit hole, especially when a new version of React Router comes out and breaks everything. | |||||||||||||||||||||||
▲ | solarkraft 17 hours ago | parent | next [-] | ||||||||||||||||||||||
The amazing thing about React to me is that millions of dollars keep flowing into improving its DX further. They have spent a lot of time building React Compiler (https://react.dev/learn/react-compiler/introduction) which does all the memoization for you! This severely lightens the performance concerns. | |||||||||||||||||||||||
| |||||||||||||||||||||||
▲ | branko_d 11 hours ago | parent | prev | next [-] | ||||||||||||||||||||||
I think React can be approached a little like JavaScript at this point: just use the good parts! In my case that means using it as a rendering library and component composer, but not for managing state or side-effects. | |||||||||||||||||||||||
| |||||||||||||||||||||||
▲ | boredtofears 11 hours ago | parent | prev [-] | ||||||||||||||||||||||
I had problems with prop drilling on early projects but since Context has been around it hasn't been an issue. Never bothered with all these state management libraries, any time someone on my team has tried to sell me on it they've never made a strong case for it over simple proper react state management. useEffect took a little getting used to - it becomes much less problematic when you learn which scenarios to use it in (fewer than you initially think). I've had to use React.memo() at times, but it's usually done in a simple optimization pass not unlike something I'd do in a backend framework. The only time I am even aware of these problems is when I stick my head into the javascript frontend framework "scene" where everyone acts like each one of these are dealbreakers and they happen constantly all the time. Life is actually pretty easy as a React dev, it's a well polished and at this point battle tested framework. I wish the other tools in my dev stack were as easy to deal with. |