Some parts at least where I see LESS as useful:

= Separation of the codebase =
Separate your CSS into multiple files, smaller entities, more easily manageable when the project grows. And still compile the output into a single, compressed file (which is another benefit)

This also applies to external code that you include in your CSS. Like only include those parts of Bootstrap that you really use.

= Containers =


Isn't that easier to write than what it compiles to?

= Mixins =
These are extremely useful in many cases. Cannot give any specific example because there are so many. E.g. see the mixins in the Bootstrap framework, or build your own framework for some CSS3 attribute that needs 3 or more different versions (-webkit, -moz, -o, etc.) in normal CSS.


I'm sure there are other benefits as well that I've missed here but at least I find these parts extremely useful.

Less is so much better than straight css(sass is still more powerful, but less can be built into a php site)

You can set up styles where you can adjust a single colour rule and the whole sheet changes, everything that uses that colour and related shades, all automatic. Same with dimensions, all automatically recalculated.

When compiling a stylesheet, less will throw an error on any faulty rules. No more having to find them in the browser or use external checking tools.

You can also scope a whole load of rules by wrapping them in a single scoping rule. The ability to have a hierarchical structure results in much more tightly scoped css and reduced incidence or styles bleeding where they are not wanted.

As you note, simple examples look more verbose. But complex examples are considerably less verbose and much easier to manage changes.

You can also compile Sass (SCSS) into PHP:
http://leafo.net/scssphp/

Does not support the original Sass syntax but I think people are moving away from that anyways (which I have hoped for since its beginning).

I don't personally see Sass any more powerful than LESS. It's just a matter of syntax differences and preferences.

It's also matter of nuance differences e.g. in writing mixins. Sass might have some better abilities in terms of that but everything is possible with both alternatives.

Only time will tell us which one will be the de facto. I think currently they share quite similar adoption rates. There are different communities hailing for LESS (the majority of the PHP community) and different for Sass (the Ruby community for instance). That's why they both exist but I assume the other one will die at some point in the future.

I reckon CSS pre-processors are one of those tools that you sort of have to grow into, instead of immediately seeing their benefit.

I know that when I first looked at Less and Sass, it didn't immediately click. I sort of held off for a while, as we were using Skeleton for grids and we had our way of working.

Then I had a particular CSS problem where I wondered if I could programmatically output the CSS instead of hand coding it. The problem was something like that I needed to output a series of button styles but in a range of different colour schemes. I used Less for this and found it worked really well, especially when the client wanted a new scheme added...

Then I compared Less with Sass and picked Sass as some of the features and frameworks appeared to suit my way of working a bit better.

I prefer Sass but I'd never knock Less.
I prefer beer but also like cider - both are better than water.

Then I tried replacing my hard coded colour with variables.

Then I started to use the 'Compass' features of Sass. Instead of trying to generate all the vender prefixes for stuff like gradients, I let the Compass in Sass do that work. 1 line of code was generating multiple of cross browser CSS, including SVG generation to support browsers like IE9. I started putting clearfix mixins in my css and not clearfix classes in my HTML.

Then I started using the nested syntax, creating more readable code. I stopped using IDs heavily and started using classes as much as possible, using the nesting to better control specificity. I read the SMACSS book (again) and things started to click more.http://smacss.com/

Then I started breaking my stylesheets down into separate files, 'partials', to handle different components. I included normalize.css but also created a 'vendor' directory to link in the css of scripts we commonly used like flexslider. This combined all our separate stylesheets into a single compressed file.

Then I started using nested media queries. No more scrolling back up and down in a stylesheet to adjust an elements styling at different breakpoints.

Then I started (for concrete5.6.x) using partials and nesting to better handle the typography.css file. http://www.mesuva.com.au/blog/concrete5/managing-concrete5-typograp...

Then I started realising that I could simply drop my partials into new projects, to handle stuff like navigation, forms and other repeatedly styled components. I stopped re-looking up class names uses in blocks and started simply using the partials as guides to what needed styling.

I started to focus on the fiddliest bits of our projects and created some reusable and configurable components, e.g.http://www.mesuva.com.au/blog/technical-notes/a-sass-based-combined...

At this point we felt that we'd never write vanilla CSS again, things were just too good. Lelita and I were writing CSS much faster, but it was also much more maintainable and easier to navigate.

Then I started to feel that Skeleton was too restrictive and investigated what was on offer in terms of grid systems.

Then I discovered Susy grids (http://susy.oddbird.net/).

Everything I wanted from a grid system was suddenly available, plus some. We found we could set up any kind of grid we wanted, with any number of columns or sizing, even combining grids on the same page, and it was all really easy to code. We moved all of our non-semantic class names (like 'span3', 'off-set-1') out of our HTML.

Then we started combining Susy with nested media queries. We could change columns and sizing at any breakpoint we wanted to, for any element. Our sites became fluid and had breakpoints where the design needed adjusting, not at fixed sizes based on common screen dimensions. At this point I realised that we were now building _truly_ responsive sites and not just adaptive ones.

Then we realised that we could adjust an entire site's width by adjusting one number in the SCSS. We could widen an entire design a bit if needed, with everything kept in proportion.

Then we realised that Susy grids maintain their positioning regardless of source order. So we found that we could re-order page components for a logical order on mobiles without having to re-code any css.

So with all this learnt and in place, we now write better, more maintainable and more predicable css. We also find we do _much_ less debugging in IE8 and IE9.

Ultimately I'd estimate we spend less than 50% of the time we originally spent on styling now, tackling more complex designs. We're also much happier styling up sites and are constantly finding new and interesting ways to write better and cleaner code.

It's been the most valuable thing I've added to our development toolkit in the last several years.

Thanks for all of the info folks.

I started looking into Susy and now I'm deep into that rabbit hole - it looks great. As a side-effect it started me towards looking at other CMS solutions. <gulp>

Out of curiosity, what other CMS solutions were you looking at? What features are they offering that concrete5 5.7 doesn't?


Susy really is great and doesn't take very long to learn.

The Susy Two demos will get you up to speed quickly.
http://susy.oddbird.net/demos/

I also enjoyed the Sass Basics video course on Treehouse. The course instructor is Sass creator, Hampton Catlin.
http://teamtreehouse.com/library/sass-basics...
Treehouse free trial
https://teamtreehouse.com/subscribe/plans?trial=yes...
(also check your local library, many have Treehouse partnerships that offer free basic Treehouse memberships)

If you plan on using Susy, use LibSass to compile your Sass (instead of Ruby). LibSass is a C/C++ based Sass compiler that can be as much as 5 times faster than Ruby.

Some LibSass compiler options:

Brackets
- open-source
- as you type real-time Sass preview without saving (using brackets-sass extension)
http://brackets.io/
https://github.com/jasonsanjose/brackets-sass...

Takana for Sublime Text
- open-source
- as you type real-time Sass preview without saving
http://usetakana.com/

CodeKit
- paid
https://incident57.com/codekit/...

Prepos
- paid, with free unlimited trial for Sass compiling
http://prepros.io/

Grunt
https://github.com/sindresorhus/grunt-sass...

Gulp use
https://github.com/dlmanning/gulp-sass...

Thanks for all of the helpful links. I'm really enjoying Sass.

In terms of other CMS's it's not that C5 5.7 is missing features it is that the UI is not friendly. 5.6 has a great UI (aesthetics aside) for adding and editing areas. Specifically trying to add a block in 5.7 is difficult. In 5.6 it's a elegant. Click on an area and a context menu appears. I've yet to confuse a single client with this UI. More often than not they just get it.

In 5.7 I'm stumped more often than not. To add a block I need to click out of the area I am editing, aim for the plus plus symbol, drag an icon to a tiny target and pray I hit the right target.

I am willing to give up features if the interface is simple.

Thanks again for all of the Sass links.

In terms of UI, I think C5.7 is just getting there, it's just not fully polished at the moment.

I have to partly agree with you on the block adding part. Having built several sites now on 5.7, I've yet to experience the breeze of easiness of adding blocks. The adding / editing UI is still quite buggy (which I know will get better) and in 5.6 I felt that adding blocks was quite much quicker. The recently added feature of keeping the left-side menu locked helps this a bit but not much.

Even SquareSpace (that I know they've taken some influence from) is going the "old route" in terms of concrete5 UI. There's no drag+drop, you just click where you want a new block and then select what kind of. Two clicks (+ possibly a quick search) and you're there (as said above by @apc123).

Someone usually wants us to elaborate what we mean by "buggy", I mean sevaral things:
- The droppable areas sometimes do not show up in the correct spot,
- Trying to hit areas that are close to each other might be tough sometimes (as I think @apc123 referred to above)
- Sometimes afer adding a block, the scrollbar disappears forcing you to refresh the page to add another one
- Sometimes when entering the "in-context" editing mode of the content block, you see the content twice on top of each other, the other content slightly off positioned which makes editing really hard (it's like you were really drunk and seeing the same text in two spots)

I know these bugs will get fixed as we go but they are all hurting the experience. And as said I second your opinion about the drag + drop, an alternative way (the old way) would be greatly appreciated. It would just need bringing the "Add Block" action back to the in-context menu we already have for the areas.

I went down the LESS path first, but I wasn't ready for it. I checked out SASS a little while later and picked up the book Sass for Web Designers (find it on A Book Apart) and delved in.

I immediately saw the benefit and set to work getting comfy with it. It really didn't take too long before I was carving up my shylesheets into partials (a tremendous help), using variables and mixins - the biggest one for me was being able to write nested code. That's a huge win.

My point is - the leap is very doable and IMHO it's worth it as you'll become better organized at a higher level on your projects - you'll have cleaner css and spend less time writing CSS, more time actually getting sh*t done.

Good Luck!

You've got me excited to check out SASS :)
I've checked out LESS in the past, I get the concepts but haven't coded in it yet.
I've just been spending all day bug fixing some HTML/CSS I got someone else to code for me to "save me time" -- but it's not.
The SASS stuff you talked about sounds like it could be handy for what I do...

Bootstrap will drop out from LESS.
https://twitter.com/mdo/status/591364406816079873...

Bootstrap 4 (alpha) moved from LESS to Sass.
http://blog.getbootstrap.com/2015/08/19/bootstrap-4-alpha/...

@hissy

Thank you for the link.