CoffeeScript: less typing, bad readability

I’ve used CoffeeScript for a few months now. Coming from Python, I felt that CoffeeScript was more concise than Javascript, so I decided to use it for a few small projects. Initially, it was a nice experience, but then I gradually realized that, while writing CoffeeScript code was very pleasant, reading it wasn’t so. I started to notice that it was hard to read my own code a few months later. It was even harder to read other people’s code. I often found my self reading the translated JavaScript code to understand a line or two of CoffeeScript. I concluded that CoffeeScript was a language designed for writability at the cost of readability, easier to write, but harder to read.

The roots of CoffeeScript readability problems are two principles applied to the design of the language:

  • Implicit is better than explicit
  • There is more than one way to do it

1. Implicit is better than explicit.

Implicit or optional tokens in a programming language usually bring readability problems. For example, in C-like languages, you can omit curly brackets after a conditional expression if you only have one statement:

if (condition)

But what happens if we add a new statement:

if (condition)

Now let’s take a look at a classic problem associated with implicit semicolon insertion in Javascript:

function foo() {
      foo: 1

Both examples show cases where, at first glance, the code looks like it’s doing something, but after looking more carefully it’s doing something completely different. Even if you know the rules, it’s easy to fall into this trap if you’re an unwary reader. That’s a readability problem.

CoffeeScript introduces multiple implicit or optional tokens that create a lot of situations like these ones. And that’s something you can easily see in real code. For example, take this statement:

action(true, {
   option1: 1,
   option2: 2

In CoffeeScript, you can omit the parenthesis, the curly brackets and the commas. They’re optional. So you can rewrite the statement above as this:

action true
   option1: 1
   option2: 2

Problems with optional parenthesis

Take a look at these two snippets. Next to the CoffeeScript code is the resulting JavaScript:

doSomething () ->  'hello'
doSomething(function() {
  return 'hello';
doSomething() ->  'hello'
doSomething()(function() {
  return 'hello';

Both statements do completely different different things, although they look very similar. The first one takes the space after the function name and applies implicit parenthesis to the function call, taking the function as a single parameter. The second one interprets the parenthesis as a function call with no arguments and applies implicit parenthesis on that result. Note that in CoffeeScript parenthesis are also optional in function definitions with no arguments. That means that the following two statements have exactly the same meaning:

x = -> 'result'
x = () -> 'result'

Something curious about the rules used by CoffeeScript for implicit parenthesis is that the case for function calling is exactly the opposite of the case for function definition. In function calling you can omit parenthesis except when the function takes no arguments, whereas in function definition you can omit parenthesis only when the function has no arguments.

Now let’s take a look at some interesting case of how implicit parenthesis make things harder to read. This a small snippet taken directly from the CoffeeScript source code:

action = (token, i) ->
      @tokens.splice i, 0, @generate 'CALL_END', ')', token[2]

The @tokens.splice function call has five elements separated by commas. At first glance you can think that the function is taking five arguments, but if you read carefully, you will notice that there is another function call as an argument: @generate. The last two arguments are for @generate not for @token.splice.  A more readable way of writing this would have been:

action = (token, i) ->
      @tokens.splice i, 0, @generate('CALL_END', ')', token[2])

Problems with optional commas

In CoffeeScript you can omit commas for separating function arguments if you put them in a new line. For example the following two statements are equivalent:

moveTo 10, 20, 10
moveTo 10,

The comma after the first argument is mandatory, except if the next argument is an object definition:

moveTo(10, {key: value})

moveTo 10
  key: value

Also, if you’re not using explicit parenthesis, indentation is important, but not alignment, take a look at these examples with the resulting JavaScript next to them:

doSomething 1,
doSomething(1, 2, 3, 4);
doSomething 1,
doSomething(1, 2);
doSomething 1,
doSomething(1, 2, 3, 4);
doSomething(1, 2, 3, 4);

You’re not safe from indentation problems if you use parenthesis, for example:

doSomething (->
'hello'), 1
doSomething((function() {}, 'hello'), 1);
doSomething (->
  'hello'), 1
doSomething((function() {
  return 'hello';
}), 1);

In the first case, the line break after the function definition is replaced by an implicit comma, the parenthesis seem to be ignored.

Problems with optional curly brackets

Suppose that you have a function that takes two objects as arguments:

action({key: value}, {option: value}, otherValue)

If you omit the curly brackets, you might think you get the same result:

action(key: value, option: value, otherValue)

However, in this case CoffeeScript will take the first comma as a separator for object properties instead of a separator for arguments. The second comma however, it is taken as argument separator because it’s not an explicit key-value pair. The code will be translated to the following Javascript:

action({key: value, option: value}, otherValue);

Something curious here is that in CoffeeScript, explicit key-value pairs are optional in object definitions, but only if you use explicit curly brackets. That means that you can write something like this:

x = {
  key3: value3
x = {
  key1: key1,
  key2: key2,
  key3: value3

2. There is more than one way to do it (TIMTOWTDI)

In CoffeeScript TIMTOWTDI is a strong principle. For example, instead of just having true and false keywords for boolean values, you can also have yes and no, off and on.

Also, you can write a simple conditional statement in multiple ways:

x = 1 if y != 0

if y != 0
  x = 1

x = 1 unless y == 0

unless y == 0
  x = 1

All the four statements above do exactly the same thing.

The problem with having multiple ways of doing one thing, is that the language end up with too many idioms. This makes code harder to read because a programmer trying to understand a piece of code must be familiar with all those idioms.

When we combine multiple idioms with implicit stuff and the fact that everything is an expression, the result is a bomb for readability. Here are a few examples taken directly from CoffeeScript’s source code.

Fancy for loop

  break for [tag], i in @tokens when tag isnt 'TERMINATOR'
  @tokens.splice 0, i if i

This code deletes leading newlines from the list of tokens. The for loop is
just a “cool” one liner to write this:

  for [tag], i in @tokens
    if tag is 'TERMINATOR'

Tricky while

i += this, token, i, tokens while token = tokens[i]

In CoffeeScript everything is an expression. In the code above, is the while
expresion an argument of or is it acting as while for the
whole statement? When we translate it to Javascript, this is what we get:

while (token = tokens[i]) {
  i +=, token, i, tokens);

Much easier to read in my opinion. Also, note that the while expression is
using an assignment operator instead of a comparision one. That adds 10 points
to the readability bomb.

Tricky if

@detectEnd i + 1, condition, action if token[0] is 'CALL_START'

Here is a similar example, but this time, we’re using an if statement. As in
the previous example, the if here is acting over the whole statement:

if (token[0] === 'CALL_START') {
  this.detectEnd(i + 1, condition, action);

But what happens if we add an else to the if?

@detectEnd i + 1, condition, action if token[0] is 'CALL_START' else false

Now the if is assumed as an expression argument for the @detectEnd function:

this.detectEnd(i + 1, condition, action(token[0] === 'CALL_START' ? void 0 : false));

Fancy redefinition

mainModule.moduleCache and= {}

This code clears the module cache only if the value is not null (or something
falsy). This could have been writen this way:

if mainModule.moduleCache
  moduleCache = {}

But short and original code is much cooler. This is a good example of how TIMTOWTDI kills readability.

Nested made flat

js = (parser.parse lexer.tokenize code).compile options

In this example we see how a nested chain of calls looks flat thanks to the
magic of implicit parenthesis. The code translates to the following Javascript:

js = (parser.parse(lexer.tokenize(code))).compile(options);

When the nested calls are explicit, the code becomes easier to read.


Of course readability is a very subjective topic. The problems described here might not apply to you if you come from a different background. I come from Python, C# and C++. But if you come from Ruby or Perl, you might think these are not problems but actually cool features.

I think that readability is more important than writability for a programming language. Code is usually written once, but read many times. Given that CoffeeScript doesn’t fix any of the fundamental problems of JavaScript, but damages readability, I decided not to use it anymore.


Another interesting post with some other readability problems in CoffeeScript:

About these ads

58 comentarios on “CoffeeScript: less typing, bad readability”

  1. “Bad Readability” is a subjective term. I think CoffeeScript has great readability, because I’ve taken the time to learn how it works.

    Sure it looks easy to screw up when you first take a look at it, but that’s usually the case with any new language.

    With the widespread use of TDD these days, most (should be all, if you do it right) of your code is able to be automatically checked for problems that your concerns would cause.

  2. foljs dice:

    “Bad Readability” is a subjective term.

    No, it’s not. There are many ways to measure it, from A/B tests, to compiler rules, to statistics (and things like Huffman encoding etc).

    I think CoffeeScript has great readability, because I’ve taken the time to learn how it works.

    It doesn’t work that way. You just got used to bad readability. But “getting used” is the easy part. You could have got used (and easier) in good readability.

  3. Most of the people I’ve heard complaining about CoffeeScript also have never used a declarative language such as Haskell or Lisp to begin with; they think using the wrong paradigm.

    CoffeeScript is only hard to read if you try to read it with a JavaScript mindset. Not using parenthesis for function application is very common in functional languages and after a while it becomes second nature. What I like the most about the optional parenthesis is that the *only* parentheses left in my code are for precedence and function argument lists.

    Once you get used to the declarative syntax as opposed to the imperative one, CoffeeScript becomes much more readable than even well-written JavaScript.

    • eamonnerbonne dice:

      I don’t think I’d haskell declarative, and certainly lisp isn’t but in any case, they’re entirely different in their syntax for parameters. The nastiness in coffeescript isn’t that parenthesis can be omitted, it’s that they can also (equivalently) be included, which makes spacing suddenly quite important.

      It’s the flexibility that’s killing: it doesn’t add any power and expressiveness, but simply means that you need to read much more carefully to ensure the code _really_ says what you think it says.

      If you code with really strict syntax conventions, then the problem is less severe. But then, you’d want those conventions to be machine-checked; and the very best way to have that is for the language to enforce one particular convention over the other.

    • Sura dice:

      I love Haskell syntax, because it’s simple and clean — both visually and semantically. CoffeScript syntax is clean only visually

    • Derek dice:

      I was sort of on the fence about coffeescript, loved it, hated it.

      Then I learned Haskell.

      Now I unambiguously love coffeescript.

      Of course you can come up with terribly unreadable code.
      This is easier with coffeescript, because it gives you so many syntactic options.

      It does take a good amount of care and experience and careful decision making to use these syntactic options responsibly.

      But the syntactic options make functional paradigms easier to use.

      Javascript is completely capable of doing functional programming. C can do object oriented programming. In both cases, extra care must be taken by the developer to use the paradigm correctly because the language doesn’t enforce it.

      Unrelated, but I never used to like type systems or strongly typed languages. Then I learned haskell.

      You should learn haskell and functional programming before you bash coffeescript.

  4. Tom (@tubbo) dice:

    CoffeeScript certainly rewards those who review their own code. You can easily write something in CoffeeScript (just like you can in any other language that doesn’t enforce a style or semantics upon you) that is totally unreadable, but CoffeeScript’s flexibility is precisely why it’s easier to read. Good CoffeeScript programmers can quickly express themselves in readable code if they are making design choices for the right reasons.

    Just like in JavaScript, you need to *think* about the way you write your code, because its expressiveness lends itself to confusion in the wrong hands. And just like JavaScript, CoffeeScript is a powerful tool that can be devastating in the wrong hands. Simply re-upholstering a language like JavaScript is not going to change its semantics entirely, and unfortunately for all you Python devs out there it’s not going to make JS any more like Python than it already is. Sorry to say it, but CoffeeScript actually requires an above-average understanding of JS and how it works in order to be used to its fullest extent.

  5. I’m mainly Ruby programmer, and for me things that you described are not exactly language problems, but conventions problems. If you write code in readability in mind, some languages are flexible enough, to make it easy. In my opinion CoffeScript wins here over Javascript. Sometimes writing readable code is hard, and people have different opinions about it, but then following conventions help a lot. Too bad, that from examples that you showed, it looks like CoffeScript sourcecode wasn’t written in readability in mind.

    • I‘m a ruby programmer, and I’m agree with you. those issues addressed here happens in ruby, and is the overhead of flexibility.
      In ruby it is not a problem, because experienced programmers have common sense about which paradigm to choose, and with all the paradigm language give to us, we can write clear code.
      And this article reminds me that coffeescript is a powerful tool, maybe not suit for inexperienced programmers.

  6. xixixao dice:

    Some of the examples are long-known issues (almost bugs, like the indentation for parameter list), some are simply quite readable and their critisism is subjective, but one thing I agree with is that postfix loops and conditions are bad. I personally don’t use them at all and I kinda wish they weren’t included. “One way to do it” should be the way to do it, I agree with that as well, but there is no point in arguing that bad CoffeeScript (like: i += this, token, i, tokens while token = tokens[i]) isn’t readable, as that is the case for all languages (Javascript “more than” included).

  7. The only one problem with CoffeeScript imho is keywords aliasing. All these and=, is, on.. Solution is very simple. Don’t use them. Done.

  8. haters_gona_hate dice:

    Haters gona hate!

    • phtrivier dice:

      Would you consider the article “hateful” ? The author mention he actually *tried* the language, and that some idioms commonly used in the language, which he describes in details, seems *subjectively* less readable *to him*. He then concludes that *he* is not going to keep using the language.

      In the world of “I don’t want to ever try XXXX, it has whitespaces / parenthesises / dots / is not endorsed by YYY”, does “giving an honest shot at something and ending up not liking it” really qualifies as “hating” ?

  9. James dice:

    As a Perl programmer I do not find these to be cool features, for the same reason I do not find the equivalents in Python or Ruby to be cool features.

    I prefer Javascript to Coffeescript because of the things fans of Pythonic / Rubyish syntax dislike about it, braces, semilcolons, the whole C-like language thing.

  10. All of this can adequatly be delt with by following a style guide. For example, parentheses are not optional when calling a function. Braces are not optional when defining an object. Don’t use the synonyms on/off, yes/no, isnt, unless/until. Always use explicit return, except when writing one liner/lambda functions (where it is obvious what the return value is).

    There are quite a few more rules I follow, but in general I agree that CoffeeScript can be unreadable. That doesn’t mean it’s bad, it just means you should select the readable subset of it. For example this one:

  11. threedot dice:

    CofeeScript really have got good features. But follow the code flow very hard with CofeeScript.

    I can follow the code flow with matching brace on JavaScript easily. I don’t like whitespace indentation to collapse statements instead of curly brace.

  12. abhidilliwal dice:

    I totally agree with your second reason, TIMTOWTDI

  13. rtfeldman dice:

    The thesis claims that CoffeeScript is “easier to write, harder to read”, but the article’s evidence goes on to refute this claim. These examples show very readable CoffeeScript code side-by-side with messy CoffeeScript code (of negligible character count difference), plainly demonstrating that readable CS code is no harder to write than the unreadable kind.

    Instead, the evidence shows only that it is *possible* to write messy code in CoffeeScript. While true, this is not a particularly damning charge. Obviously it is possible to write messy code in every language. The tradeoff of TIMTOWDTI languages is that you are both freer to write clean code in a variety of ways and freer to make a mess in a variety of ways.

    I have written a lot of CoffeeScript in my spare time and currently do it professionally, 40 hours per week. When I looked at your examples, my immediate reaction was to recoil, thinking “ughhh, why would anyone ever write it that way?”

    (That goes for the example in the CoffeeScript compiler’s source code, by the way. If I saw that in a Pull Request, I would immediately ask for a rewrite of the offending code before accepting the PR.)

    Whether CoffeeScript code is “harder to read” clearly depends on the programmer’s choices, not on some intrinsic characteristic of the language.

  14. Many commenters seem to make the point that it is possible to write good readable code in CoffeeScript. That’s not the point. The point is that it is almost as easy to write unreadable code. It allows a programmer to make bad choices by leaving it up to them. A style guide can’t fix this because there will always be code written that ignores the style guide.

    • M dice:

      That’s exactly the point – it makes it so easy for a developer in your team to mess up everything simply by ignoring style guidelines.
      I think it has great features, it offers you a way to speed up your coding by offering a simple suntax for good programming patterns in JS (like for classes), but the desire to add “cool” features” ruined everything.
      The main defect of JavaScript is that it includes “bad parts”. This could have been avoided in coffeescript, it could have forced programmers to use only the good parts in JS, and it would have caused pure JS programmers to extinct like dynosaurs.
      Instead, it added bad parts of its own – just to make things more complicated :-/

  15. Ellie K dice:

    The most salient aspect of poor readability that I noticed was the peach colored font on a barely blue background, for the CoffeeScript code examples on the left. The darker blue background (on the right) significantly improved JavaScript’s readability!

    I find the (seeming) ambiguity of CoffeeScript very puzzling. How does the compiler know what to do! Seriously, I suspect that if standards were observed, a style guide strictly enforced, then CoffeeScript readability would improve. But as eamonnerbonne said in a prior comment, it just seems easier all-around if the syntax were machine-checked, no?

  16. Jason Orendorff (@jorendorff) dice:

    Thanks for posting this. I had no idea.

  17. Trev dice:

    Good write up but I think this article would be more appropriately titled: “How to write bad CoffeeScript”

  18. anamika dice:

    Do programmers preere coffescript since they don’t have much experiene with javascript? As a guy working on js code for many years i find coffescript unreadable. But then i don’t like haml as well. Sass seems the only usable tool since it enhances css instead of comming up another syntax, and its readble as well.

  19. yoco dice:

    I believe the responsibility of a “readable code” should be share by programmers and programming language.

    Programmer should be responsible for writing readable code. Avoid using confusing features, writing confusing code.

    Programming language should be responsible for preventing programmers to write a hard-to-read code. Maybe, CoffeeScript is not doing good enough on this topic.

  20. asdf dice:

    > Do programmers preere coffescript since they don’t have much experiene with javascript?

    It’s difficult to use CoffeeScript if you don’t have a thorough knowledge of JavaScript, since you need to know what JS it will translate to and how that code is going to work.

    I think it is much easier to read and the syntax is incredibly clever. Then again, I’ve read through the entire CoffeeScript source code (which itself is written in CoffeeScript) a few times so I am very familiar with the language.

    I recommend practicing a little more. It’s really not a problem at all after a year.

  21. asdf dice:

    Looking more thoroughly, I actually don’t personally have a problem reading any of your examples. I love to be able to write code like that, and I have no problem reading it quickly. It’s all about the practice broheim.

    Whitespace is significant in CoffeeScript. Remember that. A space after an identifier is an implicit function call. Same with an indented block after an identifier.

    I personally love it, it’s a very zen like experience with the sparseness of the non-alphanumeric tokens.

  22. vk dice:

    If you need to get used to it, it’s not readable. That’s like saying “riding a unicycle is easy, after I learnt how to do it”. The point of concern is that code written well, can still be difficult to read, even if it’s been written with the idea of readability in mind. And if to do so one needs to then create code less efficiently, negating the benefits of the language, the language in turn is not readable by nature. It’s not a bad thing, it’s just a fact.

  23. agentultra dice:

    All of this can be dealt with by using some sort of “Coffee-Lint” checker. As soon as you have to lint your source you have to admit that it has syntactic deficiencies that make it tricky for a human being to write a correct programs on their own. If an errant space can change the meaning of your program, you need a lint checker and you should run it all the time.

  24. I disagree that TIMTOWDTI (henceforth T7I) makes a language hard to read.

    T7I gives you more than one way to write something, which means that it gives you the choice and allows to pick the syntax that looks the clearest. I find this an improvement.

    That’s true that it still gives you more room to screw up, but that’s nothing new in this game – responsibility for the quality of your code holds regardless of the language.

    Readability in unclear sections (as well as the programmer’s skill itself) can be improved using reasonable approaches, for example quick code reviews (“if your peer can’t read it, rewrite it or at least comment more verbosely”). This approach sounds promising.

    I acknowledge that CS allows for much and sometimes for more than is necessary, but I approve of this trend.

  25. I completely agree that CoffeeScript has some weird issues — a single space can mean a completely different execution. Some other opinions of mine: JavaScript is less readable than CoffeeScript in the vast majority of code. JavaScript is more bug-prone than CoffeeScript. JavaScript is more verbose.

  26. Mike McG dice:

    Many thanks for making this point with so many specific examples. This is extremely well-argued.

    I read through all dissenting comments and found non that even attempt to defend the specific examples given in the article. Instead, statements that amount to “you don’t know the language” are lobbed around. As far as I can tell, each of his examples are valid CoffeeScript, ergo by that measure he inarguably knows the language. Other comments contain the sentiment “this can be handled by convention, style guide, linting”. The author never argued against that point. The author’s argument was about the language itself.

    I’m curious to hear more specific rationalization for the language features that the author has criticized as harmful to readability.

  27. I come from C, Ruby, JavaScript, etc. and I find CoffeeScript unreadable. I’m starting to switch my stance on Ruby readability and ease of use after several years too though, now preferring explicit and consistent syntax to implicit and inconsistent syntax.

  28. mpmedia dice:

    I use coffeescript but i agree with you. But same things would apply to Ruby for instance. If you are not used to all the idioms and edge cases , you can make “sementic” mistakes in cs. I think cs should have less idioms and be more minial

  29. CoffeeScript does a good job for us. We use it for 2 years already. The entire code and the Jasmine specs look much cleaner with CoffeeScript. Having a strict code syntax, CoffeeScript makes your life easier when working in a team and debugging other’s code.

  30. simoncpu dice:

    Successful troll is successful.

  31. [...] you hate CoffeeScript, here are some good reasons not to use it. If you like CoffeeScript, that article has a lot of syntax features best [...]

  32. Sorry, but you’re simply doing it wrong. Write clean CS code and you will be able to read it months later. The mistakes you mentioned are total beginner mistakes (I did stuff like that in my first few months of CS) and you will learn how to avoid them.

  33. [...] CoffeeScript: less typing, bad readability « Manuel Cerón Bloggpost som menar att coffeescript försämrar läsbarheten. Några bra poänger, men jag tycker fördelarna är fler. Och själv använder jag alltid parenteser. [...]

  34. [...] completely incorrect. I don’t mean to pick on a language which I’m unfamiliar with, but CoffeeScript: less typing, bad readability is a great example. A space or pair of parens leads to valid syntax but erroneous behavior. The [...]

  35. han dice:

    coffeescript is a wonder cure for bad javascript

    if you can write purely solid javascript, have complete mastery of DOM and browser differences – GOOD on You!

    it simply takes too good an understanding of javascript to not first make glaring single statement errors that –> customer-offending UX —> spaghetti patching to fix browser crashes –> finger-pointing at backends and browser quirks.

    … chances are… there aren’t enough such talent and you don’t have enough funds to hire such a genius – and I can’t afford, even if I could, I wouldn’t want to

    with coffee, you don’t make those mistakes
    have the most commonly-used comprehensions and manipulation functions in terse form
    where everything is nicely englishly expressive very much like Ruby
    (and you can level down to Javascript anytime you need to)

    I’d rather write coffeescript as far as the current state of the Web is concerned

  36. xixixao dice:

    Most of the examples you have given are written in bad style, compared to CoffeeScript’s JS output, which is intended to be pretty.

    Only thing I would agree with is that CoffeeScript has more than one way to do some things, and in case of suffix “if” and “while” I think this undermines the language.

    But next time, please compare to minified JavaScript and confusingly indented C++, to be fair.

  37. Tony dice:

    Why is it mostly ruby guys like coffeescript lol, If you notice most of the top node guys don’t use cs, I’m glad to be in good company

  38. I’m writing a modestly large CS library, and have fallen into every trap discussed here and more!

    I think a “best practices” post would be really great. How to use “safe” styles that avoid the bad parts of coffeescript.

    If you have any pointers, I’d love to see them, because for all the bad parts, CS is still a winner for me.


    — Owen

  39. I was lacking for information how write clean CoffeeScript code, when I started coding in CS, so I have created article containing set of rules tested out in development on group of programmers that was developing for over 7 months product in CoffeeScript.

    The rules I applied:

    - Don’t skip braces when defining associate arrays
    - Always use parens for function parameters
    - Never forget the Camel Case
    - Write constants and enums with caps-lock
    - Start private functions and variables with underscore
    - Avoid constructing unneeded objects, if you can
    - Comprehensions are not always the fastest solution
    - Always keep your code modularized to avoid callback hell

    If you want to see these rules deeply explained on examples, see the link:

    Then you can see how the CoffeeScript rock and how clean it can be,

  40. Clever Coder dice:

    The problems that you show are not because of the language. it’s just your ambiguous coding behaviours that creat ambiguous code.

  41. Keith Kim dice:

    Learning a language means also learning the idioms of the language. Any language can be written to be difficult to read. It is up to the writer to keep readability in mind when writing. What one person deems readable may by unreadable to another. It depends on their experience and style. When writing it is important to consider what is readable not only to oneself but also to others on the team. This goes for any language. As such CoffeeScript offers many ways to write readable source but doesn’t enforce any. I for one am quite content with this.

  42. Craig dice:

    Making syntax too flexible and parts of it optional is an absolute deal breaker for programming in the large. CoffeeScript has all the drawbacks of hacker languages (difficultly with consistency and agreeing on patterns within larger teams) but none of the productivity benefits (think Lisp macros). CoffeeScript truly is a hipster language in that it’s all style and zero substance.

    • absolutely, and imho its not even stylish at all. It just adds dualities and uncalled-for problems. Nowadays that JavaScript is so powerful, fast and stable I don’t see the point to add this mad man’s translation layer to mess everything up.

  43. Craig dice:

    @Keith Kim spoken like a true lone wolf who simply doesn’t understand the issues of programming in the large.

  44. koko dice:

    Yes, Coffeescript is shit. Only masochist hipsters use it.

  45. […] certainly has its faults. Like how hard it makes debugging, how poor readability is when you remove almost all punctuation, and how tedious it can be tracking down a bug caused by cached javascript files not being […]


Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de

Estás comentando usando tu cuenta de Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s


Recibe cada nueva publicación en tu buzón de correo electrónico.