Another pain is (was?) debugging. This might have changed since but back when I tried and rejected using it. But back then, if you had an error at line X it would report the (compiled) JavaScript line rather than the CoffeeScript line - meaning you'd need to figure out which CS code generated what line of JS code in order to hunt down and fix issues.
While this is an issue, it's a pretty minor one from my own (limited) experience using CoffeeScript. It's extremely easy to relate the JS errors to your CS code, since the JS generated is so readable. It's just a little tedious to have to take a look at the generated JS, but not that bad really. Try it out for some node.js stuff and see for yourself.
Also, the issue is being fixed for Chrome/Firefox, which is good enough for dev work.
I don't the fact that CoffeeScript can't be debugged until browsers support it. JavaScript errors are bad enough, but until I can get a CoffeeScript source line number in an error I simply refuse.
Too bad you "already moved on". I coded in CoffeeScript in Gedit for a few weeks now. A CS compile error in the version I have does show the line number... and if it compiles and I have a runtime JS error (also with line-number in NodeJS) then opening the compiled JS file in my ./project/_js folder and jumping to the line is also not a Big Deal at all.
Since the compiled JS is just-the-code-I-wrote-myself only in a slightly more verbose curly syntax, troubleshooting my own CS code even when compiled in JS is totally not an issue. Thankfully Coffee does not minify or otherwise obscure the code.
It's a pain, still. I don't generate js files. When something like that happens, I have to go back to command-line, type 'coffee ...coffee', open generated js file and see where the problem was.
I use coffeescript both clientside and serverside (node). Since semantically the coffeescript maps to javascript almost one-to-one, the only debugging difficulty is mapping line numbers in the error output to the location in the coffee file.
Client-side is zero problem because the chrome and firebug developer tools jump you right to the line in the JS file, and you can figure out where the error is there since the compiled coffeescript is very readable.
Server-side has a slight hassle since there's no clickable link, so the line numbers don't help much, but a quick look at the stack trace makes it pretty easy to find where in the coffeescript its referring to.
I'm not a CS lover, but I think most of your arguments are invalid. You say that you don't like CoffeeScript because it generates JavaScript code you don't understand. But do you understand what machine code will JS generate? No? Why? Maybe because you don't care... In general same thing applies here. If you need to debug generated JS, use source maps. This argument is not an excuse. Beside, CS is fairly simple in translating to/from JS. If you think it's not, try use dart2js ;)
My biggest problem is definitely the source maps. It took me forever to get them to "work" and while the stack traces are mostly correct, they're often off by a line number or two. This makes debugging ridiculously hard when the line numbers are just "close".
I know this might not sound like a big deal in the grand scheme of things, but I also don't think CoffeeScript really improves on js all that much, so the annoyances of source maps are just not worth it to me personally.
I had fun with CoffeeScript but my projects definitely had its frustrations. CS allowed me to write some pretty damn ambiguous code.
Also when working with external libraries and dependencies, I found myself resorting to trial and error figuring out the correct syntax because nearly all documentation is written in JS and not CS.
Debugging compiled code is absolutely unpleasant. Fortunately, I only have to do it rarely. From what I can tell, debugging JavaScript that was compiled from CoffeeScript is a standard practice, and I simply don't want to pursue that. It's interesting how you describe CoffeeScript as a tool rather than a language, but in my opinion it is still a very leaky abstraction.
As I mentioned, I look forward to revisiting it when a standard toolset has matured.
I'd hardly characterise coffeescript generated js as difficult to debug (even the OO flavoured bits). My experience and that of most others I've seen online is that the mapping from the js that you debug back to the coffeescript that generated is trivially done in your head.
Not me so much as others - it's a very common problem I've seen when debugging other people's CoffeeScript code. CoffeeScript is a bit of a different situation than other languages since with other languages, it's the norm (i.e. Ruby) - however, with JavaScript, it is not something inherent in JS, so when people jump from JS to CoffeeScript, there is a disconnect.
Because most of the code runs in the browser, we were able to use the WebKit debugger. I never had any trouble matching up the compiled JS with the original CS source.
If you can't debug in CoffeeScript, you can't take it seriously. Even meta-CSS frameworks suffer from this problem when there's errors you have to back-track through a whole layer.
Coffeescript is great in theory. The problem is that when debugging stuff in the browser, you're going to be looking at Javascript in Chrome Developer Tools or Firebug. You can hopefully do an inverse mapping from generated JS to the corresponding line in Coffeescript...but that's kind of a pain, especially because it's not a line for line conversion.
Short of patching Chrome Dev Tools to support stepping through Coffeescript itself, not sure how to fix that.
Hi Jeremy. Dmitry's argument you mention, for instance, is questionable and not very popular. I think I can't point to what you're going against (vs "old style" coding), maybe some examples in the post could help.
On CS: you are already using a compile step that dynamically changes code, how more complex can it get? I have thousands of lines of CS in production and it never caused any more problems than JS. If you think of CoffeeScript as a tool to write Javascript, not a separate language, things go much smoother (you want to debug the javascript output, not the cs source).
MVC Web Framework for NodeJS written in CoffeeScript.
This is an open source project that has just been released, and from my experience developing it, here are my conclusions:
I believe some people are comfortable coding one way, and others are comfortable coding another. Anyways, everybody uses what works. At the end, the productivity you've got and the time you save is all that matters.
Regarding the issue with the stack traces and CoffeeScript, you're right, line numbers are not accurate, but if you know where the problem is and you'll know how to debug it, on the spot.
I was not attracted to CoffeeScript myself when I first saw it, but after having a closer look, I finally realized it is a great tool to use when applicable. Then I decided to migrate the whole code to CS.
From my experience, it's all about your coding workflow. Knowing CoffeeScript syntax and how it translates to JavaScript. I use CoffeeScript's simplicity to implement complicated concepts that would require some ellaboration when it comes to syntax.
That's a fair point, and there are a few things I would point out in no particular order:
The first is that CoffeeScript is ultimately a sort of dialect of Javascript. CS and JS can interact with eachother seamlessly, so as mentioned in the OP article there's no need to switch over to CS for everything and/or all at once.
Another important thing is that where possible CS tries to map relatively directly to JS, so for experienced JS developers they will recognize CS as a series of shortcuts which map to idioms they use constantly.
If you are familiar with JS, doing a few small projects in CS should get you pretty familiar with it.
CS is obviously somewhat immature, but I think it's reached the point where it can be considered for "serious work". I've found the tooling is pretty decent: coffee is slick with commands like --watch to recompile on changes, and coffee-mode for emacs is nice. There's also CS mode for vim, textmate, gedit, + more.
Honestly the main hurdle is potential debugging problems, but I haven't found that to be too difficult either. Being mindful of how CS transforms your code, and strategic debugging code make the process for me not much different from debugging regular JS.
So I'd say at this point I don't think CS presents hurdles which are terribly difficult to overcome.
Yes, until there are proper stack traces in CoffeeScript, it's very hard for me to adopt it for anything. A project I work on has a small amount of CoffeeScript, and debugging problems in that component is the hardest part of the whole project.
reply