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

Kind of annoyed at React

blog.cassidoo.co

Post reply on HN
Print view View original

101–110 of 135 posts

Re: Kind of annoyed at React

#101

Post by danpalmer »

drewcoo wrote: post #88
danpalmer wrote: post #26

Earlier quoted context omitted.

I don't think new paradigms are a bad thing, I think the problem with hooks is that they are a "clever trick" to work around the fact that the language/runtime does not have the necessary features to support the developer experience that they would ideally have. What's sad is that the class-based component system did have those necessary features, it also had a nice distinction between components and their lifecycle…

> they are a "clever trick" to work around the fact that the language/runtime does not have the necessary features to support the developer experience that they would ideally have I'd call that a pretty good definition of a "design pattern." In this case, it's also magic framework code.

Hooks are a design pattern, but I disagree that hacks around languages are a definition of a design pattern. What makes you feel they are?

Re: Kind of annoyed at React

#103

Post by WirelessGigabit »

danielvaughn wrote: post #75
coolThingsFirst wrote: post #36

Earlier quoted context omitted.

Whats the beat resource for the mental model?

There was an article I read, maybe 3-ish years ago, that explained it very well. It had you actually build a hook from scratch (not a custom hook, like actually implementing hook-like behavior into JavaScript). It was great. I just tried looking it up but couldn't find it, if anyone knows what I'm talking about please link here.

Following in care you remember / find it.

Re: Kind of annoyed at React

#104

Post by jridgewell »

danielvaughn wrote: post #75
coolThingsFirst wrote: post #36

Earlier quoted context omitted.

Whats the beat resource for the mental model?

There was an article I read, maybe 3-ish years ago, that explained it very well. It had you actually build a hook from scratch (not a custom hook, like actually implementing hook-like behavior into JavaScript). It was great. I just tried looking it up but couldn't find it, if anyone knows what I'm talking about please link here.

Any chance it was https://pomb.us/build-your-own-react/? You can't really have hooks without building an entire framework, because the framework has to have the preserve the execution context between renderings.

Re: Kind of annoyed at React

#105

Post by charlotte-fyi »

andix wrote: post #33
notpachet wrote: post #19

Earlier quoted context omitted.

> one the best things ever invented Fire? The wheel? Penicillin? Maybe it's just because I'm getting older, but I'm increasingly annoyed when people use these sorts of over-the-top hyperboles.

One of the best things ever invented in component based frontend frameworks. It makes purely functional frameworks like modern react much easier to deal with. Off course it's a violation of some theoretical principals. So what? What I don't get: people complain about not being able to handle all the useEffects, but they probably shouldn't be there in the first place. In my experience most ambiguous use effects can be…

> It makes purely functional frameworks like modern react much easier to deal with.

But hooks aren't pure functions. They aren't referentially transparent and have an implicit dependency on call order. Likewise, React components aren't "functional" the second you use any of these APIs which subscribe to effects, state, context, whatever coming from elsewhere. React is simply not a "pure functional" enterprise and it's strange to represent it as simply a "violation of some theoretical principles." Those principles are the entire basis of what constitutes functional programming, which is why the original parent described this as not-functional not-oo.

Re: Kind of annoyed at React

#106

Post by piva00 »

franciscop wrote: post #43
brigadier132 wrote: post #9

React is fundamentally bad technology. I know there are historical reasons for the virtual dom but the reasons that justified it don't exist anymore. If you want to do anything interesting with react that involves interacting directly with browser APIs you need to deal with these absurd use effect hoops to initiate state with references to dom nodes. I've worked on 4 large react code bases and they always devolve int…

I've worked in many react codebases, some great some not, and the main predictor of the quality tends to be both the dev lead knowledge, the experience of the team and the learning vs churn out features culture. Same thing used to happen with jQuery BTW, only it was a lot easier to shoot yourself on the foot back then. I feel like "X new library/framework's code is a mess" is the new "People don't want to work anymor…

Coming from the assumption that Facebook should have tons of experienced people using React, their implementation on Facebook.com just plainly sucks after 7+ years. The UI is slow, breaks back button navigation often, loads completely different views in case a tab goes into background and gets reloaded (I have multiple tabs open from FB Groups that interested me, many of them default to opening my Home feed or the Groups main page after a background reload).

If Facebook.com cannot get it right, who actually can?

"No True Scotsman" is also a trope going on for > 100 years, yet you are appealing to it.

Re: Kind of annoyed at React

#107

Post by qPkk4Bi »

scotty79 wrote: post #81
brigadier132 wrote: post #37

Earlier quoted context omitted.

The problem is you literally need to use effects to make api requests or access browser apis. You can't get away from it. Maybe you can try and tame the complexity by centralizing this logic as a small team but if the team gets big enough it's fruitless.

> The problem is you literally need to use effects to make api requests No. Wtf? Don't do that. Never do that. Effects are for legacy DOM manipulation (and ad-hoc use of browser apis). Pretty much nothing else. Who tampers with states and data in useEffect is hellbent on creating spaghetti.

I assume your suggestion here is just to embrace a framework for data fetching and try not to think too hard about how they in turn implement it?

Can't really fault developers for falling into this useEffect trap when even the official docs show that data fetching is indeed handled via useEffect[1], while at the same trying to yell at the reader to "NOT TRY THIS AT HOME" and just go use a framework because it's such a complex problem... which naturally just creates more questions than answers for the poor developer trying to understand how it all works.

[1] https://react.dev/learn/you-might-not-need-an-effect#fetchin...

Re: Kind of annoyed at React

#108

Post by ok_dad »

scotty79 wrote: post #85
ok_dad wrote: post #21

Earlier quoted context omitted.

Hooks are a new paradigm? That’s news to me, hooking is at least as old as two decades when I first started programming. Hooks are, like most programming ideas, hard to understand at first but easier as time passes and you see more of them.

It's fairly new to react and has a very specific meaning there. I don't think they are similar to any generic concept of hook.

oh ok, thanks

Re: Kind of annoyed at React

#109

Post by scotty79 »

rmccue wrote: post #95
scotty79 wrote: post #84

Earlier quoted context omitted.

Hooks are not like functions. They are like imports. They provide your component with piece of functionality. You don't put imports in if-s or for-s. It's as simple as that.

From a user’s perspective, they’re not, they’re functions. That’s my point: they introduce a new concept, foreign to the language you’re writing in. There’s not necessarily bad reasons for this, but the cognitive overhead of this is relatively high compared to existing language functionality.

They are no more just functions than require() was a function.

They use subset of function syntax to provide unique functionality. That's all.

JS was full of such things already. Functions that are hooks (in traditional sense of the word) into some platform provided functionality. setTimeout(), fetch api, promise chains, jquery. You could say that all of those are just functions but you still need to learn what each does separately to get behavior you want. JS is not Lisp where a function means just one thing used always the same way with same restrictions. JS uses functions to construct idioms that introduce functionalities foreign to the core language. React hooks are just one such idiom. You may still argue that introducing yet another idiom is unnecessary burden. I personally like them very much. Component classes were imho very bad conceptual fit for react with a lot of intricate lifecycle methods and special fields. Hooks allow to simplify the core of it to just render that just runs every time it's necessary into which you are bringing in additional functionalities as needed.

Re: Kind of annoyed at React

#110

Post by scotty79 »

qPkk4Bi wrote: post #107
scotty79 wrote: post #81

Earlier quoted context omitted.

> The problem is you literally need to use effects to make api requests No. Wtf? Don't do that. Never do that. Effects are for legacy DOM manipulation (and ad-hoc use of browser apis). Pretty much nothing else. Who tampers with states and data in useEffect is hellbent on creating spaghetti.

I assume your suggestion here is just to embrace a framework for data fetching and try not to think too hard about how they in turn implement it? Can't really fault developers for falling into this useEffect trap when even the official docs show that data fetching is indeed handled via useEffect[1], while at the same trying to yell at the reader to "NOT TRY THIS AT HOME" and just go use a framework because it's such…

Uhh... That's terrible piece of docs. They don't even cancel stale fetches, just ignore the recieved responses. They don't debounce anything.

There are so many things about syncing data between the client and the server that this section of the docs should just say "Don't", use Apollo or Redux or whetever. React is UI library, for data you need data library or at least general state handling library. Quick and dirty will bite you tenfold.

Post reply on HN