WOW this is a long article! Still waiting for the substance though...
The only point I can agree with is that React is stupidly hard to learn. It feels like a tool made for aliens, though once you master it, it can be pretty efficient.
Sorry to be the bearer of bad news, but the JS-free web isn't coming back. And if you're using modern JS, you might as well use React (or a similar tool). The user won't be able to tell the difference.
Cannot agree more! Mastering React is ridiculously hard for what it is. There are so many “buts,” “it depends,” and subtle differences to navigate, like useEffect vs. useLayoutEffect. But don't forget useEffect is an evil in the first place and so on, and so on.
It feels like a clever proof of concept with a leaky abstraction at its core, one that no amount of effort can truly fix, no matter how much they throw at it. They’re even building their own compiler. A compiler. For something that’s supposed to represent the V in MVC.
As a SPA framework, it’s questionable. But using React to build server-side apps? That’s beyond absurd for me, it’s like Electron for the backend, only worse. And yet, the industry loves to pretend otherwise, so here we are.
React is a guided missile foot gun. You can figure out how to have it hit something else, but even when you aren’t pointing it at your foot, it’s probably going to hit your foot. You can have that feeling of wonder as the rocket sails off into the distance, and then just as you get customers, it comes back over the horizon and hits your foot. Experienced physicists and rocket scientists can override the guidance mechanism and have a much better chance of not hitting a foot, but who has time for that. Most people just like that it has a big red button labeled “Shoot” that’s easy to press.
You shouldn't write a single useEffect in the first year or two of your career in React.
Why people are so keen on stabbing themselves just because there's one or two weird shaped forks in the kitchen drawer. Why do suddenly everyone tries to use it for spreading butter or peeling eggs?
Just understand what unidirectional data flow is and you are golden. You know the entirety of React you should be using for your first year of full-time job.
That’s true. Just to note, I never claimed otherwise. See, useEffect is an evil remark. This is more based on my experience working with an average React codebase.
As for your question, “Why does everyone suddenly try to use it for spreading butter or peeling eggs?”
I guess part of the reason is that many people rely on older tutorials and patterns where the usage of useEffect was much more tolerated or even encouraged as a catch-all solution. There’s still a lot of inertia from the old componentDidThis/componentDidThat paradigm, with useEffect being its direct replacement.
I feel it is only a recent tendency to finally abandon the overuse of effect hooks.
Just open an average Stack Overflow React question, and you’ll see how many useEffects are crammed in there.
That’s probably the main real-world use case for useEffect. Dedicated third-party libraries like React Query obviously use useEffect under the hood as well
> Sorry to be the bearer of bad news, but the JS-free web isn't coming back.
It has never went anywhere? All it takes is a user brave enough to disable it or to use a web browser that doesn't use it or has issues with it. But for some reason many web devs actively ignore that.
It was so easy that people strived very, very hard to make it seem complicated - and they succeeded. Back in the day every React tutorial layered in soooooo much other stuff, Redux and a million middleware layers that completely obscured what React was.
The core of React though is really simple and no amount of attempts at complexification can destroy that.
Hello world might be simple, but you don’t have to build very much before you start to run into problems with the simple “props down, events up” and you start needing to learn about contexts, hooks in general and so on.
Hooks is really one of those things where you need an IDE to tell you that you’re doing it wrong, since there’s a whole bunch of footguns. It’s doing its best to solve a hard problem inside the limitations of JavaScript, but it is essentially a kludge.
As someone who developed in Adobe Flex back in the day I find React so straightforward that as long as you keep an iota of discipline then even events, contexts and hooks feel "easy" compared to every other attempt at large Rich Internet Application approaches I've seen.
Just like in Flex the difficulty (and don't get en wrong often extreme awful difficulty) comes when someone fights against the system and can cause a cascade of terribleness. There were always telltale red flags when looking at Flex code when someone tried to circumvent the component lifecycle and the same smell can be spotted in React code.
Not GP. Started using React at work around 2017. The hooks API is just awful. Those complaints are extremely well-trodden ground at this point so I won't rehash. I'm using Lit.js for personal stuff instead these days. Shadow DOM isn't perfect but web components with Lit has been pretty low-surprise so far, which I can't say for Hooks React.
Hard disagree. Hooks are 100% what is best about React these days and custom hooks make organizing or encapsulating and sharing behaviors between components a total breeze.
This is something that I just don’t get, in the olden days, when you wanted to encapsulate logic and state and share it between instances you would just use a singleton service. But now when classes are “bad” for some reason (when the whole point of a class is encapsulation of state and logic) you get weird stateful functions that makes everything hard to track with complicated API.
This is one of the reasons I think hooks stink. It seems like they tried so hard to avoid using classes that they came up with an opaque, framework-only way to manage state so that they could declare "ha! Stateless functions at last!". The state's still there, it's always gonna be there, it's just now hidden behind an abstraction that has a few footguns.
How do you write a singleton service that can feed state back into the component that calls it when that state changes?
For example, `api.fetchInfo()` would want to feed Loading | Success(T) | Error(E) back into the React component call-site when they change.
EventEmitters come to mind but aren't without their own issues like subscription leaks. And you have to track component arguments in order to know when to call the service again when they change which is a classic source of complexity.
Hooks provide a solution for this since they themselves are just nested React lifecycle constructs (like useState + useEffect).
In class components you just could await the result and perform a set state, and that would be it. Easy as pie.
But now in function components when everything is called all the time without your control you have to use escape hatches like use effect just to work around react.
Hooks let you wrap all sorts of logic (and other hooks) and return values that rerender the callsite component when changed. Just keep adding on to my hook example and you get more and more code that you need to repeat in every class component that uses it.
Of course, the class component solution to this was to use an HOC, but that had its own issues like complex data flow and wrapper hell.
Hooks solve problems of composition without Yet Another Wrapper and they give clearer data flow, better ref forwarding, etc.
It's easy to see complicated useEffect spam and blame hooks but frankly that wasn't any better when it was happening at different layers of HOCs.
You can just use a service instead, expose public methods and hide private while keep expending and refactoring the internal logic. The same way it’s been done for decades. The only problem is the one that react created for itself in function components which is when to refresh the render from the state.
1. Nobody said that classes are bad. Yes you can encapsulate logic and state in a singleton, that's not the issue, the issue is how you then "apply" it. There was a fantastic diagram that (most likely) Dan Abramov posted on Twitter a while ago (before it became the olympic pool of diarrhea that it is today) that was demonstrating the superiority of hooks in a beautiful and obvious way but I cannot find it anymore... :/
2. Sorry but if you keep using "weird", "hard" and "complicated" adjectives to define something that is quite honestly not so hard to grasp you make it hard to not go with "skill issues".
Nobody is saying that officially, but for the past 7-8 years the react documentation pretty much ignore class components. Today you have no way of knowing how to create a large class based react application because the ecosystem has moved on, it’s not the best practice.
I’m using weird and hard in a relative and not absolute way. Weird because functions can’t have state, and for years we’ve been taught to keep functions small and predictable.
Hard because there are much simpler ways to write stateful code other than hooks.
The problem with react is that instead of creating a powerful state library, powerful ui library, and creating a bridge between them, they chose to subjugate the state library to the UI library’s limitations.
Not parent, but I'll answer anyway: React was much much easier to learn back when Class Components were the thing. Nowadays there is layers upon layers of magic like Functional Components with State from Hooks.
> Nowadays there is layers upon layers of magic like Functional Components with State from Hooks.
1. you can still write class based components if you want, but if you are in a team everyone will hate you for that because...
2. the preferred and vastly more flexible and powerful way is functional components. That's it, there isn't any other way or any other mystical layer of magic.
What everybody in this umpteenth omfg-react-is-satan thread is that implementing complex things with simple things is a fucking pipe dream. Fucking deal with it.
I didn't talk about any pipe dream, I named a very specific way of how those things were done before - in React! - and how it used to be simple and now it's not.
"Fucking deal with it?" What are you, a cultist? I answered a question here, fuck off.
As someone who's been doing React since the beginning, I would agree that it's hard starting out.
However, I think any new paradigm is difficult starting out. Recently I've been learning OO for work and I've been finding it stupidly hard and entirely unintuitive.
I’ve found Vue easier to learn because it bundles things and lets you learn visual components before fully exploring the reactive model. So while the modularity of React is preferable to a seasoned developer, it does no good to a newcomer.
I have no doubt React is easy if you've been there from the beginning. But if you learned it last year like me, you got to find out the hard way that things are done slightly differently in each version, introducing breaking changes which invalidate the vast majority of the documentation you can find (which you need because the official docs is absolute crap for beginners, as it assumes you already know React's paradigms).
what do you mean by learning OO here? javascript is OO too, so you have already been doing OO, as far as i understand it and what you are learning is something different. and now i am curious what that is.
Between modern frameworks and that MS born monstrosity Typescript, I thought this was the JS-free web. I would love to see the back of it.
Web Dev seems to be ignoring the last 10-15 years of new native browser technologies and getting really stagnant with proprietary bloat as a result.
It's a really good time to start from scratch and see what we can do with WebGL/WebGPU/Shaders, WASM(C, C++, Rust Etc) and Web Audio, as well as the new features of Vanilla JS
The only point I can agree with is that React is stupidly hard to learn. It feels like a tool made for aliens, though once you master it, it can be pretty efficient.
Sorry to be the bearer of bad news, but the JS-free web isn't coming back. And if you're using modern JS, you might as well use React (or a similar tool). The user won't be able to tell the difference.