Is it worth to learn haml & sass?

In your professional experience have haml & 开发者_高级运维sass proved to be useful? In which way?

---

Haml is nice, and I use it a lot, but Sass is worth it alone, especially if you have to build complex stylesheets. For example, one of the worst things about CSS is how much redundancy you have to do when naming selectors. In CSS, you have to do

#navbar ul 
#navbar ul li a
#navbar ul li a:hover

With Sass, you can simply nest these decendants naturally.

#navbar

  ul
    margin: 0
    padding: 0
    list-style: none
    width: 100%

    li
      margin: 0
      float: left
      margin-right: 10px
      border: 1px solid #000

      a
        text-decoration: none

        &:hover
          color: red

You can also use variables

!border_color = #333

.box
  border = 1px "solid" !border_color

And you can use math with them

!measure = 18px
!text_size = !measure / 1.5

body
  font-size = !text_size
  line-height = !measure

h1
  font-size = !measure
  margin-bottom = !measure

h2
  font-size = !measure + 2

#wrapper
  width = !measure * 50

You can also share code

=rounded
  -moz-border-radius: 4px
  -webkit-border-radius: 4px
  border-radius: 4px
  border: 1px solid #000

.box
 +rounded

There's so much power in this that you owe it to yourself to learn it. Plus, the end result is plain CSS so it can be converted.

Don't forget about css2sass which converts your existing css to sass files!

You can play with some examples at http://rendera.heroku.com/ if you'd like. It's a site I built to help people learn HTML5 and CSS3 and I have support for both HAML and SASS there.

Also, take a look at StaticMatic (staticmatic.rubyforge.org) for an amazing way to do static web site work with HAML and SASS. It generates web sites you can upload to static hosts and has a layout and template system similar to Ruby on Rails.

To address the direct question you asked, by way of "is it worth it", the answer is yes. Being able to use variables, easily group things by selector, and share code via modules makes complex stylesheets much easier. Building the stylesheets doesn't take long at all, and you can use the excellent Compass framework to go even further. For example, you can use the 960.gs or Blueprint modules to mix those frameworks into your existing stylesheets. This way you don't have to change the markup of your code. Adding 960.gs and its "grid_12" and "container_12" classes to all of your markup might not be possible, but with Compass and Sass it's a breeze.

Sass also makes it easier to have multiple stylesheets for development mode and generate a single stylesheet for production, thus improving client-side performance (less calls to the server on page load.)

HAML has its own benefits, although they're not as noticeable as Sass. HAML does make it incredibly easy to nest elements and declare DIVS... using even regular 960.gs for example is easy with HAML:

#header.container_12
  .grid_12
     %h1 Welcome!
#middle.container_12
  .grid_8
     %h2 Main content
  .grid_4
     %h3 Sidebar

Much less typing. And if you decide you need to add a wrapper around all of that for some reason, just indent the whole thing beneath a new tag.

Hope that helps. I <3 Sass.

---

My current web site has over 800 Haml files and 150 Sass files, and let me tell you it has helped my development tremendously.

The biggest boon is in terms of rapid development: creating Haml/Sass files requires far less typing, so you can nail out your presentation logic with far fewer keystrokes than if you were doing an erb template.

I also find Haml files far easier to read, and less error prone.

YMMV, but I have reached the point that not using Haml feels like a chore.

---

TL;DR - While popular, I prefer not to use HAML or SASS, but I like SCSS.

It seems that the general consensus on HAML is overwhelmingly in favor of it, but personally I do not care for it.

If my intention is to generate HTML, then I prefer the template language to be as close HTML as possible. This avoids having to learn another layer of indirection which adds opportunity for confusion and error as well as incurring cognitive overhead.

I find the constraints that HAML places on my preferred use of whitespace for readability and line wrapping to be onerous and often results in a syntax that can be difficult to read.

Recently I encountered a subtle error in a HAML template that would have been immediately obvious if the template were ERB, for example:

 .table
   .thead
   .tr
   .tr

The table rows are not within the THEAD tag, which is perfectly valid HAML, but incorrect with respect to the intended HTML structure. While the page appeared to render properly, a CSS selector failed, which resulted in a silent failure of some Javascript code.

I'm sure this kind of error would be obvious to most HAML users, as shown in isolation, but in the context of a larger template, it can be hard to spot; especially to a developer new to HAML.

On the other hand, if this were ERB or HTML:

 <table>
   <thead>
   <tr>...</tr>
   <tr>...</tr>

To my eye, the error in structure is much easier to spot due to the way ERB and HTML are nearly always indented.

Having spent nearly two decades writing HTML, I must admit that I have a certain pride in writing well formed HTML and I see no reason to learn a different way of representing it and learning all of the new visual patterns needed to spot errors.

On the other hand, I very much like SCSS (as opposed to SASS) because SCSS is essentially a superset of CSS. It does not add a completely new layer of indirection that I need to mentally translate. It adds only a modest change in syntax which provides a more concise (and DRY) representation of CSS which I find very easy to read and understand.

Indeed, I prefer not use to any language that enforces a strict syntax regarding how I should indent or line wrap my code such as python. Or languages that serve only as an indirection layer on top of an underlying language such as coffeescript.

I'm not saying that I believe abstraction and indirection are bad in programming languages; only that I prefer not to use them with respect to the specific languages discussed here.