DEV Community

Cover image for The Problem With React

The Problem With React

Stephen Belovarich on March 17, 2023

In this post I'll tell the other side of the story. The parts the React Documentary failed to mention. The recent React documentary was not a good...
Collapse
 
devdufutur profile image
Rudy Nappée • Edited

Indeed we heard so weird things from react core team last months about React frameworks.

But 90% of new React documentation, even if CRA isn't recommended anymore, focus on front-end development. Vite and parcel now allow you to bootstrap front-end React app (with battery included : HMR, TS, ...) without bringing webpack, Babel and their friends and it's a good thing. If you take distance, doing React app has never been easier. 😉

Collapse
 
steveblue profile image
Stephen Belovarich • Edited

React leadership has a history of saying things, then walking them back. Famously, they claimed Virtual DOM is faster than DOM. In reality, Virtual DOM is overhead and they had to remove any mention of that.

Yes, although this is also true for other libraries and frameworks. Vite, parcel, and esbuild work with them out of box and when they don't, the community makes it happen. I use a Vite server for developing a server-side rendered app with custom elements, for example. esbuild support is coming to Angular CLI soon, etc.

Collapse
 
lexlohr profile image
Alex Lohr

I hear you. But I really think the react devs are victims of their own misconception. They still believe that immutable state is the way to go on all fronts, and memoization will keep things performant at scale, even when the world a around them now turns to signals to achieve better results with less compromises.

The reality of complex apps showed again and again that this doesn't scale, even if you write idiomatic react code, which soon becomes unmaintainable for all the numerous dependency arrays.

Collapse
 
steveblue profile image
Stephen Belovarich

Yeah, I see where you’re coming from, although I don’t blame the devs. In my opinion the fault lies on the React team, influencers and YouTubers that cater to the echo chamber. An entire generation of web developers started with React because code academies taught React. React is all they know, and they’ve been misled by sheer marketing that masquerades as best practices. The same could be said for other JS frameworks and libraries though.

Collapse
 
alaindet profile image
Alain D'Ettorre

I've always enjoyed using React as much as despised working with its toolchain. I think the churn is the #1 reason for both ugly DX on enterprise React and unpredictability of what to expect as a developer joining a React project. I hoped CRA and maybe Recoil (RIP) could have unified the ecosystem, instead they both got abandonded explicitly (CRA) or implicitly (Recoil). I don't know, Angular and Vue both are frameworks and give you a minimum viable set of libraries you need, while React doesn't and it should.

Collapse
 
dannyengelman profile image
Danny Engelman

Why? COBOL developers now make more than React Developers. React has the same future as COBOL.

Collapse
 
steveblue profile image
Stephen Belovarich

That’s pretty funny.

Collapse
 
steveblue profile image
Stephen Belovarich • Edited

I may sound like a grumpy old man but engaging in ad hominem attacks to prove a point isn’t a good look. Nobody attacked your choice in library or you. Is all criticism with React met with this? We can’t even have a healthy discussion when people limit and dismiss others opinions out the gate.

Collapse
 
iq9 profile image
Russ Brooks

Ever hear this excellent Nerd Rage rant at the top of my article? dev.to/iq9/how-to-escape-js-framew...

Couldn't agree more.

The costly part with React is that it's a very proprietary implementation. I've been coding for 35 years, and I had to take a 80-hour paid ($200) Udemy course before I could be productive on React. And even then, I wasn't sure which feature I was supposed to use to solve Problem X vs Y. It's unoppinionated, so there was a dozen different styles of doing things in those repos. Then another $200 course later and 120 hours, I was maybe 75% the spreed I normally am ES6 other. It can't be learned thru the usual method that 90% of devs use: experimentation! Experimentation only works if the technology has a conventional implementation. Or if it has a unique implementation, one so small, it can be learned in days anyway.

The following technologies at that same co, took me merely 3 days to be productive on, having never touched them before:

  • Svelte - conventional implementation (good-ol' events calling functions).
  • CoffeeScript - conventional implementation (events calling functions).

Another costly mistake I witnessed at my last 2 cos, spanning 5 years:

  • Eng dept incurs $120k in costs and 1 year's time, refactoring the entire repo to use Functional, but don't leave OOP ones in place, not realizing their supposed to be used in tandem.

Quote from React docs:

OOP components are for when you need State. Functional are for when you don't.

Each has its appropriate use case. If they didn't, Class ones would have been purged from React, and its docs.

Then everyone realizes the mistake 6 mos later when devs are passing State around in creative ways. Then they throw Redux at the problem.

It's was entertaining watching these exact same thing transpire at 2 completely different cos.

Collapse
 
mykezero profile image
Mykezero

I can relate to a lot of this. Had to learn how to bootstrap the React front end from scratch. Learned how to integrate it into antiquated C# ASP NET 5.0 code, which doesn't have direct support for it (oh the horror, copy to scripts folder, MSBuild / csproj magic and CDN fallback logic). Conflicts between CSS selectors and existing Bootstrap 4.0 classes and new Bootstrap 5.0 classes when rendered on existing pages on the website. Website includes more than a dash of JQuery on the webpages. It takes quite the effort to keep all that working and in sync.

I won't be able to upgrade the ASP NET 5.0 code to something newer for at least 2 years and it's going to be an absolute nightmare to re-code all those old pages and consolidate the separated React apps / JS into a cohesive unit. Code that delivers value stays around, even if it's not latest and great thing.

Collapse
 
matpk profile image
Matheus Adorni Dardenne

This line "OK, how would I do that without React?" is funny, because I distinctively remember saying that exact line about jQuery several years ago. I was activelly searching Google for how to target elements, add and remove listeners, and especially handling http requests, without relying on jQuery. Not long after, I came across React and Vue, and am working with them ever since.

I'm not yet feeling the same pull to abandon ship, though. jQuery already felt dead at that point, it was easy to write but terrible to maintain, and this made it unpleasant to work with it. With React I'm still having a lot of fun building applications that would take me years with jQuery. I'll stick around for a couple more years.

Collapse
 
matpk profile image
Matheus Adorni Dardenne

I'm working with React for some 3 years now and I never felt so productive, but I can relate to some of OP's struggles.