5 ms·

I hope this catches on. I love coffeescript (not a huge fan of haml) as well, but the article is spot on, haml has an adoption problem ... and by that I mean I

I hope this catches on. I love coffeescript (not a huge fan of haml) as well, but the article is spot on, haml has an adoption problem ... and by that I mean I could pull a guy who can do html/css layouts off the street corner and they can figure out erb templates in an hour or so, but with haml they're still having trouble working with it weeks later. Thats because haml was built to solve Rails developers problems not frontend developers problems like say less or sass was (and you can see how those are doing). With coffeescript, the two problems are - writing coffeescript is fun, coming back to make sense of what you wrote months later is an absolute nightmare - debugging it is a massive PITA Coffeescript is mostly syntactic sugar that gives you a lot of other benefits but, again, if you want to move quickly as a dev team its one more thing for people to learn or know when they come on line and maintaining it can be a real hassle. On my current team, we started out on an app that had an even split between haml and erb templates, we stopped doing haml and only do erb now. We started out with some coffeescript but after running into the problems mentioned above, we don't write any new coffeescript. That is not to say certain teams won't prosper by embracing these two abstractions, just that in my experience the benefits aren't usually worth it. As always YMMV

lucisferre 13y ago
I have literally taken people who are almost strictly HTML/CSS (limited or no coding) and had them hack on HAML with zero trouble. In fact they really enjoyed it.
- trustfundbaby 13y ago
  excellent, I've seen the opposite. Looks like our completely anecdotal observations cancel out :)
  - agumonkey 13y ago
    Have you wrote about their issue somewhere else in details ? I'm on the same side as the parent comment[1] and I really wish to read and ~understand what I'm missing[2]. [1] I'm natively wired to run toward very dense 'interfaces' (ui, syntax) [2] Honest open question, don't wanna 'argue'.
  - briandear 13y ago
    Is HAML really that hard? It seems pretty damned elementary to me. The hardest part is simply being sure you're using soft tabs. So called "front-end engineers" who can't understand haml after 3 minutes have no business calling themselves "front-end engineers"
    - trustfundbaby 13y ago
      Nope, but whats wrong with html or something that resembles it closely enough without the whitespace active stuff and extra syntax. I'll give you the answer ... nothing. Haml feels like just an unnecessary abstraction on top of something (html) that was just fine to begin with. But a lot of engineers seem to like it, so I think its great for those people. > So called "front-end engineers" who can't understand haml after 3 minutes have no business calling themselves "front-end engineers" Gotta love the arrogance of the remark :) Remember that there are tons of people that aren't classically trained "engineers" that have to work on apps around the world, lets spare a thought for them ;) More seriously, I don't think the argument is them understanding haml. The problem is the learning curve. Its not that steep but having to look up how to do stuff that you could just type right away from memory in plain html every 5 minutes, slows you down, and people want to move quickly. Theres also the fact that when haml breaks you get a Rails error vs the way html breaks which is that the display just looks all wonky. Lets not underestimate that. > Is HAML really that hard? Again, what are all the objective "benefits" of haml that necessitate having to learn this new abstraction? I can tell you why I use Rails over Cakephp, but what is the problem that haml is trying to solve exactly?
      - slantyyz 13y ago
        >> what is the problem that haml is trying to solve exactly Speaking only from personal experience (and I'm talking about my own bad habits with HTML), I have had plenty of bugs related to mismatched open and close tags in heavily nested HTML code, which would result in time consuming debugging. I've all but eliminated these types of issues by using Haml. I no longer have to worry about accidentally deleting the wrong close tag when de-nesting a block of markup. Is it a cure-all for everyone? Not at all. But for some people, it's a godsend.
  - lucisferre 13y ago
    Except that yours doesn't make logical sense. You're suggesting that someone who is good (?) at HTML and CSS can't grok Haml syntax. That just doesn't compute.
- coldtea 13y ago
  It's sugar, why wouldn't they enjoy it? The thing, as with Coke, is if it's good for them.
  - wambotron 13y ago
    As far as I know, Haml will not ruin their tooth enamel or wreak havoc on their kidneys. ;)
    - coldtea 13y ago
      No, but it will needlessy multiply entities and abstractions they have to deal with, even adding extra processing steps, without providing that much improvement to be worth it over vanilla HTML. As if HTML's problem was that it's not succint enough. Plus, I've heard that syntactic sugar causes cancer of the semicolon.
wambotron 13y ago
I've found the opposite with Coffeescript as far as returning to old code. It's clean, nicely indented, easy to follow. I don't use all of the shortcuts, though. For example, I'd never write a plain object without including the curly braces. With javascript, there is SO MUCH there that it can be hard to read through.
- agumonkey 13y ago
  Truth lies in the middle. I can imagine javascript concise when writing with combinators such as those in Javascript allonge, it gets close to CS. While I fear CS can cross the perlish cryptic threshold too easily.
- pyrrhotech 13y ago
  nicely indented? Install jsbeautify plugin in sublime, on save, your codebase will be beautiful and consistent. Brackets, semicolons, insignificant whitespace, var keyword, and named functions are some of Javascript's strengths. List comprehensions are nice, but be honest, how many times per year do you use them? I'd take JS over Coffee any day
  - lowboy 13y ago
    The lack of visual clutter like brackets, semicolons, the var keyword, and the addition of significant whitespace are some of Coffeescript's strengths. Some others are loop variable initialization, better hasOwnproperty checks, destructuring assignment, null soaking on objects, string interpolation, and array ranges. I've never found a good case for named functions over function expressions, other than maybe arbitrary order of source code. Even then, I usually put functions at the top of my files before they would be used in the script's execution. But to each their own. I don't use list comprehensions that often. I'd take CS over JS any day.
    - pyrrhotech 13y ago
      how about when debugging? nice to see function name in stack traces. You can use named function expressions in JS, you can't in CS
ch4s3 13y ago
If you can do HTML AND CSS you can learn HAML in an afternoon. It's literally CSS class naming conventions applied to HTML with indentation controlling scope. Its far easier to read and reason about than the alphabet soup that complex html turns into.
camus2 13y ago
> writing coffeescript is fun, coming back to make sense of what you wrote months later is an absolute nightmare if you document your code properly, there should be no issue figuring out what does what month later, I dont really find JS very readable,you often need to guess the intend of the programmer since there are little structures available. > debugging it is a massive PITA no problems with source maps. I use Coffeescript because it's more productive than writing Javascript , on average i write 40% less code with it.I dont have to lint anything,worry about prototype inheritance done right and my code feels more descriptive than imperative,thus more readable. The class system allows really powerfull metaprogramming. With nodejs and the source-map-support module, there is 0 issues. As for documentation there are tool that allow doc generation from cs source files, test generation for from cs classes ,etc ... There is a reason why there is all these transpiled languages around js, because most people just dont like writing JS code.
- Spiritus 13y ago
  >on average i write 40% less code with it And yet, by the end of the day you will have implemented the same amount of functionality. Reading and testing is what takes time, not writing.
deleted 13y ago
[deleted]

lucisferre 13y ago

I have literally taken people who are almost strictly HTML/CSS (limited or no coding) and had them hack on HAML with zero trouble. In fact they really enjoyed it.

trustfundbaby 13y ago
excellent, I've seen the opposite. Looks like our completely anecdotal observations cancel out :)
- agumonkey 13y ago
  Have you wrote about their issue somewhere else in details ? I'm on the same side as the parent comment[1] and I really wish to read and ~understand what I'm missing[2]. [1] I'm natively wired to run toward very dense 'interfaces' (ui, syntax) [2] Honest open question, don't wanna 'argue'.
- briandear 13y ago
  Is HAML really that hard? It seems pretty damned elementary to me. The hardest part is simply being sure you're using soft tabs. So called "front-end engineers" who can't understand haml after 3 minutes have no business calling themselves "front-end engineers"
  - trustfundbaby 13y ago
    Nope, but whats wrong with html or something that resembles it closely enough without the whitespace active stuff and extra syntax. I'll give you the answer ... nothing. Haml feels like just an unnecessary abstraction on top of something (html) that was just fine to begin with. But a lot of engineers seem to like it, so I think its great for those people. > So called "front-end engineers" who can't understand haml after 3 minutes have no business calling themselves "front-end engineers" Gotta love the arrogance of the remark :) Remember that there are tons of people that aren't classically trained "engineers" that have to work on apps around the world, lets spare a thought for them ;) More seriously, I don't think the argument is them understanding haml. The problem is the learning curve. Its not that steep but having to look up how to do stuff that you could just type right away from memory in plain html every 5 minutes, slows you down, and people want to move quickly. Theres also the fact that when haml breaks you get a Rails error vs the way html breaks which is that the display just looks all wonky. Lets not underestimate that. > Is HAML really that hard? Again, what are all the objective "benefits" of haml that necessitate having to learn this new abstraction? I can tell you why I use Rails over Cakephp, but what is the problem that haml is trying to solve exactly?
    - slantyyz 13y ago
      >> what is the problem that haml is trying to solve exactly Speaking only from personal experience (and I'm talking about my own bad habits with HTML), I have had plenty of bugs related to mismatched open and close tags in heavily nested HTML code, which would result in time consuming debugging. I've all but eliminated these types of issues by using Haml. I no longer have to worry about accidentally deleting the wrong close tag when de-nesting a block of markup. Is it a cure-all for everyone? Not at all. But for some people, it's a godsend.
- lucisferre 13y ago
  Except that yours doesn't make logical sense. You're suggesting that someone who is good (?) at HTML and CSS can't grok Haml syntax. That just doesn't compute.
coldtea 13y ago
It's sugar, why wouldn't they enjoy it? The thing, as with Coke, is if it's good for them.
- wambotron 13y ago
  As far as I know, Haml will not ruin their tooth enamel or wreak havoc on their kidneys. ;)
  - coldtea 13y ago
    No, but it will needlessy multiply entities and abstractions they have to deal with, even adding extra processing steps, without providing that much improvement to be worth it over vanilla HTML. As if HTML's problem was that it's not succint enough. Plus, I've heard that syntactic sugar causes cancer of the semicolon.

wambotron 13y ago

I've found the opposite with Coffeescript as far as returning to old code. It's clean, nicely indented, easy to follow. I don't use all of the shortcuts, though. For example, I'd never write a plain object without including the curly braces. With javascript, there is SO MUCH there that it can be hard to read through.

agumonkey 13y ago
Truth lies in the middle. I can imagine javascript concise when writing with combinators such as those in Javascript allonge, it gets close to CS. While I fear CS can cross the perlish cryptic threshold too easily.
pyrrhotech 13y ago
nicely indented? Install jsbeautify plugin in sublime, on save, your codebase will be beautiful and consistent. Brackets, semicolons, insignificant whitespace, var keyword, and named functions are some of Javascript's strengths. List comprehensions are nice, but be honest, how many times per year do you use them? I'd take JS over Coffee any day
- lowboy 13y ago
  The lack of visual clutter like brackets, semicolons, the var keyword, and the addition of significant whitespace are some of Coffeescript's strengths. Some others are loop variable initialization, better hasOwnproperty checks, destructuring assignment, null soaking on objects, string interpolation, and array ranges. I've never found a good case for named functions over function expressions, other than maybe arbitrary order of source code. Even then, I usually put functions at the top of my files before they would be used in the script's execution. But to each their own. I don't use list comprehensions that often. I'd take CS over JS any day.
  - pyrrhotech 13y ago
    how about when debugging? nice to see function name in stack traces. You can use named function expressions in JS, you can't in CS

ch4s3 13y ago

If you can do HTML AND CSS you can learn HAML in an afternoon. It's literally CSS class naming conventions applied to HTML with indentation controlling scope. Its far easier to read and reason about than the alphabet soup that complex html turns into.

camus2 13y ago

> writing coffeescript is fun, coming back to make sense of what you wrote months later is an absolute nightmare if you document your code properly, there should be no issue figuring out what does what month later, I dont really find JS very readable,you often need to guess the intend of the programmer since there are little structures available. > debugging it is a massive PITA no problems with source maps. I use Coffeescript because it's more productive than writing Javascript , on average i write 40% less code with it.I dont have to lint anything,worry about prototype inheritance done right and my code feels more descriptive than imperative,thus more readable. The class system allows really powerfull metaprogramming. With nodejs and the source-map-support module, there is 0 issues. As for documentation there are tool that allow doc generation from cs source files, test generation for from cs classes ,etc ... There is a reason why there is all these transpiled languages around js, because most people just dont like writing JS code.

Spiritus 13y ago
>on average i write 40% less code with it And yet, by the end of the day you will have implemented the same amount of functionality. Reading and testing is what takes time, not writing.

deleted 13y ago

[deleted]