Part of me is sad that Javascript has now been made OOP, after a majority of efforts pushing the balance towards becoming more and more functional (e.g. PureScript) only a few years ago.
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.
1: https://github.com/acdlite/recompose
2: https://github.com/acdlite/recompose/blob/8c4ac2e4/docs/API....
https://github.com/acdlite/recompose/blob/8c4ac2e4a4cd8d60c8...
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.
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.
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.
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.
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.
What do you think of citrus so far? Is it production ready? Stable? Anything missing?
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.