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.

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.

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.

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.

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.

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.

In React v0.13 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.

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.

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.

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.

I suppose it isn't really a GUI but it does manage them.

http://xmonad.org/

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.

Or the use of something like recompose[1]'s `lifecycle` function[2].

1: https://github.com/acdlite/recompose

2: https://github.com/acdlite/recompose/blob/8c4ac2e4/docs/API....

Yeah, although that itself is implemented internally using an ES6 class:

https://github.com/acdlite/recompose/blob/8c4ac2e4a4cd8d60c8...

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"

Classes are perfectly fine in JS, they are just syntactic enhancements for managing prototypes more easily.

Not sure what you mean by 'just syntactic enhancements'. Check this out https://esdiscuss.org/topic/javascript-vision-thing#content-...

ClojureScript's re-frame[0] is my favorite way to React, honestly. PureScript's halogen is also pretty nice. Re-frame has a built-in, functionally pure way to do ajax and side-effects, too, which comes in pretty handy.

[0] https://github.com/Day8/re-frame

I use reframes little brother, citrus with cljs and it has been awesome. The promise of data oriented frontend engineering really pays off.

https://github.com/roman01la/citrus

Awesome! I've used reagent/re-frame extensively for years, but I've never tried Rum because I couldn't find an obvious way to use it with re-frame.

What do you think of citrus so far? Is it production ready? Stable? Anything missing?

actually once redux is introduced to react it's very very very functional.. so hold the sadness

React is functional even without Redux :-)

Look at the Reason team, with their Reason-React implementation. Cheng Lou seems to actively dislike a single store that Redux is, and, if anything, co-locates stores to stateful components.

That sounds more like flux, how do they avoid all the boilerplate that flux was? It was very very painful.