But nevermind me, React is a great tool, and this is a very nice and needed project!
Since ES6+ is now the actual Javascript language standard, it makes sense for React to move away from their homegrown class definition approach, and build on top of the approach that is now standardized in the language. The React community has already eagerly adopted ES6, and while React.createClass() isn't going to be deleted any time soon, it's time to start encouraging people to move away from using it.
Either way, though, React's API _does_ depend on having something "class"-like available.
We don't like classes, but we don't like "pseudo classes" (createClass) even more. Better the devil that's standardized.
We already offer a way to create stateless components with just functions. We will keep exploring that space and eventually might have a class-less solution we like that satisfies all our use cases.
createClass might not have been the answer, but on top of stateless component functions, things like the good old ES3 module syntax honestly would be more flexible/powerful (giving you a closure to do things like private members, etc)
Instead we have people using babel with all sorts of plugins, tacking on 3rd party decorators and utilities, and a bunch of other cruft just to mimic features JavaScript have had from the beginning. And then (talking out of my rear here), it possibly put pressure on the TC39 to waste time discussing features we seriously don't need.
It was a great idea back then, but that was never syntax. This and similar patterns rely on the fact JavaScript is very dynamic and flexible language and enables creating closures and creating objects dynamically.
These are very powerful features of language, but they're dynamic, which is unfortunate because to know what exactly is happening in this code you have to run it. for IDEs/editors it's hard to look at your code and guess "well, it's module pattern, I see! You mean this and that". Tooling operates usually on static analysis of syntax. They use JS parsers to parse code to AST(Abstract Syntax Tree).
And here's the thing: ES6 classes are visible in AST, there is something called ClassDeclaration. This means that every programmer can install some ES6 parser from NPM and analyse ES6 classes. This means that there will be better linting, better autocompletion etc.
On the other hand - JavaScript parsers don't understand module pattern or other homegrown idioms. It's harder to analyse them statically. Especially if they rely on dynamic aspects on language. ES6 parser doesn't run your code. That's why ES6 classes, because they're static, are better for parsers, and consequently, enable better tooling, IDE support, autocomplete etc.
Situation maybe were a little bit different if we had tooling for some sort of dynamic analysis (if tools were running code in sandbox and gathered data in runtime, not from syntax etc.).
But because currently most of tooling is syntax based I think ES6 classes (and e.g. ES6 modules) are just better for analysis.
Well... to contradict what I said early I must say that actually it's often possible to analyse such things like module pattern, createClass etc. But:
1. not always with 100% certainty of the result
2. there are too many idioms. If every framework, every team and every programmer has own way of writing JS, own module syntax, own class syntax etc. it's very hard to support all the frameworks and provide tooling for all people...
In other words, classes in JavaScript are a poor substitute for static types, and should not be used that way. That's why a lot of React people are using flow, and a lot of Angular people are using TypeScript.
class Foo {... }
// then, after class definition
Foo.A = X;
Foo.B = Y;
etc.
So... it seems that every try to make JS more static is doomed to fail... Because people will still use it in dynamic way...
Not sure how to solve this problem. Maybe we really need tooling that would run code in sandbox instead of analysing it via AST (but how to sandbox e.g. NodeJS code that interacts with file system or MongoDB? Mocking everything? Or make complete dev environments/virtual machines with NodeJS code running in it?)
(Maybe I overengineer solution ideas in my head, but I think proper tooling support is important for modern web development. It hurts me when I have to learn new large JS codebase and IDE is not helping)
> That's why a lot of React people are using flow, and a lot of Angular people are using TypeScript.
I don't like the idea of defining types for everything but maybe it's the solution (I'm not sure because I have too little experience with TypeScript to judge).
Several React libraries are already doing that. In spite of all our warnings, people are trying to extend classes for React views, and use `class` in the rest of their code, as well, moving it into the state layer, and modeling their business domains with them instead of using pure functions and Redux.
`class` affords `extends` like balls afford throwing and chairs afford sitting. When you ignore the power of suggestion that comes with the tool affordances, you point users in the direction of trouble.
Sadly, scaling developer education is a lot harder than it seems from inside our ivory towers, surrounded by smart colleagues well-versed in programming wisdom and design patterns.
React really should have gone from createClass to <insert better design pattern that doesn't rely on the class keyword here>. It already supports the module pattern. They easily could have expanded on that.
React.createClass (and angular.directive or similar guerilla solutions) are harder to analyse statically. And without static analysis you won't have proper tooling (IDE autocompletion, "go to definition" feature, dependency graphs, linting etc.).
So. Welcome language standards or goodbye static analysis. I'm seriously happy that both React and Angular go into ES6 classes and resign from guerilla coding...