It's nice to see some critiques of CoffeeScript from an actual user, and not just speculation about why it might be bad...however some of the criticisms strike

It's nice to see some critiques of CoffeeScript from an actual user, and not just speculation about why it might be bad...however some of the criticisms strike me as the product of not understanding CoffeeScript and/or not sharing it's philosophy/principles/etc. The author seems to have not totally familiarized themselves with CoffeeScript, and seems to think it's "Ruby and JavaScript's love child" which it is decidedly not. It's totally valid to not share the philosophy, I just think it's important to judge it on those terms. > "->" wtf? why? Not liking the arrow; fair enough...personal opinion and totally valid, but I think it deserves commentary. What's wrong with "function"? Way too long and cumbersome. Maybe it's the Lisper in me but "def" is not specific enough for my tastes. I like the use of a symbols because it pops in my eyes. It also provides a nice opportunity for features like the fat arrow (=> for binding to the current context) which would be more difficult/less elegant if something like "function" was used. Also note this particular syntax has precedent in other languages. > Plus syntax highlighting goes to pot when you use the coffee way. Not really sure what the author means here. Syntax highlighting works just fine for me with CoffeeScript. I suspect they have some problems with some particular editor or feature not working correctly with CoffeeScript, but overall I haven't had any problems with it. > You'd expect this: x = true x? "Badger" : "Fish" to return badger, right? Not really. To be honest I'm not sure what this code is supposed to be. I'm guessing that the "true" is just some sort of typo/copy-paste error, in which case it's not valid CoffeeScript. (Coffescript's succinct syntax makes the ternary ? unnecessary and ? is used as the existential operator) In CoffeeScript it would be: x = if x then "Badger" else "Fish" ...which will behave exactly as you expect. The author mentions this, but says it should generate a syntax error. As written it does, if written as I suspect they meant...it doesn't but I don't know if it's entirely fair to expect a syntax error for every single nonsensical (but mostly syntactically valid) construct in a language. I think their larger point stands though; there are a lot of things in CS that don't generate a syntax error that probably should. This is mitigate by the fact that once you learn CoffeeScript you're less likely to make these sorts of errors, and that a lot of them will cause syntax or obvious errors in the generated JS. (still it would be nice to catch them ASAP) > Closure. This has caused a world of pain, given every coffee file is compiled within a closure, it takes some hacking and extra work to use modularity with ease This I can't really get behind. Wrapping everything in a closure is a sane default IMHO. If you have a lot of scripts, it's trivial to turn it off and then handle it in the build. Even with the wrapping, it doesn't strike me as had managing it...but that may just be a product of how I tend to structure my projects: There's generally a master file that creates the namespaces for the project, then any loaded modules attach to that. Others may find the auto-wrapping interfere with their structure, fair enough. > I really like Chrome's JS debugging feature... yes, you can sort of work out which line relates to which, but when you're fixing a bug this becomes more difficult. Another common criticism, and one that's generally fair. This is one that should get better with time, as support increases. In the mean-time I find that this issue is mostly problematic for people who aren't totally familiar with CoffeeScript yet. After you become comfortable with it, it sort of fades into the background. As you write the CS you know what JS it will generate. Everything maps pretty closely. For me personally, I find that the types of things I am debugging have little to do with the CS/JS translation. They're usually logic errors, problems with some API I'm using, etc. In those cases I don't need to muck around with the translated code...I just add some logging/tests to my CoffeeScript or step through the JS and watch local variables. If I need to find out that I misspelled the name of some API call... I don't really need to figure out what JS corresponds to what CS. I just see what the exception says, realize the problem, and change the CS. Anyway, this sort of feedback from the trenches is invaluable. It's not my intention to try and write off these criticisms. CoffeeScript definitely has issues and we need discussion about them to fix them. I just thought I'd offer some counterpoint in case others who have no experience with CoffeeScript happen to read this, so they can hear some from someone who has been using CoffeeScript a lot and had a mostly positive experience.