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

Ask HN: Anyone else notice that HN isn’t full of JavaScript frameworks lately?

news.ycombinator.com

Post reply on HN
Print view View original

131–136 of 136 posts

Re: Ask HN: Anyone else notice that HN isn’t full of JavaScript frameworks lately?

#131

Post by mejutoco »

unconed wrote: post #105
prewett wrote: post #103

Earlier quoted context omitted.

Hooks are particularly bad to reason about. I can't figure out why hooks seems to be the official Way, it just leads to a bunch of spaghetti functions. The old object-oriented approach might feel old and creaky, but OOP was invented for user interface. Functional programming, not so much.

The why of hooks is actually easy to explain, it's just that nobody does it. A complex UI component will usually contain different aspects A, B and C. Each of these requires hooking into the component lifecycle in various ways. In a class/interface-based system, you have to sprinkle parts of A/B/C around in each of the lifecycle methods. The only way to abstract and contain this is to make ` ` ` ` ` ` subcomponents,…

> people don't understand how they should useMemo for derived state, and instead emulate the old way with useEffect/setState

The problem is react keeps coming up with new leaky abstractions, instead of solid building blocks. Fashion is not a good way to do engineering.

Re: Ask HN: Anyone else notice that HN isn’t full of JavaScript frameworks lately?

#132

Post by wryanzimmerman »

unconed wrote: post #105
prewett wrote: post #103

Earlier quoted context omitted.

Hooks are particularly bad to reason about. I can't figure out why hooks seems to be the official Way, it just leads to a bunch of spaghetti functions. The old object-oriented approach might feel old and creaky, but OOP was invented for user interface. Functional programming, not so much.

The why of hooks is actually easy to explain, it's just that nobody does it. A complex UI component will usually contain different aspects A, B and C. Each of these requires hooking into the component lifecycle in various ways. In a class/interface-based system, you have to sprinkle parts of A/B/C around in each of the lifecycle methods. The only way to abstract and contain this is to make ` ` ` ` ` ` subcomponents,…

Almost all of the issues you’re pointing out come from misunderstandings about derived state and side effects.

Derived state should be eliminated! If it can be derived, it’s not state.

If you aren’t trying to do derived state patterns, you don’t need to access the previous value. That’s a huge red flag. Likewise, “state” in useRef is a huge red flag. useMemo() is often a signpost pointing to bugs. If the useMemo cannot be removed without getting a different behavior in the application, that’s wrong—it might be slower, but the result should be the same with or without it.

It’s not a side effect free rendering model. Mouse interactions, requests, etc, are side effects; the pattern is side effect sets state and state defines the render. The problem happens when people try to “outsmart” this pattern and try to jump from side effect to outcome by subverting the state pattern, which makes them lose most of the advantages of react.

Any discussions around “triggering renders” or “preventing renders” before the component is behaving correctly are also big time red flags.

Re: Ask HN: Anyone else notice that HN isn’t full of JavaScript frameworks lately?

#133

Post by wryanzimmerman »

mejutoco wrote: post #131
unconed wrote: post #105

Earlier quoted context omitted.

The why of hooks is actually easy to explain, it's just that nobody does it. A complex UI component will usually contain different aspects A, B and C. Each of these requires hooking into the component lifecycle in various ways. In a class/interface-based system, you have to sprinkle parts of A/B/C around in each of the lifecycle methods. The only way to abstract and contain this is to make ` ` ` ` ` ` subcomponents,…

> people don't understand how they should useMemo for derived state, and instead emulate the old way with useEffect/setState The problem is react keeps coming up with new leaky abstractions, instead of solid building blocks. Fashion is not a good way to do engineering.

Since the beginning, the way to solve derived state is to remove it from state—these patterns are both anti patterns.

Re: Ask HN: Anyone else notice that HN isn’t full of JavaScript frameworks lately?

#134

Post by awesomeMilou »

austin-cheney wrote: post #113
awesomeMilou wrote: post #102

Earlier quoted context omitted.

> They exist to supplement skill deficits in people, primarily around architecture and composition That's just another hot take which makes no sense if you think about it. Being able to fit complex features into already existing abstractions is an even more sought after skill with frameworks than without. Frameworks exist to standardize architecture, not to mitigate skill issues.

> Frameworks exist to standardize architecture, not to mitigate skill issues. It's a pre-formulated architecture in a box so that developers don't have to make those such decisions, most often because they can't. That is a supplement for an absence of skills, the same reason that made jQuery popular.

> the same reason that made jQuery popular.

jQuery emerged from a lack of standardization and features in web browsers. It was a huge step forward and some of it's core features were standardized as extensions of the DOM interface (DOM queries are an example of this)

> most often because they can't

The issue isn't skill, it's a question of common architecure. A batteries included framework gives you exactly one choice for each part of your core architecture, which accelerates development because you don't have to worry about it. In addition, it saves you time and _immense_ costs on maintaining the core architecture of your app. React is a bad example due to it's simplicity, but take Angular or Ruby on Rails. Lot's of choices made for you, so you can benefit from the ecosystem.

Post reply on HN