Hacker News Reader

I can read it but it's a struggle. Much like reading Ruby, for someone who comes from Python. The syntax doesn't quite make sense to me and its usage varies between authors—a bunch of things are optional and used unpredictably (parenthesis, lambdas, indent-alignment).

Despite the Pythonish indent-based blocks, CoffeeScript is very much Ruby-like in syntax and culture. From my experience, fluent Ruby readers enjoy CoffeeScript much more.

Regardless, the point is that CoffeeScript != JavaScript. Doing things like answering JavaScript questions in CoffeeScript is simply inconsiderate and not very useful—much like answering Python questions in Ruby.

It's true—I could go ahead and learn CoffeeScript and become more fluent at it if I wanted to, but I don't. I actually like JavaScript as it is, especially the newer specifications. Same way I choose to continue using Python rather than learn Ruby more thoroughly so that I can benefit from random Ruby answers to my Python questions.

I think making analogies about this is hard. Programmers are used to thinking about languages as Big Things that change the way you think. This is not that.

I would encourage you to dedicate a block of about 30 minutes to port a single piece of non-trivial JavaScript code to CoffeeScript. You'll almost certainly neutralize any hangups you have in this short period.

The first time I tried to do this, it forever changed the way I write Javascript.

Very solid points. As someone that also enjoys JS as-is, it really frustrates me when people use CoffeeScript in JS answers and tutorials.

Wile I don't consider them to be solid points (see my reply), yours is a solid one: when one asking a question (say on SO) asks speaking in JS tongue, I'd expect the person answering to reply in JS, simply out of courtesy.

And conversely.

"Doing things like answering JavaScript questions in CoffeeScript is simply inconsiderate and not very useful"

Fuck me, right?

Strange. I know Ruby and Python and switch between them quite frequently, but generally prefer Ruby.

I loathe CoffeeScript. My problem with CoffeeScript is it imposes extra burden—to learn the syntax, and to learn how the build tools and process works (which, once you factor into account the various different web frameworks like Rails, Django, Flask and whatever brand of crazy syrup the Node people are currently drinking can be quite substantial)—but the benefit isn't there. CoffeeScript is just JavaScript but prettier.

That's not a worthwhile tradeoff for me. When Rails started doing CoffeeScript, I just opened up ~/.railsrc and popped --no-coffee in there, and my life has been a lot less painful.

CoffeeScript fixes the things about JavaScript that are least significant to me in terms of developer pain (semi-colons, curly braces and so on) but does nothing to address the things that I hate about writing JavaScript (oh, the weakly-typed type system for one thing).

If a front-ender on my team started using CoffeeScript on a project I work on, I'd take him to one side and say "it's fine to practice weird kinks in private, but compile it into JavaScript before you check it in". :)

> does nothing to address the things that I hate about writing JavaScript (oh, the weakly-typed type system for one thing

It can't because it's actually JS, by design. Yet it dutifully tries as hard as it can within this design goal by e.g making its == compile to JS ===. Maybe you'd rather be interested in ClojureScript or Dart, which use JS merely as a VM instead of their systemic core.

> If a front-ender on my team started using CoffeeScript on a project I work on, I'd take him to one side and say "it's fine to practice weird kinks in private, but compile it into JavaScript before you check it in". :)

If a back-ender[0] were to come to me-as-a-front-ender (since I'm equally both), and tell me what language to use, I'd tell him to, well, mind his own server-side business and let front-enders use whatever language they deem able to make them go from A to B in the most clean, reliable, and efficient way possible to them, or else I'll make them rewrite their stuff in NodeJS under cover of both ends being able share and reuse code, just to make them suffer ;-)

[0]: which I don't know if you are or not, but given the substance of your comment, I'd venture mostly the former.

> Yet it dutifully tries as hard as it can within this design goal by e.g making its == compile to JS ===.

Now we're effectively losing the "==" operator, which is behaving like in most other traditional scripting languages (e.g. Perl). What did we win by losing an operator? Why obfuscate that this is not the JS "==" operator but most likely the "===" operator?

Either one wants weak typing or strong typing, but one cannot have both. "most other traditional scripting languages" consists of Perl and PHP (not even (ba)sh/test, to which == is string comparison whereas -eq is integer comparison), while languages typically used on the backend together with JS/CS include Python, Ruby, Java, C#, and whatnot, none of which have such an error-prone feature.

> What did we win by losing an operator? Why obfuscate?

Type safety, and resistance against both bona fide errors and clueless developers. Sane defaults matter.

> If a front-ender on my team started using CoffeeScript on a project I work on, I'd take him to one side and say "it's fine to practice weird kinks in private, but compile it into JavaScript before you check it in". :)

I know this was just a hypothetical, but this is a bad idea. You've lost the original source code and replaced it with something that is, I think everyone can agree CS-advocates or not, hard-to-read Javascript code.

I use Coffee everyday, and I think the features most worth looking at are that every statement is an expression, list comprehensions and the "do" statement (for closing over variables in loops).

And I'm a seasoned JavaScripter. Not a hater either. I just truly believe the benefit is there, and I urge you to take a second look. The syntax won't take you long if you put your mind to it.

I second that. I wouldn't hire any developer delivering just CS, because it shows a "just wanting getting stuff done" attitude, as opposed to some commitment to the language used and its inner workings.

Example: Maybe the most beloved feature: anonymous functions

CS: (x) -> x + x

It's like "yeah, I want to get this block done here", and it obfuscates the workings of the language (e.g.: this is a function with all its inheritance and a shared scope, it returns a reference, which can be used as any reference and is interchangeable with a reference to a named function, etc – the construct essentially obfuscates that the expression is returning an object of type "Function").

I don't think that anyone would get away with it in a C-development position, who would be delivering a source for a precompiler using a construct like, say

loop(i <- 0 .. 9):

as a replacement for

for (i = 0; i < 10; i++) {}

IMHO, this is a very JS-specific phenomenon. And it's a bit strange, having something like a lingua franca nobody seems to care about.

(Edit: Sticking to the lingua franca issue: It's a bit like having Latin as a lingua franca in the middle ages and some community using "Habs papa" for "Habemus papam". Even if "habs" compiles to "habemus" and the forth case of "papa" is easily inferred by the context, it fails the whole issue of using a lingua franca.)

> CoffeeScript != JavaScript [...] Python != Ruby

I beg to differ, CoffeeScript really is JavaScript, written (literally) differently. CoffeeScript is merely a different formal language+grammar[0] that can (and is — almost) translated word for word into the same core. The semantics and underpinnings are exactly the same as with JavaScript.

Conversely, were you writing Python with a Ruby-like formal language, it would not give you things that are profoundly Ruby, like blocks or inheritance model (classes and modules, singletons, method resolution) or open classes or require. The opposite is completely true, as writing Ruby in a Python formal language would not give you decorators or (python) modules with their imports and namespaces.

CoffeeScript vs JavaScript is literally a bikeshed over the very same core.

(That said, I'm in the CS camp because I find the language requires much less overhead to keep code safe and sound, especially when dealing with not so potent developers that just can't seem to understand that yes, var is damn important)

[0]: in the mathematical sense, i.e http://en.wikipedia.org/wiki/Formal_language

Yes, this is what I've been saying all along. CS does not alter the semantics of JS, it is just a different syntax for the same language. A PL is not just its syntax. I sometimes hear new programmers say something like "it's easy to learn more programming languages once you know one, it's just syntax" and I'm not sure where they're getting this idea from :(

Agreed completely. My only issue w/coffeescript is that, uh, I like clojurescript better. But clojurescript is all the things coffeescript is, just more---further from javascript, more concise, less compatible with standard js tools.

coffee-script is not less compatible with standard js tools. Again, "it's just javascript" and you can use backticks in coffee to get embedded js.

Common mistake made by coffee-script-nay-sayers.

Give me a break, you know what I mean. When you look at the page source, do you see embedded coffeescript? Can you debug in coffeescript with the standard tools?

I know these things aren't possible and shouldn't be expected b/c coffee is a "compiled" language...but you can do them in javascript, and telling the vanilla js programmer that they're "exactly the same" is being less than honest.

For "vanilla js programmer", coffee-to-js-correspondance probably doesn't matter anyway. But the point of coffee is that compiler output is very straightforward. While I have to admit that tooling is far from good enough at present, I personally have no problem reading any js generated by coffee, even without source available to me. Apparently many[citation needed] coffee users can do this.

What really made the "vanilla js programmer" feel uncomfortable, I speculate, is the correct way of handling javascript oddities, such as handling nulls (`?` in coffee). They are daunting -- but ignorance is no excuse. Once you start to populate these patterns yourself in your javascript, not only would you immediately recognize them in coffee-generated js, but also you'd appreciate that coffee abstracted them.

I think these common points against coffee mostly apply to other compile-to-js languages such as clojure-script, where the generated code almost always made no sense to a "vanilla js programmer".

sure, using source maps in chrome dev tools, I can work directly with coffee source, the same way I work with less source instead of compiled css

chrome/ff dev tools have source maps support, I can work directly with coffee source the same way, as I work with less source instead of compiled css ... only coffeeconsole is in a separate tab via chrome extension

He's probably referring to debugging etc.

> The first time I saw CoffeeScript I immediately realized, oh, fuck yes, this is obviously better, and switched over to it immediately. I was productive with it instantly.

Which is fine for you. But I tried it for a project then ditched it, because it didn't justify the extra tooling required in my development pipeline, and because there are ambiguities and inconsistencies in the syntax and the language, and yes, occasionally it's actually worse than Javascript.

Which is only to say that not everyone fits into a "doesn't know CoffeeScript"/"loves CoffeeScript" dichotomy.

The point wasn't that everyone should use it. The point was that it was trivial to pick up and use so I'm often surprised when people complain about how difficult it is to read. If I handed you a piece of CoffeeScript and you literally had never read the docs, but are a competent programmer who knows Javascript well, it'd be surprising if you couldn't just read it as-is and know what it's doing since you know it's just an alternative syntax for javascript.

I don't mean to sound dense, but who isn't using some kind of build system these days with their JavaScript? "Extra Tooling" really is quite trivial given the general de-facto standards that are now in place.

As far as the ambiguities and inconsistencies go, that I can understand.

+1, CS can be learned in few hours and any questions on what each constuct produces can be quickly resolved in coffeeconsole for chrome

Verification: lead development of 50MD and 300MD mobile html5 apps for major UK TV's and even people who did see CS first time were able to pick it up quickly. I had literally about 5 cases when I had to answer some chat questions on how CS works, and about the same count when I corrected/optimized some CS usage in a code review.

The productivity gain was impressive. In ducktyping, but esp. in __understanding__ the code quickly.

We're not going back.

This might be shortsighted, but maybe the fact that Discourse was not "getting as many contributions as they expected simply because their JavaScript was obfuscated behind Coffee" is a good thing. Surely, the higher quality contributors prefer CoffeeScript. ;)