by bemaniac on 4/13/12, 6:53 PM with 53 comments
by debacle on 4/13/12, 7:26 PM
Proceeds to list example that isn't valid JavaScript.
I have no fundamental objections with CoffeeScript, but I will never use it because there's nothing wrong with JavaScript that CoffeeScript improves upon.
For me, personally, it's way easier to visually scan a file that looks like this:
var helloWorld = function () {
// ...
Than this:
helloWorld ->
// ...
I don't mind if you use CoffeeScript, but don't try and force-feed me some BS about concise syntax, make broad generalizations (complex CoffeeScript is harder to debug than JavaScript), or attack someone as a 'whiner' because they said "It's nice, but not my cup of tea."
My thought process:
1. In order to debug CoffeeScript, I will need to know JavaScript.
2. If I run into a tricky problem, not only will I need to know JavaScript but I'll also need to know the CoffeeScript compiler's internals.
3. If I run into a really tricky problem, or if I need some sort of optimization, I might have to use JavaScript anyway.
4. JavaScript is actually quite a nice language to program in.
5. All of the libraries I will be using will be written in JavaScript.
6. wu.js ain't nuthin' ta fuck wit. [1]
Therefore, I'll keep using JavaScript. YMMV.
[1] wu.js is actually quite a killer library: http://fitzgen.github.com/wu.js/
by Zikes on 4/13/12, 8:12 PM
Example: I see a post on HN or in one of my RSS subscriptions about a great new JS library or plugin, only to click through and see a page full of CoffeeScript examples, and the source code is written in CoffeeScript as well. This is not JavaScript. I will not learn CoffeeScript just to decipher your plugin or library and integrate it into my JavaScript project. And no amount of forceful whining on your part will convince me that it's so readable and intuitive and minimal that there is no significant learning curve there.
by dustingetz on 4/13/12, 8:47 PM
posts on coffeescript (and all posts about software) need to be taken in context. This post's context, it seems, is the type of problem where your pain points are, it seems, "javascript: the bad parts". Coffeescript is pretty great at cleaning up the bad parts and if that's your pain point on a daily basis then coffeescript is probably great for your team.
there are other classes of problems where your pain points are different - e.g. layers upon layers of inheritance hierarchies, complexity on top of complexity, bringing feature development pace to a crawl. Teams where all of the grizzled engineers know javascript cold, know the idioms and thus are rarely bit by "javascript: the bad parts". Switching from javascript to coffeescript provides at most a small, incremental improvement to this class of problems. These are the teams that are laughing at the OP. These teams are also a hell of a lot more interested in ClojureScript, because it brings with it a whole new toolbox of idioms to solve problems of complexity.
i think you one could take all the coffeescript blog posts, and sort them into buckets of "loves coffeescript" and "just doesn't care", and these buckets align perfectly with the two categories of problem i described.
Saying "at Posterous, they use it but don’t have any real JavaScript engineers" is ad hominem and uncalled for, but if you squint past his tone, he's saying: there are different kinds of software, and some problems are harder than others, and it ain't one tool fits all.
by pestaa on 4/13/12, 7:13 PM
for own key, value in hash
I also observed that using longer, more descriptive variable and function names, the difference between Coffee and compiled JS is definitely not an issue in debugging sessions. I'd say there is not a context switch even.
It feels like thinking in JavaScript and writing in a new dialect.
by gavinlynch on 4/13/12, 8:22 PM
I don't use CoffeeScript, because Javascript suits me just fine. But I also don't know many developers that slam it or recall an abundance of anti-CoffeeScript articles... For whatever it's worth (shrugs)
by friggeri on 4/13/12, 9:59 PM
Basically, I do have more of a problems with libraries which add layers of indirection (eg using _.each) at eval time when it could be done on CS at compile time.
So, once again, CS is JS, written a little differently and with some nice bonuses.
by pjenvey on 4/13/12, 7:41 PM
by mkmcdonald on 4/13/12, 7:53 PM
Be sure not to whine, though, when the abstraction leaks and your code breaks.
by latchkey on 4/13/12, 7:26 PM
by gfodor on 4/13/12, 7:43 PM
by ilaksh on 4/13/12, 10:38 PM
People generally are motivated by feelings and the rationalizations come after. For awhile I felt like I did not want to learn CoffeeScript and that it was silly and annoying that people wanted me to waste time learning it. Honestly what really started to change my mind was that I needed to alter PDFKit, and I had to learn a little bit of CoffeeScript in order to do that. I think that the need to learn it came first and then later the rationalizations for why it was a good choice came after.
Another real issue that is below the surface but not mentioned while people are discussing the actual pros and cons of CoffeeScript: is JavaScript a good language, or is it fundamentally flawed somehow?
A professional JavaScript programmer's identity will often be tied in to some degree with his general JavaScript associations (the same way someone who races Formula 1 cars would identify with that type of car and might be offended if someone started attacking the body shape of those cars), and so to make a significant investment in learning CoffeeScript implies fundamental issues with JavaScript and may therefore be an attack on that person's identity. Obviously this wouldn't be a conscious thought process but the subconscious associations are often there.
Whatever is making people choose to learn CoffeeScript or not to learn it, its not really a rational process usually. Its more like a religious battle.
I think that the amount of time you have invested in JavaScript, how well you really know it, to what degree you have come to terms with/got over those pain points that CoffeeScript helps with, how much you identify with JavaScript versus other technologies, whether you actually have a specific need to learn CoffeeScript (i.e. for altering a library or reading a coworker's code), all of those things are going to add up subconsciously in a sort of vector for or against CoffeeScript that is pretty much an emotion which will motivate different rationalizations about specifics.
So in cases where that subconscious equation just isn't adding up in CoffeeScript's favor people will find all sorts of (often tangential) arguments against it. One thing that probably can help if you are trying to push CoffeeScript is to repeatedly mention certain small improvements such as using -> instead of writing function() or the class and extends syntax. That would mean that they would have to learn those things just in the process of the discussion. (Of course, they may want to stab you if you mention those things too many times though.)
by meanguy on 4/13/12, 9:55 PM
The productivity issue that nobody seems to talk about: the damn compiler is slow. We're talking seconds, but it adds up. (The CSS compilers are far worse.)
I'm used to save/refresh/boom! when coding HTML. Now it's save, contemplate what the hell could possibly take so long, stare sadly at the compile output window, tab, reload, oops, reload again.
by rikthevik on 4/13/12, 9:26 PM
by pascalr on 4/13/12, 8:58 PM
by CCs on 4/13/12, 8:57 PM
If you like Ruby, check out CoffeeScript.
If you don't now there's Google Dart. The IDE is pretty nice.
None of the above? Closure Compiler, jshint etc. are your friends.
Edit: a good article about "verbal vs visual" programming languages: http://ryanflorence.com/2011/2012/case-against-coffeescript/
by njharman on 4/13/12, 10:48 PM
Also the title is total bull dooty, instead of saying what the title implies; "CS, it's for some, not for others. Shut up already." Or better yet not posting this crappy blog in first place. OA retreads the same horse beatings everyone else has ad nauseum.
by geuis on 4/13/12, 10:41 PM
The guys that I was working with were way more brilliant than I am. Guys that have machine learning books on their desks for lunchtime and are doing some amazing work that is going to benefit hundreds of millions of people around the world.
To reference this quote from the article: "Any respectable CoffeeScript engineer should have a strong knowledge of JavaScript".
That, frankly, is not true.
One of the reasons I was brought on was to work on some javascript-heavy stuff. I was a newbie to coffeescript beforehand, so to hit deadlines wrote everything in vanilla js to save time and get work done. The guys on the team are very smart, but not really on top of the javascript game. So in this case, coffeescript was definitely being used because it was easier for them as traditional programmers.
Earlier this week, I spent a couple days and finally went through and ported everything over to CS.
In my experience of having manually written a complicated client-side app in js, then manually ported it to coffeescript, I really just don't like CS.
I'm used to Python. Indentation there is natural. Its idiomatic to what Python is. But its not in javascript. Granted, indentation should always be used in js for readability, but brackets really are needed to denote code blocks.
Another complaint I have against CS is that it tries to do so much stuff "as if by magic" that I was never 100% what my code was going to output. I just find:
abc (arg,arg2) ->
I'm probably old school, but when I write code I need to know explicitly what it will do. I know what 'this' will refer to based on how I write. Same for closures.
Lots of times, my original code was just as concise as the coffeescript version, and a hell of a lot more concise than what CS rendered out.
So everyone has their opinions, likes and dislikes. For me, I'm gonna stick with native javascript for the time being.
by robwgibbons on 4/13/12, 9:34 PM