> Dear React.js, > We've been together for almost 10 years. We've come a long way. But things are getting out of hand. We need to talk. > It's embarrassing, I know. Nobody wants to have that conversation. So instead, I'll say it in songs. Am I the only that finds this open letter format extremely cringey? I almost didn't want to read the article after that intro. The content was excellent otherwise.
React I love you, but you're bringing me down
271–280 of 574 posts
Re: React I love you, but you're bringing me down
#272Earlier quoted context omitted.
I ditched React soon after they released hooks, mainly because I couldn't relate to the tradeoff React roadmap was taking from there. They went in a different direction from that point onwards, it seem like whatever code you write will become obsolete with the new set of best practices in the next release cycle. More importantly, I realized React is trying to tame Facebook level of problems and hence their design dec…
I haven't got the ideas why many frontend jobs require experience in React whether it's for a new or existing projects, maybe I need enlightenment.
Re: React I love you, but you're bringing me down
#273As a developer who’s been working with React since the beta, I can confidently say that the author is speaking the truth. Especially so near the end of the article where they can’t seem to quit React. For all the annoyances of Hooks, they really are a godsend when it comes to composing state. And refs do indeed suck, but they sucked even more with class based components. I can’t tell you how many times I was able to…
I just use vanilla JS on the front-end just like I do with Node. I have never understood why people find state management challenging. I suppose its because they are stuck in a framework or MVC mindset where everything is a separate component and each must have separate state models that must be referenced frequently and independently. I just put all my state data in one object, save it on each user interaction, and…
The more you deviate from one of the set of common conventions, often enforced by frameworks, the more you have to build on your own.
The larger your project gets, and the more developers who need to understand your code, and the more developers you need to hire and get onboarded quickly, the more that those extra rules start to make sense.
And once you've learned and internalized the patterns necessary to build larger systems, it becomes force of habit to just use it wherever, even if it's nominally easier without them. For most developers, a go-to pattern will be faster than working from first principles on every project.
Re: React I love you, but you're bringing me down
#274Earlier quoted context omitted.
Isn't it also easier to get subtle lifecycle bugs with them, because you can forget one.
I don't know that I agree with that. I recently had to fix a few bugs because some devs forgot, or simply didn't know, that lifecycles still exist. We have reached a period of time where junior devs exist that did not cut their teeth on class components and have no idea of what the lifecycles are. They don't know how rendering works so they either throw up useless memoization everywhere or they don't bother to think…
And then it just stays fixed. You don't have to split up the logic across different lifecycle methods and remember to keep them in sync. They're consolidated into functions that can be trivially pulled out into their own hooks and reused.
React is definitely a more low-level framework that requires you to have some familiarity with how the scheduler works, and could benefit from a couple more built-in hooks. But the benefits are undeniable, they make writing and refactoring complex applications an absolute breeze. The fact that you can factor out some state-related behavior into a hook and trivially reuse it is incredible.
For example, take state. With hooks, you use useState. A very common pattern is to need to persist it in the URL to enable deep linking. You can literally just replace your useState call with useQueryParam from the use-query-params library [1] and have your component function identically. You just can't do that with class-based components.
Re: React I love you, but you're bringing me down
#275As a developer who’s been working with React since the beta, I can confidently say that the author is speaking the truth. Especially so near the end of the article where they can’t seem to quit React. For all the annoyances of Hooks, they really are a godsend when it comes to composing state. And refs do indeed suck, but they sucked even more with class based components. I can’t tell you how many times I was able to…
We have had success in migrating away from React, and in fact away from client-side code altogether by building more and more of the UI of our Elixir/Phoenix backed application in Phoenix LiveView. There are still some parts of system that really need to be client-side code powered (a WYSIWYG HTML editor, for example) but now our default choice for new UI is LiveView.
Re: React I love you, but you're bringing me down
#276Earlier quoted context omitted.
Nope, I'm with you. React inventing a half-baked, partial re-implementation of objects/classes (in a language that already has them!) with super-weird declaration syntax & runtime behavior, just to avoid telling their userbase "Ok you will have to use classes sometimes, for certain functionality", was when I started looking around, because they were clearly out of real problems to solve that were sufficiently good-lo…
It is purely because `this.state` is hard for V8 to optimize, nothing more and nothing less. They did it for their own purposes, for better performance on low-end machines. You can almost certainly just use classes for 99% of use cases
Per https://reactjs.org/docs/hooks-intro.html , the primary motivations were:
- "It’s hard to reuse stateful logic between components "
- "Complex components become hard to understand"
- "Classes confuse both people and machines" (remembering how `this` works, code minification, method binding, etc)
There's also an excellent "Why React Hooks?" post at https://ui.dev/why-react-hooks that gives background details.
Additionally, the React team has talked about how hooks and function components allow them to have "forks" of the component tree in various states of partial completion at a time, for use with Suspense and transition features. This works because closures capture data in a scope, whereas mutable class instances could have gotten changed and refer to a single `this` instance.
Re: React I love you, but you're bringing me down
#277Earlier quoted context omitted.
I ditched React soon after they released hooks, mainly because I couldn't relate to the tradeoff React roadmap was taking from there. They went in a different direction from that point onwards, it seem like whatever code you write will become obsolete with the new set of best practices in the next release cycle. More importantly, I realized React is trying to tame Facebook level of problems and hence their design dec…
Step 1: The existing tooling is too clunky, big and a major PITA to work with, Developers spend most of their time fighting their framework and tooling to do simple things. Step 2: Someone gets fed up with this writes a framework that "does things right" and is designed for "simplicity" Step 3: People start loving the new tool because it is so much easier to work with. Step 4: People start to do things the tool wasn'…
I have been doing Rails development for past 10 years now and I never faced a dilemma where the framework took a direction which isn't aligned with its core vision.
I have been just trying to find a similar tool for frontend where I don't have to keep rewriting the entire codebase.
Re: React I love you, but you're bringing me down
#278Earlier quoted context omitted.
I'm trying to select a good framework and coming from long before react, having a tough time finding why shouldn't use just custom elements with no framework. Which is already built in. customElements.define('my-element', class MyElement extends HTMLElement { ... }) I can manage state within the component, app state in window.state. Coding up a simple reactivity is really pretty straight forward. Now, for this featur…
Mithril or Svelte should be all you need. If you're coming from React, I'd recommend trying Mithril first. I've been using it heavily for 5 years now and I'll likely stick with it for at least another 15. Mithril is reactive out of the box, and just works. It smokes React in every category, but still has an optional JSX integration if that's what you're comfortable with. https://mithril.js.org/ https://svelte.dev/
Re: React I love you, but you're bringing me down
#279Waiting for React Recoil to become the standard, it's amazing!
I have never used Recoil. How does it compare to Zustand?