CoffeeScript is JS. And to be more honest and judgemental, CoffeeScript is the sweeter-but-poorly-documented Javascript.
The reason people are attempting to put javascript everywhere is because they can and because others enjoy it. And those who do enjoy JS, know what parts of JS are to be avoided at all costs. And I actually like it compared to other modern scripting languages for two reasons:(1) I don't have to worry about whether my end-user will have to worry about installing 100 dependencies to consume my code/service (2) I can choose how robust my setup is (Closure Compiler) or how sweet (CoffeeScript), and spend time sharing my setup with others who like the language instead of using proverbial sarcasm on topics about languages that I don't want to use.
But the one-page manual of coffeescript is far more useful to users than those looong specifications. No document about the syntax is better than the annotated source of the parser. And you can find specifications about all kinds of javascript runtimes elsewhere, they document the coffeescript runtime too.
Language specifications are important for interoperability. They are very useful for people who write tools like smart IDEs or linters. They are also interesting for people who want to create their own VM or compiler. There are various JavaScript and Java VMs. There are also various C and C++ compilers.
But there are also users who read them if they think that some particular behavior is puzzling. Then they check the spec to see if this stuff really is supposed to happen or if this is something which wasn't properly specified.
For example, there was a 50:50 split when it came to the behavior of SVG masking. As it turned out, that part of the spec was just confusingly written and the compliant behavior was actually really silly. The spec was changed and now every browser does the same intuitive thing.
Without this "central authority" there wouldn't have been a way to get this fixed.
Dart is another interesting example. They had a specification since the beginning and every part of the ecosystem follows it. This way, different teams (and even different companies) can create all kinds of tools which all have the same precise understanding of the language. Naturally, this also helps with identifying spec issues.
Without a specification, you have to reverse-engineer the behavior and you might end up being forced to replicate some really nasty crap. Some of JavaScript's warts were set in stone this way.
Comments
CoffeeScript is JS. And to be more honest and judgemental, CoffeeScript is the sweeter-but-poorly-documented Javascript.
The reason people are attempting to put javascript everywhere is because they can and because others enjoy it. And those who do enjoy JS, know what parts of JS are to be avoided at all costs. And I actually like it compared to other modern scripting languages for two reasons:(1) I don't have to worry about whether my end-user will have to worry about installing 100 dependencies to consume my code/service (2) I can choose how robust my setup is (Closure Compiler) or how sweet (CoffeeScript), and spend time sharing my setup with others who like the language instead of using proverbial sarcasm on topics about languages that I don't want to use.
What do you mean by "CoffeScript is JS"? CoffeeScript is not JavaScript. CoffeeScript compiles to JavaScript.
I suggest that you refer to the CoffeeScript home page: http://coffeescript.org/
It very clearly states, 'The golden rule of CoffeeScript is: "It's just JavaScript".'
what?
There still isn't any language specification, is there?
JavaScript, TypeScript, and Dart have one.
But the one-page manual of coffeescript is far more useful to users than those looong specifications. No document about the syntax is better than the annotated source of the parser. And you can find specifications about all kinds of javascript runtimes elsewhere, they document the coffeescript runtime too.
Language specifications are important for interoperability. They are very useful for people who write tools like smart IDEs or linters. They are also interesting for people who want to create their own VM or compiler. There are various JavaScript and Java VMs. There are also various C and C++ compilers.
But there are also users who read them if they think that some particular behavior is puzzling. Then they check the spec to see if this stuff really is supposed to happen or if this is something which wasn't properly specified.
For example, there was a 50:50 split when it came to the behavior of SVG masking. As it turned out, that part of the spec was just confusingly written and the compliant behavior was actually really silly. The spec was changed and now every browser does the same intuitive thing.
Without this "central authority" there wouldn't have been a way to get this fixed.
Dart is another interesting example. They had a specification since the beginning and every part of the ecosystem follows it. This way, different teams (and even different companies) can create all kinds of tools which all have the same precise understanding of the language. Naturally, this also helps with identifying spec issues.
Without a specification, you have to reverse-engineer the behavior and you might end up being forced to replicate some really nasty crap. Some of JavaScript's warts were set in stone this way.
Who needs documentation when you can just pop open a REPL and copy-paste your functions to see how they compile?
People who don't know javascript.