The desire to compile into JavaScript is not what's being criticized here; it's the "blah is to JS as C is to Assembly" analogy: "That’s not to say that any of these systems are bad, just that the “blah is to JS as C is to Assembly” analogy is wildly wrongheaded."
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).
A compiler that did an 'identity compilation' on a strict subset of real JavaScript, and rejected any problematic or confusing constructs would have value.
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.
It would. But it would be a linter, not a compiler.
It would only be a linter if it weren't a compiler. If it compiles language X to language X, it's a compiler. Because it compiles. Rule of thumb: if it compiles, it's a compiler, not a linter. Simple. Like ducks.
Correct. That doesn't make CoffeeScript->JavaScript like C->assembly. In fact, it supports the idea that it's like C++->C. C++ provides stronger type checking than C and provides different syntax for things like constructors, heap allocation, etc.
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).