> What I find sad, though, is that most people who dislike CoffeeScript don’t truly know it. They haven’t taken the time to really learn it, or even try it. Their reactions are usually knee-jerk, or based on fallacies.
This sounds a bit like the bi-polar LISP programmer. Belief that he groks things much better than most programmers grok things? Check. Belief that most people are behaving irrationally? Check. Belief that it's foolish to make an obvious choice? Check.
JavaScript is now a moving target. It's what the examples for new "HTML5" features and libraries are written in. It's what an open source library should be written in if you want it to get traction, and to attract other developers. While it may be a good choice for quickly modifying code on a single project, it isn't as good of a choice for something to get great in as JavaScript is.
There's the saying that you need to know JavaScript in order to write CoffeeScript, but you really only need to be able to read JavaScript in order to write CoffeeScript. My guess is that a lot of developers who mostly write CoffeeScript would trip over simple things for a while if they tried switching to JavaScript. This might keep them from seizing opportunities for JavaScript developers such as contributing to an existing JavaScript project or an open source library that's implemented in JavaScript.
While I understand your sentiment... I have to disagree with a few assumptions. I feel that it's perfectly fine to write a project, or even a module in coffeescript. If you look at the NodeJS/NPM ecosystem, you will find a lot of modules will use, or be used by other modules that will be in either JS or Coffee respectively.
While CS supports some features with different syntax than JS, it really isn't THAT hard to pick up, and for the most part I don't care too much. I've mostly written JS, but have used CS for certain bits.. I find the syntax much more pleasant in unit testing, and for grunt tasks in particular (though will likely be using gulp in the future over grunt).
This presentation did show a lot of the niceties with dealing in Classes with CoffeeScript, a lot of which I wasn't aware of... I do tend to keep my objects a bit differently than many though.. I tend to treat my objects as either libraries or effective structures, rarely do I add "smart" methods to my entities.
Will it get me to switch everything, no.. however, multiline strings are nearly enough to get me to strongly consider .coffee for a lot of cases, often I will even mix into .js projects in node.
"If you look at the NodeJS/NPM ecosystem, you will find a lot of modules will use, or be used by other modules that will be in either JS or Coffee respectively"
The big thing for me with Node.js was you could have whole application in one language. Apparently it's not possible anymore because you have to deal with CoffeScript.
If it's a third party module, what do you care... plenty of 3rd party modules are written as wrappers to libraries in C. Probably in your language of choice even. This includes .Net and Java.
This sounds a bit like the bi-polar LISP programmer. Belief that he groks things much better than most programmers grok things? Check. Belief that most people are behaving irrationally? Check. Belief that it's foolish to make an obvious choice? Check.
http://www.lambdassociates.org/blog/bipolar.htm
JavaScript is now a moving target. It's what the examples for new "HTML5" features and libraries are written in. It's what an open source library should be written in if you want it to get traction, and to attract other developers. While it may be a good choice for quickly modifying code on a single project, it isn't as good of a choice for something to get great in as JavaScript is.
There's the saying that you need to know JavaScript in order to write CoffeeScript, but you really only need to be able to read JavaScript in order to write CoffeeScript. My guess is that a lot of developers who mostly write CoffeeScript would trip over simple things for a while if they tried switching to JavaScript. This might keep them from seizing opportunities for JavaScript developers such as contributing to an existing JavaScript project or an open source library that's implemented in JavaScript.