A Case Against Using CoffeeScript

There has always been a <i>strong</i> "case against using CoffeeScript", from day one. Like any other new language, it's a new, strange thing to learn, there's new tools and a new compiler, and your team doesn't already know it.<p>In addition, CoffeeScript has it's own distinct burden to bear: the entire point is to compile (in as straightforward a fashion as we can manage) into JavaScript. That you're debugging JavaScript when you run CoffeeScript in production should be no surprise -- that's the point. But it's also quite a large hurdle to jump.<p>What's interesting about CoffeeScript is that despite there being a strong case against using it -- and I try to make the same case in my workplace -- people still find it useful enough, and transparent enough, to use it regardless.<p>As of this morning, CoffeeScript is the 13th most popular language on GitHub, and the second most popular module in npm, after Underscore. All of the top ten languages on GitHub date from the mid-1990s or earlier.<p><a href="https://github.com/languages/" rel="nofollow">https://github.com/languages/</a> <a href="http://search.npmjs.org/" rel="nofollow">http://search.npmjs.org/</a><p>The better question is not "What is the case against using CoffeeScript?" ... but instead: How is it that despite all of the obvious hurdles stacked against a new source-to-source language, people are actually using CoffeeScript?<p>That's the question I'd like to know the answer to.

The debugging complexity is more than just a fair point. It is what kills the language for me.<p>I spend way more time debugging code than writing it. I suspect most coders do. Programming has taught me that I am far from perfect.<p>Give me a language where I can jump right to the problem and my debugger will tell me how I goofed up, and I can look at it as a potential language I will use. Give me something where you double my debug time (which will add probably 30% to my total programming time) and I will ignore it. It doesn't matter how pretty and short it makes the code. Give me error line numbers or go home.<p>If you make my debugging more of a chore than it already is, you ain't no friend of mine.<p>I also agree with the author on the need for symbols rather than words in languages. It may make people feel all warm and fuzzy to write what looks like english, but &#38;&#38; trumps and every day. {} or () wrapping something gives me a lot of info about what is going on and with little mental parsing.<p>In the end, CS just doesn't deliver a advantage to me that is worth moving away from something as easy to code in as JS, warts and all. And I have tried very hard to want to like it.

I agree with the author of this post. What is interesting for me is how people are happy to use an intermediate layer in front of javascript just to gain some <i>syntax</i> and not real semantics.<p>CoffeeScript does not really change the complexity of your program. I agree that in modern languages it is a good idea to avoid all this parens and useless syntax that we have in Javascript, ObjectiveC, and so forth, and I hope next versions of Javascript could even change syntax at some point, but to use an intermediate layer/compiler/translation stuff just for that... is strange.

&#62; Verbally Readable !== Quicker Comprehension<p>-&#62; is Coffee-Script's greatest trick. When I first started poking through the codebase, it would take me ages to 'sound out' each line. Coffee-Script is succinct not simply because its syntax is short, but because it is dense. Everything is an `expression`, which means I can be more expressive/loc.<p>I can now read it as fast as any other language, which means I can comprehend code faster.<p>&#62; doSomething() if five and six and seven<p>That was difficult for me to parse as well until I saw it enough. Which is true of everything new I have ever learned. Some syntax took me out of the C comfort zone, and I am better for it. There's a <i>feel</i> that code written "out of order" has that I instinctively like for some scenarios.<p>&#62; Therefore it will never really be supported natively, and will always be a compile-to-JS language, and will therefore always have a terrible debugging experience.<p>Mozilla has been working on this issue in earnest (<a href="https://github.com/mozilla/source-map" rel="nofollow">https://github.com/mozilla/source-map</a>). It seems that compile-to-JS languages may be part of some greater strategy. Surely, Google must be working on something similar for Dart. Some progress has been made on the GitHub Issue: <a href="https://github.com/jashkenas/coffee-script/issues/558" rel="nofollow">https://github.com/jashkenas/coffee-script/issues/558</a>

<p><pre><code> &#62; This is really weird: getUser = (id) -&#62; url = "users/#{id}" dfd = $.ajax url: url format: 'json' method: 'get' url: url promise: dfd.promise() &#62; It’s hard to recognize instantly that I’m actually &#62; calling $.ajax, not just assigning it. If you don’t know &#62; CoffeeScript, I’m sure the last two lines are totally &#62; baffling. </code></pre> Um... I agree, but as someone who <i>does</i> know the language, that's clear, unambiguous and easy to read. I maybe wouldn't use implicit object return there, but it doesn't surprise me to see it.<p>In fact, I'll make a positive argument for the implicit call syntax: the whitespace under 'dfd' tells me, without reading any further, that the line is a call which takes an object argument. Without significant whitespace, I couldn't rule out it being just a typo.

These are all valid points. Debugging is probably the most significant. I agree that the syntax can potentially make CoffeeScript hard to read, but this can be easily avoided.<p>One of the nice thing about CoffeeScript is that it allows one to be selective about the syntax. For example, unlike the author I will use keywords like is, isnt, or, and, yes, no, on, off because I find it easier to read that way. However, I dislike the calling functions without the parentheses and I dislike the long one-line comprehensions. Instead of doing this:<p><pre><code> eat cheese for cheese in cheeses when cheese is blue </code></pre> I would do:<p><pre><code> for cheese in cheeses if cheese is blue eat(cheese) </code></pre> I can have a minimal syntax, but retain some of the unnecessary bits to make it easier to read. If the author finds themselves writing code that is hard to read, they should just not write it that way. Write it the way you (and your team) like it to be written.

The increase in debugging complexity is a fair point, and it does add an extra step in between finding a problem and fixing it. However, in practice, I'm not sure I've ever had this be a <i>major</i> problem; I've had more problems related to bad error messages from the Coffeescript compiler (generally due to significant-whitespace errors) than I have had in trying to associate Javascript to its source Coffeescript.<p>The rest of the examples, though, don't hold much water. The takeaway from them is "it's possible to write terribly-factored code, even in a pretty language".<p><pre><code> doSomething() if five and six and seven </code></pre> Can be rewritten as this, if it's more comfortable for you:<p><pre><code> if (five &#38;&#38; six &#38;&#38; seven) then doSomething() </code></pre> !=, &#38;&#38;, ||, (), and the like are still usable in Coffeescript. If it makes the code easier to read, then use them!<p>The whole concern with list comprehension syntax order is sort of a red herring - it works that way in Javascript 1.8, as well! In fact, nearly every language that implements list comprehension does it similarly. 160-column 1-liners are evil in any language, not just Coffeescript. If you don't like the "method, loop, condition" syntax of list comprehensions, that's a problem with list comprehensions, not with Coffeescript.<p>The points about the implicit returns and parentheses-less calls apply, as well. When it makes sense to explicitly use them for code clarity, <i>use them</i>.<p>For example, your confusing getUser method can be easily written as:<p><pre><code> getUser = (id) -&#62; url = "users/#{id}" dfd = $.ajax( url: url format: 'json' method: 'get' ) return { url: url, promise: dfd.promise() } </code></pre> Voila, it's still coffeescript, and it's very readable, easy to understand, and not at all difficult to maintain.<p>The fat arrow, like the rest of the examples, is yet-another-case of "Yes, you can shoot yourself in the face with it, if you abuse it". Event binding isn't the only case when you need to preserve scope! Sometimes (frequently, even) you need to pass around an anonymous function bound to a specific scope. The fat arrow is explicitly for that sort of work. If you abuse it every time you could otherwise just call call() or apply() (because you have access to the scope to invoke the function on, in addition to the function itself), then yeah, it's bad.<p>Have you even <i>looked</i> at the implementation of $.proxy() used in your examples there? Guess what it does? It creates a new anonymous function, binds it to the passed-in scope, and returns it. Which is <i>exactly</i> what the fat arrow does in Coffeescript. Why is it evil in Coffeescript, but okay in jQuery? Because you aren't aware it's happening?<p>Your "This is how you should do it" method in Coffeescript is wrong. It should be something like this:<p><pre><code> widget = attach: -&#62; @el.bind 'click', @handler handler: (event) =&#62; doStuffWithThis() </code></pre> That's clearer than any of your examples, Just Works, doesn't have a jQuery dependency, and is even less code than your corrected example. First-class functions have the `this` problem in <i>every</i> language, and the fat arrow is very nice syntactic sugar for what you have to do anyway.<p>The purpose of Coffeescript is to make your life as a Javascript developer easier. If you're using it to make your life harder, you're doing it wrong. It's not a case against using Coffeescript - it's a case against writing terrible code.

Am I the only one to completely disagree with the author?<p>It's important not to mix everything. CoffeeScript is a <i>language</i>. There just happen to have an <i>implementation</i> for it.<p>This invalidates the "debug" workflow problem. Let me restate the CS debugging workflow:<p><pre><code> Start discovering the problem in the code I wrote. Fix it in the CS Problem fixed, move on, otherwise start over. </code></pre> A computer language is by definition a mean to express unambiguous statements. So does CS. So does the other languages. The resulting program will do exactly what your code asked to.<p>Do we check compiled code when we code in C? Do we look at the Bytecode when we write Java?<p>The fact that CS compiles to JS is an "implementation detail". That's the CS compiler's job. If you don't trust it, don't use it.

To quote the author:<p>"Check out this one-liner I pulled out of the first .coffee file I randomly opened from our application:<p>scores = (student["assignment_#{@assignment.id}"].score for own idx, student of @gradebook.students when student["assignment_#{@assignment.id}"]?.score?)<p>That’s 160 columns of “readable code”..."<p>You can write a 160 columns of unreadable code in any languages. If you guys enjoy coding like that, don't blame coffeescript.<p>You might be right however that it is "more tempting". For instance, with scheme, it's really easy to start using macro and redefining everything; or to nest lambdas into lambdas into lambdas "because you can do it and it avoids using variables".<p>Still, I think it's the programmer's job to write clear code, whatever the language.

Seems like author is trying to learn a new language and is having a hard time getting out of the shell he created around him with experience. During the struggle he wrote this post.<p>I had exactly same feelings about one-liners and understanding succint statements when I was learning Python after years of programming in C.

<i>My code is more readable for me than yours. That’s just how it is. While the JavaScript CoffeeScript compiles looks decent, it’s still not mine.</i><p>That would change if you practiced reading other peoples' code. When I see my code, I often think, "yeah, I wrote this" because I know how I name things, but other than that, my code looks like everyone else's code. I know this because I based my style on what other people do, rather than just inventing my own. (At work, people like to write Python likeItsJavaOrSomething, and I refuse to follow that convention. While ugly, it doesn't make the code amazingly hard to read. You get used to it with practice.)<p>Now, compiler output is another thing, but c'mon. Sometimes I have to figure out what the computer is doing by reading memory dumps in gdb or the assembly output of gcc -O3. Complaining about the output of a JavaScript compiler is just silly; do it more and you'll figure it out. Programming is all pattern recognition, and if you can't understand patterns in the output of your toolchain, then you aren't using the tools enough.<p>People also like to complain about things like GHC's type inference errors or Perl's "confess" dumps. I personally have no problem extracting the information I need from them. I write a lot of programs and they fail a lot, so I've gotten good at reading the debug messages. Instead of saying, "this is too hard", try harder, and soon your life will be much better.

As a year-long CoffeeScript user, I have a few points to rebut:<p>debugging workflow: he makes a long list of bullet points, when in practice you can find the error directly in your coffeescript code 90% of the time, since you have a clear image of what it's compiling to and errors tend to happen on the piece you're working on. Hopefully source-mapping in Firebug/Inspector will be ready in a few months and end this discussion.<p>"We Process Images and Symbols Faster than Words": It has been demonstrated that the understanding of text is based on the same principle, we don't "read" words, we identify them. <i>and</i> and <i>or</i> are as much a symbol as <i>==</i> and <i>&#38;&#38;</i> (which you still can use if you think they are more visible).<p>"ugly syntax": the examples are ugly. Don't use a trailing if for long conditions, don't create huge one-line comprehensions. You can do worse in javascript.<p><pre><code> if five and six and seven doSomething() </code></pre> "bad parts": every language has bad parts, but the example is just bad practice. Just because you can omit <i>return</i> and start an object literal without indentation doesn't mean you should.<p><pre><code> getUser = (id) -&#62; dfd = $.ajax url: "users/#{id}" format: 'json' method: 'get' return { url: url promise: dfd.promise() } </code></pre> "Significant White-space Means CoffeeScript Will Always Be Compiled": what? No it doesn't. You can compress coffeescript, you can't <i>minify</i> it.<p>Readability is not a strength of most javascript code out there.

The debugging complaint is valid, but a) doesn't generally seem <i>that</i> troublesome in practice (especially given the still-crude state of JavaScript debugging tools in general), and b) will be a lot less valid in the near future, as WebKit, Google and Mozilla are all adopting support for alternative languages in their respective JavaScript implementations IIRC.

&#62; You feel pictures and symbols, you feel the relationship. &#62; one !== two &#62; isSet || isDefault &#62; &#62; one isnt two &#62; isSet or isDefault<p>I agree, but it's important to note that pictures and symbols are only felt because the relationships have been so well defined in the past. I'm not a JS or CoffeeScript developer (I use python and C mostly), so "!==" is much less clear than "isn't".

A style guide becomes very important in a language like CoffeeScript where (a) there aren't established conventions for the language yet like Python's PEP-8 and (b) excluding unnecessary syntax is very, very tempting.<p>No parens or braces necessary? Don't just omit them everywhere! I was reading the source code for batman.js (written in CS, after having written quite a bit of CS myself), and some lines were absolutely baffling. It took way too much work to parse.<p>I've started building up a personal style guide. The most useful parts for maintaining readability are probably:<p>- Always keep the parens for function calls, possibly excepting oft-used functions that are only being called with one argument. (e.g. document.createElement 'div'; parseFloat '10.5')<p>- Always keep the braces for object literals when used in an expression (e.g. as an argument in a function call); omitting them in a simple assignment is OK.

I use CoffeeScript in nearly all my JS packages now, and I like it a lot. But I do not like how many people use it. I use only a subset of the features. The most important aspects are: short function syntax, implicit vars, short object syntax, function binding to this, @. I always use brackets when calling functions, because you need to use them anyway, when you do not pass any arguments. Omitting brackets makes CS nearly unreadable. CoffeeScript is a big win for whatever I am doing. The resulting JavaScript is more stable since CS removes the possibility of a lot of flaws and giving developers the best parts of JS. On the other hand, you still need clear and constraining guidelines to manage complex projects. But you need that in any language and framework. It's not just a necessity in JS development. Thank you, Jeremy. It pays off!

The debugging problem is definitely the biggest strike against CS, so it's weird that most of the article focuses on stylistic options (all those parens, brackets, and ampersands are optional!).<p>I'm still feeling CS out in terms of what style works best for me (for instance: should I always wrap arguments in parens so that all function calls have parens following them?) but it's nice to have that flexibility and be able to find what I think is readable and clean. For instance, I prefer '==' because it parses better at a glance, but I find that 'is' is much faster for me to type. :/<p>Also the white-space argument meaning it will always be compiled is not necessarily true. CS's brevity over JS would probably make up for the significant whitespace difference.

I think this article is a mix of fair criticisms but at points lapses into a lot of hand waving. At points it devolves into "This is confusing/non-intuitive if you don't know CS" and "This is not the way I like to do things".<p>I find the proposition that porting a library (no matter the size) gives you "as much experience as anyone" pretty dubious. It's clear the author has some experience with CS, and I wouldn't discard out of hand the input of someone who had only used it for 5 minutes...but I found that particular statement a bit dismissive of people who have been using CS for a long time on a lot of different projects. Too often people confuse the "getting comfortable, I basically know whats going on here" phase of learning a language with "knowing" that language...which is really more "I understand this on an intuitive level".<p>I found the "We Process Images and Symbols Faster than Words" section extremely dubious and strikes me as very hand-wavy. I see what the author is going for, but it's a completely false analogy and their point is flawed to begin with.<p>They're trying to compare the acquisition and understanding of <i>new</i> concepts vs the recognition of an already known pattern, entirely different things.<p>Also, the author is essentially cheating, because they are talking about conveying inherently <i></i>visual<i></i> information using pictures. Showing someone a picture of a circle and saying "this is a circle" does <i></i>not<i></i> convey what a circle <i></i>is<i></i>, it conveys what a circle <i></i>looks like<i></i> (or perhaps, it does explain what a circle <i></i>is<i></i>, but only visually) which is to be sure useful for some purposes. However, it gives them no inherent understanding of how to properly construct a circle, or what it's relation is to other shapes (such as a line) geometrically (say compared to a triangle which could be called any three non-collinear points).<p>With the baby picture, again...I see what they are going for but I think it just doesn't actually support what they are trying to assert. Evoking an emotional response is not the same as passing knowledge, and it doesn't strike me as a good objective to have when writing code. Sure, show someone a picture of a baby and they will have an emotional response. However, they will have no idea who the baby is or why you are showing them the picture which would probably be more useful.<p>All of this does very little to support their assertion that "&#38;&#38;" is somehow more of a symbol and is more visually rich than "and", something I find dubious even disregarding the poor examples. Letters are symbols themselves and "&#38;&#38;" is just as much a "word" as any other, though admittedly more visually distinctive. With syntax highlighting, I would say that there is no objective difference between "&#38;&#38;" and "and".<p>"That is verbally readable code, but it’s not very comprehensible"<p>I'd say that less the fault of CS, and more the fault of the fact that the algorithm they are expressing in it doesn't make any sense:<p><pre><code> wash plate, brush, sink for plate of dishes when plate.dirty if meal.status is 'done' </code></pre> This is not a valid construct. By using "of" you are iterating through the keys of dishes, which will inevitable be strings. You later check the dirty property of the key (string) which will surely not exist. You need to either use in or less likely, access them as dishes[plate]. (I'd assume dishes in an array, in which case a loop is more idiomatic and safe than for-in)<p>Fine, probably an honest mistake. Sure, I just felt the need to point it out, though I think it does <i>potentially</i> suggest that the author is not yet at the "intuitive" level of knowing CS. You are going to have problems like this in <i>any</i> language where you do not yet fully know it, JavaScript included.<p>Even excepting that, the algorithm doesn't makes sense. You're cleaning your sink and brush after washing each plate? Doesn't make much sense. I suggest a more realistic version:<p><pre><code> if meal.status is done wash plate for plate in dishes when plate.dirty wash brush, sink </code></pre> The author makes a couple points about their original comprehension; how it's densely packed, and I think this largely untangles them. It puts the most important predicate first.<p>You don't need to know immediately that you are dealing with the dishes array... The code is composed of discrete "pieces" and each depends on the others. I think it's arbitrary to say "oh I need to know I'm iterating through dishes first thing". It's just as useful to say "ok, I'm going to be washing something, a plate...". That provides a context for everything else. The fact that it's a comprehension is pretty obvious immediately so it's just a case of deconstructing it.<p>So overall I find this a bit of a straw man. It doesn't make sense to begin with, it doesn't need to be so packed, and it's taken out of context which dramatically cuts back readability. If you were writing an app about doing things in the kitchen, the comprehension (even the dense version) would make quite a bit of sense because the context would make certain things more obvious. In my code, this section would probably be prefaced with a comment like:<p><pre><code> # cleanup wash dishes wipe counter stow utensils </code></pre> So the fact that we just spent X number of lines getting dishes dirty, and knowing precisely what a dish object is in the context of the overall program i.e. that they need to be cleaned, it would be obvious that I need to now wash them each in turn...amongst other things.<p>Now really, I see what the author is going for. List comprehensions get messy fast. Sure, I just don't see this as a criticism of CS per se and I find the example poor.<p>Remember, just because CS offers extreme conciseness doesn't necessarily mean you have to use it. I'll admit CS users often make a big deal about conciseness, and that can send mixed messages...but I would say in most cases it's about demonstrating that power is there <i>if you need it</i> than saying <i>this is always best practice</i>. The author clearly understand this as they go on to provide more readable examples, but it bears repeating.<p>I could similarly break down the "one liner", but I'm running pretty long already and don't have forever. Again, what is probably a misuse of "of", and sticking more than is needed in the comprehension. I get the idea that the point is you can do this, but every language has powerful features with which to shoot yourself in your foot.<p>If the author actually found that in their company's code, I most respectfully suggest perhaps they don't know CS well enough or it may not be their style. At any rate, it would explain their distaste for CS.<p>"It’s hard to recognize instantly that I’m actually calling $.ajax"<p>I suppose, but CS uses juxtaposition to call functions, if you see identifier<i></i>\w<i></i>value or identifier<i></i>\w<i></i>identifier...it's a function call. I would say, remember CS's golden rule: when in doubt disambiguate. Feel free to add () to function calls.<p>I think the next point the author makes it better. I would say that it's just an unfortunate fact that in many languages some constructs will be ambiguous. I think CS does a good job of pushing ambiguity to edge/rare cases.<p>In the author's particular example I would note the point is a bit moot because CS has implicit return:<p><pre><code> getUser = (id) -&#62; url = "users/#{id}" dfd = $.ajax url: url format: 'json' method: 'post' # return url: url promise: dfd.promise() </code></pre> In other cases I would refer you to the Golden Rule.<p>"Now with the fat-arrow, people are encouraged to fat-arrow their way to oblivion"<p>I find this a dubious assertion. Stupid people maybe, but I doubt very much giving stupid people JavaScript will give you overall less problems...just different ones. At any rate, I don't see any problem with saying a tool should be reserved for experienced users.<p>"Therefore it will never really be supported natively, and will always be a compile-to-JS language, and will therefore always have a terrible debugging experience."<p>I disagree. The browsers are working on features to make such debugging much easier. Further, I know a few people working on CS in CS interpreters, so that if you need a richer debugging experience you could run your scripts through the interpreter rather than as JS. Granted it will probably never be as rich as the Developer tools in the browser, but between the two I would say it's enough.<p>The author noted they feel the need to throw in a lot of logging in to debug. I would say this is a style a lot of CS developers I know use, myself included. I am quite adept with the developer tools, having debugged JS since the Venkman and Visual Studio days, but I just don't feel the need for that sort of debugging very often. For me, it's either a syntax error or a problem with the flow of data through my program. The only time I really break out the debugger is debugging other people's code.<p>Editor macros make inserting logs dead simple. A good build process removes them except when needed. I can appreciate that some people will find this workflow annoying and a pain, which is fair. I just want to note I find it works superior for me.<p>So this is getting long. Despite my objections, I like this article. CS is not perfect by any stretch, and it's still relatively new. It needs work. It needs criticism from the trenches. I think most of the stuff in this article is mostly fair.<p>However, I find that CS suits a particular group of developers...and for them it is a very useful tool. I think that a lot of people criticize it without realizing that really they don't fit into that group.

I just spent my entire day tracking down a missing "var" that caused a bug only in Internet Explorer. I haven't written any assembly code since college, and I hope to reach a day when I never have to write or maintain native Javascript again.

what about these reasons:<p>1. It's trendy. Snooty programmers use them. 2. It's hyped. Annoying masters of hyperbole won't shutup about it. 3. javascript is already easy to write, easy to read, easy to use, and well understood.<p>But really it's because I despise hype at such a deep and fundamental level; it leads people to being impulsive and emotional; making decisions based on personal reasons rather than finding the right tool fo the job.<p>countless times i've seen people work significantly longer and harder with the hype technology then if they had just been solid project managers and made good decisions regardless of what is being currently blogged about.<p>other times i've had legacy systems that were built in the super-trendy tech of yesteryear that was a fly-by-night and nobody uses any more ...<p>sometimes you will have managers for instance, that wlil request something like perl code to be rewritten in ruby or some other rearranging of the deck chairs kind of activity. It's a complete and utter waste of time. I'd rather go home and click on all those nsfw tags ...<p>so yeah, no freakin' way; unless there is native support, it's been around for a few years, and there is actual real solid evidence that it doesn't suck (extra time that is) for a similar goal.

Pythonista and Haskell hacker here. Everything he hates about Coffeescript is what I love about it, minus debugging. My debugging workflow looks entirely different (and more efficient) than his, however.<p>While I can't say for sure, it reminds me of the days where Java programmers would try Python and complain that it was harder to write Java code in Python than it was in Java (esp. with getters and setters).

What are your experiences writing CS <i>on top</i> of another well-established javascript API framework, e.g. Dojo. I do a lot of work with ArcGIS Server's Javascript API, which is based in Dojo. I also mix in Jquery when needed (because I prefer it over Dojo). So, would CS be a benefit in these situations, or just muddy the waters?

My biggest problem is that because it lacks firm rules in a lot of area, CoffeeScript is a language that is not always intuitive. With JavaScript it's pretty simple to know the rules; they are completely uniform. Not so with CoffeeScript. Here's my biggest gripe:<p><pre><code> greet = (greeting, person) -&#62; "#{greeting} #{person}!" greet "Hello", "world" </code></pre> That's simple. A function that takes 2 parameters, separated by a comma. But wait, here's another:<p><pre><code> longRunning = (onsuccess, onerror) -&#62; dosomething (e) -&#62; if not e.error? onsuccess() else onerror() </code></pre> And the implementation:<p><pre><code> longRunning () -&#62; "Yippee!" () -&#62; "Oh noes" </code></pre> A function with 2 parameters, this time separated by a carriage return, not commas. How would one know that intuitively? That some times functions parameters are separated by commas and some times by carriage returns? Or that some times function calls have to include the () (when they have no parameters) and some times they don't (when they do have parameters)?<p>I'm sure these things become second nature over time, but learning them will result in a lot of trips to StackOverflow as you wonder why your code doesn't behave as expected.

The "symbols are more comprehensible" thing is a bunch of pseudoscientific mumbo-jumbo. Not the least of all because 'and' and '&#38;&#38;' are both obviously symbolic, just with different symbols.

JavaScript looks better than CoffeeScript...

Also, talking so much about using it or not adds another layer of complexity :)

That was a brilliant article, the most complete honesty about coffeescript that actually makes sense. After reading it I really felt like coffeescript is cool. but you know what he's got something there. he really does =&#62; I'm going to stick to JavaScript ("See what I did there"). thanks;

It took me about 3 months of intense CS usage to really get the hang of it. I've written a good 20-30k lines of CS so far for my application, so I've developed a lot of good practices since I started. Now, I can't imagine writing 'pure' JS ever again.<p>I tend to avoid a lot of the one-line comprehensions for the reasons documented in this article (they get difficult to 'parse'). I also tend to write in a more of a Java style, mostly because of my background is in Java. I tend to put (parens) around a lot of function calls so that I can see it is still a function. Sure, CS can be abused to the point of being barely able to read, but that can be said of any language. Having standards and code-review with your co-workers kind of negates that issue.<p>Debugging can be a bit of a pain since you have to find the line number out of a big file. I think this will go away if/when browsers natively support CS. I've gotten good at naming things so that they are easy to search for in the developer tools. That makes finding the right line to put a breakpoint on a lot easier and faster. If need be, I'll throw a console.log('here') in there and search for that too. Context switching between CS and compiled JS takes a bit of getting used to, but it isn't really that big of a deal. I'm already context switching between Java, HTML, CSS, json, etc... what is one more?<p>The fat/thin arrow thing took a while to get used to, but now it makes perfect sense. The change they made (too quietly, imho) in 1.1.3 to not use __bind so much anymore really helped with comprehension. Now I can see the var _this = this in the compiled code and things make more sense to me now. It also helped performance and made me worry less about using it. In most cases, it is safe to just fat arrow things now so it really isn't that big of a deal.<p>In terms of workflow, I found it very important to integrate it in with my IDE so that every time I save a file, all of my CS is immediately compiled to JS. [1] As a result, I don't see any overhead with the compilation phase of things.<p>Being able to declare 'class'es and constructors has also been really great for compartmentalizing my code. Yes, it is possible to emulate all of this in JS, but I find that a lot more difficult to manage. I do wish there was an 'import' statement though. Right now, I hacked that together with the way I'm using LabJS.<p>In the end, is CS a significant improvement over JS? I think so. Just looking at the compiled output of CS, I couldn't imagine myself writing all of that JS code and not making a ton of mistakes (ie: === vs. ==, nesting of brackets, this binding, etc). People say there is a lot of boilerplate in Java... so, when I use CS, I feel that way when I look at the compiled JavaScript.<p>[1] <a href="http://stackoverflow.com/questions/6645640/integrating-coffeescript-with-eclipse/7507987#7507987" rel="nofollow">http://stackoverflow.com/questions/6645640/integrating-coffe...</a>

CoffeScript just adds more complexity into a already complex problem.

Note: This page is crashing my Chrome

All I can say is, I'm way more productive with CoffeeScript than I ever was with JavaScript. Debugging can be a pain. But I'm using Jasmine heavily, and finding that a steady dose of TDD eliminates most of the debugging frustration.

Some languages are designed for professionals to comprehend easily at a glance: these languages use symbols instead of words, use brackets effectively and don't rely too much on whitespace.<p>Other languages are designed to be easy for anyone: these languages use English as inspiration, using whitespace instead of brackets.<p>CoffeeScript has a place, but not in production. It belongs in the classroom, to help those wanting to learn an easy language to program in. Ruby, I believe, belongs there as well.<p>Languages like C, C++, PHP, JS, etc. are all designed for production. They may not be pretty to look at, but they're easy to comprehend at a glance.<p>It's all a question of what learning curve you're aiming for: the learners curve or the advanced curve.<p>TL;DR - tradeoffs: learn them.