Why I Don't Use CoffeeScript (2011)
oscargodson.com
Why I Don't Use CoffeeScript (2011)
1–10 of 23 posts
Re: Why I Don't Use CoffeeScript (2011)
#2I 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.
Re: Why I Don't Use CoffeeScript (2011)
#3It 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".Re: Why I Don't Use CoffeeScript (2011)
#4Re: Why I Don't Use CoffeeScript (2011)
#5> -> 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;iYou 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?
Re: Why I Don't Use CoffeeScript (2011)
#6I 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…
Re: Why I Don't Use CoffeeScript (2011)
#7Interesting 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?
var keys = Object.keys(myObj);
for (var i = 0; i
myObj[keys[i]];
}Re: Why I Don't Use CoffeeScript (2011)
#8Re: Why I Don't Use CoffeeScript (2011)
#9Re: Why I Don't Use CoffeeScript (2011)
#10After 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 doSometh…
promiseFunc() .then (a) -> doSomething(a) .then (b) -> doSomething(b)