Hacker News Reader

Coffeescript definitely has some warts. The syntax for functions that take parameters after an anonymous function isn't obvious. In fact the Codeschool.com course gets it wrong. And there have been slight changes to the syntax between versions. I've had to deal with code that broke because of it.

It's still probably a win on the whole, but there's one thing that coffeescript advocates should never do. And they frequently do it.

And that is answering javascript questions with coffeescript. If they want to write Jasmine tests, don't show them coffeescript. If they want an answer on stackoverflow don't give them coffeescript.

Coffeescript is not javascript, and it should never be given unless specifically asked for.

    > The syntax for functions that take parameters after 
    > an anonymous function isn't obvious.

Eh? A function is an argument list (), an arrow ->, and an indented body of code. Putting 'em together:

    request(url, (response) ->
      handle response
    , (error) ->
      handle error
    )

To be fair, having the comma on the same indentation as the enclosing function call doesn't follow the standard multiline list formatting in comma-last JS.

To be fair, that style works just fine as well, if you prefer it.

    request url, ((response) ->
      handle response), 
    (error) ->
      handle error

But then you get into do-you-don't-you with parentheses, which I find is a sticking point for some people when they try CS.

I prefer your first example, personally.

The following are all equivalent:

    request(url, (response) ->
      handle response
    , (error) ->
      handle error
    )

    request(url, 
      (response) ->
        handle response
      (error) ->
        handle error
    )

    request(url 
      (response) ->
        handle response
      (error) ->
        handle error
    )

    request url, \
      (response) ->
        handle response
      ,
      (error) ->
        handle error

    request url, (response) ->
        handle response
      ,
      (error) ->
        handle error

It's very reasonable for a JS developer to be confused when seeing those.

If you can't see what all of these have in common, then you probably shouldn't call yourself a software developer.

It's just syntax, people.

I'll be the first to admit, I still find it a bit of an awkward syntax, and it was one of the parts of the syntax I kept bumping up against for the longest time. Amazingly I'm finally comfortable with it, but there is a kind of cognitive friction around that one. Personally, I blame whitespace significance. It's hard for whitespace to be both significant to syntax and formatting without impacting one or the other negatively.

The principle argument against whitespace significant languages is separation of concerns. Punctuation only for syntax and whitespace only for formatting.

That said the benefits of CoffeeScript still outweigh the tradeoffs for me.

I would agree. If you have a hard time learning HAML, something is wrong.

I learned it very early in my career, and it was once of the first things that really accelerated my work. I'm not, and have never been, a rails dev.

Coffee is a bit different (IMO) because it changes the way the language works, instead of being a 1-1 conversion like HAML. I personally don't like it, it just seems like a big bag of syntax sugar tricks thrown together. If I'm going to learn a js preprocessor language, it will be something with a cohesive design as a language (like Clojure or Wisp https://github.com/Gozala/wisp) instead of Coffee's grab bag of gee whiz.

> I would agree. If you have a hard time learning HAML, something is wrong.

Why learn a new way of writing html at all though? what exactly is wrong with HTML as it is that necessitates learning a new way of doing it?

* Writing end tags and angle brackets are annoying (and lots of wasted characters)

* HTML's ceremoniousness is burdensome (I hate XML declarations)

* I've never liked the appearance of regular code inside an XML document... visually, HAML looks a lot more like "code", so template code is more visually pleasing (this is a matter of taste)

In the end its all a matter of taste, and not any actual objective gain in developer productivity, which loops us back to the original point.

If you have a team of people who love and want to do haml/coffeescript. have at it. If not, its just another thing to learn for people who'd rather not.

If you're willing to learn CS, it is objectively better. I've been able to more efficiently write, read, and maintain CS than the equivalent JS.

Having external factors such as a diverse team, or wanting to draw from a larger pool of developers should factor in to your decision to adopt CS. But as a language, I can say it's objectively better in my experience.

> If you're willing to learn CS, it is objectively better. I've been able to more efficiently write, read, and maintain CS than the equivalent JS.

"I've been able to ..." indicates that it is subjectively better (better for the individual reporting.) It is not the kind of information that supports a claim of objective superiority.

Fair point - I kept it to my experience because I don't have any objective empirical sources to draw from, so maybe I shouldn't use that word.

I would argue that it is objectively better to have less boilerplate code (hasOwnproperty(), loop var initialization, lack of splats), visual clutter (brackets, braces, etc), strict comparison by default, string interpolation, array range notation, destructuring assignment, etc. My experience does back that up, but again, I can't source any objective empirical evidence.

And it's important to have a thorough knowledge and experience with both languages. I find in arguments about CS, there's a lot of knee-jerk reaction from people who haven't given CS a fair shake. It had (has?) a "Ugh, hipster" backlash against it.

With things like Haml and Coffeescript, the only truth is that YMMV.

On the individual level, I do think you can find actual objective gains in developer productivity, but on a aggregate level, it becomes muddier because of the variation of developer habits.

Personally, I eliminated a lot of problems associated with close tags in my markup by using Haml. But my coding habits aren't someone else's coding habits, so Haml (or Coffeescript) can go from being a solution to being a problem for someone else.

For the same reason we don't write Assembly code or C or binary most of the time. Just because you can do it doesn't mean it's the most effective use of your time.

The problem with HTML is the closing brackets that don't need to be there if you use indentation. If you are using indentation anyway, what is the point if closing tags? You can eliminate a lot of extra characters. It's not always perfect, but in many cases it is a lot cleaner.

>Both offer non-trivial gains in terms readability of the written code.

I've never seen non-trivial gains by either, either in readablity or expressibility. A few less lines != more readable.

Coffeescript removes the trailing `});` that stacks up when writing callback-heavy code (such as node.js).

Use of promises also reduces the callback "hell".

I'm agaist callback spagheti either, so I prefer promises for that purpose.

The gain is non-trivial once your eyes and brain speak HAML fluently. It may vary person to person. Once you know both HTML and HAML fluently, your brain is going to find one easier/quicker to grok than the other. My brain happens to parse HAML a lot faster than fully bracketed HTML these days.

No, but eliminating boilerplate code and extraneous characters like brackets and braces does make the code more readable.

I've been using CS wherever possible for the past couple of years, and I find it much more readable than JS.

> Neither are particularly hard to learn, assuming you understand HTML and Javascript reasonably well to begin with

I disagree. this might be the case for Rails devs and people familiar with the Rails stack. But I have worked on a large enough team with enough people coming and going with different backgrounds to see more people having difficulties picking up and using haml && coffeescript than just erb/good 'ol javascript.

Sure they'll figure it out eventually, but the learning time adds up, and I haven't seen any actual gains from eventually knowing both of them well enough.

> Both offer non-trivial gains in terms readability of the written code.

Please elaborate on this, because I've seen the opposite. Everybody working on the web knows html and javascript. Usually having to layer haml and coffeescript on top of that knowledge slows them down unless they've been doing it for long enough

Really Haml is difficult? You need to find a new team. They sound stupid. It takes about a 5 minute explanation to demo Haml.

I don't use Haml much, but I find CS easier to parse visually. There are fewer distracting elements, like braces, brackets, etc. This results in the intention of the code coming through with a louder voice compared to syntax requirements.

CS also eliminates boilerplate code like hasOwnproperty() checks, loop variable initialization, null checks on object properties (null soaking), etc. It's visual clutter.

I can code in JS just fine, but it looks rather busy compared to CS.

If they don't understand HAML or Slim, then they don't really understand HTML.

They may have the syntax memorized, but they aren't seeing the bigger picture. HAML and Slim are just alternate ways of getting at that bigger picture.

I think Coffeescript is not as much a 1-to-1 mapping to javascript as HAML is to HTML. It has a bunch of features that don't exist in Javascript and that I, personally, am only familiar with because of previous Python experience.

There's also a productivity thing: familiarity is a really big deal in UX design, and dev environments are no different - you might already have your build system all setup, and be accustomed to read non-HTML/CSS syntax, but others may not be up to the same speed and the requirement for a non-standard tool may bog them down more than help.

Time and again I've seen people say their setup is great, but then try to get someone else setup too, and it's a never ending series of downloading this and installing that and some typing some undocumented command line thing and oh you need a VPN connection to see the database in order to auto-gen that other thing, and to start the web server you type this, and oh crap how do I edit hosts files in Macs again, etc etc

> I think Coffeescript is not as much a 1-to-1 mapping to javascript as HAML is to HTML

In my opinion, the opposite is true – HAML adds a lot more than CoffeeScript. As a very experienced front-end developer, this example from the HAML documentation is completely inscrutable to me:

    %div[@user, :greeting]
      %bar[290]/
      Hello!

Granted I have never used HAML nor Rails, but I have absolutely no idea what that would produce besides some kind of <div> with the text "Hello!" somewhere nested(?) inside.

Come on, you're cherrypicking an obscure, rarely used feature to make a point. When I say mapping, I'm referring to syntax that pertains to HTML, not Ruby data binding syntax (which itself is not too terrible, if you stay within idiomatic subsets).

In any case, your argument kinda reinforces my point about familiarity...

That may be true, I'm not sure which features of HAML are considered obscure? But that in itself reinforces my point: you're saying there are obscure parts of HAML that don't pertain to HTML, apparently. That's the argument I was trying to make.