Define good in this context. I'm inclined to say that if it doesn't have cross-browser bugs and it's fast, then it's good. The output being readable to human programmers probably shouldn't be a goal when JS is being used as a compiler target.
Agreed in principle, but readability still matters a great deal for debugging. There's vastly more browser tool support for JS (e.g. Firebug) than for languages targeting JS. These tools get harder to take advantage of as one's compiled JS gets less readable.
Sometimes I think the holy grail for what we do would be a Slime-like REPL in the web browser that speaks Parenscript, maps to source code, and had full debugging support. In the meantime, though, things like Firebug are indispensable.
I'd define good as it takes full advantage of the javascript language and produces & can be used to create structures optimised for javascript, not the language it was written in.
This is why I think it's better to reduce the context-switch between server and browser and not eliminate it. There's going to be a context-switch there no matter what you do, so there's no sense in paying such high prices to try to eliminate it.
