Live data from Hacker News

Kind of annoyed at React

blog.cassidoo.co

111–120 of 135 posts

Re: Kind of annoyed at React

#111
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.

React documentation lists a lot of other use cases for useEffect() than just that:

- useEffect is a React Hook that lets you synchronize a component with an external system.

- Connecting to an external system

- Wrapping Effects in custom Hooks

- Controlling a non-React widget

- Fetching data with Effects

- Specifying reactive dependencies

- Updating state based on previous state from an Effect

- Removing unnecessary object dependencies

- Removing unnecessary function dependencies

- Reading the latest props and state from an Effect

- Displaying different content on the server and the client

https://react.dev/reference/react/useEffect#specifying-react...

Re: Kind of annoyed at React

#112
post #50

I’ve never gotten into web development but enjoyed developing iOS apps in Obj-C or Android in Java. Anyone recommend a website framework that might allow me to completely avoid html/css/javascript?

There's nothing wrong with html/css/js. They are a joy to use really. We're just discussing the abstraction of React here. No need to completely disregard them. You can't eitherway.

Re: Kind of annoyed at React

#113
post #92
post #65

Earlier quoted context omitted.

The more I get into RSC I have the feeling their main purpose is to pump up Vercel bills. A reason to buy more of their expensive compute resources. They are nice in theory, but I don't see that many benefits over simple SSR, or the more traditional concept of server generated HTML with interactive islands. Next.js applications often feel way less responsive than SPAs with proper pre-rendering on first load.

The speed problem imo is completely fabricated and is an angle to sell you their cloud offering. The mobile web is already unusable thanks to cookie banners, various popups, and ads. Loading spinners are the equivalent of Don Quixote's windmills.

I think it would be great to improve the speed of web applications. Including all the advertisements ;)

But I'm really doubting if Next.js is actually solving this problem. They are heavily caching everyting, so it might bring big benefits with slow and weird backend systems.

Re: Kind of annoyed at React

#114
post #95

Earlier quoted context omitted.

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…

> JS is not Lisp where a function means just one thing used

Lisp uses dynamic binding for that.

  (defun do-something ()
    (funcall *something-to-call*))

  (let ((*something-to-call* 'turn-the-light-on))
    (do-something))
The behavior depends on the dynamic binding, which provides the context...

Re: Kind of annoyed at React

#115
post #111

Earlier quoted context omitted.

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

React documentation lists a lot of other use cases for useEffect() than just that: - useEffect is a React Hook that lets you synchronize a component with an external system. - Connecting to an external system - Wrapping Effects in custom Hooks - Controlling a non-React widget - Fetching data with Effects - Specifying reactive dependencies - Updating state based on previous state from an Effect - Removing unnecessary…

Just because you can doesn't mean you should.

What you should have gotten from this list of every possible use (and misuse) of useEffect is that it's for interaction with external things. And if you are doing a lot of interafacing with external stuff you should use a dedicated service for it, not pollute your code with ad-hoc bits of interaction, each wrapped in their own bespoke useEffect().

And the linked section talks about specifying dependencies of the code block inside useEffect()

You don't define dependencies WITH useEffect. You define dependencies OF useEffect. And you don't have much choice in the matter. Any local variable (also parameter) of render function needs to be a dependency of useEffect code. As this section states.

Here are some common misuses: https://react.dev/learn/you-might-not-need-an-effect

Re: Kind of annoyed at React

#116
post #111

Earlier quoted context omitted.

React documentation lists a lot of other use cases for useEffect() than just that: - useEffect is a React Hook that lets you synchronize a component with an external system. - Connecting to an external system - Wrapping Effects in custom Hooks - Controlling a non-React widget - Fetching data with Effects - Specifying reactive dependencies - Updating state based on previous state from an Effect - Removing unnecessary…

Just because you can doesn't mean you should. What you should have gotten from this list of every possible use (and misuse) of useEffect is that it's for interaction with external things. And if you are doing a lot of interafacing with external stuff you should use a dedicated service for it, not pollute your code with ad-hoc bits of interaction, each wrapped in their own bespoke useEffect(). And the linked section t…

You can overuse useEffect() for sure. But I don't know how else you'd react e.g. to the page query string parameters or component properties changing, when the rendered content depends on them.

Re: Kind of annoyed at React

#117
post #116

Earlier quoted context omitted.

Just because you can doesn't mean you should. What you should have gotten from this list of every possible use (and misuse) of useEffect is that it's for interaction with external things. And if you are doing a lot of interafacing with external stuff you should use a dedicated service for it, not pollute your code with ad-hoc bits of interaction, each wrapped in their own bespoke useEffect(). And the linked section t…

You can overuse useEffect() for sure. But I don't know how else you'd react e.g. to the page query string parameters or component properties changing, when the rendered content depends on them.

You use a router or you have a service that watches history api and dispatches Redux actions.

React is UI library. Just because it can do a lot doesn't mean it should do everything. Especially in larger apps.

Re: Kind of annoyed at React

#118
post #116

Earlier quoted context omitted.

You can overuse useEffect() for sure. But I don't know how else you'd react e.g. to the page query string parameters or component properties changing, when the rendered content depends on them.

You use a router or you have a service that watches history api and dispatches Redux actions. React is UI library. Just because it can do a lot doesn't mean it should do everything. Especially in larger apps.

Yeah and then the router sends you property changes which you react to with useEffect().

Re: Kind of annoyed at React

#119
post #71

Earlier quoted context omitted.

I started a new React project back in December after being annoyed with Angular, just to see whether it would be any less annoying and/or quicker. It's been neither of those things and I'm actually beginning to regret making that choice.

The learning curve is steep for React, you’ll struggle without solid JS skills

You'll also struggle with solid JS skills - even the best FE devs I know, working for top tech companies, are able to produce React spaghetti.

Re: Kind of annoyed at React

#120
post #118

Earlier quoted context omitted.

You use a router or you have a service that watches history api and dispatches Redux actions. React is UI library. Just because it can do a lot doesn't mean it should do everything. Especially in larger apps.

Yeah and then the router sends you property changes which you react to with useEffect().

The whole point is not to use it directly in your components. It is implementation detail of that particular router. You might use router that interfaces with Redux not React directly.

Or you could write your router in the form of a service that lives directly in the history api event handlers and communicates directly though react state setters of some top-level component. Not a single useEffect needed.

Besides, router doesn't usually send you anything. It just sets props on your components according to url.

Post reply on HN