YmMot

It's nice to see some critiques of CoffeeScript from an actual user, and not just speculation about why it might be bad...however some of the criticisms strike me as the product of not understanding CoffeeScript and/or not sharing it's philosophy/principles/etc. The author seems to have not totally familiarized themselves with CoffeeScript, and seems to think it's "Ruby and JavaScript's love child" which it is decidedly not. It's totally valid to not share the philosophy, I just think it's important to judge it on those terms.

> "->" wtf? why?

Not liking the arrow; fair enough...personal opinion and totally valid, but I think it deserves commentary. What's wrong with "function"? Way too long and cumbersome. Maybe it's the Lisper in me but "def" is not specific enough for my tastes.

I like the use of a symbols because it pops in my eyes. It also provides a nice opportunity for features like the fat arrow (=> for binding to the current context) which would be more difficult/less elegant if something like "function" was used. Also note this particular syntax has precedent in other languages.

> Plus syntax highlighting goes to pot when you use the coffee way.

Not really sure what the author means here. Syntax highlighting works just fine for me with CoffeeScript. I suspect they have some problems with some particular editor or feature not working correctly with CoffeeScript, but overall I haven't had any problems with it.

> You'd expect this:

      x = true  x? "Badger" : "Fish"

to return badger, right?

Not really. To be honest I'm not sure what this code is supposed to be. I'm guessing that the "true" is just some sort of typo/copy-paste error, in which case it's not valid CoffeeScript. (Coffescript's succinct syntax makes the ternary ? unnecessary and ? is used as the existential operator)

In CoffeeScript it would be:

    x = if x then "Badger" else "Fish"

...which will behave exactly as you expect. The author mentions this, but says it should generate a syntax error. As written it does, if written as I suspect they meant...it doesn't but I don't know if it's entirely fair to expect a syntax error for every single nonsensical (but mostly syntactically valid) construct in a language.

I think their larger point stands though; there are a lot of things in CS that don't generate a syntax error that probably should. This is mitigate by the fact that once you learn CoffeeScript you're less likely to make these sorts of errors, and that a lot of them will cause syntax or obvious errors in the generated JS. (still it would be nice to catch them ASAP)

> Closure. This has caused a world of pain, given every coffee file is compiled within a closure, it takes some hacking and extra work to use modularity with ease

This I can't really get behind. Wrapping everything in a closure is a sane default IMHO. If you have a lot of scripts, it's trivial to turn it off and then handle it in the build. Even with the wrapping, it doesn't strike me as had managing it...but that may just be a product of how I tend to structure my projects: There's generally a master file that creates the namespaces for the project, then any loaded modules attach to that. Others may find the auto-wrapping interfere with their structure, fair enough.

> I really like Chrome's JS debugging feature... yes, you can sort of work out which line relates to which, but when you're fixing a bug this becomes more difficult.

Another common criticism, and one that's generally fair. This is one that should get better with time, as support increases. In the mean-time I find that this issue is mostly problematic for people who aren't totally familiar with CoffeeScript yet. After you become comfortable with it, it sort of fades into the background. As you write the CS you know what JS it will generate. Everything maps pretty closely.

For me personally, I find that the types of things I am debugging have little to do with the CS/JS translation. They're usually logic errors, problems with some API I'm using, etc. In those cases I don't need to muck around with the translated code...I just add some logging/tests to my CoffeeScript or step through the JS and watch local variables.

If I need to find out that I misspelled the name of some API call... I don't really need to figure out what JS corresponds to what CS. I just see what the exception says, realize the problem, and change the CS.

Anyway, this sort of feedback from the trenches is invaluable. It's not my intention to try and write off these criticisms. CoffeeScript definitely has issues and we need discussion about them to fix them.

I just thought I'd offer some counterpoint in case others who have no experience with CoffeeScript happen to read this, so they can hear some from someone who has been using CoffeeScript a lot and had a mostly positive experience.

Not really. There are several causes of death where this is the case, though admittedly suicide is one of them.

It's not a question of "importance" or "purpose", it's a question of interest or relevance.

This young man's death is just as "important" as the young woman you mention...they are both tragedies, they both will leave an indelible wound on many people's lives.

However, this is a social news site for the tech community. The young woman's death is not covered here because it's not relevant to the tech community.

This young man started (with others) a project which is followed, used, and worked on by many in the tech community...it's of interest to them that one of the initiators died just as any other major development would be. It's also safe to say that there are a few people here who either knew him personally or had had some interaction with him, so it's of interest to the community when one of it's own dies.

Any time you load Hacker News there will probably be some stories that don't interest you. However, as long as they follow the community guidelines, are relevant to hackers, etc...it's best to simply skip them.

As for your other point(s), I agree somewhat with what you seem to be saying. I don't think it's rude per se to respectfully ask if anyone happens to know the cause of death. I would find it more rude to speculate. I also agree that a bunch of strangers offering their condolences doesn't accomplish or mean much, but I can also appreciate that people are just trying to be nice to anyone who did know him who happens to be reading.

CoffeeScript doesn't allow you to shadow variables in enclosing scopes. The compiler will declare the variable in the "outer-most" scope in which is is used and then any uses in enclosed scopes refer to that one.

In this case as long as OP was not using the variable in an enclosing scope, it would have been made local to the function.

Teaching?

>Is it really necessary to expect a front end developer to have complete knowledge of manipulating the DOM without jQuery?

It depends. For your average front-end developer adding light functionality to a web page/app? No, probably not.

However, if you are creating heavy, full-featured, client-side web-apps...absolutely.

Not because you need to do it without jQuery, but because you need to understand what jQuery is doing behind the scenes. At least a couple times a year some major website like (to pick at random) Twitter crawls to a halt, bugs out, etc...because some front-end dev treated jQuery like magic without considering what is going on behind the scenes.

So I would say if you serious about being a front-end developer, then sure...spend some time browsing the jQuery source and learn to do things in "vanilla" JS.

In terms of whether to consider it re; hiring, it depends on what you are hiring for.

These aren't some obscure "nice to know" functions...this isn't a "you don't have the manual memorized" gotcha question. Those functions are fundamental to writing JavaScript web applications...particularly at that point in time, but even in today's world of DOM libraries. At this point in time (and even today to a lesser extent) JavaScript's raison d'etre was to manipulate DOM objects and those functions are key to that.

That's like saying "Heart surgeons don't need to be able to draw a rough diagram of a heart when asked...they can always consult a medical textbook".

Sure...I agree with you that heart surgeons don't need to have every obscure cardiovascular disease memorized...but they need to have memorized the basic cardiovascular functions, how the heart works, what it looks like, etc. The same is true for programmers of any type...there is a base amount of information that you should just know in order to be considered proficient for a particular field.

If a candidate comes in and doesn't know this stuff, that doesn't necessarily mean you shouldn't hire them...however it does mean they are not proficient in whatever field and will need to be trained to some extent.

Also of course, as with any other sort of question; it could be they just had a "brain fart" or off day...but not asking these sorts of questions doesn't make that issue go away.