6 ms·
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 pr
by Zak 16y ago
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.
- msy 16y agoI'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.
- stcredzero 16y agoThis 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.
- gruseom 16y agoAgreed 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.
- sedachv 16y ago"The output being readable to human programmers probably shouldn't be a goal when JS is being used as a compiler target." Everyone says that until they have to debug the generated JavaScript in IE.