Why I Don't Use CoffeeScript(oscargodson.com)
oscargodson.com
Why I Don't Use CoffeeScript
http://oscargodson.com/posts/why-i-dont-use-coffeescript.html
1 comments
Here is another post about coffeescript from the author http://oscargodson.com/posts/writing-eloquent-javascript-wit... that pretends javascript best practices can be elegant enough that you don't need coffeescript.
Best practices are nice, but it's even nicer when they're enforced by the language so you don't have to see anyone not using them. So you don't have to read books and search for tutorials on how to do basic stuff like inheritance and choose from a zillion library options. Using coffescript you can at least learn the top best practices in one place.
If you're using prototypal inheritance to do the equivalent of classical inheritance, it would be nice to just say what you mean - class and super. The JS language committee seems to hold this viewpoint, say what you mean with keywords, instead of low level blah.prototype, blah.prototype.call(this). The multitude of libraries handling this are inconsistent. If you read Crockford, you might choose the style where everything private is in a closure, you're not using prototype and taking a performance hit. Then if you do need performance, if you have hundreds of instances, Crockford just screwed you and refactoring should make you bitter.
Jeremy's own underscore has _.extend which is the cleanest, but to control the wild west JS out there, the language should enforce one true way.
Nobody wants to know that ugly low level detail of blah.call(this). I can't think of one example of JS code not using the equivalent of classical inheritance. All these arguments against CoffeeScript seem silly when the official language committee is adopting bits and pieces of it where they can. If they could adopt the whole thing, they probably would.
CoffeeScript's real problem is debugging. No one complains much about it, but it would be smoother to see bugs in CS instead of the generated JS.
Best practices are nice, but it's even nicer when they're enforced by the language so you don't have to see anyone not using them. So you don't have to read books and search for tutorials on how to do basic stuff like inheritance and choose from a zillion library options. Using coffescript you can at least learn the top best practices in one place.
If you're using prototypal inheritance to do the equivalent of classical inheritance, it would be nice to just say what you mean - class and super. The JS language committee seems to hold this viewpoint, say what you mean with keywords, instead of low level blah.prototype, blah.prototype.call(this). The multitude of libraries handling this are inconsistent. If you read Crockford, you might choose the style where everything private is in a closure, you're not using prototype and taking a performance hit. Then if you do need performance, if you have hundreds of instances, Crockford just screwed you and refactoring should make you bitter.
Jeremy's own underscore has _.extend which is the cleanest, but to control the wild west JS out there, the language should enforce one true way.
Nobody wants to know that ugly low level detail of blah.call(this). I can't think of one example of JS code not using the equivalent of classical inheritance. All these arguments against CoffeeScript seem silly when the official language committee is adopting bits and pieces of it where they can. If they could adopt the whole thing, they probably would.
CoffeeScript's real problem is debugging. No one complains much about it, but it would be smoother to see bugs in CS instead of the generated JS.
It's very clear that you have not used coffeescript much, you just checked it out, glossed over a few features, tried to write something, were doing poorly because you didn't know it well, and said "well fuck it, I'm going to write an angry rant about this".
Let's break your post down to sections. Syntax first. Most people like the syntax. It's much easier to read for me and other developers, personally. If you don't like it, nobody's forcing you to use it.
Your analysis of 'wart removal' is misinformed too. Coffeescript is essentially a collection of helper functions for things we commonly need to do (as are many programming languages - for example, ruby, which a nicer syntax and a collection of helpers built on c). You missed all of them except for one. If the whole language was one helper function, you'd be right. But it's not. Read up before you rant.
I don't know what convinced you that javascript is different from every single other programming language enough such that classes are not useful, or why you again propose that classes are the only thing coffeescript contains. They are one helper function in a collection, and they are very helpful. I have used them a number of times in production code for large companies and it's saved me loads of time and made the code a lot cleaner.
If everyone had your philosophy, we would all be writing in assembly language and/or c. Hell, why do we need a whole different language to make the syntax nicer and contain helpers for common tasks? We could always just write a function for it, right?
It's a weird perspective coming from a language you understand to an abstraction that you don't, and that's why there are so many posts that say this exact same thing. But you have to keep at it until you understand it better, then the speed boosts and convenience will be worth every second.