5 ms·

"You do not need to know how `useState` works" I feel like you eventually do. The issue with React, at least in my experience, is that it's a type of abstracti

"You do not need to know how `useState` works" I feel like you eventually do. The issue with React, at least in my experience, is that it's a type of abstraction that seems ill-suited for how the web works under the hood, so it's incredibly leaky. Everything seems to make sense initially, and you get along just fine, but then you run into an edge case, and there's an official workaround for the edge case, but then you run into edge cases for the workaround for the edge case, and suddenly, that's your whole life. Before you know it, you really do have to know how things actually work under the hood.

djbusby 2y ago
Seems like that happens with every frameworks I've ever used since 2000 (in Perl, PHP, Ruby, JS, etc). Every framework makes the easy things slightly easier, the boring stuff is included and you get to focus on the fun/hard part - and I think then, naturally, you bump into the edge. But! You get to that point faster. And then you have to know the guts to solve the issue the "framework" way or do some lower-level shit-hack. I feel like it's just a natural law of any general purpose framework. It made the first 80% of the job easy. Now you just have to finish the other 80%.
dartos 2y ago
I thought pre-hooks react provided a really nice and simple abstraction over how the web works. FRP is a nice fit for the kind of UI that makes the majority of the web. Hooks ruined the framework imo. Confusing api (useState returning an array for example). Having a class component with hooks for lifecycle behavior made perfect sense. Each component’s state being a field on those classes was easy to understand. Hooks came out of left field and made everything more complex for the worse.
- kaoD 2y ago
  > Hooks ruined the framework imo. Confusing api (useState returning an array for example). It just returns a tuple. That's not confusing at all and it's a very well established pattern in most modern languages. If there's anything that can be considered complex and footgun-y in React it's useEffect because most of the time you shouldn't use it at all but it can be abused very easily and it kinda works even if you abuse it (but introduces a huge maintenance burden).
  - dartos 2y ago
    > It just returns a tuple. That's not confusing at all and it's a very well established pattern in most modern languages. A few things wrong with this. It does not return a tuple, it returns an array with 2 elements. You, as the react dev, need to just know that this is the case and that one is the value and the other is a set function. In most modern languages, tuples are common, yes. But not in JavaScript. React isn’t a python or go framework, it’s a JavaScript framework. Why doesn’t it act like almost everything else in js land and return an object with 2 named fields? Why place extra knowledge burden on the developer? It’s just poor api design Yes useEffect is also a huge complex pain point, but it just takes longer to type out why that is. Pretty much all the hooks are as almost nothing else in the JavaScript ecosystem acts like they do.
    - xpl 2y ago
      > Why doesn’t it act like almost everything else in js land and return an object with 2 named fields The explanation is actually very simple: because in 100% of times you need to give those two fields custom names. It is easier and more concise with tuple: const [text, setText] = ... Than with object + renaming, which quickly gets clumsy when you have dozens of such lines in your component: const {value: text, setValue: setText} = ...
      - dartos 2y ago
        That’s not a good reason. Especially in our world where strong typing is something preferable. Fewer characters at the cost of clarity is poor api design. Implicitness is almost always worse than explicitness. Explicit !== clumsy And again, almost nothing else in the js ecosystem behaves like this. Especially at the time of the big hooks update to react. Also, again, it’s not a tuple. It’s an array with 2 elements. JavaScript does not have tuples or the semantics for interacting with them as such. You just need to know that there’s always going to be 2 elements. That extra knowledge burden is the hallmark of poor api design.
        xpl 2y ago
- com2kid 2y ago
  React + classes made sense. Redux was hard to use. All react needed was a simple state management solution that didn't take 500 loc across multiple files and a ton of useless object copying to make a page full of form elements work. Instead it got a complete paradigm shift to a leaky abstraction. Not that the previous abstraction wasn't leaky, it was alwayz super easy to have components re-render when not necessarily.
- ljm 2y ago
  There's a world where browser UIs are programmed in Smalltalk instead, which I think is what the authors of the DOM may have intended when building it out OOP-style. It would bear almost no resemblance to the web we have today, but message passing between UI components throughout various parts of their lifecycle has been a great way to model an interface for decades. You only need to look at the overall fit and finish of a typical MacOS or iOS app, with Swift simply pulling Objective-C into the 21st century.
  - dartos 2y ago
    Web UIs tend to make heavy use of message passing via event listeners. The major difference between web UIs and desktop apps is two fold. In web UIs, you don’t generally have an event loop in which you change your app state based on system input events and there is, generally, a slow request/response cycle for any interaction. That’s why immediate mode UI doesn’t really fit well in web land.

djbusby 2y ago

Seems like that happens with every frameworks I've ever used since 2000 (in Perl, PHP, Ruby, JS, etc). Every framework makes the easy things slightly easier, the boring stuff is included and you get to focus on the fun/hard part - and I think then, naturally, you bump into the edge. But! You get to that point faster. And then you have to know the guts to solve the issue the "framework" way or do some lower-level shit-hack. I feel like it's just a natural law of any general purpose framework. It made the first 80% of the job easy. Now you just have to finish the other 80%.

dartos 2y ago

I thought pre-hooks react provided a really nice and simple abstraction over how the web works. FRP is a nice fit for the kind of UI that makes the majority of the web. Hooks ruined the framework imo. Confusing api (useState returning an array for example). Having a class component with hooks for lifecycle behavior made perfect sense. Each component’s state being a field on those classes was easy to understand. Hooks came out of left field and made everything more complex for the worse.

kaoD 2y ago
> Hooks ruined the framework imo. Confusing api (useState returning an array for example). It just returns a tuple. That's not confusing at all and it's a very well established pattern in most modern languages. If there's anything that can be considered complex and footgun-y in React it's useEffect because most of the time you shouldn't use it at all but it can be abused very easily and it kinda works even if you abuse it (but introduces a huge maintenance burden).
- dartos 2y ago
  > It just returns a tuple. That's not confusing at all and it's a very well established pattern in most modern languages. A few things wrong with this. It does not return a tuple, it returns an array with 2 elements. You, as the react dev, need to just know that this is the case and that one is the value and the other is a set function. In most modern languages, tuples are common, yes. But not in JavaScript. React isn’t a python or go framework, it’s a JavaScript framework. Why doesn’t it act like almost everything else in js land and return an object with 2 named fields? Why place extra knowledge burden on the developer? It’s just poor api design Yes useEffect is also a huge complex pain point, but it just takes longer to type out why that is. Pretty much all the hooks are as almost nothing else in the JavaScript ecosystem acts like they do.
  - xpl 2y ago
    > Why doesn’t it act like almost everything else in js land and return an object with 2 named fields The explanation is actually very simple: because in 100% of times you need to give those two fields custom names. It is easier and more concise with tuple: const [text, setText] = ... Than with object + renaming, which quickly gets clumsy when you have dozens of such lines in your component: const {value: text, setValue: setText} = ...
    - dartos 2y ago
      That’s not a good reason. Especially in our world where strong typing is something preferable. Fewer characters at the cost of clarity is poor api design. Implicitness is almost always worse than explicitness. Explicit !== clumsy And again, almost nothing else in the js ecosystem behaves like this. Especially at the time of the big hooks update to react. Also, again, it’s not a tuple. It’s an array with 2 elements. JavaScript does not have tuples or the semantics for interacting with them as such. You just need to know that there’s always going to be 2 elements. That extra knowledge burden is the hallmark of poor api design.
      - xpl 2y ago
com2kid 2y ago
React + classes made sense. Redux was hard to use. All react needed was a simple state management solution that didn't take 500 loc across multiple files and a ton of useless object copying to make a page full of form elements work. Instead it got a complete paradigm shift to a leaky abstraction. Not that the previous abstraction wasn't leaky, it was alwayz super easy to have components re-render when not necessarily.
ljm 2y ago
There's a world where browser UIs are programmed in Smalltalk instead, which I think is what the authors of the DOM may have intended when building it out OOP-style. It would bear almost no resemblance to the web we have today, but message passing between UI components throughout various parts of their lifecycle has been a great way to model an interface for decades. You only need to look at the overall fit and finish of a typical MacOS or iOS app, with Swift simply pulling Objective-C into the 21st century.
- dartos 2y ago
  Web UIs tend to make heavy use of message passing via event listeners. The major difference between web UIs and desktop apps is two fold. In web UIs, you don’t generally have an event loop in which you change your app state based on system input events and there is, generally, a slow request/response cycle for any interaction. That’s why immediate mode UI doesn’t really fit well in web land.