Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

marmelab.com

Post reply on HN
Print view View original

141–150 of 574 posts

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

#141

Post by engineeringwoke »

yamtaddle wrote: post #86
nonethewiser wrote: post #46

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.

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

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

#142

Post by neals »

nonethewiser wrote: post #46

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 think many of us are still using class components and loving it. We're just not that vocal because we're busy get stuff done.

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

#143

Post by mikeryan »

kayson wrote: post #78
nonethewiser wrote: post #46

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

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

#144

Post by alexfrydl »

nonethewiser wrote: post #46

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.

It really rather seems like they achieved a near-perfect library for creating complex web applications, then in order to justify continued work on the project, simply kept making up unnecessary clever/cool features motivated by vibes that classes are passé.

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

#145

Post by phailhaus »

3vidence wrote: post #132
bornfreddy wrote: post #100

Earlier quoted context omitted.

Fair enough. Though, the first question is - why does the component do so many things? Do they all need to be in a single component or can you break them apart? For the cases when this is not possible, I agree, useEffect works better than classes lifecycle methods. But do you really want a system which caters to a small percent of use-cases at the expense of readability in others? And the improvement, to my eyes, is…

An issue I have with hooks are the names. "useEffect" is one of my least favorite function name in any library. What am I using? What is the effect?

Yeah, it's not great, but that's because it's extremely general purpose. Its name refers to function side-effects. Since you're writing your components functionally, you need to explicitly declare any effects of your function to be run appropriately. Hence: `useEffect`. The names are super generalized because hooks don't necessarily need to render anything; they're just hooks into the React scheduler, so they can even be used to manage connection state if you want.

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

#147

Post by buscoquadnary »

BilalBudhani wrote: post #97
nonethewiser wrote: post #46

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 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't designed to do. They start making "minor feature enhancements" to the tool so that it can fit more use cases.

Alternative Step 4: Tool becomes "industry standard" so everyone starts using it because it is "the right way", regardless of whether or not it is a good fit.

Step 5: The new tool becomes massive and bloated and overwhelmed with too many features, configurations, and options.

Step 6: Return to step 1.

> The Wheel of Time turns, and Ages come and pass, leaving memories that become legend. Legend fades to myth, and even myth is long forgotten when the Age that gave it birth comes again. In one Age, called the Web 2.0 Age by some, an Age yet to come, an Age long past, a wind rose above the great mountainous island of FANNG. The wind was not the beginning. There are neither beginnings nor endings to the Wheel of Time. But it was a beginning.”

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

#148

Post by ajkjk »

yamtaddle wrote: post #86
nonethewiser wrote: post #46

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.

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.

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

#149

Post by molszanski »

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 `` 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.

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

#150

Post by debaserab2 »

y-c-o-m-b wrote: post #109
irrational wrote: post #71

Earlier quoted context omitted.

Well, I work for a fortune 100 company and we use Vue. After using React, I strongly prefer Vue, so I would say it is the greener JS pasture ;-)

Agreed. Vue is the best of all worlds in my opinion. Here's my take on the whole thing from a Svelte post a couple of weeks back: https://news.ycombinator.com/item?id=32763509#32767905 > I still think Vue (especially Vue 2) is the greatest of them all. I've worked professionally with Angular, React, and Vue. Each for several years. Vue is easily the winner for me with the syntax that closely matches native HTML and J…

v-if and v-else are not native html attributes either. Control flow via HTML tags has always felt like a code smell and been a major turn off to me.
Post reply on HN