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

221–230 of 574 posts

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

#221

Post by chrisco255 »

azemetre wrote: post #186
dragonwriter wrote: post #90

Earlier quoted context omitted.

> hooks aren’t JS They literally are. > hooks aren’t JS The code in React executing components relies on hooks running in a consistent order each time the component runs, but the existence of a runtime context that has expectations about side effects (and hooks are side effects) doesn't make it “not javascript”.

Hooks are executed in order as they are defined, isn't that a fundamentally broken design in regards to language spec? I don't have an opinion, just generally curious because it feels very odd that the order of my functions matter.

It only matters that the order not change dynamically between renders. This probably could have been avoided if react required a unique key per hook, but I think for brevity it's a decent trade-off.

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

#222

Post by awinter-py »

collyw wrote: post #45

Does anyone do server side rendering these days? I fail to see the point in SPA apps for the majority of web apps. At my work we have an ancient Dojo frontend and a newer react one being build. Its a few list views that the user can filter and a few forms with validation. It's a ridiculous amount of complexity to avoid loading a page. I could do almost everything for half the effort with server side HTML from Django…

yeah django's approach to forms is not the worst

thinking of forms as a model that can be rendered is really valuable IMO. most UXes would be 10x easier to write if we had better standardization around the 'schema to UX' step

'form first UX' would also reduce the work of building cross-platform apps

guessing django is ramping up on its AJAX, but I think a real forms standard would need to understand AJAX -- users aren't going to remember to scroll down to a 'save' button. realtime validation also an AJAX issue, typeahead as well.

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

#223

Post by mmis1000 »

gherkinnn wrote: post #177
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.

They absolutely do not have their place. Just about everything is worse with class components. I’ll take a dozen useEffects over a single class component any day. That said, the hooks model is far from perfect. They give you a lot of rope to hang yourself with and were badly introduced. Within weeks the internet was ablaze with terrible advice. When so many people get it wrong, the library is to blame. And I wish hoo…

I don't think hook themselves are a bad thing. But the way react implements hook probably is. The react team invented their hook format the suite themselves the most, but that probably isn't for other.

Vue 3 also has hook now. But none of these defects in the article exist.

In vue.

To use some value in a effect, you just use it and it is tracked.

If you need to clear up your code. You cut some code into a useXxx function, and your reusable utility is done. You can use it everywhere now. You don't really need to specify dependency of whatever by yourself.

If you must manipulate a dom, you just manipulate it. It will work as long as you revert the change before vue want to update it again.(And vue do provide a hook for you to attach a handler when these happen)

These restrictions are added by the way react implements hook, but not hook themselves. Hooks are just more user friendly services (by allow the hook to attach to component instance without all the glue codes(addListener or whatever))

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

#224

Post by 7speter »

tcoff91 wrote: post #180
jibe wrote: post #157

Earlier quoted context omitted.

In 5 years if no one else is using Hotwire I think that's the opposite of what he is saying. Because React is updated and changes frequently, your code becomes obsolete unless you update to follow the latest changes. In theory, if everyone abandoned Hotwire, your code would never be obsolete or need changes, because Hotwire would never change. In reality, as browsers and web standards change, frameworks need updating…

All the class components people wrote still work and can be maintained. React doesn't overhaul everything like Angular did. You can have function components with hooks and also have your old class components in the same app.

No ones learning class components for react anymore, and I'm not implying that class components are bad or ancient.

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

#225

Post by addicted »

frosted-flakes wrote: post #175
jibe wrote: post #157

Earlier quoted context omitted.

In 5 years if no one else is using Hotwire I think that's the opposite of what he is saying. Because React is updated and changes frequently, your code becomes obsolete unless you update to follow the latest changes. In theory, if everyone abandoned Hotwire, your code would never be obsolete or need changes, because Hotwire would never change. In reality, as browsers and web standards change, frameworks need updating…

React doesn't change frequently though, that's the point. And it has always had excellent backwards compatibility. Class components are still fully supported, for example.

React changing best practices every few years is a good thing! It means it keeps getting better.

That would be a bad thing if it meant that earlier best practices were no longer maintained. But that’s not true. Class components are still around. All official documentation continues to have class component examples and explanations (where it makes sense obviously…there isn’t any class component documentation under hooks, of course). And class components will likely still be around 5 years from now.

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

#226

Post by phailhaus »

esprehn wrote: post #176
phailhaus wrote: post #67

Earlier quoted context omitted.

> How can a replacement for lifecycle methods be called useEffect? Seriously? Yes, seriously. Have you used it for more complex components? You can split your effects across multiple useEffects, and have a guarantee that they run completely independently of each other (especially since you know what their dependencies are). Compare that to lifecycle methods: you only have one per component. All your effects concerned…

That didn't require the meta language and rules of hooks though, they could have added this.addEffect(callback, deps) or something to class components. To preserve back compat they could have added a new base class you inherit from to get access to new APIs. Most of hooks could have been done incrementally on top of classes.

Imagine trying to debug a component that both has lifecycle methods and reactive hooks? That would be a total nightmare, especially when the same state is being updated in both places (because that would have to be allowed). Going all-in on hooks means that there are two distinct, independent ways of writing components, and you never have to deal with interactions between the two.

I also don't think this would be possible. Hooks are based on closures and injected state, which you can't do in a class since separate methods won't share the closure.

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

#227

Post by Rapzid »

engineeringwoke wrote: post #141
yamtaddle wrote: post #86

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…

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

It's just a prop access how is that hard for v8 to optimize? What were they doing to cause that to de-optimize?

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

#229

Post by H1Supreme »

ajkjk wrote: post #148
yamtaddle wrote: post #86

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.

Exactly! If the Javascript implementation was better, React probably never would have had to come up with Hooks in the first place.

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

#230

Post by arcturus17 »

mind-blight wrote: post #28
knoebber wrote: post #19

I spent about 2 years at my last job building a greenfield react app mostly by myself (around 10k sloc). I enjoyed it for the most part. But I did run into all the issues raised here, they are valid. I think the worst issue with React is the dependency arrays that get sprinkled around everywhere - in my opinion the framework is unusable without a 3rd party linting tool that points out when your dependency array is mi…

I think a lot of the problems the author highlighted become more apparent as the number of devs in the codebase goes up. If one member doesn't understand all of the nuances of useEffect or paint useCallback, they can write a component or custom hook that another team uses and gets subtle bugs from. For example, I need to look inside of a hook to see whether the callback it provided was wrapped in useCallback. That me…

I don’t know of any language or framework that guards from mangling a buggy abstraction and then exposing an interface for it.
Post reply on HN