DEV Community

Discussion on: Really, why React?

Collapse
guitarino profile image
Kirill Shestakov • Edited on

As someone who's been working in React professionally for many years, I disagree with a lot of what you're saying. Not going to try to convince you, just share my experience with you.

  1. Excessiveness. Tools seem overwhelming in the first few months of working with webpack and babel, but eventually you get a hang of them and learn to really appreciate the flexibility and value these tools provide. Now, this "issue" is actually completely unrelated to React, in fact, you can import React as a bundle just as well and just use createElement instead of JSX. It's not a recommended way, for a good reason, because the engineers who created React build apps using bundlers and latest es6 features, which provide a lot of value and improvement for the developers and web app users.
  2. JSX. JSX is fine. The only problem with it is the initial resistance when you're transferring from another library / way of doing things. JSX came before tagged template literals were a thing, and I find no problem with a decision to hide the cumbersome (yet decently clean) "createElement" in favour of nicer, shorter and familiar HTML-like syntax. There are differences from HTML that I also think shouldn't have existed, but it's easy to get used to them and the different syntax isn't actually worse than HTML's, it's just different. Regarding JSX turning into "unmanageable mess", that's just factually incorrect. And regarding transferability, JSX is somewhat transferable - if you really wanted, you could create a transpiler from JSX to HTML if you really wanted, but in general, yeah, if you use a library, it doesn't have a perfect transferability to other libraries or to pure HTML, but JSX is pretty darn close and easy to transfer. And also, I can assure you, the vast majority of people who use JSX for a while, like to use it and not just tolerate it.
  3. Too many options, patterns, ideas. The longer you work in react, the more you stick with a single pattern, and the longer people around you work in react, the more they choose the same pattern as you, which usually turns into a company-wide practice that everyone follows. Most people these days prefer to just use hooks rather than class components, again, for a good reason, because it allows for a standardized way to reuse functionality without using custom mixins or whatnot. Also people almost always prefer controlled components over uncontrolled. That said, I do have a gripe with how people use certain things: for example, I think that organizing routing via components is a horrible practice, using HOC should be avoided in favour of hooks, and that people should separate as much logic out of components (and out of hooks) as possible into their own classes, factories and functions.
  4. Synthetic events. Yeah, agree with you that synthetic events shouldn't have been a thing. That said, they aren't too bad: they still have all the functionality that you need, they're just a bit slower, harder to debug, and a bit different from native events. But, yeah, synthetic events is one of the reasons why I use Preact instead of React in my personal projects.
  5. Styles. Honestly, I never understand why people have problems with styles. The main ways of doing styling are css modules, styled components and BEM. And I've worked with all 3 and they're all roughly equivalently good.
  6. Developer Experience. React Dev Tools are good, but aren't necessary. Since it is basically JavaScript, you can easily put a breakpoint or a debugger statement in your component and see what's going on.
  7. Lack of respect for web standards. Not quite sure what you mean here. Do you mean the fact that React doesn't use custom elements? Also, not fully sure what you mean by the lack of portability to non-React apps. React components can be used within custom elements and vice versa, and there are ways to use React components in angular or vue or svelte. I think expecting direct copy-paste portability (to what?) is unreasonable, regardless of which framework / library you're talking about. There will obviously need to be a lot of changes if you decide to move away from any library, and React isn't worse than the vast majority of other libraries in terms of this. That said, I think people in general should strictly separate logic from the view layer, and logic should be independent of any framework / library, and, sadly, no framework to my knowledge recommends this approach (for an obvious reason).
  8. Performance. Yes, performance is a bit of a problem, no doubt, unless you use recommended ways to improve performance via React.memo and useMemo. I also think that it's a problem that is easy to solve: make every component memo by default, since it'll always be faster to check flat props than the tree-like rendered virtual DOM elements. You can even override createElement to do memo by default, but it's quite a messy thing to do admittedly. Still, I think when compared to other frameworks, React definitely has a problem. React also doesn't need to be as huge as it is, e.g. Preact is a light-weight alternative to React and has almost the same syntax, development flow and functionality.

Now, there are real problems that React has, I believe. One is, how unengaged React dev team is with pretty much everyone else, with React community, etc. They have their own idea of the future of React, the future nobody asked for, and they're going for it. React used to be a simpler library, its behavior and timing of renders could be easily understood, hooked into and leveraged, but nowadays it's completely impossible and you have to go with a "recommended" way of doing things rather than just being provided with the rendering functionality and given the flexibility. Things like fiber rendering, suspense mode, etc, are actually taking away flexibility from the user and force React's set of priorities (that will likely hurt the user). Things like server components are also something nobody asked for. Many people would like React to go in the direction of improving rendering performance in a svelte-like way, and becoming more flexible rather than less, but React dev team is not interested in engaging with developers or seeing past themselves and their own idea of how things should go. Clearly, React will not last forever, but in full honesty, React has overall been a pretty great experience over the years I've worked with it.