Hacker News Reader

Comment by jlongster | Hacker News Reader

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.

View on HN

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

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/.

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.

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.

Reply on news.ycombinator.com