Hmm… let me be frank about my experiences with React. I’ve been using React heavily for far over 6 or 7 years.
React is amazing. And what I see is that people find so many ways to shoot themselves in the foot. At the same time, I understand that batteries-not-included approach will lead to that result.
First of all, people get out of their skin and try to make it a complicated and entangled mess. In programming, there was always a semi golden rule, to not architecturally fuse your business logic to any particular framework. We logically isolate our app from whatever framework we are using at the moment.
I’ve given the same demo day (task) exercise to ~50+ react devs. Basically two inputs and a button to draw a pattern on an HTML canvas. You wouldn’t believe how many of them (roughly 47) completely and unnecessary implemented most of the business logic inside react components. The sad part is this app doesn’t need react at all. Or could implement 99% of the BL in pure JS and just call one function from React.
React gives an option to store business logic state in `useState` and manage it via `useEffect` and we gladly use that to our demise. Litter our code with singletone instances of a business logic because we’ve “forgot” how to do a DI without a framework. People write `<IF>` components for christ…
Second there is this immutable transducer reselect memoized concurrent proxy suspense state promotion society. Performance zealots obsessing over trillion renders per second. Which they don’t deliver, by the way, beyond todo examples. They describe how their Rube Goldberg flux redux machine works. A machine to read and write data into a JSON object.
In a nutshell, the we should critique ourselves, not the framework. IMO the framework is doing it’s job just fine. Unless we learn what really goes wrong with react projects we are doomed to repeat the same mistake again and again with next (pun intended) framework.
Where are good examples of clean, well-implemented React code by your definition? Because your comment perfectly encapsulates my experiences and frustrations in learning and using React off-and-on over the past 8 years or so.
React is the one tech that really freaks me out because every time I have to dive into it, it's a completely different beast and it feels like so many people actually writing in React are just effing CRAZY
Years ago I wrote a 12-line-or-so JS "framework" that did one-way databinding, it accepted a fragment of HTML with template strings and replaced those with the data you wanted... it could handle thousands of updates without falling over (though updating the whole table would freeze the browser for a half second) and last I checked was still in production doing fine. But now nobody understands it and I'm fielding weird questions about why X framework wasn't being used in 2015 when I wrote it. And it feels like 90% of what I do in React is the same thing! (Simplifying, sure, but my point is that React feels bloated as hell and reinvents the wheel way too much)
> your comment perfectly encapsulates my experiences
> feels like so many people actually writing in React are just effing CRAZY
Same here. We had an experienced-but-batshit-crazy dev create a React site with approximately 250,000 LOC to support 3 forms with a max of 4 simple inputs and a 3-column data table view. To this day it makes my head spin how it is even theoretically possible to write that much code for so little functionality - much less _actually do it_. And don't even get me started on how unmaintainable it is - IIRC I tried to update the string content of an error message once and it required changing something like 57 lines in 10 files (or maybe it was 1 line in 57 different files? something like that...).
They essentially created a unique type for every. single. variable. I'm talking like, if you needed string constant for an error message on Input 1 on Form 3, there was an ErrorLoadingMessageForInput1OnForm3 type declared for that instead of defining it as a string. The types were never reused - like if you had the same error message on Form 2, there'd be a separate ErrorLoadingMessageForInput1OnForm2 type for the same string. And then every interaction between any 2 variables had its own type of types. Like if Form 3 was displaying the error message, there'd be a type for Form3DisplayingErrorLoadingMessageForInput1OnForm3. Which of course, is distinct from Form3DisplayingErrorLoadingMessageForInput1OnForm3AndErrorLoadingMessageForInput2OnForm3. And then those types were combined to create even more types, and so on until you had literally tens of thousands of lines of _just_ type declarations for variables and every possible permutation of UI state sitting atop a recursive pyramid of smaller subsets of the permutations (and so on until it eventually got to actual variable declarations). An then all that was piped through the craziest clusterfuck of redux butchery imaginable with a similar dynamic of explosively exponential growth of references and types and states and properties and so on. Like I said, it still hurts my brain thinking about it.
That's not code written by an experienced dev like you said.
They might have worked long enough to think they're experienced, but this is proof they're just terrible if not a complete hack that's in the wrong line of business.
Yeah...unfortunately they managed to fool me (and the rest of the team) in the hiring process. It was a nice day when they were finally forced off but also unfortunately it's been an ongoing, multi-year scourge dealing with the codebase they left behind. It works just well enough that it's not worth scrapping and totally replacing yet (at least as far as management is concerned) but it's virtually impossible to make changes/updates to it and maintain your sanity.
Sweet pumpkins, I feel the pain. Architecture astronaut combined with a spaghetti aficionado. When one talks to people who have been around you hear amazing stories like that. thedailywtf material
The more power we give to developers - by simplifying, abstracting, optimising - the more they want to achieve, the faster they want to do it, the less effort they want to spend.
Which puts them right back in the position of working under complexity.
The reason people are now complaining about React is that React made writing 2015 webapps extremely easy. The result was our appetite and ambition stretched to 2022 webapps and we blame the framework for making things harder, not ourselves.
Fully agree with you. I think the issue is that people think about React imperatively. "When I press this button, it should do X" or "This input should update Y".
And then people start adding unnecessary useState or useEffect to their demise.
It's hard to blame them honestly. When React is one of the first thing you learn, you don't know the other possibilities. Many probably haven't used any framework outside it. And most probably don't know what problems React help solve.
And when they start developing, they solve problems by using what they know: The React tutorial that taught them to use useState and useEffect for every state and logic.
React is amazing. And what I see is that people find so many ways to shoot themselves in the foot. At the same time, I understand that batteries-not-included approach will lead to that result.
First of all, people get out of their skin and try to make it a complicated and entangled mess. In programming, there was always a semi golden rule, to not architecturally fuse your business logic to any particular framework. We logically isolate our app from whatever framework we are using at the moment.
I’ve given the same demo day (task) exercise to ~50+ react devs. Basically two inputs and a button to draw a pattern on an HTML canvas. You wouldn’t believe how many of them (roughly 47) completely and unnecessary implemented most of the business logic inside react components. The sad part is this app doesn’t need react at all. Or could implement 99% of the BL in pure JS and just call one function from React.
React gives an option to store business logic state in `useState` and manage it via `useEffect` and we gladly use that to our demise. Litter our code with singletone instances of a business logic because we’ve “forgot” how to do a DI without a framework. People write `<IF>` components for christ…
Second there is this immutable transducer reselect memoized concurrent proxy suspense state promotion society. Performance zealots obsessing over trillion renders per second. Which they don’t deliver, by the way, beyond todo examples. They describe how their Rube Goldberg flux redux machine works. A machine to read and write data into a JSON object.
In a nutshell, the we should critique ourselves, not the framework. IMO the framework is doing it’s job just fine. Unless we learn what really goes wrong with react projects we are doomed to repeat the same mistake again and again with next (pun intended) framework.