What speed and ease to you gain with it? CoffeeScript won't get you any performance; if any, less. Making obscure or verbose patterns easier to use is syntactic sugar. Part of the thing about CoffeeScript, is that there are more bad parts that it introduces than prevents. Cleaning up the class model is generally not a good thing, since JavaScript isn't designed to have true OOP principles. Things like it's expressive for loops and default arguments generate really ugly code, and shun people from using ES5 array methods like .forEach, .map, and .filter, which are a lot cleaner and more optimizable by the engine. If you're ever trying to check the existence of a variable, then you've already probably made a bad design choice; but you won't realize it because CoffeeScript encourages the pattern. Also, CoffeeScript will completely obscure the way JavaScript works to newcomers, and will confuse them and encourage them to use the syntactic sugars in place. The syntactic shortcuts were originally there to make it easier for those who really needed to use the nasty things to achieve it. Now, a CS user would use them because they're there. If you teach a ruby programmer CoffeeScript in order to introduce them to JavaScript, they're not going to be able to know the differences well enough to appreciate and understand them.

> Part of the thing about CoffeeScript, is that there are more bad parts that it introduces than prevents.

I'm not sure about that; it prevents many of JS's ugly quirks: http://arcturo.github.io/library/coffeescript/07_the_bad_par... ;)

> Cleaning up the class model is generally not a good thing, since JavaScript isn't designed to have true OOP principles.

I really don't understand this. What does "true OOP principles" mean? Objects are so central to JavaScript that it has a concise syntax for object literals. It even goes to the extent of having a dynamic "this" to let any function work as a method in an object.

It has its rough edges (like primitives), yes, but they don't make it a non "true OO" language (whatever that means) IMO.

> [...] it's expressive for loops [...] shun people from using ES5 array methods like .forEach, .map, and .filter, which are a lot cleaner and more optimizable by the engine.

Thay are cleaner in the compiled JS, but Coffee's for loops are quite clean too, and they don't require a nested closure ;)

And, although i would also like native Array#forEach et al to be faster than manual for loops, that hasn't been the case in modern JS VMs: http://jsperf.com/for-vs-foreach/75

I think you're referring to OOP in the literal, "program uses objects so it's object-oriented" sense, whereas parent is referring (more accurately, IMO) to the common, "classical" understanding of OOP as implemented in Java/Python/Ruby. When people say OOP, that is what they are referring to, and in that sense parent is correct, JavaScript is not really OOP. And in the broader JS community, heavy use of OOP is very uncommon.

> What speed and ease to you gain with it?

Speed and ease of development! Yes it is mostly syntactic sugar, where I wanted to make a point is that this "sugar" adds more to the language than sweetness for the sake of it. It exposes beautiful pattern that are cluttered in day to day javascript syntax. My final compiled javascript code is not the same I would have produced would I have coded directly in Javascript. Coffeescript also gives me a different approach to think about a problem.

> Things like it's expressive for loops and default arguments generate really ugly code, and shun people from using ES5 array methods like .forEach, .map, and .filter, which are a lot cleaner and more optimizable by the engine.

I use underscore which will delegate to .forEach et all it they exist... I really rarely use loop comprehension, though they can be very expressive if used correctly..

> CoffeeScript will completely obscure the way JavaScript works to newcomers

I disagree. I've installed the proper plugin (I'm on emacs, same is true for vim, sublime or lightTable), I am therefore two stroke away from the compiled javascript. Furthermore, I spent a decent amount of time a week in the debugger where the code is in JS. If I could have disliked this in the beginning, having two different languages whether you code or debug can seem unfamiliar, I actually love it. It keeps my Javascript sharpen and it gives a thorough understanding of exactly what's happening in my Coffeescript code. And that's exactly where I found a niche for Coffeescript. In my opinion, it is definitely not a replacement for Javascript, it is a cleaner, more expressive and easier way to write it, without any real overhead. Honestly, it took me minutes to understand and less than a day to feel comfortable and be efficient in Coffeescript. What I recommend to newcomers is to use coffeescript's syntax to to learn Javascript, by continually compiling down to JS and understanding what's happening. The JS output by CS isn't ugly at all, and that is a strong point. It is really possible to learn some great javascript idoms just by applying built-in coffeescript construct and understanding their value and working in JS

> JavaScript isn't designed to have true OOP principles

... Hmm right... ?