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