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:

76 thoughts 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.

    1. I am using TDD with statically compiled CoffeeScript It works well and code is much readable than JavaScript. (take a look at /assets/js/este/) and especially some Mocha tests:

      My answer for article: Forget about crippled super long lines. I consider them as disgusting too. One operation per one line. Then your code will be much cleaner and easier to read.

    2. “Bad Readability” is a subjective term.

      No, Is not, in CoffeScript the syntax doesn’t matters, and that makes it hard to read source code from another developers.

      Here( is a new language that compiles to javascript which is designed for to make large web applications.

  2. “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.

    1. 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.

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

    3. 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. are you serious? comparing functional paradigm languages to imperative ones like Coffeescript or javascript? javascript most of times is IMPERATIVE so you don’t have to compare it to Haskell or LISP, are not the same beasts.

  4. 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.

    1. 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. 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).

    1. 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” ?

  7. 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.

    1. Semicolons are optional in both Python and JavaScript. JS braces are optional for single statements, and can be used in Python if quoted:
      for i in range(3):
      if i == 1:
      print(‘Hello ‘)

  8. 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:

  9. 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.

  10. 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.

  11. 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.

    1. Thanks!!!
      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 :-/

  12. 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?

  13. 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.

  14. 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.

  15. > 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.

  16. 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.

  17. 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.

  18. 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.

  19. 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.

  20. 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.

  21. 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.

  22. 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.

  23. 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

  24. 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.

  25. 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.

    1. CS is marketed as something you can learn instantly and completely in a short while. To justify its existence despite the extra work needed to execute and debug, there shouldn’t exist such unnecessary “bad parts” to begin with. If you need more than a couple days to a week learning new idioms, let alone a few months, you might as well have spent that time working on your JavaScript.

      Statements like yours – and this section is full of them, all being parroted like self righteous rhetoric – completely invalidate the arguments that “CS is just JS” and that “CS is easy to learn”.

      In other words, if you need to learn to use all of the correct idioms and write patterns with an enforced style guide, why in blue cheese couldn’t you just do the same thing in JavaScript?

      I could understand such a sentiment if everything was built in CS and you had no real viable alternative, but why would any sane person go out if their way to go from one imperfect syntax to another? I hate all of these trendy new transpile to JS pseudo- languages, but even I know it would be crazy to, say in an alternate universe where CS came first and everything was built in it, insist on writing everything in JS and then transpiling it to CS. I would focus my energy and attention on learning how to code properly in the language that everyone else was using. Not just because the overhead is more or less the same, but because programming would truly be hell if everyone decided to create their own special syntax because it looked nicer to them at one point in time, just to transpile it to another already extremely high level interpreted language.

      tl;dr: Bad languages don’t make messy, confusing code, only programmers do.

      1. You see, CoffeeScript just isn’t marketed. Period. No big-&-greedy corporations promote it, unlike Google’s Dart and Go or necrosoft’s TypeScript, C# or F#. CoffeeScript is mostly developed by a single person as an open source project. And the fact of wide CS usage proves its ability to promote itself.
        As for time expenses… you see, you didn’t learn JS itself in one day. It may take some time to practice. But then, especially if you need to write relatively large JS modules/plugins, you’ll quickly find out the thing CoffeeScript is about: it will really save your time, and you won’t regret you have learned it. Unfortunately, this is really hard to understand until you actually try to write something useful in it.
        As for “how to code properly in the language that everyone else was using”… you see, I’m an Arch Linux user, almost everyone else uses Faildows, although it’s obviously not the best OS out there. Should I follow their examples? Obviously not. Don’t suffer from mass consiousness manipulation. Use whatever you really consider convenient, despite everyone’s else opinion.

  26. 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

  27. 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.

  28. 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

  29. 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

  30. 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,

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

  32. 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.

  33. 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.

    1. 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.

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

    1. Then why did we switch from vanilla JavaScript to CoffeeScript precisely to write the largest JS modules we have?

      Because we already know that 13000 lines of JS hanging around lead to nothing good.

  35. I’m a rubyist. That’s why I like using Coffee because of simplicity.
    But I do agree with the author regarding the problem of readability.
    That’s why it’s very important to keep those optional parentheses, commas, etc. for your tricky “one-line-does-many-things” style

  36. You see, lots of people that are given freedom actually don’t know how to deal with it because they still think within their old borders. Unlike lots of other languages (like Python, which I also used to use, but Java will serve as a better example of what I’m trying to say), CoffeeScript does not force you into any coding style. You just choose your own and use it permanently. That way your code will always remain readable.
    You say “CoffeeScript doesn’t fix any of the fundamental problems of JavaScript” but again, where are the problems? Lots of features CoffeeScript offers just have appeared in not-so-widely-adopted-yet ECMAScript 6 standard (classes, generators, fat arrow lambdas, readable variable arguments syntax etc ), and lots of CS features aren’t present even there. Just for an example, it’s not very comfortable to work with native DOM collections in pure JS without any jQuery-like rubbish, and ES6 doesn’t fix that very much. Yes, there is [], but it’s still not only less readable than CoffeeScript’s array comprehensions (I think you, as a pythonist, would greatly appreciate them) but even slower, because these comprehensions are compiled into a usual indexed for-loop that natively runs much faster than Array.prototype.forEach. Really, try to squeeze more juice out of JS engine and you’ll quickly see how CoffeeScript helps you organize your thoughts the way you want.
    Conclusion: If you have dropped CoffeeScript, you just aren’t ready for it yet.

  37. All the problems with readability will go away if you stick to the community guidelines on how to write idiomatic coffeescript. You can make similar arguments for ruby but when you get right down to it, the reason you can’t read it is because you wrote it badly.

  38. I do not know if it’s just me or if everybody else encountering problems with your website.
    It seems like some of the written text on your content are
    running off the screen. Can somebody else please provide feedback and let me
    know if this is happening to them too? This may be
    a issue with my web browser because I’ve had this happen previously.

  39. My name is Albert. And I am a professional academic writer with many years of experience in writing.

    My interest is to solve problems related to writing. And I have been doing it for many years. I have been with several groups as a volunteer and have assisted people in many ways.
    My love for writing has no end. It is like the air we breathe, something I cherish with all my being. I am a passionate writer who started at an early age.
    I’m happy that I`ve already sold several copies of my poems in different countries like England and others too numerous to mention.
    I also work in a company that provides assistance to many students from different parts of the world. Students always come to me because I work no matter how hard their projects are. I help them to save energy, because I feel happy when people come to me for professional help.

    Academic Writer – Albert Mata – jennBi Corps

  40. Hi and welcome to my website . I’m Ianis Bowers.
    I have always dreamed of being a novelist but never dreamed I’d make a career of it. In college, though, I assisted a fellow student who needed help. She could not stop complimenting me . Word got around and someone asked me for to write their paper just a week later. This time they would pay me for my work.
    During the summer, I started doing academic writing for students at the local college. It helped me have fun that summer and even funded some of my college tuition. Today, I still offer my writing skills to students.

    Professional Writer – Ianis – Team

Leave a Reply to albert Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s