Why coffeescript is bad

According to this issue we might see something like CoffeeScript Version 2 - but I haven't found any decent information about this. I'm already migrating to ES6. There's a chance that CoffeeScript might disappear - or gets "forgotten" by its developers. I'm sure that it'll be around for a long time since it's already used in a lot of projects , but I'm not sure if it's future-proof.

Honestly I don't believe this at all. So migrating at this point made sense for me; at this stage of my project migration takes around one day, which is fine. And migrating has one additional advantage: if someone joins the project he or she could easily start developing. No need to learn a new technology at all. Since I'm really interested in this there'll be a post about it for sure. I'm already very vulnerable to one of the most basic rules of developing: Premature optimization is the root of all evil.

But what if the technology you decided to use is becoming obsolet or - even worse - dying? That's exactly what is happening to CoffeeScript.

There's no official statement about "CoffeeScript is dead" - but just keep in mind that: as said above: seeing big projects moving away from a technology isn't good for the technology. Just 7 releases this year, where four of them were just patches and the other three were minor releases. Conclusion make sure the technologies you're going to use are future-proof as good as you can. In summary, CoffeeScript began as a fantastic idea making it easier to write JavaScript code ultimately, however, it did not stand the test of time and was pushed out by JavaScript and currently, hardly anyone remembers about it.

Most new people in the front-end environment do not even know that such a language existed. You can learn more about CoffeeScript on their official website. If you want to share your opinion about this article, feel free to leave it in a comment below! Get feral when you answer to the greatest interview in history Share your philosophy. The human mind is good at understanding logic in symbols; English is not good at expression logic.

As an example, consider the line eat food for food in foods when food isnt 'chocolate' from the CoffeeScript tutorial. That code could easily be worse if unless eat is undefined was added to the end, making the whole line conditional. Imagine if the expression before the for had been a complex multi-line method call with logic in it. In CoffeeScript there is no variable declaration syntax equivalent to var in JavaScript. Instead, all variables are declared in the scope they are first assigned in.

This means it is easy to accidentally change the scope of a variable and not even realize it. To see how this would happen, imagine you are in a hurry to implement the next feature. Unbeknownst to you, the following code is near the bottom of the file you are about to modify. Did you catch the error? Originally, lastValue was local to the innocent function, but now it is global to the file and the innocent function actually modifies it.

We now have a bug waiting to happen when someone calls innocent then checks the value of lastValue. Keep in mind there could be multiple screens of code between these two code segments. That is frequently listed as one of the bad parts of JavaScript.

Why no provide separate operators for the two? Instead CoffeeScript could have altered the meaning of typeof to something that was more useful, for example the typeOf function recommend by Douglas Crockford.

Many developers wish that JavaScript had classes. If we would write in CoffeeScript from scratch the code would be more idiomatic. Because of that later we decided that we won't port the existing code.

In general readability of shorter function and smaller object increased to some extend. However, for longer methods that wasn't the case at all. Some pieces of syntax seemed quite confusing, especially object literals. CS omits curly braces around member definitions and combined with "everything-is-an-expression" and implicit return that made some bits of code pretty hard to read. In our project we heavily rely on object literals: we pass them as function parameters and return them from other functions.

In many cases these objects tend to be quite complex: with members of different types and several levels of nesting. In our case the overall feeling was that CoffeeScript code was actually harder to read than plain JavaScript code. Although debugging CoffeeScript turned out to be easier than we expected editing experience has degraded quite a bit. In fact everyone in a team agrees that when they switch to CoffeeScript they get a rather poor support from their tool.

IDE and editor plugins are in very early shape and in some cases they can't even give us a proper syntax highlighting or indentation support.

Not talking about code snippets or refactoring. NET shop so everybody is developing on Windows boxes. Until recently Windows support was almost non-existent in Node. The compiler is quite fast and doesn't increase the startup time much. The downside is that the resulting JavaScript gets eval ed and it's a little bit hard to put breakpoints in it in browsers' developer tools especially in IE8. If we have hard time with the debugging we pre-compile CoffeeScript code with the same migration tool that I listed above but that's still not very convenient.

Anyway, the fact that Coffee produces the same kind of "clean" code is a good thing. That said I wouldn't say that CoffeeScript saves a lot of time by putting var keywords for me. Missing var s are easily caught by JSLint and are easily fixable. Moreover, once you get corrected by it for some time you start writing good JavaScript automatically anyway.

Thus I wouldn't say Coffee is really that helpful in this regard. We evaluated CoffeeScript for about a week. All team members were writing code in it and we shared our experiences with each other. We wrote some new code with it and ported some existing code when we saw fit. Our feelings about the language were mixed. In general I would say that it didn't sped up our development but it haven't slowed us down either. Some speed gains due to less typing and less error surface were offset by slowdowns in other areas, mostly tool support.

After a week we decided that we won't mandate the use of CoffeeScript but we won't prohibit it either. Given a free choice, in practice no one uses it, at least for now. From time to time I think of prototyping some new feature in it and then convert the code to JavaScript before integrating with the rest of the project to get a faster start but I haven't tried that approach yet.

For easy stuff - CoffeeScript is redundant, because doing easy stuff is easy in any language. And jQuery is probably even simpler than CoffeeScript. For hard stuff - you must understand your medium.