Live data from Hacker News

Kind of annoyed at React

blog.cassidoo.co

81–90 of 135 posts

Re: Kind of annoyed at React

#81
post #35

Earlier quoted context omitted.

And that's why using effects for such tasks is a huge anti pattern. https://react.dev/learn/you-might-not-need-an-effect

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.

Re: Kind of annoyed at React

#82

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…

React was a massive improvement over Ember.js, Backbone.js and their ilk, which at the time as a young dev I couldn’t grasp by myself. React, however just clicked. f(state) = UI just makes sense

Which is not at all how it works in practice. In a large React codebase you have state scattered throughout contexts, GraphQL caches and complex hook dependency trees.

Throw in SSR and component memoization and you really have no idea what caused a UI change to occur.

Re: Kind of annoyed at React

#84
post #38
post #29

Earlier quoted context omitted.

But all the lifecycle methods were magic that needed to be understood... hooks just let you co-locate related logic in one place instead of scattered across 3 or 4 lifecycle methods.

I disagree that they were magic - you could build a test renderer for yourself and see pretty easily how they'd work. The system as a whole was understandable, and it fit into an existing mental model: you implement this interface, and React will call your methods. The specifics of how and when it did were part of the system on the other side of the interface. Hooks on the other hand are functions that you call, whic…

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.

Re: Kind of annoyed at React

#85
post #21

> it’s not clear/an easily understandable mental model for most people That's already the case, thanks to hooks. Hooks are weird, and should not be taught to junior programmers because it will confuse them for the rest of their careers. Hooks are weird because it doesn't align with functional programming paradigm or with OOP paradigm... it is a new paradigm and it is like nothing else. More on that: https://medium.co…

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.

Re: Kind of annoyed at React

#86
post #78

A couple of things make React extremely valuable to me: - The functional programming model (State => UI) allows building very complicated interfaces in a very simple way, by defining dependencies with useEffect() and other hooks. It can take years to master it, but when you develop complex apps where all kinds of state needs to update when some other state changes, you really appreciate how simple it is to do with Re…

> defining dependencies with useEffect()

Please don't. useEffect() is for pluging 3rd party DOM components into react. Not for doing anything else. Definitely not for any state manipulation or dependencies.

Re: Kind of annoyed at React

#87
post #69

Earlier quoted context omitted.

Nobody's forcing them, no. But often there isn't anyone preventing them, either. React happily hands these developers enough rope to hang themselves. To be clear: I don't mind React per se. Some of the best UI codebases I've worked in were React -- they just had a very strict separation of concerns and one-directional data flow via something like MobX or Redux. All the business logic was kept separate from the UI. Bu…

I have to say that I've seen Redux being abused until insanity (and probably misunderstood) much more often than hooks. And much harder to clean up that mess, because it's a centralized mess. The hook mess is usually decentralized and can be improved incrementally. What kind of frontend stack would you recommend that enforces keeping some meaningful separation of concern, without limiting productivity?

I will concede your point about horrible Redux codebases. I think I've tried to push that dark era out of my mind.

Without limiting productivity, I have no idea. I think you have to limit productivity along some axis or other, otherwise your codebase just turns to quicksand.

Re: Kind of annoyed at React

#88

> it’s not clear/an easily understandable mental model for most people That's already the case, thanks to hooks. Hooks are weird, and should not be taught to junior programmers because it will confuse them for the rest of their careers. Hooks are weird because it doesn't align with functional programming paradigm or with OOP paradigm... it is a new paradigm and it is like nothing else. More on that: https://medium.co…

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.

Re: Kind of annoyed at React

#89
post #10

Maybe, it's just me - I miss the good old days when sites didn't have anything to do with react or similar. Everything was just plain old hyperlinks and some basic JS. I am not even talking about the 90s, just look at what Facebook used to be in its early days - such a simple UI, just based off of hyperlinks, very basic JS. That simplicity alone made it such a joy to use. Today, I don't even feel like logging into Fa…

I was always surprised that a bunch of people looked at Facebook's website and said, yeah, I want their code to be the next big JS framework. Facebook has behaved for me for the past year or so, but for years prior to that, visiting their site was just an exercise in frustration for me. It was mainly because of components that remained in the gray loading state but never loaded. The messaging window used to do that for me about 50% of the time. Whenever I visited Facebook, I used to instinctively put my fingers over Ctrl-R in case I had to reload.

Also, one time, they managed to deploy code that broke form submissions under Firefox but not Chrome. I would be more understanding if it dealt with some cutting-edge features of HTML, but these are HTML forms. Mosaic had support for them in 1993.

Re: Kind of annoyed at React

#90
Everyone fucking off & writing frameworks that oh just so happen to be server side is incredibly bold self dealing. Now front and back end are deeply conflated, and instead of finding consistent controlled paradigms to tackle async on the front end we've just made an even bigger soup of what-renders-where-when.

We have been deeply mislead these past couple years. React ecosystem should have been working on better faster front end systems that integrate data better. Redux should just have been a start. Instead, managing data has gotten more complex and worse.

Post reply on HN