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.
I agree the other issue with someone like me using CoffeeScript is that first I'd want to really understand Javascript otherwise I'd never be able to trust that I could fix any bugs I ran across, it's another layer of abstraction I essentially don't need.
I dislike using coffeescript mainly because the language is too flexible. Being able to optionally omit a ton of syntax has led to some annoying problems that aren't obvious at first glance. This ambiguity is exacerbated by the way javascript is typically used (chained methods, nested lambdas, etc).
The other gripe I have is that debugging it is a pain in the ass since errors that come back reference the javascript code, not the coffeescript. Apparently this is a problem being worked on but it's still irritating.
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 have pretty much moved to using CoffeeScript exclusively over JavaScript. One of the minor complaints I have (overall, it is magnificent) is that the looseness of the syntax sometimes leads me to doing a kind of guess-and-check style of programming where I write something, then try to compile it to see if it did what I expected. An example of this is when calling a function, you need a comment to continue the function arguments onto the next line, unless the argument on the next line is an object literal.
The only real problem is that debugging with CoffeeScript adds an extra layer of complexity. I know that this is more or less inevitable, but it is really the only major pain point that I encounter on a day-to-day basis.
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 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.
I use both javascript and coffeescript extensively and regularly, and I just don't understand how this ever causes real problems to anyone - unless you're writing 5000 line long spaghetti code coffeescript files with ambiguous variable names, in which case lexical scoping is the least of your worries.
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.
What's with the insta-downvotes whenever someone mentions Coffeescript's debugging issues? I am not an active Coffeescript developer, but I thought that debugging line-by-line was prohibitively difficult, especially in the browser. Has this changed? If not, why the animosity?
As someone who is doing more and more coffeescript this is awesome. However debugging in the console seemed like the only way I was going to stay fresh in native javascript!
It's not like CoffeeScript really forces you to use classes. It's not an object-oriented language. It's just Javascript with a ruby-like syntax. Even the class keyword is just some monkey-patching (and a commonly-used method of doing it) of the prototype system to support some pseudo-inheritance.
100% of what you learn in CoffeeScript is applicable to Javascript, and viceversa. The real pain, is like you said, debugging applications. I can't just write coffeescript into the console, not even a little`console.log`which is infinitely nicer without the parentheses.
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.
Nice to see this, as it seems to address one of the most common concerns about using CoffeeScript. I have to wonder, though, how many minds will it really change? Maybe a lot, but I'm wondering how this will pan out. I'm guessing some people provide line matching for debugging as a concern but will continue to move the goal posts as this and other barriers are removed.
I feel like that's a pattern I see around here, which is odd because if you'd rather just use javascript that seems totally reasonable without an excuse.
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.
reply