[Recoil42]

You're actually the one missing something important: complexity.

His examples are simple, meant to give you an idea of how sass/less work on a basic level. But I'm currently working on site that is several thousand lines of CSS, employing enormously complex css structures. Pseudo-selectors are in use everywhere. As are complex gradients, shadows, sprites...

It's imperative to have some sort of organization in your code. Working with really long class names or IDs isn't an option.

For instance, on this project, we have a defined color set of colours. The red we're using is #c03838. The blue is #2767d1. A shadow used throughout the site is 1px 1px 3px rgba(0,0,0,0.2), and one of the gradients (used in a few places) looks like this when written out fully: http://i.imgur.com/YZi3f0B.png

It wouldn't make sense to memorize those values/strings. Not only that, but it would become a pain in the ass to change them in specific places over dozens of iterations if that becomes necessary. Instead, if I define things like $headline-color and $highlight-color, I can refer back to those in my header file, and change them throughout the site simply.

In the case of complex selectors, it becomes vastly more simple. Not only is your style sheet organized analogously to your dom tree, but it's infinitely more flexible, and doesn't require duplicate writing in the case of long chains.

Less/sass are a huge boon to front end development because they help you manage complexity. That won't come through in simple examples, but it should be obvious if you've ever written a stylesheet more than a few hundred lines long.

[Kiro]

"Working with really long class names or IDs isn't an option."

How does SASS/LESS solve this? Don't you still need the class names and IDs to hook it up with the DOM?

[Recoil42]

Yes. My point is that you avoid namespace conflicts.

Say you're building a windows-style scrollbar:

                |-> up arrow button
    scrollbar --|-> track -> drag button
                |-> down arrow button

Rather than having a CSS file (1) full of long, convoluted global class names:

    .scrollbar-frame{}
    .scrollbar-button-up{}
    .scrollbar-button-down{}
    .scrollbar-track{}
    .scroolbar-track-drag-button{}

or (2) full of overly-verbose endless trails (imagine how this gets when you're working with a complex object 5-6 levels deep)

    .scrollbar-frame{}
    .scrollbar-frame > .button-up{}
    .scrollbar-frame > .button-down{}
    .scrollbar-frame > .track{}
    .scrollbar-frame > .track > .drag-button{}

you can do this:

    .scrollbar-frame{
        .button-up{}
        .button-down{}
        .track{
            .drag-button{}
        }
    }

On compilation, you'll end up with a final result somewhat like example 2 -- but you weren't forced to write your first-level selector over and over the whole time. Your code also resembles the structure logic much closer at write time.

It gets better, too. Let's say we wanted to define our buttons in the classic windows 95/98 style -- grey, with a 1px relief border. In the classic CSS style, using example 2 as a pattern, we'd have to do it this way, duplicating our definitions the whole way:

    .scrollbar-frame{}
    .scrollbar-frame > .button-up{
        height: 20px; 
        width: 20px;
        background: #ccc;
        border-top: 1px solid #ddd; 
        border-left: 1px solid #ddd;
        border-bottom: 1px solid #888;
        border-right: 1px solid #888;    
    }
    .scrollbar-frame > .button-down{
        height: 20px;
        width: 20px;
        background: #ccc;
        border-top: 1px solid #ddd; 
        border-left: 1px solid #ddd;
        border-bottom: 1px solid #888;
        border-right: 1px solid #888;
    }
    .scrollbar-frame > .track{}
    .scrollbar-frame > .track > .drag-button{
        width: 20px;
        background: #ccc;
        border-top: 1px solid #ddd; 
        border-left: 1px solid #ddd;
        border-bottom: 1px solid #888;
        border-right: 1px solid #888;    
    }

However, using SASS/LESS, we could define a mixin. Using SASS, here's how you'd achieve the exact same thing:

    //Define a mixin
    @mixin greybtn{
        width: 20px;
        background: #ccc;
        border-top: 1px solid #ddd; 
        border-left: 1px solid #ddd;
        border-bottom: 1px solid #888;
        border-right: 1px solid #888;
    }

    .scrollbar-frame{
        .button-up{
            height: 20px
            @include greybtn; //Include our mixin.
        }
        .button-down{
            height: 20px
            @include greybtn;
        }
        .track{
            .drag-button{
                @include greybtn;
            }
        }
    }

The resultant code will be almost exactly the same, but you just wrote a lot less to get there, and will have an easier time of modifying it in the future. You can see the massive benefit in both speed and organization this allows, especially on large projects.

[Kiro]

This is actually a great argument. I'm almost convinced. However, in the second example, wouldn't it be better to just have a .scrollbar-frame > .button with all the styles and then just do class="button up" and class="button down"?

[coldtea]

Yes, but this enables it to be reused in other contexts, where the names "up" and "down" would not make much sense, but you would like to have the same border style for some reason.

Plus, you could turn this into a mixin "function", with the actual colors of the states changed depending on where you include it.

So the way he writes it, you could have a green, blue, whatever version of those borders, with the same one line (plus a parameter), whereas in CSS you would have to do:

up-blue, up-red, up-green, down-blue, down-red, down-green etc classes.