4 ms·

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

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

lucideer 6y ago
> 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.
- varrock 6y ago
  > 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.
  - lucideer 6y ago
    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).
    - acemarke 6y ago
      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.
      - lucideer 6y ago
        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.
dota_fanatic 6y ago
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.
- littlecranky67 6y ago
  > 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).
  - tabtab 6y ago
    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.
ampdepolymerase 6y ago
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.
- peterbell_nyc 6y ago
  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.
- tabtab 6y ago
  See nearby for my early-car analogy.

lucideer 6y ago

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

varrock 6y ago
> 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.
- lucideer 6y ago
  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).
  - acemarke 6y ago
    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.
    - lucideer 6y ago
      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.

dota_fanatic 6y ago

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.

littlecranky67 6y ago
> 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).
- tabtab 6y ago
  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.

ampdepolymerase 6y ago

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.

peterbell_nyc 6y ago
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.
tabtab 6y ago
See nearby for my early-car analogy.