6 ms·

So I've been having a similar discussion with people on this exact issue (disclaimer: I actually use SLIM not HAML but same difference). From my fairly long ter

So I've been having a similar discussion with people on this exact issue (disclaimer: I actually use SLIM not HAML but same difference). From my fairly long term experience with both I've found: 1. Neither are particularly hard to learn, assuming you understand HTML and Javascript reasonably well to begin with. In fact, there isn't much to these abstractions at all. Coffeescript probably has more rough edges to be aware of though. Which is to be expected, all programming languages have their dragons to be sure. 2. Both offer non-trivial gains in terms readability of the written code. 3. Both can make future change of code non-trivially easier 4. Both seem to offer less friction for what is a fairly trivial learning curve. I've never been able understand the argument that on teams using these abstractions things makes it harder because not everyone "knows" them. I guess my response is "what is there to know?". This may come across offensively, but I'd be pretty dubious of anyone who struggled to "get" HAML/SLIM or Coffeescript. I used to hear a lot of similar arguments working in .NET for not using open-source frameworks, things that were vastly superior or easier than the MS ordained stuff (nHibernate, Nancy, ServiceStack, etc.). In the end that perspective hindered the teams growth and abilities far more than it helped them. I also don't seem to experience this added friction people say is there. Don't get me wrong I see the bulk of the problems that HAML/SLIM and Coffeescript have, they're far from perfect. But I still find them more comfortable and notably lower friction than working with HTML and Javascript directly.

coldtea 13y ago
>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.
- pjc50 13y ago
  Coffeescript removes the trailing `});` that stacks up when writing callback-heavy code (such as node.js).
  - nawitus 13y ago
    Use of promises also reduces the callback "hell".
  - coldtea 13y ago
    I'm agaist callback spagheti either, so I prefer promises for that purpose.
- DLarsen 13y ago
  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.
- lowboy 13y ago
  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.
trustfundbaby 13y ago
> 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
- lowboy 13y ago
  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.
- briandear 13y ago
  Really Haml is difficult? You need to find a new team. They sound stupid. It takes about a 5 minute explanation to demo Haml.
  - deleted 13y ago
    [deleted]
- mcmillion 13y ago
  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.
woah 13y ago
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 https://github.com/Gozala/wisp) instead of Coffee's grab bag of gee whiz.
- trustfundbaby 13y ago
  > 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?
  - tomc1985 13y ago
    * 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)
    - trustfundbaby 13y ago
      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.
      - lowboy 13y ago
        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.
wmil 13y ago
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.
- jashkenas 13y ago
  > 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 )
  - lowboy 13y ago
    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.
    - jashkenas 13y ago
      To be fair, that style works just fine as well, if you prefer it. request url, ((response) -> handle response), (error) -> handle error
      - lowboy 13y ago
        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.
  - 13y ago
lhorie 13y ago
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
- exogen 13y ago
  > 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!
  - Spiritus 13y ago
    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.
  - lhorie 13y ago
    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...
    - 13y ago

coldtea 13y ago

>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.

pjc50 13y ago
Coffeescript removes the trailing `});` that stacks up when writing callback-heavy code (such as node.js).
- nawitus 13y ago
  Use of promises also reduces the callback "hell".
- coldtea 13y ago
  I'm agaist callback spagheti either, so I prefer promises for that purpose.
DLarsen 13y ago
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.
lowboy 13y ago
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.

trustfundbaby 13y ago

> 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

lowboy 13y ago
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.
briandear 13y ago
Really Haml is difficult? You need to find a new team. They sound stupid. It takes about a 5 minute explanation to demo Haml.
- deleted 13y ago
  [deleted]
mcmillion 13y ago
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.

woah 13y ago

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 https://github.com/Gozala/wisp) instead of Coffee's grab bag of gee whiz.

trustfundbaby 13y ago
> 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?
- tomc1985 13y ago
  * 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)
  - trustfundbaby 13y ago
    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.
    - lowboy 13y ago
      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.

wmil 13y ago

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.

jashkenas 13y ago
> 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 )
- lowboy 13y ago
  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.
  - jashkenas 13y ago
    To be fair, that style works just fine as well, if you prefer it. request url, ((response) -> handle response), (error) -> handle error
    - lowboy 13y ago
      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.
- 13y ago

lhorie 13y ago

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

exogen 13y ago
> 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!
- Spiritus 13y ago
  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.
- lhorie 13y ago
  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...
  - 13y ago