Hacker News Reader

Comment by hoorayimhelping | Hacker News Reader

>I think hooks aren't really making React more of a black box, but just that it's invalidating a lot of people's incorrect mental models on how React works.

Isn't that exactly the point that the big image on the front page is making? If most people have a mental model of a technology that doesn't match what the company is putting out, it makes very little sense to blame the people who have the 'incorrect' mental model. If it wasn't so widespread, your point would be much stronger. But the fact that the core pieces of react are misunderstood, especially when React publishes documents explaining how all of this is supposed to work and how you're supposed to think about this is an indication that something is wrong with React, not the people who use it.

View on HN

> If most people have a mental model of a technology that doesn't match what the company is putting out, it makes very little sense to blame the people who have the 'incorrect' mental model.

While you're right that we shouldn't "blame the people", I think blaming the company / library in this case doesn't fly either, given the specifics.

The "incorrect mental model" people have about React is based on two things:

1. the prevalence of OO concepts in programming education and in practice in most engineering teams

2. the introduction of class abstractions onto JS prototypes by the ES spec.

followed by:

3. React bundling things like `createReactClass` and encouraging class abstractions in their docs in the pre-hooks days

While the 3rd point above may have been a mistake on the part of the React team, I do think points 1 & 2 are much bigger factors here.

> something is wrong with React

The only thing "wrong" with modern React is that they're challenging the status quo in popular programming concepts with something they believe is a conceptual improvement.

You can disagree with them on whether it represents a true improvement, but saying they're "wrong" because their conceptual model is a departure from the status quo is pretty reductive.

> 1. the prevalence of OO concepts in programming education and in practice in most engineering teams

What makes this point tricky is that React did initially introduce their library with OO concepts for years.

Yup; mentioned that as point 3.

To put that in context: that was at the time ES was starting to introduce OO abstractions to the spec. and it was somewhat trendy to go in that direction. I never got the impression that the React guys were heavily invested in that paradigm, and they definitely moved away from it very quickly after first encouraging it in their API. Everyone makes mistakes.

As a side-note: I think class abstractions in ES are a feature that in retrospect is less of a great idea now than it may have seemed at the time. ES class abstractions obscure their own subtle issues (in a very similar way to the article's fake Twitter screenshot jokes about React hooks).

From my perspective, the sequence was:

- From 2008-2014, _everyone_ was writing their own "class-like" abstractions (see: Backbone, Class.js, five million other "inheritance" libs). So, the React team wrote `createClass` as their own implementation.

- When ES6 classes came out, the React team took that as an opportunity to drop maintaining their own abstraction and switch to something that was actually standardized, and reduce the amount of magic behavior (auto-binding, mixins, etc).

- Function components came out in React 0.14, and were initially limited to just rendering based on props - no state or effects possible

- Hooks now give function components the ability to have state and effects. In addition, encouraging a move away from classes dovetails into the React team's long-term plans for the React APIs.

Yeah, great rundown.

The class abstractions added to ES spec. didn't happen in a vacuum; it was very much on the back of community demand. Backbone especially had an outsized influence.

Perhaps that was a necessary step toward realising tools to solve problems without those abstractions, I don't know.

Perhaps React is just as complex as it needs to be solve the problems it tries to solve. Is that a true statement? Probably not. Close to true? Maybe.

Whatever the case, just because we wish solutions to those problems were easier to understand doesn't mean reality owes us that. I suspect React in particular, being in the web dev space, has a lot of people working with it who have very little CS background. Because they don't understand how React works under the hood or even above the hood is "something wrong with React"? I'm not sure I buy it.

I've seen a lot of really poor React code that breaks all kinds of best practices, many of them explicitly laid out in the docs. Even before hooks came along. In fact it's been hard to find examples of people who understand the dom well, much less React. I will continue to suspect there's something wrong with most of the people using React, not React itself, which from my perspective has only become better over time.

  > has a lot of people working with it who have very little CS background

This and so much this. This applies to "frontend development" in general. I work as a contractor in the frontend space (Europe, no where near FAANG like companies) and very often I meet other "devs" that have basically become frontend "engineers" out of being a webdesigner - like you know, creating nice html templates for wordpress, having decent CSS and photoshop skills and later in their career started to copy-paste some jquery plugins into their template to get nice animated toggles and alike. It is very common in "frontend teams" that people started to get into JS out of webdesign, and have never actually programmed in any other language.

Another issue is even with people with a CS or another STEM background, they only get taught in the "traditional" OOP sphere on top of blocking thread environments. Those usually have a hard time wrapping their heads around higher order functions or async-based development (and to be fair, I also had a hard time when I first encountered it).

Most rank-and-file development doesn't need async and HOF. If your framework does, it's either screwed up or for a special/rare niche. I've been in these debates many times, and when examples are given I can usually trace the "fault" down to the framework or limits of the language. I stand behind this claim.

At least in browser-world, most APIs (i mean the ones defined by the web standards) are built around async/Promise/callbacks/HOF, like it or not. There is no switching to other languages/framework when targeting the browser as a runtime.

This is largely because JavaScript has weak areas.

Crikey. Higher order functions are rare or niche?

To my mind they are oftentimes magic pixie dust that can turn a hideous, verbose and inflexible API into something humane and readable.

Not quite what I said. I said they are not needed for rank and file application (domain-centric) development, IF the tooling and programming language are decent.

If you bring up a scenario, I can probably poke holes in it. Done it many times in many debates. I don't mean to sound arrogant, but I keep winning THIS one for whatever reason.

> I've been in these debates many times, and when examples are given I can usually trace the "fault" down to the framework or limits of the language.

I don't disagree, but my follow-up question with that statement is "ok, now what?"

If you've got a weak/inexperienced developer who's stuck in a framework where they have have to start grokking async/HOF/whatever to solve the problem they've encountered, where do they go from there? It's fine and good to blame the framework they're operating in to be shitty, but they a) didn't have the skills initially to make a solid decision about the framework to use, and b) are now likely stuck with it (unless they're going to do a rewrite with something else).

I agree that our current tooling requires more "rocket science" than it should to do ordinary things. I'm not sure how to fix the entire industry, but the first step to solving a problem is admit there is one.

Early cars were hard to learn, drive, and maintain. Over time they got better via trial and error by manufacturers. The desktop IDE's of the early 90's were like this, but got better over time (until web ruined their market). However, the web is still stuck in 1903: simple things are esoteric. Perhaps because too many other things about "cars" keep changing? Something is wrong. CRUD web dev is a mess.

Most software engineers without a strong background in physics or CFD won't be able to reliably explain how an airfoil works either. Having a wrong mental model (equal transit time of air molecules resulting in lift) does not mean airplanes are not useful.

The question is not whether your mental model is incorrect, but whether the deficiencies in your model cause problematic consequences. For example if my model of how wings work is that "the slower you go the more lift you get", should I pilot a plane I'd probably end up getting in trouble.

See nearby for my early-car analogy.

Reply on news.ycombinator.com