5 ms·

> I was just surprised when I recently revisited it. You can STILL write React like you used to (with class components). There haven’t been any major breaking

> I was just surprised when I recently revisited it. You can STILL write React like you used to (with class components). There haven’t been any major breaking changes. The transition was very slow. It was only recently that they even changed the docs. You’re complaining that they made changes to it half its lifetime ago after you walked away from it and now you can’t just go back to the way it was.

pier25 3y ago
> You’re complaining that they made changes to it half its lifetime ago after you walked away from it and now you can’t just go back to the way it was. Wouldn't you expect jQuery to keep using the same fundamental methodology a couple of years later?
- bobthepanda 3y ago
  I mean, Java was the stereotype of boring enterprise language, and has certainly changed a lot in the last ten years in terms of its shift towards functional-friendly programming.
  - pier25 3y ago
    How is this even comparable? Not only React changed completely almost overnight, but the changes in the methodology were fundamental.
    - baron816 3y ago
      This is just blatantly untrue. The changes were definitely not overnight. Not even close. You’re still free to write React in the old way. The docs were there for half a decade. If they had just made a different project, we’d still be talking about the same thing. You would still be complaining that things changed and you didn’t feel like bothering to learn a new thing.
    - bobthepanda 3y ago
      So are the Java 8 changes? Java lambda functions, streams and futures look nothing at all like traditional Java methods and threads, yet you're still free to write them, but nearly every Java Stack Overflow question has a dedicated Java 8+ answer because it is so different.
      - bcrosby95 3y ago
        Note that Java futures are from 2004. By the time Java 8 rolled around they definitely were "traditional". But lambdas and everything coming in project amber, yeah, there will increasingly be many styles of Java out there.
        yazaddaruvala 3y ago
        > By the time Java 8 rolled around they definitely were "traditional". Based on my experience only once CompletableFuture was added to Java did the Future interface really start getting used in mass. Before that, there were other libs that implemented Future like things (Rx, Guava, Netty, etc) but they were not adopted across the board. The transition to Java 8 was night and day! Roughly on par with the React Hooks transition.
kokanee 3y ago
Sure, React still supports that, for some reason. But good luck getting a job offer or even a PR approved if you're using `this.setState()` in 2023.
- trgn 3y ago
  Shame. Simple class-based React-components are joy to work with. Flat code layout, simple life-cycle, no new semantics to learn ("rules of hook"), no crufty mem-allocation. I firmly believe that FP-seepage into web programming is one of the reasons why so many web apps are so slow and feel sluggish, jittery.
  - Izkata 3y ago
    I can't speak in general, but there is one thing I vaguely remember being on the React roadmap as part of the class->function switch that AFAIK never happened (at least it hadn't last time I did a lot of React, which was years into the switch): Because they were pure functions based on props, React-the-framework would have the class-based shouldComponentUpdate built into it and using function-based components everywhere would get a free performance boost. Instead nowadays people who started with the function form don't know shouldComponentUpdate ever existed and all their React components constantly rerender.
  - kokanee 3y ago
    The great downfall of hooks, IMO, is that they allow you to create components that look clean and legible, but act unpredictably because all of your state updates are triggered by variable reference changes. The idea is that this makes your state updates happen automagically so you don't have to think about them, but this is a classic example of an abstraction that works until it doesn't. Redux mainstreamed the concept of reference changes triggering updates, but I think this is a horrible pattern - we don't even have an operator in JS for explicitly passing by reference, so you end up destructuring large objects constantly in order to change one property and create a new object reference, which is a totally inefficient alternative to calling a render method. Plus javascript developers don't generally think about the concept of passing by reference vs value anyway, in large part because the language gives us so few tools for making those choices. As a result, there is a class of bugs where the only solution is to change the list of dependency variables for a given hook. It doesn't take a huge amount of complexity for the implications of those dependency trees to bend the mind, and the "clean" syntax of hooks comes crashing down.

pier25 3y ago

> You’re complaining that they made changes to it half its lifetime ago after you walked away from it and now you can’t just go back to the way it was. Wouldn't you expect jQuery to keep using the same fundamental methodology a couple of years later?

bobthepanda 3y ago
I mean, Java was the stereotype of boring enterprise language, and has certainly changed a lot in the last ten years in terms of its shift towards functional-friendly programming.
- pier25 3y ago
  How is this even comparable? Not only React changed completely almost overnight, but the changes in the methodology were fundamental.
  - baron816 3y ago
    This is just blatantly untrue. The changes were definitely not overnight. Not even close. You’re still free to write React in the old way. The docs were there for half a decade. If they had just made a different project, we’d still be talking about the same thing. You would still be complaining that things changed and you didn’t feel like bothering to learn a new thing.
  - bobthepanda 3y ago
    So are the Java 8 changes? Java lambda functions, streams and futures look nothing at all like traditional Java methods and threads, yet you're still free to write them, but nearly every Java Stack Overflow question has a dedicated Java 8+ answer because it is so different.
    - bcrosby95 3y ago
      Note that Java futures are from 2004. By the time Java 8 rolled around they definitely were "traditional". But lambdas and everything coming in project amber, yeah, there will increasingly be many styles of Java out there.
      - yazaddaruvala 3y ago
        > By the time Java 8 rolled around they definitely were "traditional". Based on my experience only once CompletableFuture was added to Java did the Future interface really start getting used in mass. Before that, there were other libs that implemented Future like things (Rx, Guava, Netty, etc) but they were not adopted across the board. The transition to Java 8 was night and day! Roughly on par with the React Hooks transition.

kokanee 3y ago

Sure, React still supports that, for some reason. But good luck getting a job offer or even a PR approved if you're using `this.setState()` in 2023.

trgn 3y ago
Shame. Simple class-based React-components are joy to work with. Flat code layout, simple life-cycle, no new semantics to learn ("rules of hook"), no crufty mem-allocation. I firmly believe that FP-seepage into web programming is one of the reasons why so many web apps are so slow and feel sluggish, jittery.
- Izkata 3y ago
  I can't speak in general, but there is one thing I vaguely remember being on the React roadmap as part of the class->function switch that AFAIK never happened (at least it hadn't last time I did a lot of React, which was years into the switch): Because they were pure functions based on props, React-the-framework would have the class-based shouldComponentUpdate built into it and using function-based components everywhere would get a free performance boost. Instead nowadays people who started with the function form don't know shouldComponentUpdate ever existed and all their React components constantly rerender.
- kokanee 3y ago
  The great downfall of hooks, IMO, is that they allow you to create components that look clean and legible, but act unpredictably because all of your state updates are triggered by variable reference changes. The idea is that this makes your state updates happen automagically so you don't have to think about them, but this is a classic example of an abstraction that works until it doesn't. Redux mainstreamed the concept of reference changes triggering updates, but I think this is a horrible pattern - we don't even have an operator in JS for explicitly passing by reference, so you end up destructuring large objects constantly in order to change one property and create a new object reference, which is a totally inefficient alternative to calling a render method. Plus javascript developers don't generally think about the concept of passing by reference vs value anyway, in large part because the language gives us so few tools for making those choices. As a result, there is a class of bugs where the only solution is to change the list of dependency variables for a given hook. It doesn't take a huge amount of complexity for the implications of those dependency trees to bend the mind, and the "clean" syntax of hooks comes crashing down.