4 ms·

React explicitly discourages using inheritance with components, instead promoting composing components together like functions. You're also encouraged to keep t

React explicitly discourages using inheritance with components, instead promoting composing components together like functions. You're also encouraged to keep them stateless if possible, so they create the same output for the same input. I'll need some convincing that functional programming is on its way out in JavaScript.

personomas 9y ago
Yeah, but why did they switch from `React.createClass({..})` to the class syntax? Classes are terrible in JS, they're not even native JS, it doesn't fit in JS. This change alone has brought more and more OO JS code.
- personomas 9y ago
  In React v0.13 https://reactjs.org/blog/2015/03/10/react-v0.13.html https://reactjs.org/blog/2015/03/10/react-v0.13.html, they claimed the reason for the switch is because the `class` syntax is for "more flexibility." What can you do with the `class` syntax that you can't do with the functional syntax? Furthermore, you can generate React code much easier with the functional syntax than with the class syntax. Also, the functional syntax has mixins and other ways to combine objects or share code, I think that would be harder to do with classes, which make them even less flexible.
  - acemarke 9y ago
    At the moment, React does not yet have support for stateful functional components. It's something they've said they would _like_ to research and implement down the road, but right now, component state and lifecycle methods requires class components.
    - bjeanes 9y ago
      Or the use of something like recompose[1]'s `lifecycle` function[2]. 1: https://github.com/acdlite/recompose https://github.com/acdlite/recompose 2: https://github.com/acdlite/recompose/blob/8c4ac2e4/docs/API.md#lifecycle https://github.com/acdlite/recompose/blob/8c4ac2e4/docs/API....
      - acemarke 9y ago
        Yeah, although that itself is implemented internally using an ES6 class: https://github.com/acdlite/recompose/blob/8c4ac2e4a4cd8d60c8db9bc4cd73f0ce044fd9ca/src/packages/recompose/lifecycle.js#L16-L25 https://github.com/acdlite/recompose/blob/8c4ac2e4a4cd8d60c8...
  - always_good 9y ago
    Seems like a weird thing to miss for someone who ostensibly prefers functional programming. For example, people here will talk about `function User() {}` like it's the pinnacle of amazing abstraction. Because it has the word "function" in it or something. There's nothing functional about that to me. Mutating the prototype and dealing with the implicit `this` variable in your functions is about as far away from functional programming as you can get. Meanwhile Javascript just gets more and more functional, from the mindshare of higher order functions/components gaining traction to the @decorator transformation to the Promise 'monad'. It just gets better and better. I have a hard time taking anyone seriously who doesn't recognize the pain that `class` solved in the ecosystem whether you personally decide to use it or not. People have been writing OOP code in Javascript since day one, just with some of the worst idiosyncrasies of all OOP languages.
    - hungerstrike 9y ago
      People also write tons of bad functional code with JS. It gets worse and worse the more that people keep following this cargo cult of HOCs and functional programming. The obsession with using HOCs for passing a simple variable around is particularly absurd. Importing objects with methods (or even just a namespace with functions) is way, way cleaner than importing every function seperately. Which stable and widely used GUI kit has ever been done well with functional programming? Until one exists, I can’t really take anybody who pushes functional programming for GUIs very seriously. Functional programming just isn’t that good for complex domains. OOP is way better for GUIs.
      - girvo 9y ago
        ReasonML and ReasonReact agree with you: instead of HOCs, they prefer using standard functions, explicit “self”, and just passing things down through props. It’s quite a breath of fresh air really.
      - krysp 9y ago
        I suppose it isn't really a GUI but it does manage them. http://xmonad.org/ http://xmonad.org/
- acemarke 9y ago
  Prior to ES6, there were hundreds of incompatible class-like implementations in the JS ecosystem, and every major library had its own. That included React. Now that ES6 classes are actually part of the language, there's no reason for the React team to continue maintaining their own class-like implementation. They can defer that to the language itself. This also enables better use of standardizing tooling around the JS language.
- cname 9y ago
  I thought `createClass` does/did something essentially similar to what `class` does in ES6. Not having to use a framework's custom class-creation machinery doesn't seem like a big loss to me or like it is has anything to do with functional programming.
  - acemarke 9y ago
    Yep. It also had some differences in behavior. `createClass` auto-bound functions so that `this` always pointed to the component instance, and it supported mixins. The React team now encourages functional forms of composition rather than use of mixins, so that's another reason why React.Component doesn't support them. The lack of automatic method binding has certainly been a major pain for people learning and using React, but it also means that there's no "magic" involved. The Stage 3 Class Properties syntax is the recommended way to ensure that methods are bound properly, and there's plenty of other possible solutions as well.
- recursive 9y ago
  What do you mean native JS? It doesn't get much more native than "given keywords and syntax in the language and in the specification"
- kowdermeister 9y ago
  Classes are perfectly fine in JS, they are just syntactic enhancements for managing prototypes more easily.
  - vinnymac 9y ago
    Not sure what you mean by 'just syntactic enhancements'. Check this out https://esdiscuss.org/topic/javascript-vision-thing#content-5 https://esdiscuss.org/topic/javascript-vision-thing#content-...
- coldtea 9y ago
  Classes in JS6 are just a syntax sugar for the native JS prototype inheritance. Nothing "terrible", absolutely native (both since the keyword is part of JS and since the implementation is based on prototypes that have been with JS since the beginning), and fits perfectly.

personomas 9y ago

Yeah, but why did they switch from `React.createClass({..})` to the class syntax? Classes are terrible in JS, they're not even native JS, it doesn't fit in JS. This change alone has brought more and more OO JS code.

personomas 9y ago
In React v0.13 https://reactjs.org/blog/2015/03/10/react-v0.13.html https://reactjs.org/blog/2015/03/10/react-v0.13.html, they claimed the reason for the switch is because the `class` syntax is for "more flexibility." What can you do with the `class` syntax that you can't do with the functional syntax? Furthermore, you can generate React code much easier with the functional syntax than with the class syntax. Also, the functional syntax has mixins and other ways to combine objects or share code, I think that would be harder to do with classes, which make them even less flexible.
- acemarke 9y ago
  At the moment, React does not yet have support for stateful functional components. It's something they've said they would _like_ to research and implement down the road, but right now, component state and lifecycle methods requires class components.
  - bjeanes 9y ago
    Or the use of something like recompose[1]'s `lifecycle` function[2]. 1: https://github.com/acdlite/recompose https://github.com/acdlite/recompose 2: https://github.com/acdlite/recompose/blob/8c4ac2e4/docs/API.md#lifecycle https://github.com/acdlite/recompose/blob/8c4ac2e4/docs/API....
    - acemarke 9y ago
      Yeah, although that itself is implemented internally using an ES6 class: https://github.com/acdlite/recompose/blob/8c4ac2e4a4cd8d60c8db9bc4cd73f0ce044fd9ca/src/packages/recompose/lifecycle.js#L16-L25 https://github.com/acdlite/recompose/blob/8c4ac2e4a4cd8d60c8...
- always_good 9y ago
  Seems like a weird thing to miss for someone who ostensibly prefers functional programming. For example, people here will talk about `function User() {}` like it's the pinnacle of amazing abstraction. Because it has the word "function" in it or something. There's nothing functional about that to me. Mutating the prototype and dealing with the implicit `this` variable in your functions is about as far away from functional programming as you can get. Meanwhile Javascript just gets more and more functional, from the mindshare of higher order functions/components gaining traction to the @decorator transformation to the Promise 'monad'. It just gets better and better. I have a hard time taking anyone seriously who doesn't recognize the pain that `class` solved in the ecosystem whether you personally decide to use it or not. People have been writing OOP code in Javascript since day one, just with some of the worst idiosyncrasies of all OOP languages.
  - hungerstrike 9y ago
    People also write tons of bad functional code with JS. It gets worse and worse the more that people keep following this cargo cult of HOCs and functional programming. The obsession with using HOCs for passing a simple variable around is particularly absurd. Importing objects with methods (or even just a namespace with functions) is way, way cleaner than importing every function seperately. Which stable and widely used GUI kit has ever been done well with functional programming? Until one exists, I can’t really take anybody who pushes functional programming for GUIs very seriously. Functional programming just isn’t that good for complex domains. OOP is way better for GUIs.
    - girvo 9y ago
      ReasonML and ReasonReact agree with you: instead of HOCs, they prefer using standard functions, explicit “self”, and just passing things down through props. It’s quite a breath of fresh air really.
    - krysp 9y ago
      I suppose it isn't really a GUI but it does manage them. http://xmonad.org/ http://xmonad.org/
acemarke 9y ago
Prior to ES6, there were hundreds of incompatible class-like implementations in the JS ecosystem, and every major library had its own. That included React. Now that ES6 classes are actually part of the language, there's no reason for the React team to continue maintaining their own class-like implementation. They can defer that to the language itself. This also enables better use of standardizing tooling around the JS language.
cname 9y ago
I thought `createClass` does/did something essentially similar to what `class` does in ES6. Not having to use a framework's custom class-creation machinery doesn't seem like a big loss to me or like it is has anything to do with functional programming.
- acemarke 9y ago
  Yep. It also had some differences in behavior. `createClass` auto-bound functions so that `this` always pointed to the component instance, and it supported mixins. The React team now encourages functional forms of composition rather than use of mixins, so that's another reason why React.Component doesn't support them. The lack of automatic method binding has certainly been a major pain for people learning and using React, but it also means that there's no "magic" involved. The Stage 3 Class Properties syntax is the recommended way to ensure that methods are bound properly, and there's plenty of other possible solutions as well.
recursive 9y ago
What do you mean native JS? It doesn't get much more native than "given keywords and syntax in the language and in the specification"
kowdermeister 9y ago
Classes are perfectly fine in JS, they are just syntactic enhancements for managing prototypes more easily.
- vinnymac 9y ago
  Not sure what you mean by 'just syntactic enhancements'. Check this out https://esdiscuss.org/topic/javascript-vision-thing#content-5 https://esdiscuss.org/topic/javascript-vision-thing#content-...
coldtea 9y ago
Classes in JS6 are just a syntax sugar for the native JS prototype inheritance. Nothing "terrible", absolutely native (both since the keyword is part of JS and since the implementation is based on prototypes that have been with JS since the beginning), and fits perfectly.