What is it about CoffeeScript that people don't like?
It also bugs the fuck out of me that CoffeeScript projects frequently end up being given a *.js extension in the name and how often people who want nothing in the world to do with CoffeeScript, people like me, end up having to deal with it for some reason. Like I don't like ada, and I never have to look at it. ada never ends up in my editor or on a github page I'm looking at, but frequently someone puts CoffeeScript somewhere where someone was expecting JavaScript, like a StackOverflow answer, or a package for Meteor, or something. If CoffeeScript stayed out of my life, and I out of it, I would probably hate it a lot less.
It's not that it's transpiled. I mean that isn't a great thing, but for example I like the idea of Dart and even TypeScript. But CoffeeScript? No thanks.
> [...] how often people who want nothing in the world to do with CoffeeScript,
> people like me, end up having to deal with it for some reason. Like I
> don't like ada, and I never have to look at it. ada never ends up in
> my editor or on a github page I'm looking at, but frequently someone
> puts CoffeeScript somewhere where someone was expecting JavaScript,
> like a StackOverflow answer, or a package for Meteor, or something.
> If CoffeeScript stayed out of my life, and I out of it, I would probably
> hate it a lot less.
But I can understand , because it's popular , some people feel like they are forced to understand or learn it.
Yet you can be proud that Coffeescript influenced the latest ES spec, that's all that matters , you pushed Javascript forward, by saying "Dont wait for other to make the stuff you need, do your own stuff and eventually people will wake up and adress your intial issue".
I'll never forget reading a blog post [0] by Brendan Eich in which he addressed upcoming ES features that were influenced by or emulated Coffeescript syntax.
It was a pretty solid Krusty the Clown reference on his part.
If a project compiles down to Javascript and is intended to be used as such, a .js name suits it regardless of the source language.
A compiler is a program which translates between two programming languages. CoffeeScript -> JavaScript is just compilation. There is no need for a new word.
For better or for worse (I think for the better), CoffeeScript is fully interoperable with JavaScript. The runtime characteristics and the lowest-common-denominator ES3 support are such that you can use it just about anywhere you might want to use JS. That, and a modicum of success, means that JS programmers sometimes stumble across it in unexpected places, only after popping the hood. e.g. "I thought I was just using a simple library -- Eauggh! What is that stuff down there!" This makes it very hard to ignore...
As a JavaScript programmer, you're forced to ask yourself the question, "Why haven't I given CoffeeScript a real try yet?" Not all, but a large part of the dislike comes from folks rationalizing their response to that question to themselves.
tl;dr, CoffeeScript is almost perfectly situated to inspire fear and loathing in JavaScript programmers with closed minds.
[1] - http://www.youtube.com/watch?v=zM-gUM9C5SA&feature=player_de...
1) That people who don't know CoffeeScript have to use CoffeeScript when they encounter CoffeeScript.
2) He thinks require might have been implemented differently, though he thinks that maybe that might have been changed, but "I don't really use it so I don't really know."
I don't really dislike it but I really do not see myself using it if I had a task where I needed JavaScript.
This can be caused by an unnoticed block of whitespace, corner case of CS language itself, or me simply screwing something up.
About 5-10% of the time I hit a WTF in CS, which is, for now, an acceptable trade off vs. using pure boilerplate ridden JS.
If there was a concise TypeScript a la Scala for Java, I'd be all over it.
f x + f y // is f(x + f(y))
f g x // is f(g(x)) console.log inspect value
model.save(attrs).then ->
ui.update attrs
rect.scale height * factor
Log the inspected value.
Save the model, then
Update the UI with the attributes.
Scale the rectangle by (the height times the factor).
Definitely doesn't solve many of JS's problems, but it certainly makes things easier when writing client side apps. We use it a lot for Backbone development.
With languages like TypeScript, or Dart, you also reduce the amount of typing work, but that's just a side-effect of the good tooling these languages have to offer. You can auto-complete everything.
It makes a lot more sense to boost productivity via structure and tooling, because that's what really helps with scaling.
The real problem is there are a lot of "developers" that came up just doing simple Javascript functions. They know their functions, and they dont want their world to change. They would rather accidently reference closure or global and type significantly more code than learn a slightly different way to code Javascript.
Complaints such as "extra hassle due to compilation" are laughable honestly. If adding a build step is an extra hassle, this might be the wrong profession. Tinkering should be in your nature!
CoffeeScript super charges Javascript. Any truly competent JS programmer that gives it a try for a few days would realize it.
That's a very railsy answer. The strength of the web is that you don't need to run a build at all. I think that's the fundamental dislike of Coffeescript. I've worked on so many html frontends where a build process wasn't necessary to accomplish our job, and if someone tried to introduce one for the sake of coffescript it would simply be an annoyance.
That mental context-switch overhead is the whole driving philosophy behind NodeJS in the first place - don't switch languages so often. CS/JS is enough of a change that the overhead is not insignificant.
Becoming expert in a new language goes beyond learning syntax; one must also learn code conventions/style, compiler/transpiler quirks, runtime quirks, and library/framework ecosystem. In CoffeeScript the last two may be moot, but the first two remain. Additionally, to be an expert in a transpiled language, one must be an expert in the target language. It is much harder to find someone that has this knowledge and experience in both CoffeeScript and JavaScript.
This begs the question of each web dev team: if you are already experts in JavaScript, is the value-add from the transpiled language worth the cost of increased solution complexity/cognitive load, and smaller talent pool? My take is that CoffeeScript doesn't meet that bar for most teams.
For individual projects, or isolated one-off tools, these non-technical issues are moot. Also, server-side may be less of an issue since complexity is reduced by not having to write for multiple runtimes (only Node.js and usually without DOM).
Ok, so Javascript has a bunch of gotchas but it's an interesting language which I both like and dislike but I don't dislike it enough to add yet another layer to my dev platform.
Also, as someone stated elsewhere on this page the true solution is to make a browser virtual machine and use any high level interpreted language you want.
In my experience working with CoffeeScript, I've always found well-written code easy to read with no ambiguities.