No more Haml or CoffeeScript(kirillzubovsky.com)
kirillzubovsky.com
No more Haml or CoffeeScript
http://kirillzubovsky.com/no-more-haml-or-coffeescript/
90 comments
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.
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.
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 errorBut 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.
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
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.
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.
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 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?
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?
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.
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.
* 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)
* 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 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.
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.
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.
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.
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.
"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.
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.
>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.
I've never seen non-trivial gains by either, either in readablity or expressibility. A few less lines != more readable.
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.
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
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
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.
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 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.
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.
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]
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
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:
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!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...
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.
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.
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
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
> 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.
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.
>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.
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.
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.
With javascript, there is SO MUCH there that it can be hard to read through.
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.
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
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
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.
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.
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
Yup, good point.
Apparently a future version of CS or CSRedux will have it so that this CS:
Apparently a future version of CS or CSRedux will have it so that this CS:
myFn = ()->
# function body
var myFn = function myFn() {
// function body
}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.
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.
excellent, I've seen the opposite. Looks like our completely anecdotal observations cancel out :)
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"
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?
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?
>> 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.
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.
Learning HAML is elementary. Writing HAML consistently well enough to avoid triggering unnecessary compiler errors due to minor indentation issues that simply wouldn't affect output if you were writing HTML/ERB is a different matter, a particularly irritating trait for a markup language. It's not difficult to imagine good engineers being considerably less productive in HAML
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'.
[1] I'm natively wired to run toward very dense 'interfaces' (ui, syntax)
[2] Honest open question, don't wanna 'argue'.
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.
It's sugar, why wouldn't they enjoy it? The thing, as with Coke, is if it's good for them.
As far as I know, Haml will not ruin their tooth enamel or wreak havoc on their kidneys. ;)
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.
Plus, I've heard that syntactic sugar causes cancer of the semicolon.
[deleted]
I've watched these precompilers come and (perhaps) go. Granted, I'm a big fan of the likes of SASS, LESS, and tools built on those platforms such as Autoprefixer, as those give me new tools (mixins, variables, modularization, automatic vendor prefixes) I don't have in the "native" language they compile into.
HAML and Coffeescript only change the syntax.
To me, this adds little value. If Javascript appears scary, spend more time with Javascript so groking it becomes easier for your brain. Making a tangental change to a completely different syntax seems like a wasted investment. When debugging in the browser, you're still going to require knowledge of JS, even with source mapping. Delving into other libraries will still require knowledge of JS. The entire JS community is not hardened in Coffeescript, so the pivot you make to learning Coffeescript is time not spent learning JS, setting you behind when groking other source.
HAML seems to add even less. HTML is just markup, it can only ever get so scary, and if you're in control of the source, you should strive to not make it scary. HAML seems like the worse case scenario for hand-holding.
That is to say, I'm not against precompilers that actually add something useful. I'm in the middle of evaluating TypeScript, and depending on its 1.0 release and its community support, I may very well choose to fully adopt it. But for me to start using your precompilation tool, you better be adding more than just syntactical changes. If you're worried about needing tools to help you remember to close an HTML tag, your problem isn't with the language, you just need to become a better programmer.
HAML and Coffeescript only change the syntax.
To me, this adds little value. If Javascript appears scary, spend more time with Javascript so groking it becomes easier for your brain. Making a tangental change to a completely different syntax seems like a wasted investment. When debugging in the browser, you're still going to require knowledge of JS, even with source mapping. Delving into other libraries will still require knowledge of JS. The entire JS community is not hardened in Coffeescript, so the pivot you make to learning Coffeescript is time not spent learning JS, setting you behind when groking other source.
HAML seems to add even less. HTML is just markup, it can only ever get so scary, and if you're in control of the source, you should strive to not make it scary. HAML seems like the worse case scenario for hand-holding.
That is to say, I'm not against precompilers that actually add something useful. I'm in the middle of evaluating TypeScript, and depending on its 1.0 release and its community support, I may very well choose to fully adopt it. But for me to start using your precompilation tool, you better be adding more than just syntactical changes. If you're worried about needing tools to help you remember to close an HTML tag, your problem isn't with the language, you just need to become a better programmer.
"If Javascript appears scary, spend more time with Javascript so groking it becomes easier for your brain."
I knew JavaScript better than probably 99% of JavaScript developers. I was skeptical of CoffeeScript until I was forced to use it for a couple weeks, and haven't looked back since.
I knew JavaScript better than probably 99% of JavaScript developers. I was skeptical of CoffeeScript until I was forced to use it for a couple weeks, and haven't looked back since.
You only think you knew javascript that well. Your anecdotal evidence is unsupported by reality. You likely never really liked or used javascript as much as a real javascript developer. Let me guess, you're "full stack".
Idunno, all HAML does is to relieve you of the need to track down closing tags. If you like closing tags, fair enough, but this is really all it does.
Common, this is a vague and unconvincing article, I suspect people up voted for it for its opinion rather than reasoning
> First, compiler languages require some learning.
Every new technology require some learning. This shouldn't be the number 1 reason not to use one.
> Second, both languages make debugging a harder process.
Haml harder to debug than html? How so? Coffeescript harder to debug javascript? Maybe there is an extra step, but how do you weigh in the better readability in CoffeeScript when it comes to debugging complex code?
> Lastly, there are just too many dependencies.
"Every time I touch code, I am forced to touch two levels of abstraction." I seldom if ever need to touch the javascript file compiled from the coffeescript. And I really don't see how come more coffeescript files is more complex to handle than a couple of coffeescript? I can assume that you don't manually compile them one by one right?
> First, compiler languages require some learning.
Every new technology require some learning. This shouldn't be the number 1 reason not to use one.
> Second, both languages make debugging a harder process.
Haml harder to debug than html? How so? Coffeescript harder to debug javascript? Maybe there is an extra step, but how do you weigh in the better readability in CoffeeScript when it comes to debugging complex code?
> Lastly, there are just too many dependencies.
"Every time I touch code, I am forced to touch two levels of abstraction." I seldom if ever need to touch the javascript file compiled from the coffeescript. And I really don't see how come more coffeescript files is more complex to handle than a couple of coffeescript? I can assume that you don't manually compile them one by one right?
There's a lot of reasons to not use abstraction languages like CoffeeScript and Haml, but the reasons the author cites are weak.
> First, compiler languages require some learning. HAML is awesome, but the number of people who know how to write it is small. That means every time we need to make a change to Scoutzie, not everyone can get tasked with updates. Same goes for Coffee.
I'm sorry to hear that you don't have a culture of learning and teaching other people at your company new technologies.
> Second, both languages make debugging a harder process. When something breaks and I try to fix it, I can't always tell right away whether it's due to poorly written logic, or simply improperly written code.
Both CoffeeScript and Haml have syntax errors so you can tell whether your error is syntax related or not.
> Lastly, there are just too many dependencies.
If you're using Rails, which it sounds like you are, the coffee-rails gem is in your Gemfile by default. I've never had any issues with the coffee-rails or Haml gems in 3 years of using them. I hardly notice that they are even there.
> First, compiler languages require some learning. HAML is awesome, but the number of people who know how to write it is small. That means every time we need to make a change to Scoutzie, not everyone can get tasked with updates. Same goes for Coffee.
I'm sorry to hear that you don't have a culture of learning and teaching other people at your company new technologies.
> Second, both languages make debugging a harder process. When something breaks and I try to fix it, I can't always tell right away whether it's due to poorly written logic, or simply improperly written code.
Both CoffeeScript and Haml have syntax errors so you can tell whether your error is syntax related or not.
> Lastly, there are just too many dependencies.
If you're using Rails, which it sounds like you are, the coffee-rails gem is in your Gemfile by default. I've never had any issues with the coffee-rails or Haml gems in 3 years of using them. I hardly notice that they are even there.
To expand on your second point. Debugging coffeescript has become pretty easy with Chrome and Firefox supporting source maps. With livereload and coffee's autocompile (watch & compile flags) I basically skip the build steps. For me, coffeescript was similar in syntax to Python (our main language at work) and it makes everything much cleaner compared to JS for big projects.
I agree with your opinion on CoffeeScript, but HAML is so petite and small - you can learn to use it in 15 minutes.
Granted, I don't use HAML because it's syntax is ugly; I prefer Slim. I vastly prefer using SLIM as opposed to raw HTML with horrendous tags. Compare:
Granted, I don't use HAML because it's syntax is ugly; I prefer Slim. I vastly prefer using SLIM as opposed to raw HTML with horrendous tags. Compare:
<p><%= @user.name %></p>
p= @user.name
If you can train your mind not to let the brackets and closing elements add to your cognitive load, then it's not so bad with raw HTML.
Is a very slight syntax change really a "smarter tool"?
Yes, yes it is. Time spent on dumb things adds up specially if you do it for 8 hours a day.
I think maybe it's a semantics thing. I'm not going to claim it's not a smart choice to pick a more expressive language... I just don't know that I think of syntactic expressivity a large enough gain to call the tool itself smart.
I don't like HAML as much as I did, but one thing I do know about preprocessors:
I can't get many HTML developers to write valid markup. A preprocessor that won't build your HTML file until you satisfy its syntax prevents that.
And I can never accept "because learning it is hard and what we know works fine" as a valid argument.
I can't get many HTML developers to write valid markup. A preprocessor that won't build your HTML file until you satisfy its syntax prevents that.
And I can never accept "because learning it is hard and what we know works fine" as a valid argument.
We've come to the same conclusion with coffeescript but for a different reason. We're starting to move away from it to simplify our build process.
We have tons of little modules that are all in coffeescript that need to be compiled to js before we run component-build. Just not having to deal with that step would simplify everything. We're starting to value simplicity over fancy things at scale.
Kind of made me appreciate the thesis of Go a bit more now. I was initially unimpressed with the lack of language features in Go. Once you get to a larger sized codebase you start caring less about fancy features and more about agility and build times funny enough.
We have tons of little modules that are all in coffeescript that need to be compiled to js before we run component-build. Just not having to deal with that step would simplify everything. We're starting to value simplicity over fancy things at scale.
Kind of made me appreciate the thesis of Go a bit more now. I was initially unimpressed with the lack of language features in Go. Once you get to a larger sized codebase you start caring less about fancy features and more about agility and build times funny enough.
A template engine for HTML is unavoidable if you're using a framework. It's important to select the one you use carefully. I used Haml until I found Slim. Haml syntax vagaries bit me more than Slim's did.
I love Coffeescript and use it whenever I can, for the reason that the compiler output generated by it is better than my own Javascript. I consider the complexity of the added layer to be worth it. 95% of the time Coffeescript saves me time writing, and the 5% of the time spent debugging is made easier with the tool at coffeescript.org. My javascript workflow has only been enhanced by Coffeescript, not hurt. Then again, I don't write large, sprawling programs in Javascript and consider it a smell when it does start getting complex.
I can't say the same about Slim, it hasn't been an unqualified boon, but still overall I feel it's an improvement.
I love Coffeescript and use it whenever I can, for the reason that the compiler output generated by it is better than my own Javascript. I consider the complexity of the added layer to be worth it. 95% of the time Coffeescript saves me time writing, and the 5% of the time spent debugging is made easier with the tool at coffeescript.org. My javascript workflow has only been enhanced by Coffeescript, not hurt. Then again, I don't write large, sprawling programs in Javascript and consider it a smell when it does start getting complex.
I can't say the same about Slim, it hasn't been an unqualified boon, but still overall I feel it's an improvement.
Whenever I consider a language for a task, I try to ask myself what advantages the language has towards my task. I don't try to think of the downsides of the language at first, just the advantages.
So what does CoffeeScript give me, that JavaScript does not already have? It actually doesn't give you anything. It takes things away from JavaScript, things like explicit variable declarations (I throw "use strict" everywhere these days), and white-space independent syntax. It renames "function()" to "()->". It renames "if(condition)statement;" to "statement if condition".
Regardless of whether or not you like these things, the ultimate point is that CoffeScript, as a language, does not give me anything new, it doesn't provide anything which which I can do things any differently than JavaScript. At least for now, we need to know JavaScript, because there is too much in the wild to be ignorant of it and the transpilers aren't 100% perfect yet (leaving too many cases where you have to inspect the generated code). So why ever bother picking up another language that is, at best, a wash in terms of productivity?
On the other hand, something like ClojureScript (which I don't use, for other, unrelated reasons) gives me something. It gives me a Lisp-like language in which to write client-side applications. I know people say "JavaScript is a Lisp", but try writing good macros in raw JavaScript sometime and see how long it takes you to blow out your brains.
Similarly, TypeScript gives me static type checking, instead of having to hand-write all of my duck-typing checks. A much more explicit syntax for doing object oriented programming. A module system (though I'm not very much in love with require() style includes, I prefer namespaces).
So CoffeeScript won't likely ever be in my toolbox. Curly braces don't make my eyes cross, and I don't understand how they could ever be such a huge distraction to warrant brittle, white-space based syntax. You Pythonistas confuse the hell out of me: what are you programming that to curly brace or not to curly brace is a significant concern for you?
Note that I have no experience with Haml, so I will refrain from comments.
So what does CoffeeScript give me, that JavaScript does not already have? It actually doesn't give you anything. It takes things away from JavaScript, things like explicit variable declarations (I throw "use strict" everywhere these days), and white-space independent syntax. It renames "function()" to "()->". It renames "if(condition)statement;" to "statement if condition".
Regardless of whether or not you like these things, the ultimate point is that CoffeScript, as a language, does not give me anything new, it doesn't provide anything which which I can do things any differently than JavaScript. At least for now, we need to know JavaScript, because there is too much in the wild to be ignorant of it and the transpilers aren't 100% perfect yet (leaving too many cases where you have to inspect the generated code). So why ever bother picking up another language that is, at best, a wash in terms of productivity?
On the other hand, something like ClojureScript (which I don't use, for other, unrelated reasons) gives me something. It gives me a Lisp-like language in which to write client-side applications. I know people say "JavaScript is a Lisp", but try writing good macros in raw JavaScript sometime and see how long it takes you to blow out your brains.
Similarly, TypeScript gives me static type checking, instead of having to hand-write all of my duck-typing checks. A much more explicit syntax for doing object oriented programming. A module system (though I'm not very much in love with require() style includes, I prefer namespaces).
So CoffeeScript won't likely ever be in my toolbox. Curly braces don't make my eyes cross, and I don't understand how they could ever be such a huge distraction to warrant brittle, white-space based syntax. You Pythonistas confuse the hell out of me: what are you programming that to curly brace or not to curly brace is a significant concern for you?
Note that I have no experience with Haml, so I will refrain from comments.
> You Pythonistas confuse the hell out of me: what are you programming that to curly brace or not to curly brace is a significant concern for you?
You assume this is why people use Python instead of Jaascript. It's simply what the ignorant latch on to as "different" when they need something to blather about. I make just as many cut/paste errors in Python as I do in Javascript--very few.
I use Python because I can generally count on the fact that it has what I need "built-in". Last example I had about this was that I could open a promiscuous socket and suck up UDP packets quite easily from Python, while doing that in Javascript was a mess. There are lots of little examples like this.
I'm actually waiting for a replacement for all of my current "go to" languages: C, Python, and Javascript. A language that does concurrency well would cause me to leap from those.
You assume this is why people use Python instead of Jaascript. It's simply what the ignorant latch on to as "different" when they need something to blather about. I make just as many cut/paste errors in Python as I do in Javascript--very few.
I use Python because I can generally count on the fact that it has what I need "built-in". Last example I had about this was that I could open a promiscuous socket and suck up UDP packets quite easily from Python, while doing that in Javascript was a mess. There are lots of little examples like this.
I'm actually waiting for a replacement for all of my current "go to" languages: C, Python, and Javascript. A language that does concurrency well would cause me to leap from those.
Sorry, I didn't mean "Python instead of JavaScript", and I also didn't mean to lump all Python users into one group. I had hoped using the term "Pythonista" would connotate a die-hard user, one of those people who argue on message boards at length of the great superiority of white-space syntax.
And while I don't like white-space syntax, personally, I don't get the general debate as a whole, for the reason you mentioned: haven't made more than a handful of copy-pasta errors in the last decade. It seems like a 6-or-one-half-dozen issue, so if it's being used as a selling point of a particular language (i.e. one of the more substantial differences between CoffeeScript and JavaScript), then it's not much of a selling point at all.
Your last sentence is actually very closely to my point. Yes, the languages we have aren't perfect, but there aren't any better alternatives yet. Give me an alternative and I'll gladly use it. I'm actively evaluating languages as we speak. But I need real advantage to switch from what I'm already using. A handful of regex's in a loop over stuff I already know isn't enough.
And while I don't like white-space syntax, personally, I don't get the general debate as a whole, for the reason you mentioned: haven't made more than a handful of copy-pasta errors in the last decade. It seems like a 6-or-one-half-dozen issue, so if it's being used as a selling point of a particular language (i.e. one of the more substantial differences between CoffeeScript and JavaScript), then it's not much of a selling point at all.
Your last sentence is actually very closely to my point. Yes, the languages we have aren't perfect, but there aren't any better alternatives yet. Give me an alternative and I'll gladly use it. I'm actively evaluating languages as we speak. But I need real advantage to switch from what I'm already using. A handful of regex's in a loop over stuff I already know isn't enough.
> So what does CoffeeScript give me, that JavaScript does not already have? It actually doesn't give you anything.
This seems like the core of your argument against CoffeeScript, but it's fundamentally flawed. CoffeeScript fixes javascript's warts, eg. it gives consistent scoping rules, simplied/sane classes, list comprehensions, enforces per file encapsulation etc.
You seem to think that CoffeeScript is about aesthetics, but that's probably the least important feature of it.
This seems like the core of your argument against CoffeeScript, but it's fundamentally flawed. CoffeeScript fixes javascript's warts, eg. it gives consistent scoping rules, simplied/sane classes, list comprehensions, enforces per file encapsulation etc.
You seem to think that CoffeeScript is about aesthetics, but that's probably the least important feature of it.
Happy to read this. My own gripe is open source projects that are CoffeeScript-first. CoffeeScript is a tool. Some people like it, some people hate it, and some people just don't get a big enough win from it to care. JavaScript is the native language, and to expect someone to read documentation or source code in something that might not be familiar to them is a frightening direction or tendency.
If you are writing docs, you should be writing JavaScript.
If you are writing docs, you should be writing JavaScript.
To pose a counter-argument: should all open-source projects avoid jQuery? For many projects, it's a huge time saver, doesn't cause issues, and plenty of people like it.
I totally agree that if you want more people to use your code, you should consider the implications of tools like these, but often the tradeoff is worth it.
You don't have to use my code, so I'm going to use the tools that I think give the best results.
You don't have to use my code, so I'm going to use the tools that I think give the best results.
I think there's a difference between a dependency on a library, and choosing a syntax or language. If you do not rely on jQuery, or jQuery doesn't move your code forward, you absolutely should not depend on it. You can always spin off a pluginized version. Of course, jQuery is as near a standard component as JavaScript has, so I'm not surprised to see it so often as a dependency.
On the other hand, people learn JavaScript. It's the language of the web. CoffeeScript is something some developers prefer, and others do not prefer. Any CoffeeScript developer can read JavaScript, its native parent, but the opposite is not true.
Therefore, I respectfully stand by my original argument. :-)
On the other hand, people learn JavaScript. It's the language of the web. CoffeeScript is something some developers prefer, and others do not prefer. Any CoffeeScript developer can read JavaScript, its native parent, but the opposite is not true.
Therefore, I respectfully stand by my original argument. :-)
First off, I do like HAML and I don't really like CoffeeScript (anymore), but thats not the point.
What I see here is exactly what I've read in a rather old book (might've been the mythical man month, but not sure): There'll always be those people who don't care to wrap their heads around new ideas, because in their eyes they don't have an advantage. E.g. in the early days, assembly developer could not see an advantage in using a higher-level language such as C (:D), and when FORTRAN eventually came around, C programmers didn't really want to use that either. Why? Because if you spent time and energy on becoming proficient in something, be it assembly or javascript, the defensive but natural position of most people is to be skeptical of new ideas, because they diminish the value of their knowledge. If you're an expert in writing OO-code in JavaScript, and suddenly CoffeeScript comes around and lets everyone write "class" and be done with it, your JavaScript OO knowledge becomes less valuable.
Bottom line, I can hardly imagine anyone who'd be able to learn CSS, JavaScript, HTML and perhaps another backend language, including all the quirks and weirdness associated with these technologies, and then _not_ be able to wrap their heads around e.g. HAML, if presented with proper guidance. The same goes for CoffeeScript, even if the learning curve might be a little steeper than for HAML.
So are these specific technologies good ideas? I'd definitely say "yes" for HAML, and "don't know" for CoffeeScript (TypeScript perhaps?)... For both technologies, I agree with lucisferre:
> 2. Both offer non-trivial gains in terms readability of the written code.
> 3. Both can make future change of code non-trivially easier
What I see here is exactly what I've read in a rather old book (might've been the mythical man month, but not sure): There'll always be those people who don't care to wrap their heads around new ideas, because in their eyes they don't have an advantage. E.g. in the early days, assembly developer could not see an advantage in using a higher-level language such as C (:D), and when FORTRAN eventually came around, C programmers didn't really want to use that either. Why? Because if you spent time and energy on becoming proficient in something, be it assembly or javascript, the defensive but natural position of most people is to be skeptical of new ideas, because they diminish the value of their knowledge. If you're an expert in writing OO-code in JavaScript, and suddenly CoffeeScript comes around and lets everyone write "class" and be done with it, your JavaScript OO knowledge becomes less valuable.
Bottom line, I can hardly imagine anyone who'd be able to learn CSS, JavaScript, HTML and perhaps another backend language, including all the quirks and weirdness associated with these technologies, and then _not_ be able to wrap their heads around e.g. HAML, if presented with proper guidance. The same goes for CoffeeScript, even if the learning curve might be a little steeper than for HAML.
So are these specific technologies good ideas? I'd definitely say "yes" for HAML, and "don't know" for CoffeeScript (TypeScript perhaps?)... For both technologies, I agree with lucisferre:
> 2. Both offer non-trivial gains in terms readability of the written code.
> 3. Both can make future change of code non-trivially easier
Anyone who groups CoffeeScript and HAML into the same rhetorical category is plainly oversimplifying and really only positing an argument against the general use of abstractions.
HAML is so dead simple that if it takes your engineer more than a day to grok it, you have to admit that they're probably not yet cut out for anything but a junior role. HAML has zero debugging overhead because it's not a programming language; it's just not that hard, period. HAML does add an extra step to the build process, but who cares? It's trivial. In a world where CI and single command deploys are commonplace, the idea that an extra build step would prohibit the use of any developer tool seems absurd. It reminds me of people who argue against unit tests because "ugh, just another tool to learn", or "I end up writing more code in tests than actual code, I just want to ship". God forbid you actually have to learn something. While we're at it, please avoid the use of languages that compile to machine code because who the hell wants to deal with a linker in their build process?
Now, although I'm a huge CoffeeScript fan, CoffeeScript is an entirely different beast, and requires a deep understanding of JavaScript to use correctly. I can understand not wanting to devote time to teaching engineers about the finer nuances of CoffeeScript, especially if they aren't that experienced with JavaScript to begin with. In an ideal world, they'd pick up CoffeeScript as quickly as HAML since in my experience, CoffeeScript creates very readable code, especially when the script makes heavy use of anonymous functions, sadly, it's not always that simple. However, CoffeeScript debugging is a non-issue for an experienced JavaScript developer, CoffeeScript produces excellent JavaScript code that is easily understood. Individuals who like to minimize context changes can use sourcemaps.
Finally, dependencies for both tools are pretty trivial. I'm not sure how the author has managed to introduce 100 different gems into his project in order to support these tools, but it's certainly not a requirement.
https://github.com/haml/haml/blob/master/Gemfile
That's like 4 gems for HAML. CoffeeScript is often distributed as a binary, so zero gems required in that scenario. All in all, I'd say the author's case against these tools is pretty weak.
HAML is so dead simple that if it takes your engineer more than a day to grok it, you have to admit that they're probably not yet cut out for anything but a junior role. HAML has zero debugging overhead because it's not a programming language; it's just not that hard, period. HAML does add an extra step to the build process, but who cares? It's trivial. In a world where CI and single command deploys are commonplace, the idea that an extra build step would prohibit the use of any developer tool seems absurd. It reminds me of people who argue against unit tests because "ugh, just another tool to learn", or "I end up writing more code in tests than actual code, I just want to ship". God forbid you actually have to learn something. While we're at it, please avoid the use of languages that compile to machine code because who the hell wants to deal with a linker in their build process?
Now, although I'm a huge CoffeeScript fan, CoffeeScript is an entirely different beast, and requires a deep understanding of JavaScript to use correctly. I can understand not wanting to devote time to teaching engineers about the finer nuances of CoffeeScript, especially if they aren't that experienced with JavaScript to begin with. In an ideal world, they'd pick up CoffeeScript as quickly as HAML since in my experience, CoffeeScript creates very readable code, especially when the script makes heavy use of anonymous functions, sadly, it's not always that simple. However, CoffeeScript debugging is a non-issue for an experienced JavaScript developer, CoffeeScript produces excellent JavaScript code that is easily understood. Individuals who like to minimize context changes can use sourcemaps.
Finally, dependencies for both tools are pretty trivial. I'm not sure how the author has managed to introduce 100 different gems into his project in order to support these tools, but it's certainly not a requirement.
https://github.com/haml/haml/blob/master/Gemfile
That's like 4 gems for HAML. CoffeeScript is often distributed as a binary, so zero gems required in that scenario. All in all, I'd say the author's case against these tools is pretty weak.
What's worse is seeing documentation for npm modules where all the code examples are in CoffeeScript...please make it stop.
I wouldn't publish JS code in CoffeeScript, but for proprietary projects, especially Rails, I'd use CoffeeScript, HAML, and also, indented Sass. Coming from a different background, I was pretty resistant at first, but I think developers need to embrace different environments fully and see what the experience is, rather than molding it into something else or trying to force tools that don't belong. When in Rome and all.
So, if you're going to be working in a particular environment, be committed and embrace the experience.
So, if you're going to be working in a particular environment, be committed and embrace the experience.
The first argument is: It's easier to find people that already know how to use a more popular language. I don't like this argument. Why not take it all the way and drop ruby for a more popular programming language? Or, if they don't know HTML/JS but do know ruby, why not write a ruby tool to generate HTML and JS? Taken all the way, there's no reason to ever use a DSL.
I think that if your coworkers won't learn something new that's their problem to fix, not yours.
I think that if your coworkers won't learn something new that's their problem to fix, not yours.
People have been saying this stuff since Coffeescript first started making the rounds, but many adopted it anyway without any good reason to, and without any critical thinking about what implications using this "made up language" would have on their codebase and the life of their project. Coffeescript needs to fade into obscurity, where it should have stayed to begin with.
I don't really bother with these things, for the reasons listed here. I don't like how these concerns are brushed off, as if skepticism about these things means you're afraid of change or new tools or whatever.
When these things work they may make your development experience slightly nicer, but when they don't, you'll be sad about it. Just learn Javascript.
When these things work they may make your development experience slightly nicer, but when they don't, you'll be sad about it. Just learn Javascript.
I'm surprised that nobody seems to reference Dropbox or Github. Both companies are well-respected, successful, good at attracting talent, and choose to use CoffeeScript. I would wager that both generally manage programming projects that are larger than the majority of the HN community does.
Could you point out to evidence that they both use coffee extensively?
Here's the GitHub style guide:
https://github.com/styleguide/javascript
https://github.com/styleguide/javascript
Haml.
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.