Live data from Hacker News

React I love you, but you're bringing me down

marmelab.com

161–170 of 574 posts

Re: React I love you, but you're bringing me down

#161

I must be the only person in the world who likes class components in React. Sure, it's often overkill and a functional component does the same thing with less code. Use a functional component in these cases. But if you're doing something more complicated then stop treating class components like the fucking devil. They have their place.

I overall agree. I use functional style programming a lot but for some reason hooks have always confused me. The component classes generally make sense to me and map onto other paradigms like flutter, vue, etc. Sure methods like componentDidMount are a mouthful but I found it much more explicit

In my view, hooks are more about managing state dependencies, rather than functional programming, per se. So they're more useful for simplifying methods like componentDidUpdate, rather than componentDidMount. When you need to detect changes by comparing prevProps to this.props or prevState to this.state, the logic can quickly get really ugly. Instead you can just put the relevant prop or state you want to monitor in the dependency list of a hook, and it will be triggered whenever that dependency list changes.

Re: React I love you, but you're bringing me down

#162
post #148

Earlier 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…

Heh. Arguably JS itself "invented a half-baked, partial re-implementation of objects/classes"... _in their class implementation_. God it drives me nuts that the language will allow you to spread a class into an object and it will take the properties but not the methods.

Oh, absolutely. Pretty much every distinctive feature of prototypal OO is best classed as "please, never ever actually use this". Adding the "class" sugar and general agreement to pretend the prototypal stuff isn't there, though, made JS OO usable-enough. But yeah, it's not great.

Re: React I love you, but you're bringing me down

#163

Earlier 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'…

This tired argument has been trotted out repeatedly, and isn't really funny anymore. It's just old and boring.

For people like me who are new to JS and use these sorts of discussion to determine which technologies I should adopt first, it's really just pointless noise in the channel.

The little I know about JS so far, I definitely know this joke is tired and played out.

Step 2: Get a better joke please?

Re: React I love you, but you're bringing me down

#164

I must be the only person in the world who likes class components in React. Sure, it's often overkill and a functional component does the same thing with less code. Use a functional component in these cases. But if you're doing something more complicated then stop treating class components like the fucking devil. They have their place.

I totally agree with you and you are not alone for certain.

Re: React I love you, but you're bringing me down

#165

It may be due to the codebase I'm working on, but I doubt it since I assume I have decent colleagues (I'm in a FAANG), but I just fucking hate React. I spent years working on Angular before changing team, and there everything makes sense instantly. It's just normal programming, normal MVC, normal everything, and you basically only need to learn about the syntaxic sugar for data-binding and stuff like this. In React i…

Funny because every time I need to work on anything angular I'm constantly thinking how over-engineered everything is and how much simpler it is in react.

Re: React I love you, but you're bringing me down

#166
Concurrent react actually makes your app less concurrent: https://github.com/facebook/react/issues/21668

5yrs in progress, it’s still not documented let alone fixed. I tried to look at the code, and they make giant PRs and are experimenting with priority queues and bitmasks, which seemed pretty off in the weeds to me.

Re: React I love you, but you're bringing me down

#167

Earlier quoted context omitted.

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'…

This tired argument has been trotted out repeatedly, and isn't really funny anymore. It's just old and boring. For people like me who are new to JS and use these sorts of discussion to determine which technologies I should adopt first, it's really just pointless noise in the channel. The little I know about JS so far, I definitely know this joke is tired and played out. Step 2: Get a better joke please?

It's not a joke. It's reality. It gets mentioned repeatedly because of how true it is.

Re: React I love you, but you're bringing me down

#168

Earlier quoted context omitted.

Context is useful for certain cases, but plain old useState/useReducers are the workhorses. I think the beta docs are pretty good about explaining the tradeoffs ( https://beta.reactjs.org/learn/passing-data-deeply-with-cont... ). To me one of the biggest issue is that almost everyone is deeply afraid of prop drilling. Passing props around and having some local state works very well for large parts of many application…

> To me one of the biggest issue is that almost everyone is deeply afraid of prop drilling. Prop Drilling is considered an anti-pattern for good reason. It very quickly turns your project into an absolute mess, making it impossible to determine where props are coming from and where data is actually set. Keeping that clean is one of the most important things you can do in a frontend codebase imo.

That doesn't make sense, props are easily to follow and they only flow in one direction from parent to children. Excessively deep component structures are a problem, but not only because of the excessive prop drilling they cause.

Re: React I love you, but you're bringing me down

#169

Earlier quoted context omitted.

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'…

This tired argument has been trotted out repeatedly, and isn't really funny anymore. It's just old and boring. For people like me who are new to JS and use these sorts of discussion to determine which technologies I should adopt first, it's really just pointless noise in the channel. The little I know about JS so far, I definitely know this joke is tired and played out. Step 2: Get a better joke please?

It's not a joke, it's intended to convey the wisdom of not thinking "the next big thing" will solve all your problems, it is intended to focus on the importance of fundamentals, and of relying on using engineering skill to solve problems rather than fancy gadgets, it is to point out the value of developing technical acumen rather than becoming a tool bound technician.

If you define yourself by the technology you work with you aren't an engineer you're a technician.

Re: React I love you, but you're bringing me down

#170
post #78

Earlier quoted context omitted.

I'm definitely a novice when it comes to React, but I've shipped a beta version of an internal took using it. I never understood the emphasis on functional components. Everything I did using them was made more complicated and less obvious, especially for colleagues who are not familiar with React or JS in general. React is built on components which are objects (both in a programming and GUI sense). Using OOP to descr…

Functional components tend to be easier to compose. If your class component has very specific functionality that you won't need in other components it's fine but if you want functionality that will be shared across multiple components wrapping up that code into it's own hook is easier to share across components then trying to use wrappers, extending classes and HOCs.

Can you give me an example? I didn't have that experience. I extended classes for everything and it was super easy. But as I said, I was probably using react in a fairly basic way.
Post reply on HN