One thing though, is that the standard classes are just not up to the job without a lot of stuff tacked on. Eg: the function binding problem pushes people to use class properties, which aren't yet a standard, and then they hit walls with tools that don't support them (eg: I dunno if it's still the case, but for a while class properties caused issues with Flow).

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.

There was not such thing like ES3 module syntax. This is just programming pattern many people used: https://addyosmani.com/resources/essentialjsdesignpatterns/b...

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...

Classes don't do anything about the dynamic nature of JavaScript. They spit out basically the same constructor that everybody was using for pseudo-classes in ES5. You can still do crazy things like manipulate the prototype outside the class, tack extra stuff onto instances after they've been instantiated and so on...

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.

Yeah. You're right that even classes allow for great amount of dynamics. I've seen classes with decorator annotation and decorator can change classes as much as it wants. I've also seen patterns like:

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).

It's not syntax, I know. It's just how it's referred to in the doc and was faster to type. Read between the lines.

I'm all for better solutions for functional components. I hope we go down that road instead of locking in the decision to rely on `class` with things like class decorators and so on.

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.