3 ms·

> No classes in JS was much better than with. I think you experienced a different JS than I did. JS has always had classes, they were just "harder" to build/us

> No classes in JS was much better than with. I think you experienced a different JS than I did. JS has always had classes, they were just "harder" to build/use and every "Framework" had a different mixed bag of "utilities" and patterns to work with it and they weren't always compatible. (Mixing jQuery style classes and Dojo style classes was "fun", for two random examples. I could go on all day about the long tail from MOO Tools to YUI to Backbone to…) ES2015 class syntax just standardized already common patterns and increased interoperability and cleaned up a lot of footguns regarding Prototype-style inheritance along a "garden path". The class syntax garden path is much nicer than the weed-filled hedge maze it mostly replaced.

pier25 3y ago
> The class syntax garden path is much nicer than the weed-filled hedge maze it mostly replaced. I agree. Honestly I don't understand the obsession some people in the JS world have against classes. React components with state made more sense with classes than hooks. And yeah some people argue hooks are composable yada yada but if you need a React expert to write a useInterval hook to use a fundamental language feature, then maybe the model is not a great idea to begin with. https://overreacted.io/making-setinterval-declarative-with-react-hooks/ https://overreacted.io/making-setinterval-declarative-with-r... Of course I know I'm in the minority here.
- schwartzworld 3y ago
  It's because they have been bitten by inheritance issues. Classes are great as long as you limit or avoid inheritance altogether. They work so nice with typescript.
  - WorldMaker 3y ago
    Relatedly, it's also because of multi-inheritance issues specifically. React built hooks in part to handle cross-cutting concerns that needed some form of multi-inheritance (mixins and "higher-order components" which themselves were often something of a hack around the existence of strong JS mixin libraries/standards/best practices/meta-programming). The best hooks are an improvement over their HOC counterparts (and many of their mixin counterparts): better Typescript types, fewer footguns, fewer composability limits (HOCs had stack problems where stack them in the wrong order and they broke or interfered with each other), easier to reason about (even given the weird learning curve of hooks in general, as black box "units" they have simpler mechanics and APIs than HOCs ever did). To be fair, you can build a lot of React components without ever feeling a need for something like an HOC and never deal with some of the inheritance problems that Hooks were built to solve so some of that "classes are a better way to write components" feeling is that one has never quite before had the multi-inheritance itch to scratch that Hooks solves for. It's obviously hard to judge a tool when you don't know if you've had the problem it solves for or not.
    - schwartzworld 3y ago
      I was talking about classes as a design pattern, not just react classes. That said, I don't miss higher order components, but I do find myself reaching for renderprops sometimes. I think it's still a great pattern.
squeaky-clean 3y ago
I got quite used to the prototype inheritance style Javascript and really liked it. But I don't think it scales across teams as well as modern JS or Typescript. But for a small project with just myself or a few other skilled developers? I'd prefer old-school style JS semantics.
- WorldMaker 3y ago
  Yeah, I have some fondness for it myself, even despite listing some of the headaches I recall from past efforts. The fun/interesting/good news is that it is not technically an either/or in JS. Prototypes are still the underlying driver below the class syntax. There's absolutely still room for doing really interesting or cool things with prototypical inheritance, even doing things that aren't entirely possible with the class syntax, and then wrap them up in a cool library and make them interoperable with class syntax for all the downstream users. (Interop with the class syntax is still a useful design target.) The hardest parts of such "cool" library ideas is just likely getting the Typescript types correct with them. (Typescript doesn't quite model all the possible intricacies of prototypical inheritance, in my experience.)
  - squeaky-clean 3y ago
    Agreed, I still use it when I'm writing JS for personal projects. But at work, things have to pass code-review, be easy for someone else to modify in the future or write a bugfix for if I'm on vacation when the report comes in, etc... But I'll never fully give up that old-skool JS.

pier25 3y ago

> The class syntax garden path is much nicer than the weed-filled hedge maze it mostly replaced. I agree. Honestly I don't understand the obsession some people in the JS world have against classes. React components with state made more sense with classes than hooks. And yeah some people argue hooks are composable yada yada but if you need a React expert to write a useInterval hook to use a fundamental language feature, then maybe the model is not a great idea to begin with. https://overreacted.io/making-setinterval-declarative-with-react-hooks/ https://overreacted.io/making-setinterval-declarative-with-r... Of course I know I'm in the minority here.

schwartzworld 3y ago
It's because they have been bitten by inheritance issues. Classes are great as long as you limit or avoid inheritance altogether. They work so nice with typescript.
- WorldMaker 3y ago
  Relatedly, it's also because of multi-inheritance issues specifically. React built hooks in part to handle cross-cutting concerns that needed some form of multi-inheritance (mixins and "higher-order components" which themselves were often something of a hack around the existence of strong JS mixin libraries/standards/best practices/meta-programming). The best hooks are an improvement over their HOC counterparts (and many of their mixin counterparts): better Typescript types, fewer footguns, fewer composability limits (HOCs had stack problems where stack them in the wrong order and they broke or interfered with each other), easier to reason about (even given the weird learning curve of hooks in general, as black box "units" they have simpler mechanics and APIs than HOCs ever did). To be fair, you can build a lot of React components without ever feeling a need for something like an HOC and never deal with some of the inheritance problems that Hooks were built to solve so some of that "classes are a better way to write components" feeling is that one has never quite before had the multi-inheritance itch to scratch that Hooks solves for. It's obviously hard to judge a tool when you don't know if you've had the problem it solves for or not.
  - schwartzworld 3y ago
    I was talking about classes as a design pattern, not just react classes. That said, I don't miss higher order components, but I do find myself reaching for renderprops sometimes. I think it's still a great pattern.

squeaky-clean 3y ago

I got quite used to the prototype inheritance style Javascript and really liked it. But I don't think it scales across teams as well as modern JS or Typescript. But for a small project with just myself or a few other skilled developers? I'd prefer old-school style JS semantics.

WorldMaker 3y ago
Yeah, I have some fondness for it myself, even despite listing some of the headaches I recall from past efforts. The fun/interesting/good news is that it is not technically an either/or in JS. Prototypes are still the underlying driver below the class syntax. There's absolutely still room for doing really interesting or cool things with prototypical inheritance, even doing things that aren't entirely possible with the class syntax, and then wrap them up in a cool library and make them interoperable with class syntax for all the downstream users. (Interop with the class syntax is still a useful design target.) The hardest parts of such "cool" library ideas is just likely getting the Typescript types correct with them. (Typescript doesn't quite model all the possible intricacies of prototypical inheritance, in my experience.)
- squeaky-clean 3y ago
  Agreed, I still use it when I'm writing JS for personal projects. But at work, things have to pass code-review, be easy for someone else to modify in the future or write a bugfix for if I'm on vacation when the report comes in, etc... But I'll never fully give up that old-skool JS.