Proceeds to list example that isn't valid JavaScript.
I have no fundamental objections with CoffeeScript, but I will never use it because there's nothing wrong with JavaScript that CoffeeScript improves upon.
For me, personally, it's way easier to visually scan a file that looks like this:
var helloWorld = function () {
// ...
}
Than this:
helloWorld ->
// ...
It's also easier to grep and sed.
I don't mind if you use CoffeeScript, but don't try and force-feed me some BS about concise syntax, make broad generalizations (complex CoffeeScript is harder to debug than JavaScript), or attack someone as a 'whiner' because they said "It's nice, but not my cup of tea."
My thought process:
1. In order to debug CoffeeScript, I will need to know JavaScript.
2. If I run into a tricky problem, not only will I need to know JavaScript but I'll also need to know the CoffeeScript compiler's internals.
3. If I run into a really tricky problem, or if I need some sort of optimization, I might have to use JavaScript anyway.
4. JavaScript is actually quite a nice language to program in.
5. All of the libraries I will be using will be written in JavaScript.
That said, I found it hard to parse until I started working in it for a few weeks and got used to it. Now, reading function() and {} everywhere seems like a mess of boilerplate to me. Really, it is just a matter of what you are used to.
re #3: Also, I can't think of an optimization that JS has that can't be expressed in CS. It just doesn't work like that.
re #5: That seems like a kind of crazy generalization. How can you say that when CS 'compiles' to JS anyway?
I wasn't defining a function in that example, I was calling a function that contained a closure as an argument (in both JS and CS). This is perfectly valid JavaScript.
Proceeds to list example that isn't valid JavaScript.
The example is in fact completely valid JavaScript, used in what I consider to be a very typical way: calling a function with an anonymous function as an argument.
I don't mind if you use CoffeeScript, but don't try and force-feed me some BS about concise syntax, make broad generalizations (complex CoffeeScript is harder to debug than JavaScript), or attack someone as a 'whiner' because they said "It's nice, but not my cup of tea."
I'm confused that anything in the article came across as "force-feeding". My impression was that he attacked someone as a 'whiner' because they said people at Posterous who use CoffeeScript are not "real" JavaScript engineers.
Opinion: Your mistake parsing his JavaScript example damages your credibility as a JavaScript programmer, and your rant suggests that you didn't read the article very thoroughly before coming here to tell everyone how wrong he is. I would downvote this comment if I could.
Personally, I've played with CoffeeScript and I am a fan of the syntax sugar, but I use exclusively JavaScript for all my projects because I disagree with the scoping rules.
Nobody is "force-feeding" you anything, just close your browser tab. If you missed the top of the article, it's the author that was offended first for using CS, there's no need to continue calling names.
And please drop the straw man arguments:
> 1. In order to debug CoffeeScript, I will need to know JavaScript.
Of course, and that's the beauty of it. CoffeeScript is a tool to write javascript.
> 2. If I run into a tricky problem, not only will I need to know JavaScript but I'll also need to know the CoffeeScript compiler's internals.
You never have to know the CS compiler's internals. The output is always valid (if it wasn't that would be a serious bug, not a problem in your script).
> 3. If I run into a really tricky problem, or if I need some sort of optimization, I might have to use JavaScript anyway.
Optimization can be done in CoffeeScript itself 99% of the times, and it already outputs very efficient javascript.
> 5. All of the libraries I will be using will be written in JavaScript.
Yes, that's nice isn't it? They all interact perfectly fine with your CS code.
My primary issue with CoffeeScript: people that use it insist that it's JavaScript.
Example: I see a post on HN or in one of my RSS subscriptions about a great new JS library or plugin, only to click through and see a page full of CoffeeScript examples, and the source code is written in CoffeeScript as well. This is not JavaScript. I will not learn CoffeeScript just to decipher your plugin or library and integrate it into my JavaScript project. And no amount of forceful whining on your part will convince me that it's so readable and intuitive and minimal that there is no significant learning curve there.
It is readable. It is intuitive. It is minimal, and it has a small learning curve.
CoffeeScript syntax is very simple. It takes about a half-hour, at most, to learn using the language overview (http://coffeescript.org/), assuming you know JavaScript. There's also many well-commented examples you can learn from, such as Conway's Game of Life: http://willbailey.name/conway/docs/conway.html
Do you want to integrate a CoffeeScript library into your JS project? Compile it (many CS libs already have a pre-compiled version available) and use it. Hell, if you really don't want to learn CoffeeScript, compile it without minifying, and use the output for reference instead of the CS - it produces more readable JS than some coders I know.
It really is that simple. You don't have to use it - I only use it for large-scale projects - but you shouldn't get annoyed that people use it for their libraries. I don't want to argue this issue much, but I just don't see any difficulty involved here. I'm a terrible, still-learning coder who's still baffled by every Lisp code sample I see, but CS was super easy to grasp. If I can get it, I'm sure you can too :)
in which i tell you to take a look around outside your little bubble,
posts on coffeescript (and all posts about software) need to be taken in context. This post's context, it seems, is the type of problem where your pain points are, it seems, "javascript: the bad parts". Coffeescript is pretty great at cleaning up the bad parts and if that's your pain point on a daily basis then coffeescript is probably great for your team.
there are other classes of problems where your pain points are different - e.g. layers upon layers of inheritance hierarchies, complexity on top of complexity, bringing feature development pace to a crawl. Teams where all of the grizzled engineers know javascript cold, know the idioms and thus are rarely bit by "javascript: the bad parts". Switching from javascript to coffeescript provides at most a small, incremental improvement to this class of problems. These are the teams that are laughing at the OP. These teams are also a hell of a lot more interested in ClojureScript, because it brings with it a whole new toolbox of idioms to solve problems of complexity.
i think you one could take all the coffeescript blog posts, and sort them into buckets of "loves coffeescript" and "just doesn't care", and these buckets align perfectly with the two categories of problem i described.
Saying "at Posterous, they use it but don’t have any real JavaScript engineers" is ad hominem and uncalled for, but if you squint past his tone, he's saying: there are different kinds of software, and some problems are harder than others, and it ain't one tool fits all.
Fully agreed. The syntactic sugar saves lots of time in total, and there are few bonuses like
for own key, value in hash
that also checks `hash.hasOwnProperty(key)`, which is good practice in JavaScript, but really boring to type in almost all `for` statements.
I also observed that using longer, more descriptive variable and function names, the difference between Coffee and compiled JS is definitely not an issue in debugging sessions. I'd say there is not a context switch even.
It feels like thinking in JavaScript and writing in a new dialect.
I wonder where the blow-back is generated from. Personally, and only anecdotal of course, I feel that I have seen a far greater amount of articles extolling the virtues of CoffeeScript than I have seen condemning it. To be honest, that is the only primary source of whatever trace of resentment I feel towards CoffeeScript: I'm just almost bored of hearing about it. (tongue in cheek)
I don't use CoffeeScript, because Javascript suits me just fine. But I also don't know many developers that slam it or recall an abundance of anti-CoffeeScript articles... For whatever it's worth (shrugs)
The top articles about coffeescript posted in r/javascript are anti-coffeescript articles.
There are many reasons not to use Coffeescript.
Some may claim that 'coffeescript is javascript', it really is not. They say it with a straight face too. People that say this don't really understand the difference between DOM and Javascript, and it is very telling. Just because you can access DOM methods and properties using compiled coffeescript does not mean that the coffeescript syntax IS javascript, and nothing could be further from the truth. DOM is DOM. Javascript is Javascript. Coffeescript is Coffeescript. Confusing them just makes someone look like they don't know what they are talking about.
Anyway, javascript has been the only language used to code front-end websites for quite some time (thankfully vbscript in IE is not used any more) and as a result it has become very well know, widely written about, and quite a lot of code has been written in it. There is a wealth of experience and all the 'gotchas' are well documented and there aren't really that many of them if you don't count anything to do with the DOM. Coffeescript introduces its own gotchas. While it may fix/avoid a few of javascript's gotchas, it introduces its own. And worse, there are new releases of coffeescript that break compatability, so much that the latest version of coffeescript now adds a comment at the top of any generated code with the revision of coffeescript used to create the "transpiled" code. If you think changing the rules of the language regularly is a good way to develop software, then we don't have anything further to talk about.
There are limitations to coffeescript that make it difficult to work with. You can't have the same variable name used twice in the same source file. The var command is ambiguous, and coffeescript's syntax is generally more ambiguous than javascript leading to programmer error. It is more difficult to read coffeescript because of ambiguity that you don't get with C style syntax. Javascript uses clear delimiters { } for where things begin and end, coffeescript does not and this means 'less typing' in coffeescript, but at the cost of readability. Some say coffeescript is easier to read, more power to them. Hopefully I'll never have to read their code.
"I tend to be more critical of things before I’ve tried them, but I did try CoffeeScript to see what all the hype was about. It was nice, but it’s not worth it."
Apparently another blogger wrote that on his blog, and seems pretty even-handed with 'It's okay but not for me.'
The OP's response is "Stop whining and give it another chance." because clearly if someone tries CoffeeScript and says "Thanks, but no thanks." they're not smart enough to think on their own and should STFU and try CoffeeScript again.
In my opinion, CoffeeScript is not a language, it's nothing more that an alternative syntax for JavaScript. The argument that one should know CS in order to use a CS library makes no sense, it's nothing more than JavaScript and I cannot stress that enough. Where it helps a lot though is that it does remove a lot of JS bad parts and incorporates common patterns. Extending Array in CS is nothing more than `class Foo extends Array` and it's perfectly compatible with plain JS.
Basically, I do have more of a problems with libraries which add layers of indirection (eg using _.each) at eval time when it could be done on CS at compile time.
So, once again, CS is JS, written a little differently and with some nice bonuses.
CoffeeScript is not a language. It's a compiler to make JavaScript look like Ruby. Just like the superfluous idea of "semicolons are optional because of a design error", it's personal style.
Be sure not to whine, though, when the abstraction leaks and your code breaks.
I wish I could say blog posts like this helped the cause, but my feeling after reading it is just meh. I'm fanatic about CoffeeScript but there will always be a divide between people who are willing to try it and people who won't. Writing blog posts that effectively regurgitate the documentation while being a bit religiously pushy about it just seem kind of counter to the cause.
I think for someone who already loves CoffeeScript, this stuff shouldn't be review. This post is intended for people who have specific objections to using it.
I think a lot of the discussion about why CoffeeScript is or isn't better is really a proxy for the real issue which is, is it worth taking the time to learn it.
People generally are motivated by feelings and the rationalizations come after. For awhile I felt like I did not want to learn CoffeeScript and that it was silly and annoying that people wanted me to waste time learning it. Honestly what really started to change my mind was that I needed to alter PDFKit, and I had to learn a little bit of CoffeeScript in order to do that. I think that the need to learn it came first and then later the rationalizations for why it was a good choice came after.
Another real issue that is below the surface but not mentioned while people are discussing the actual pros and cons of CoffeeScript: is JavaScript a good language, or is it fundamentally flawed somehow?
A professional JavaScript programmer's identity will often be tied in to some degree with his general JavaScript associations (the same way someone who races Formula 1 cars would identify with that type of car and might be offended if someone started attacking the body shape of those cars), and so to make a significant investment in learning CoffeeScript implies fundamental issues with JavaScript and may therefore be an attack on that person's identity. Obviously this wouldn't be a conscious thought process but the subconscious associations are often there.
Whatever is making people choose to learn CoffeeScript or not to learn it, its not really a rational process usually. Its more like a religious battle.
I think that the amount of time you have invested in JavaScript, how well you really know it, to what degree you have come to terms with/got over those pain points that CoffeeScript helps with, how much you identify with JavaScript versus other technologies, whether you actually have a specific need to learn CoffeeScript (i.e. for altering a library or reading a coworker's code), all of those things are going to add up subconsciously in a sort of vector for or against CoffeeScript that is pretty much an emotion which will motivate different rationalizations about specifics.
So in cases where that subconscious equation just isn't adding up in CoffeeScript's favor people will find all sorts of (often tangential) arguments against it. One thing that probably can help if you are trying to push CoffeeScript is to repeatedly mention certain small improvements such as using -> instead of writing function() or the class and extends syntax. That would mean that they would have to learn those things just in the process of the discussion. (Of course, they may want to stab you if you mention those things too many times though.)
I think you come close to saying something very important but don't quite explicitly say it so I will.
CoffeeScript is a proxy war between JavaScript and Ruby developers. That's the whole "controversy" over CoffeeScript, to semicolon or not to semicolon, and everything in between.
JavaScript developers feel threatened by the influx of Ruby developers into their space and Ruby developers want to turn JavaScript into Ruby and get rid of those ghastly curly braces that cause them to have a panic attack.
I converted some old, overcomplicated, YUI-inspired javascript that relied heavily on class inheritance: big win. I converted some events-gone-nuts code that talked to Google Maps: not a win.
The productivity issue that nobody seems to talk about: the damn compiler is slow. We're talking seconds, but it adds up. (The CSS compilers are far worse.)
I'm used to save/refresh/boom! when coding HTML. Now it's save, contemplate what the hell could possibly take so long, stare sadly at the compile output window, tab, reload, oops, reload again.
I can't believe so many people fight over a syntax. In a perfect world, you wouldn't even care about the syntax that others use because it would automatically be translated into the syntax of your preferences when you look at it.
It's not just Ruby fans that like CS - it shares a lot of syntax design choices, but I think those should be taken on their own merits and not just "Durr hurrr JS for Ruby devs!!"
That article is good, and I prefer the standard operators (&&,||,!==,===) to their english counterparts. The good news is you can still use them in CS.
The other problems in that article aren't from CS itself, but rather how people write code with it. After a certain point, nested anon callbacks are terrible in JS (fat arrow complaint). Same thing with complex one-liners. You can wreak the same havok with pure JS.
I agree with OA spirit. But under "More than sugar" he only mentions surgary things like conciseness, readability, and saving time.
Also the title is total bull dooty, instead of saying what the title implies; "CS, it's for some, not for others. Shut up already." Or better yet not posting this crappy blog in first place. OA retreads the same horse beatings everyone else has ad nauseum.
I just finished a contract at a company of very smart engineers who decided to use Coffeescript way before I got there.
The guys that I was working with were way more brilliant than I am. Guys that have machine learning books on their desks for lunchtime and are doing some amazing work that is going to benefit hundreds of millions of people around the world.
To reference this quote from the article: "Any respectable CoffeeScript engineer should have a strong knowledge of JavaScript".
That, frankly, is not true.
One of the reasons I was brought on was to work on some javascript-heavy stuff. I was a newbie to coffeescript beforehand, so to hit deadlines wrote everything in vanilla js to save time and get work done. The guys on the team are very smart, but not really on top of the javascript game. So in this case, coffeescript was definitely being used because it was easier for them as traditional programmers.
Earlier this week, I spent a couple days and finally went through and ported everything over to CS.
In my experience of having manually written a complicated client-side app in js, then manually ported it to coffeescript, I really just don't like CS.
I'm used to Python. Indentation there is natural. Its idiomatic to what Python is. But its not in javascript. Granted, indentation should always be used in js for readability, but brackets really are needed to denote code blocks.
Another complaint I have against CS is that it tries to do so much stuff "as if by magic" that I was never 100% what my code was going to output. I just find:
abc (arg,arg2) ->
to be really fucking confusing. Not to mention adding in the fat arrow, or 'do' if you need to wrap something in a closure.
I'm probably old school, but when I write code I need to know explicitly what it will do. I know what 'this' will refer to based on how I write. Same for closures.
Lots of times, my original code was just as concise as the coffeescript version, and a hell of a lot more concise than what CS rendered out.
So everyone has their opinions, likes and dislikes. For me, I'm gonna stick with native javascript for the time being.
> I'm used to Python. Indentation there is natural. Its idiomatic to what Python is. But its not in javascript. Granted, indentation should always be used in js for readability, but brackets really are needed to denote code blocks.
Why are brackets needed? Eliminating braces makes code easier to write and read (IMO) and I'd appreciate almost any indented language to follow suit where possible.
> I'm probably old school, but when I write code I need to know explicitly what it will do.
I've found this is mitigated by experience with CS. Just takes a small amount of time getting to know the language. Nowadays I have a pretty good idea of exactly what JS will be output when I'm writing CS.
> Lots of times, my original code was just as concise as the coffeescript version, and a hell of a lot more concise than what CS rendered out.
Concision in this case might be in the eye of the beholder. I find the outputted JS to be quite readable (the most important aspect) and I know what to look for and how to map it to my source code.
Would I recommend porting all of your existing JS to CS? Hell no! But I'd give CS another try for a new project and see if you like it. I think it would click if you used it to actually program toward an end rather than port existing JS. I can see the latter being frustrating, seeing how many different patterns there are for JS development.
I don't use CoffeeScript, among other reasons, because honestly it's just another syntax to learn and remember. Despite what people say, it's not "just JavaScript." I write JavaScript everyday, as well as CSS, HTML, Python and PHP. Adding one more syntax layer to the stack, with its due postitives, also comes with its own costs. As for speed, I utilize tab completion in my editor and make advanced use of keyboard shortcuts, which makes my writing/editing more than "fast enough."
debacle|14 years ago
Proceeds to list example that isn't valid JavaScript.
I have no fundamental objections with CoffeeScript, but I will never use it because there's nothing wrong with JavaScript that CoffeeScript improves upon.
For me, personally, it's way easier to visually scan a file that looks like this:
var helloWorld = function () {
}Than this:
helloWorld ->
It's also easier to grep and sed.I don't mind if you use CoffeeScript, but don't try and force-feed me some BS about concise syntax, make broad generalizations (complex CoffeeScript is harder to debug than JavaScript), or attack someone as a 'whiner' because they said "It's nice, but not my cup of tea."
My thought process:
1. In order to debug CoffeeScript, I will need to know JavaScript.
2. If I run into a tricky problem, not only will I need to know JavaScript but I'll also need to know the CoffeeScript compiler's internals.
3. If I run into a really tricky problem, or if I need some sort of optimization, I might have to use JavaScript anyway.
4. JavaScript is actually quite a nice language to program in.
5. All of the libraries I will be using will be written in JavaScript.
6. wu.js ain't nuthin' ta fuck wit. [1]
Therefore, I'll keep using JavaScript. YMMV.
[1] wu.js is actually quite a killer library: http://fitzgen.github.com/wu.js/
latchkey|14 years ago
You just learn that -> == function() {}
That said, I found it hard to parse until I started working in it for a few weeks and got used to it. Now, reading function() and {} everywhere seems like a mess of boilerplate to me. Really, it is just a matter of what you are used to.
re #3: Also, I can't think of an optimization that JS has that can't be expressed in CS. It just doesn't work like that.
re #5: That seems like a kind of crazy generalization. How can you say that when CS 'compiles' to JS anyway?
bemaniac|14 years ago
I've edited the post to be more clear on this.
laughinghan|14 years ago
The example is in fact completely valid JavaScript, used in what I consider to be a very typical way: calling a function with an anonymous function as an argument.
I don't mind if you use CoffeeScript, but don't try and force-feed me some BS about concise syntax, make broad generalizations (complex CoffeeScript is harder to debug than JavaScript), or attack someone as a 'whiner' because they said "It's nice, but not my cup of tea."
I'm confused that anything in the article came across as "force-feeding". My impression was that he attacked someone as a 'whiner' because they said people at Posterous who use CoffeeScript are not "real" JavaScript engineers.
Opinion: Your mistake parsing his JavaScript example damages your credibility as a JavaScript programmer, and your rant suggests that you didn't read the article very thoroughly before coming here to tell everyone how wrong he is. I would downvote this comment if I could.
Personally, I've played with CoffeeScript and I am a fan of the syntax sugar, but I use exclusively JavaScript for all my projects because I disagree with the scoping rules.
ricardobeat|14 years ago
Nobody is "force-feeding" you anything, just close your browser tab. If you missed the top of the article, it's the author that was offended first for using CS, there's no need to continue calling names.
And please drop the straw man arguments:
> 1. In order to debug CoffeeScript, I will need to know JavaScript.
Of course, and that's the beauty of it. CoffeeScript is a tool to write javascript.
> 2. If I run into a tricky problem, not only will I need to know JavaScript but I'll also need to know the CoffeeScript compiler's internals.
You never have to know the CS compiler's internals. The output is always valid (if it wasn't that would be a serious bug, not a problem in your script).
> 3. If I run into a really tricky problem, or if I need some sort of optimization, I might have to use JavaScript anyway.
Optimization can be done in CoffeeScript itself 99% of the times, and it already outputs very efficient javascript.
> 5. All of the libraries I will be using will be written in JavaScript.
Yes, that's nice isn't it? They all interact perfectly fine with your CS code.
Cushman|14 years ago
Nobody's* saying JavaScript is a poor storage, transmission, or machine-read format; just that it's not one humans should have to use.
* Some people do say this, of course.
Zikes|14 years ago
Example: I see a post on HN or in one of my RSS subscriptions about a great new JS library or plugin, only to click through and see a page full of CoffeeScript examples, and the source code is written in CoffeeScript as well. This is not JavaScript. I will not learn CoffeeScript just to decipher your plugin or library and integrate it into my JavaScript project. And no amount of forceful whining on your part will convince me that it's so readable and intuitive and minimal that there is no significant learning curve there.
avolcano|14 years ago
CoffeeScript syntax is very simple. It takes about a half-hour, at most, to learn using the language overview (http://coffeescript.org/), assuming you know JavaScript. There's also many well-commented examples you can learn from, such as Conway's Game of Life: http://willbailey.name/conway/docs/conway.html
Do you want to integrate a CoffeeScript library into your JS project? Compile it (many CS libs already have a pre-compiled version available) and use it. Hell, if you really don't want to learn CoffeeScript, compile it without minifying, and use the output for reference instead of the CS - it produces more readable JS than some coders I know.
It really is that simple. You don't have to use it - I only use it for large-scale projects - but you shouldn't get annoyed that people use it for their libraries. I don't want to argue this issue much, but I just don't see any difficulty involved here. I'm a terrible, still-learning coder who's still baffled by every Lisp code sample I see, but CS was super easy to grasp. If I can get it, I'm sure you can too :)
geraldalewis|14 years ago
Because, semantically, it is the same as JavaScript (for the most part). It just looks different.
ricardobeat|14 years ago
dustingetz|14 years ago
posts on coffeescript (and all posts about software) need to be taken in context. This post's context, it seems, is the type of problem where your pain points are, it seems, "javascript: the bad parts". Coffeescript is pretty great at cleaning up the bad parts and if that's your pain point on a daily basis then coffeescript is probably great for your team.
there are other classes of problems where your pain points are different - e.g. layers upon layers of inheritance hierarchies, complexity on top of complexity, bringing feature development pace to a crawl. Teams where all of the grizzled engineers know javascript cold, know the idioms and thus are rarely bit by "javascript: the bad parts". Switching from javascript to coffeescript provides at most a small, incremental improvement to this class of problems. These are the teams that are laughing at the OP. These teams are also a hell of a lot more interested in ClojureScript, because it brings with it a whole new toolbox of idioms to solve problems of complexity.
i think you one could take all the coffeescript blog posts, and sort them into buckets of "loves coffeescript" and "just doesn't care", and these buckets align perfectly with the two categories of problem i described.
Saying "at Posterous, they use it but don’t have any real JavaScript engineers" is ad hominem and uncalled for, but if you squint past his tone, he's saying: there are different kinds of software, and some problems are harder than others, and it ain't one tool fits all.
ilaksh|14 years ago
hahahahaha.
pestaa|14 years ago
I also observed that using longer, more descriptive variable and function names, the difference between Coffee and compiled JS is definitely not an issue in debugging sessions. I'd say there is not a context switch even.
It feels like thinking in JavaScript and writing in a new dialect.
masklinn|14 years ago
Use _.each, you're done. Pleasure.
gavinlynch|14 years ago
I don't use CoffeeScript, because Javascript suits me just fine. But I also don't know many developers that slam it or recall an abundance of anti-CoffeeScript articles... For whatever it's worth (shrugs)
leptons|14 years ago
There are many reasons not to use Coffeescript.
Some may claim that 'coffeescript is javascript', it really is not. They say it with a straight face too. People that say this don't really understand the difference between DOM and Javascript, and it is very telling. Just because you can access DOM methods and properties using compiled coffeescript does not mean that the coffeescript syntax IS javascript, and nothing could be further from the truth. DOM is DOM. Javascript is Javascript. Coffeescript is Coffeescript. Confusing them just makes someone look like they don't know what they are talking about.
Anyway, javascript has been the only language used to code front-end websites for quite some time (thankfully vbscript in IE is not used any more) and as a result it has become very well know, widely written about, and quite a lot of code has been written in it. There is a wealth of experience and all the 'gotchas' are well documented and there aren't really that many of them if you don't count anything to do with the DOM. Coffeescript introduces its own gotchas. While it may fix/avoid a few of javascript's gotchas, it introduces its own. And worse, there are new releases of coffeescript that break compatability, so much that the latest version of coffeescript now adds a comment at the top of any generated code with the revision of coffeescript used to create the "transpiled" code. If you think changing the rules of the language regularly is a good way to develop software, then we don't have anything further to talk about.
There are limitations to coffeescript that make it difficult to work with. You can't have the same variable name used twice in the same source file. The var command is ambiguous, and coffeescript's syntax is generally more ambiguous than javascript leading to programmer error. It is more difficult to read coffeescript because of ambiguity that you don't get with C style syntax. Javascript uses clear delimiters { } for where things begin and end, coffeescript does not and this means 'less typing' in coffeescript, but at the cost of readability. Some say coffeescript is easier to read, more power to them. Hopefully I'll never have to read their code.
debacle|14 years ago
"I tend to be more critical of things before I’ve tried them, but I did try CoffeeScript to see what all the hype was about. It was nice, but it’s not worth it."
Apparently another blogger wrote that on his blog, and seems pretty even-handed with 'It's okay but not for me.'
The OP's response is "Stop whining and give it another chance." because clearly if someone tries CoffeeScript and says "Thanks, but no thanks." they're not smart enough to think on their own and should STFU and try CoffeeScript again.
masklinn|14 years ago
There isn't one, but apparently the CS users need validation and have decided to take a page out of the GOP's handbook.
friggeri|14 years ago
Basically, I do have more of a problems with libraries which add layers of indirection (eg using _.each) at eval time when it could be done on CS at compile time.
So, once again, CS is JS, written a little differently and with some nice bonuses.
pjenvey|14 years ago
lukeholder|14 years ago
Source maps are coming to coffeescript and will solve this. this article doesn't mention them.
mkmcdonald|14 years ago
Be sure not to whine, though, when the abstraction leaks and your code breaks.
petercooper|14 years ago
latchkey|14 years ago
slantyyz|14 years ago
>> For example, at Posterous, they use [CoffeeScript] but don’t have any real JavaScript engineers.
The OP probably should have ignored it, but sweeping comments implying that Posterous developers aren't JS engineers is bound to get a response.
bemaniac|14 years ago
Anyway. To each his/her own.
gfodor|14 years ago
insin|14 years ago
ilaksh|14 years ago
People generally are motivated by feelings and the rationalizations come after. For awhile I felt like I did not want to learn CoffeeScript and that it was silly and annoying that people wanted me to waste time learning it. Honestly what really started to change my mind was that I needed to alter PDFKit, and I had to learn a little bit of CoffeeScript in order to do that. I think that the need to learn it came first and then later the rationalizations for why it was a good choice came after.
Another real issue that is below the surface but not mentioned while people are discussing the actual pros and cons of CoffeeScript: is JavaScript a good language, or is it fundamentally flawed somehow?
A professional JavaScript programmer's identity will often be tied in to some degree with his general JavaScript associations (the same way someone who races Formula 1 cars would identify with that type of car and might be offended if someone started attacking the body shape of those cars), and so to make a significant investment in learning CoffeeScript implies fundamental issues with JavaScript and may therefore be an attack on that person's identity. Obviously this wouldn't be a conscious thought process but the subconscious associations are often there.
Whatever is making people choose to learn CoffeeScript or not to learn it, its not really a rational process usually. Its more like a religious battle.
I think that the amount of time you have invested in JavaScript, how well you really know it, to what degree you have come to terms with/got over those pain points that CoffeeScript helps with, how much you identify with JavaScript versus other technologies, whether you actually have a specific need to learn CoffeeScript (i.e. for altering a library or reading a coworker's code), all of those things are going to add up subconsciously in a sort of vector for or against CoffeeScript that is pretty much an emotion which will motivate different rationalizations about specifics.
So in cases where that subconscious equation just isn't adding up in CoffeeScript's favor people will find all sorts of (often tangential) arguments against it. One thing that probably can help if you are trying to push CoffeeScript is to repeatedly mention certain small improvements such as using -> instead of writing function() or the class and extends syntax. That would mean that they would have to learn those things just in the process of the discussion. (Of course, they may want to stab you if you mention those things too many times though.)
MatthewPhillips|14 years ago
CoffeeScript is a proxy war between JavaScript and Ruby developers. That's the whole "controversy" over CoffeeScript, to semicolon or not to semicolon, and everything in between.
JavaScript developers feel threatened by the influx of Ruby developers into their space and Ruby developers want to turn JavaScript into Ruby and get rid of those ghastly curly braces that cause them to have a panic attack.
Let's call a spade a spade.
meanguy|14 years ago
The productivity issue that nobody seems to talk about: the damn compiler is slow. We're talking seconds, but it adds up. (The CSS compilers are far worse.)
I'm used to save/refresh/boom! when coding HTML. Now it's save, contemplate what the hell could possibly take so long, stare sadly at the compile output window, tab, reload, oops, reload again.
rikthevik|14 years ago
ewb|14 years ago
pascalr|14 years ago
CCs|14 years ago
If you like Ruby, check out CoffeeScript.
If you don't now there's Google Dart. The IDE is pretty nice.
None of the above? Closure Compiler, jshint etc. are your friends.
Edit: a good article about "verbal vs visual" programming languages: http://ryanflorence.com/2011/2012/case-against-coffeescript/
lowboy|14 years ago
That article is good, and I prefer the standard operators (&&,||,!==,===) to their english counterparts. The good news is you can still use them in CS.
The other problems in that article aren't from CS itself, but rather how people write code with it. After a certain point, nested anon callbacks are terrible in JS (fat arrow complaint). Same thing with complex one-liners. You can wreak the same havok with pure JS.
leptons|14 years ago
njharman|14 years ago
Also the title is total bull dooty, instead of saying what the title implies; "CS, it's for some, not for others. Shut up already." Or better yet not posting this crappy blog in first place. OA retreads the same horse beatings everyone else has ad nauseum.
geuis|14 years ago
The guys that I was working with were way more brilliant than I am. Guys that have machine learning books on their desks for lunchtime and are doing some amazing work that is going to benefit hundreds of millions of people around the world.
To reference this quote from the article: "Any respectable CoffeeScript engineer should have a strong knowledge of JavaScript".
That, frankly, is not true.
One of the reasons I was brought on was to work on some javascript-heavy stuff. I was a newbie to coffeescript beforehand, so to hit deadlines wrote everything in vanilla js to save time and get work done. The guys on the team are very smart, but not really on top of the javascript game. So in this case, coffeescript was definitely being used because it was easier for them as traditional programmers.
Earlier this week, I spent a couple days and finally went through and ported everything over to CS.
In my experience of having manually written a complicated client-side app in js, then manually ported it to coffeescript, I really just don't like CS.
I'm used to Python. Indentation there is natural. Its idiomatic to what Python is. But its not in javascript. Granted, indentation should always be used in js for readability, but brackets really are needed to denote code blocks.
Another complaint I have against CS is that it tries to do so much stuff "as if by magic" that I was never 100% what my code was going to output. I just find:
to be really fucking confusing. Not to mention adding in the fat arrow, or 'do' if you need to wrap something in a closure.I'm probably old school, but when I write code I need to know explicitly what it will do. I know what 'this' will refer to based on how I write. Same for closures.
Lots of times, my original code was just as concise as the coffeescript version, and a hell of a lot more concise than what CS rendered out.
So everyone has their opinions, likes and dislikes. For me, I'm gonna stick with native javascript for the time being.
lowboy|14 years ago
Why are brackets needed? Eliminating braces makes code easier to write and read (IMO) and I'd appreciate almost any indented language to follow suit where possible.
> I'm probably old school, but when I write code I need to know explicitly what it will do.
I've found this is mitigated by experience with CS. Just takes a small amount of time getting to know the language. Nowadays I have a pretty good idea of exactly what JS will be output when I'm writing CS.
> Lots of times, my original code was just as concise as the coffeescript version, and a hell of a lot more concise than what CS rendered out.
Concision in this case might be in the eye of the beholder. I find the outputted JS to be quite readable (the most important aspect) and I know what to look for and how to map it to my source code.
Would I recommend porting all of your existing JS to CS? Hell no! But I'd give CS another try for a new project and see if you like it. I think it would click if you used it to actually program toward an end rather than port existing JS. I can see the latter being frustrating, seeing how many different patterns there are for JS development.
robwgibbons|14 years ago