Trying to treat JavaScript as assembly is silly because it doesn't vary too much between browsers- it is palatable to write, by hand, cross-browser JS programs, whereas it is literally impossible to do so in assembly because different assembly languages, as human-readable machine code, have virtually nothing in common at that level.
Treating JavaScript as C is the reality, because JavaScript is what gets run in different browsers (the analogy to compiling C to different platforms).
CoffeeScript is more like C++ than C because the language it's replacing/augmenting/etc. is very similar semantics-wise- it's just trying to make the same basic idea nicer to work with. The 10x difference thing is pointing out that C->assembly is a massive translation, whereas C++->C, while still a worthwhile difference, is much smaller.
Again, this is not a value judgement of CoffeeScript or GWT or anything. It's pointing out a flawed analogy. This is useful because when we think of JS as C rather than Assembly, it becomes clear that it shouldn't be the only option. It would be an improvement if, in the future, more mature language compilers could bypass JS to some form of bytecode (be it browser-specific, which would be a much bigger problem in the browser world, or a standardized one like the JVM does for the non-browser world... this is where the analogy breaks down a little).
CoffeeScript goes further than that and provides different syntax.
One of the things that complicates C++ is the requirement for source code compatibility with C. This necessarily requires preservation of confusing quirks.
CoffeeScript is not source code compatible with JavaScript.
A compiler that did an 'identity compilation' on a strict
subset of real JavaScript, and rejected any problematic
or confusing constructs would have value.
This is important because C++ is damaged by the attempts to provide C source compatibility.
Mr. Schlueter writes "you don’t compile it to target a given platform," as if this would be an advantage or a justification for existing ... when it's really quite the opposite.
I don't know when "order of magnitude difference" became a synonym for "worthwhile difference"
I didn't see Schlueter arguing either of these things, but we may have read the post differently. Both points, in my view, seemed only to illustrate that the JS-Assembly analogy is wrong, not to argue against to-JS languages.
https://twitter.com/#!/izs/status/114089739908415488
And to be extra clear, I appreciate the post, and agree with most of it.
"JavaScript is an assembly language. The JavaScript + HTML generated is like a .NET assembly. The browser can execute it, but no human should really care what's there."
JavaScript generated by CoffeeScript is very readable and thus does not exactly correspond to that concept of JS-as-Assembly.
edit: formatting
Debugging with GWT hosted mode is so ridiculously easy that readability is a non-issue.
[1] http://www.ecmascript.org/
CoffeeScript has its own optimizations and error checking, but type annotations would allow you to also leverage Google's continuing improvements to the Closure compiler.
https://code.google.com/closure/compiler/docs/js-for-compile...
Mr. Schlueter is right on -- C++ is a much more accurate comparison, and especially so because it was originally implemented as a cross-compiler into C source code (circa 1983-1990).
That said, saying that the desire to compile into JavaScript is (to paraphrase the post) pathological language-wank craziness, is a bit extreme.
I'd like to think that the reason why CoffeeScript has caught on like wildfire, when there are so many other AltJS languages out there (https://github.com/jashkenas/coffee-script/wiki/List-of-lang...) is that we're trying to take the deeply pragmatic approach.
Mr. Schlueter writes "you don’t compile it to target a given platform," as if this would be an advantage or a justification for existing ... when it's really quite the opposite. JavaScript is plagued with libraries that will only ever run on certain platforms because they opt-in to platform specific features. I can't use your simple pluralization library to turn "bit" into "bits", because it was only written to run on Node.js, and is riddled with `forEach` and `require`, or because it was only written for the browser, and hides data in the DOM.
CoffeeScript tries very hard to compile into efficient, lowest-common-denominator JavaScript (read avoid Internet Explorer bugs) because that's how your library can be used widely across devices and runtimes, while being reasonably future proof.
I don't know when "order of magnitude difference" became a synonym for "worthwhile difference", but ... how much easier does a program have to be to read and write before it becomes a worthwhile choice to make the change? 2x? 1.3x?
In any case, CoffeeScript is a little thought experiment -- not a corporate project, or a Dart-like browser takeover. If it suits your fancy, use it, and if it itches you the wrong way, by all means leave it out.