Both CoffeeScript and ClojureScript “transpile” into JavaScript.
ClojureScript does come with its own standard library just as you say. However, I don’t know if that’s CoffeeScript’s “biggest advantage,” althout it’s related. The way I would put it is that while the author claims that ClojureScript is “OO, the Good Parts,” CoffeeScript is JavaScript, The Good Parts.
Meaning, CoffeeScript programming is still very close in mental model to JavaScript programming. This is why it doesn’t require its own library, you are writing JavaScript and can use any abstraction or library you like.
Its syntax for OO programming is really sugar for using JavaScript’s built-in semantics in a legible way. Locally namespaced extensions are a wonderful idea, but they aren’t really JavaScript. For better or for worse, CoffeeScript eschews such deep departures from JavaScript.
That’s a disadvantage when you want something that’s a big improvement, but it’s an advantage when you are familiar with JavaScript and just want to get things done.
I don't have any evidence to back this up, but I'm guessing that the only reason CoffeeScript embraces Javascript is for debugging. It firmly places itself as an "improved Javascript" which compiles out to "normal" Javascript -- so that you can sanely debug it, and sanely use the language.
ClojureScript doesn't have this problem. It's normal Clojure code that (I assume) can be debugged like normal Clojure.
EDIT: I haven't debugged ClojureScript yet, but I assume you can debug it like normal Clojure code.
I'm guessing that the only reason CoffeeScript embraces Javascript is for debugging.
I wonder whether CoffeeScript embraces JavaScript is because its author, jashkenas, likes JavaScript’s semantics. he has created several extremely useful JavaScript tools and has described JavaScript using words like “gorgeous."
I'd call this interpretation indisputable unless I saw jashkenas himself disputing it. In many ways, CoffeeScript is just JavaScript, minus a whole ton of redundant key-tapping.
I have yet to find myself in a situation after 15 years of programming when the primary problem was "redundant key-tapping".
The more languages I learn, the less I care about syntax and the more I care about being able to express solutions to problems. In that respect, then, CoffeeScript has been no help to me whatsoever, since semantically, it's no different than JavaScript.
Well ... sort of. The Clojure debugging story is still only OK and under development. Any ClojureScript debugging story really should integrate with existing tools - I have some ideas about that brewing here: http://dev.clojure.org/display/design/ClojureScript+Debugger
We've written a Parenscript/JS debugger that runs in Emacs and interacts with V8 via Node.js as an Emacs subprocess. We started off using the JSON debugging protocol you mention on that linked page, but had to abandon it because it insisted on printing large arrays in their entirety, which hangs V8 if you ever encounter a large array as a local variable. In the end, we found V8's in-process debugging API much easier to work with. The JSON protocol is just a (bloated) wrapper around that, which gives less control and doesn't work particularly well. (I'm not aware of any systems out there that actually use it.) Of course, if you drop the JSON wrapper, you have to write your own server-side code and pass your own messages to the client. But in return, you have fewer hoops to jump through, and it felt to me like less overall work to make a good debugging client this way. The in-process API isn't documented but it isn't hard to figure out from the V8 source.
Ah, I see. I'd probably take the route of allowing ClojureScript to be run as normal Clojure, but I guess the problem is that you don't have access to the browser environment. Debugging browser-based apps can be tricky because of that.
Actually, to a large extent you can have access to the browser environment. See e.g. the ClojureScript One video and guide: http://www.clojurescriptone.com/.
Another option is source mapping, allowing the browser's tools to map from the JavaScript that is running over to the original source files (with line and column mapping). Some support for that has landed in WebKit, and we have patches for some integration in Firefox (remarkably enough with the same file format!)
> I'm guessing that the only reason CoffeeScript embraces Javascript is for debugging.
The other reason is to avoid code bloat. Adding your own runtime library adds a lot of (generated) JS that has to be pushed down to the client.
This is something we're constantly fending with in Dart. Dart does have a runtime library (including a different DOM API!) and managing that without generating enormous amounts of JS is tricky. We're getting pretty good at dead code stripping, but doing that isn't easy. Without type annotations, it would be even harder.
I thought that this would be an advantage as well but what ended up happening is that I found myself spending a lot of time in the generated javascript. Either I was checking the generated javascript too often to see if it mapped to the coffescript I wrote, or I'm fixing bugs in the generated javascript forgetting that I was using coffescript.
But the great disadvantage of those compilers (CoffeeScript and ClojureScript) is that the generated code doesn't matches up with the lines of the source code so its debugging is much more difficult.
Knowing no javascript, I didn't have a hard time debugging my first try at compiled-to-js clojurescript. It's pretty easy to see the naming correlations and conventions used by the compiler in the generated source.
