[wokwokwok]

You realize you've just done exactly what the parent complained about right?

- said it was bad

- not provided any concrete details

> they've become unmaintainable when reaching a certain size

How?

Did you start getting lot of hard to replicate bugs?

Did you find authoring new components was made difficult by your heavy use of custom hooks that were actually not as generic as you thought when you wrote them?

Did you find 3rd-party hooks had bugs?

Did you find that useRef doesn't work like you think it does, and you can't mix and match useRef and useEffect? (ouch)

What kind components are you writing that you find hooks are such a bad fit for?

Be specific.

(I'm not saying hooks are perfect; I've had all of the issues I listed happen to me, but it's still quicker to implement new features on a medium sized web app using hooks than with components in my experience; I work on 3 apps, and only one of them still uses components, and it's the most annoying to make changes too, simply because for simple business components & forms, hooks seem to reduce the amount of boiler plate, and flat out, reduce the lines of code; less code -> faster changes. It's not always that simple (see bugs comment above), but mostly... it is, in my experience: ...HOWEVER, what you've done is just wave your hands vaguely and fail to actually say anything except you don't like hooks)

[bpicolo]

A mental model being complex to grasp is concrete. Complexity is one of the biggest challenges in software.

One of my favorite papers on it: https://github.com/papers-we-love/papers-we-love/blob/master...

[wokwokwok]

You don't need to understand all the stuff you use.

How complex it is is not relevant unless it has a tangible impact.

eg. I use spark a lot. I don't really deeply understand how the DAG is translated into a distributed computation and the results are aggregated from the cluster.

It calculates things. It's fast. Sometimes I'm surprised by things that are slower than I expect. Oh well. Don't do lots of column renames. /shrug

It's a tradeoff.

Is the effort to understand the detail worth the benefit of doing so? Does not understanding it cause enough pain that it become prohibitive to develop using it?

Is it for spark? No. I really don't care how it's implemented. I don't even know scala. It works fine.

Is it for assembly? No. I don't care at all how my code is JIT'd to assembly / code. It just works.

It it for react hooks? I honestly haven't personally found it to be... but I don't write custom hooks much.

So, your experience with hooks might be different, and you may find the trade-off is more expensive if your case, because it tangibly causes, eg. bugs when you write your code.

...but you are quite wrong if you think that not understanding how something works is a fundamental obstacle to using it.

That is categorically false.

I would argue that it's far from proven that using complex systems necessarily causes the complexity of your system to balloon out of control... or that there is even a strong casual relationship between "mental model being complex to grasp" and the resulting complexity of the system.

[crispyambulance]

  > ...it's far from proven that using complex systems necessarily causes the complexity of your system to balloon...

I don't know what "proven" would actually mean in this context, but there's a notion called "leaky abstraction". It bites you hard when you use a "do-everything" framework and something goes wrong.

All of sudden, the magic stops and you have to deal with a ream of obtuse stack traces, problems that completely smash your metal model of what's going on, and you end up in deep rabbit holes of stuff you don't want to get into at the worst possible time. That is a fundamental obstacle.

[briantakita]

All things given, I'd rather use a tool that does not have leaky abstractions and if I need to investigate the inner workings of an abstraction, I can form a mental model of that abstraction with little effort. To your point, you don't need to understand the inner workings of your tools, but being able to quickly learn about the inner workings of the tools is beneficial to creating abstractions, crafting solutions, fixing issues, performing refactoring, tracking the usage of concepts across the codebase, etc.

[bpicolo]

The mental model of usage is the problem, not the mental model of its internals.

[wokwokwok]

no, its not.

Thats the point: the mental model is irrelevant unless it causes bugs when you use it wrong.

Does it? Does it actually cause bugs?

Not, “in general”; You’re just doing the same thing again here and doing vague hand waving. What actual bugs? What types of bugs?

Be specific

(yes, it does cause bugs, but see how this conversation is pointless when you don’t provide any details? Right, now go read the first post in this thread.)