Why I Don't Use CoffeeScript (2011) | Hacker News Reader

Why I Don't Use CoffeeScript (2011)

oscargodson.com

20 pointseastbayjake20 comments

The author gets a lot of stuff wrong, and the loudmouth attitude doesn't help either.

> -> vs function

Starts off taking issue with the sort triviality he later admonishes the language for solving in other areas. You don't have to start your function bodies on the same line.

> But, more than all of this what bugs me is the fact it's a completely transpiled language mostly for syntax sugar. What an awful reason.

What's awful about transpiling away syntactic ugliness? No reason is given. Presumably it's because you get away from the source. But you can read that source in the compiled js. What's the problem?

> Just use a for(i=0;i<=10;i++), but if you need to use for...ins a lot, write a helper function that takes care of the hasOwnProperty() check.

You can't use the suggested loop to iterate over an object. The indices aren't intengers. This brings me back to a quote earlier in the article: "That is pure fucking laziness in my opinion and it really makes it hard for me to take their opinions seriously after."

> I find wart removal to be an awful selling point. In other words you're saying "Fuck the need to learn how to write JavaScript, we'll fix it for ya." You really need a transpiled language to save you some time from learning the right way to write JavaScript in the first place? Learn JavaScript's pain points and just don't do them.

Using CoffeeScript doesn't stop you from learning about JavaScript's warts. It does alleviate the need to constantly dodge the same problems. I don't need a transpiled language just like I don't need an accountant to deal with my taxes every year.

> Learn JavaScript's pain points and just don't do them. It's like that C/C++ quote goes: "In C++ it's harder to shoot yourself in the foot, but when you do, you blow off your whole leg." Bjarne Stroustrup.

Easier said than done. Everyone makes mistakes. The quote was not meant to reflect favorably on C++.

> Luckily there's numerous small libraries to try to shim classes into JavaScript.

Cool. Let's write lots of tiny helpers and pull in lots of small libraries to address issues that are collectively addressed in one very focused project. I'll go with option B.

> After everything, CoffeeScript is for people who hate JavaScript.

What in the fuck?

I sometimes use CoffeeScript for personal stuff, but have mostly moved back to plain JavaScript even for that. And yet I find this one of the silliest articles about why not to use it. You've explained why very well.

The main reason I moved back to plain js is that: 1. I can't really get used to significant whitespace. But that's mostly just taste. 2. CoffeeScript is a bit too ambiguous for me at times. It makes me feel the same way Ruby On Rails does. But that might also just be a personal preference.

That said, I really miss a lot that CoffeeScript offers. Can anyone recommend a similar and ideally popular project that offers much of what CS has (brevity and comprehensions being among the main things) without the significant whitespace, and without the ambiguities?

The post is pretty subjective and doesn't sound like it comes from someone who spent much time w/ coffeescript.

If you're gonna hate on it, there are much more significant things to hate on:

- whitespace are significant in a hard-to-spot way, e.g. `foo () ->` vs `foo() ->`

- it adds a lot of potential for ambiguity and the need to revisit syntax in existing code when editing it, e.g. going from `foo(1)` to `foo(1).bar(2)` in js doesn't require deleting text in existing code. In CS, going from `foo 1` to `foo(1).bar(2)` does (and have fun grepping for the variations.) Another example: take untog's promise example and add a reject callback.

- accidental implicit returns and variable shadowing bugs do happen and they're not very easy to trace because they break code elsewhere instead of where the problem is

- Coffeescript doesn't provide a systematically superior environment (e.g. compare to compile-time type checking in Typescript or immutability-by-default in Clojurescript), but being a transpilable language, it does create significant downsides (need for a file watcher/build system, limit hireability/hinder initial productivity for non-CS devs, etc)

I wholeheartedly agree. While Coffeescript to some is a must-have in every project they work on, it comes with a higher learning curve than Javascript itself. I understand we as developers are always trying to find ways to do things faster, less typing and better productivity as well as eliminating error, but Coffeescript is not the silver bullet that many make it out to be.

I actually had a Coffeescript experience a couple of years back on quite a large project I was pulled into for about 6 months and it was the worse six months of my life. The syntax is confusing and did not seem to serve any purpose other than the lead developer had a beyond healthy infatuation with Ruby on Rails and a worrying hatred for conventional Javascript. It didn't help that developers who had not used Coffeescript before were being added to the team and every five minutes were asking questions about how to do something in it. Efficiency for the first few weeks was at an all time low because the lead developer thought using Coffeescript would give us an edge.

If anyone tries telling you that Coffeescript does not have caveats of its own, they are lying to you. Sure, it fixes some shortcomings and issues with scope and operators, but it also introduces some weird issues when it comes to scoping and definitions of functions. It is not the angelic syntactic sugar that it is made out to be, it's a lazy developers way of writing Javascript. With the recent feature freeze of ES6 adding in support for classes and other nice additions to Javascript, the need for Coffeescript is further lessened in my opinion.

I think the issues that Coffeescript aims to fix are easily fixed in conventional Javascript by using something like JSHint to prevent things loose equality operators and other pitfalls in Javascript. Save yourself some headaches, reduce the barrier of entry for future developers and just use conventional Javascript, heaven forbid having to write a curly brace or use the var keyword is not going to kill you.

Not to mention, ES6 adds a lot of the more useful stuff from CoffeeScript without most of the problems. All too often I have seen developers using CoffeeScript run into the unfortunate implicit return and awful readibility of objects problem when trying to debug code - I often either point it out off the bat, or I use the CoffeeScript compiler to figure out what they had and what they intended. That is extra unneccessary overhead for developers.

I'm curious what issues you've run into with implicit returns. I haven't traced a single problem to implicit returns in many years of using languages that have them.

Not me so much as others - it's a very common problem I've seen when debugging other people's CoffeeScript code. CoffeeScript is a bit of a different situation than other languages since with other languages, it's the norm (i.e. Ruby) - however, with JavaScript, it is not something inherent in JS, so when people jump from JS to CoffeeScript, there is a disconnect.

Thanks for taking the time to respond, but I'm wondering what specific "common problem [you've] seen when debugging other people's CoffeeScript code", ie. what bug does implicit return commonly cause in their code?

Why I use Coffeescript: It increases my productivity. I know Javascript, I've written a lot of Javascript, I don't need warts removed for my own protection.

I write Coffeescript because it generally results in ~30% less actual code over Javascript, and the reduced boilerplate substantially reduces cognitive overhead when trying to grok a piece of code that I (or my team) wrote six months ago. I get stuff done with it, and I could get stuff done with Javascript (and often do!), but...why spend effort I don't have to in order to solve my business problems?

The abrasive, condescending theme that Coffeescript is only for noobs who couldn't otherwise hack it in Javascript makes my eyes smoke from rolling so hard.

After everything, CoffeeScript is for people who hate JavaScript.

It isn't, though. It's for people who want to use a variant of JavaScript with less syntax sugar, which is exactly what the start of the post says.

And the example of a single function does make it look like CoffeeScript is a waste of time. However, I love it when working with promises. What used to be:

    promiseFunc()
    .then(function(a) {
        return doSomething(a);
    })
    .then(function(b) {
        return doAnotherThing(b);
    })

becomes:

    promiseFunc()
    .then -> doSomething(a)
    .then -> doSomething(b)

I could go through the various benefits that CoffeeScript provides, but the site already does that. And at the end of the day, people can do whatever they want. If you want to use CoffeeScript, do. If you don't, don't. But don't say that CoffeeScript users "hate JavaScript".

Actually, in this exact case the better Javascript example would be:

    promiseFunc().then(doSomething).then(doAnotherThing)

Well, sure. This is what happens when I over simplify an example.

For correctness and to make the comparison more fair, the compiled CS is actually:

promiseFunc() .then (a) -> doSomething(a) .then (b) -> doSomething(b)

Why would I be reading the compiled code?

> Even if you've never programmed before the 2nd example would make sense.

That's not actually true. Functions and return values are themselves concepts that must be learned and are not inherently more intuitive than coffeescript's lambda style. I would agree if the author means this: "Even if you've never programmed in javascript, but have learned the basics of another of the most common languages, the second example will make sense."

This might seem like a nitpick, but the whole argument is along these lines. It boils down to "I don't use coffeescript because it is less familiar to me than javascript", which is totally fine, but different people are familiar with different things.

I hate CoffeeScript for a simple reason - you can't copy and paste it into your browser's console.

The `for...of` and `for...in` loops are much more readable than their pure-Javascript versions. The author is also leaving out really nice things like comprehensions.

ES6 arrow functions are very convenient and look remarkably similar to Example 1, so learning that syntax is probably inevitable in the long term. And I doubt someone who has never programmed before would understand either snippet, although both would be simple to explain. I haven't used CoffeeScript, so I can't say whether I'd find it better/worse than JavaScript for my purposes, but this article wasn't convincing at all.

Interesting article, I like some of the points the author makes. I did want to bring up use for(var i=0; i<10; i++) rather than a for .. in loop. But isn't a for in loop for objects, while the first for example is only for arrays? I don't think you can reference an object's keys with an incrementing counter (unless the object is specifically designed like this?

I suppose you could use the first example with Object.keys ...

var keys = Object.keys(myObj);

for (var i = 0; i < keys.length; i++) {

   myObj[keys[i]];

}

Reply on news.ycombinator.com