The way that it creates closures for enclosing variables for packages is idiomatic and best practice. The way that it handles looping is idiomatic for avoiding certain kinds of common pitfalls. The way that it creates "that" variables for temporarily holding on to "this" for a while is idiomatic. There are a bunch of things like that that it does automatically.

> The way that it handles looping is idiomatic for avoiding certain kinds of common pitfalls.

Unless you're using native (or shim'd) map and similar constructs instead.

(Or, for that matter, if you're otherwise used to writing code where block scope isn't the rule.)

> The way that it creates "that" variables for temporarily holding on to "this" for a while is idiomatic.

Unless you're using bind instead.

I suppose it's true enough that people can in fact learn good things from the CS compiler output. But the JS that CS writes is not necessarily the JS an experienced dev would write or would have to write to achieve the same goals -- even taking into account the principles behind "best practices."

The same can be said for any higher level language being compiled into any lower level language or machine code. It's similarly true that an optimized C compiler won't always write the best code in a best practice way.

Also true: no matter how good something is, there'll always be someone eager to put it down.

> an optimized C compiler won't always write the best code in a best practice way.

Aaand, therefore, you might not suggest to people that a good way to learn to write good asm would be to study the output of a C compiler. However educational that experience might be.

> Also true: no matter how good something is, there'll always be someone eager to put it down.

Not sure where this is coming from unless you think we're having a conversation about the merits of a language, instead of the merits of learning another language from the output of a transpiler.