Out of interest, who's using Less/Sass vs plain old CSS

[onjegolders]

One of the things I've put off learning has been LESS/SASS, seeing as I've always managed ok with CSS and there's never time enough to learn every new technology is there?!

Was just interested to see who used it occasionally, the whole time, never at all, waste of time, lifesaver etc...

I've certainly never struggled with just CSS but that's the way with so many new things, you don't know what you're missing until you try it

[Pete]

I'm really keen to take a look at LESS at some point since it seems like the easiest to set up (only requires a single .js file nowadays to be called before your CSS files so nothing to do on the server side).

I would say that the only time I think I could use it is on a new project or a re-design since some of my projects have huge stylesheets and it would be a pain to change them - plus they work the way they are now

My only issue is that using LESS CSS with minify won't work, but I just found this which looks like it could be the best of both worlds: http://wearekiss.com/simpless - basically write in LESS and it compiles back to CSS

[Soma]

I'm really keen to take a look at LESS at some point since it seems like the easiest to set up (only requires a single .js file nowadays to be called before your CSS files so nothing to do on the server side).

I would say that the only time I think I could use it is on a new project or a re-design since some of my projects have huge stylesheets and it would be a pain to change them - plus they work the way they are now

My only issue is that using LESS CSS with minify won't work, but I just found this which looks like it could be the best of both worlds: http://wearekiss.com/simpless - basically write in LESS and it compiles back to CSS

I use the .less apps http://incident57.com/less/ (mac, pc also is available elsewhere), that converts to regular CSS when saving (watching files), you can also set it to minify them. I'm not a fan of serverside or js runtime. It's basicly great tool to help using variables and mixins etc to write css.

[DaveP]

I mainly use plain vanilla CSS, but have experimented with LESS when using frameworks that have included such files. http://crunchapp.net/ is pretty good if you want to avoid client side LESS processing - for Mac & PC.

[Adam Kiss]

I would kill myself if I had to use pure CSS - Less and SCSS are such lifesavers; even if you're just using variables, color methods and a little bit of nesting.

I started using less since it's easier to get into - install app and you're done (later, they introduced paid application with SCSS ability as well), now I'm pretty much okay with anything, be it SASS, SCSS, LESS

I would say that the only time I think I could use it is on a new project or a re-design since some of my projects have huge stylesheets and it would be a pain to change them - plus they work the way they are now

with less (and sass as well, I believe), you just rename your current css file to .less or .scss, install one app (there are both sass/less apps for os x or win or linux), and just use the language you chose. If you start to modularize your css instantly the moment you work on something, you are fully on less or sass in two days.

Note: this was actually tested. Colleague of mine took 4k line css, and while working on that project, it took him two days to clean it up (about half went gone), modularize, and add new features he was actually working on.

[Marty Walker]

I'm using LESS exclusively now. I was using the JS version but recently switched to the PHP compiler. There's a lot to like about it and I'm only scratching the surface of it.

The code below (gleaned from that site) looks at when the LESS file was changed and compiles it into a CSS file.

<?php
include ('./lessc.inc.php');
function auto_compile_less($less_fname, $css_fname) {
// load the cache
$cache_fname = $less_fname.".cache";
if (file_exists($cache_fname)) {
$cache = unserialize(file_get_contents($cache_fname));
} else {
$cache = $less_fname;
}
$new_cache = lessc::cexecute($cache);
if (!is_array($cache) || $new_cache['updated'] > $cache['updated']) {
file_put_contents($cache_fname, serialize($new_cache));
file_put_contents($css_fname, $new_cache['compiled']);
}
}
auto_compile_less('smd.less', 'smd.css');
// Compile the mobile stylesheet too you crazy fool.
auto_compile_less('smd-mobile.less', 'smd-mobile.css');
?>

Once it's compiled I can then use Minify:

<?php
echo "<link type='text/css' rel='stylesheet' href='/min/b=site/templates&f=reset.min.css,smd.css' />";
?>

Regards

Marty

[slkwrm]

I've never used less, never had such a big project to really benefit from it.

Also wanted to mention lessphp (edit: ok,stillmovingdesign already did it).

It seems like it can be pretty easily integrated as a module and it's possible to use PW's caching with it to compile to css only when necessary.

[onjegolders]

Great replies guys, most articles I read about them seem to think that Sass was the forward-thinking one of the two because of Compass and just better all round. Do you not share that opinion or is just that Sass is much more hassle to use?

[yellowled]

Funny thing: I use Sass/SCSS because (for me) it's less hassle to use over LESS or Stylus.

I have yet to manage setting up a local nodejs server on my Ubuntu machine. Setting up Ruby is very easy, so my choice of using Sass was not at all related to the actual features of the preprocessor.

As far as I have looked at other preprocessors, it doesn't really make a big difference anyway. Stylus has a much more concise syntax, which might be the reason I'll check it out one day. Sass has the Compass library, which I use, but not extensively. I prefer to write my own mixins and only use Compass for the complicated stuff and for CSS3 features which are still subject to change. My workflow probably wouldn't change much if I had to use LESS or Stylus from now on.

Personally, I wouldn't want to go back to writing plain CSS, but that's another option, of course. I feel it has simplified my workflow massively, but like everybody else, I was sceptical at first, but now I can only recommend giving it a try. It really makes a lot of things much easier and less time-consuming.

[teppo]

Just my two cents:

First of all, when I first started to get into LESS and SASS, I found LESS documentation more "newbie-friendly" -- or perhaps just "friendly" in general -- and that's a big part of why I was instantly drawn into it instead of SASS. Not the best way to choose your tools, but that's still how it often goes..

The main reason why I haven't used LESS (or SASS/SCSS) in customer projects is that we have multiple people working on same projects, sometimes at the same time, so 1) compiling locally and just uploading a compiled CSS file isn't really an option (I'm not even considering letting JS handle compiling on a production site) and 2) I can't just jump in the LESS/SASS/SCSS bandwagon by myself without discussing it properly with others or I might have some serious explaining to do later on.

I do know that LESS can be compiled server-side with the help of Node and now that the PHP version was mentioned (thanks Marty!) I'm likely going to check that one out too, although the final deployment process still requires some thought.

Anyway, I'm sad to say this but all the hassle has already made me somewhat cynical about whether we really even need the added complexity and overhead compared to plain old CSS. Is it really THAT difficult to keep pure CSS files up to date? In my experience the answer is "very rarely" and I'm saying this even though I've worked with some seriously bloated relatively big stylesheets before. LESS/SASS/SCSS/whatever are definitely an improvement over plain old CSS, too bad they're not natively supported by browsers but require various tricks and gimmicks to run smoothly. Just saying.

Sorry for the rant and sorry for getting sidetracked. This is an interesting subject both in technological and theoretical sense and those always tend to get me on my toes. One of these days I'm definitely going to try LESS on a "large-scale" site just to get a better view whether or not it's really worth it -- until then the rant above pretty much summarizes how I feel

By the way: have you guys already seen the W3C draft for CSS Variables? It's not the same thing as these frameworks mentioned here, but it is a small step to the same direction: http://dev.w3.org/csswg/css-variables/.

[yellowled]

Is it really THAT difficult to keep pure CSS files up to date?

Although Sass and Compass make it easier to keep (vendor-prefixed) CSS3 up-to-date, it's (in my humble opinion) not its main benefit. For me, it's stuff like this: http://jsfiddle.net/yellowled/xMx5X/ This fiddle demonstrates a mixin in Sass which makes it pretty easy to create rather complex CSS constructs with one @include line. It also makes it easy to change said construct just by changing some variables. Of course, this can be done with an editor which supports snippets, but that requires a lot more work on your end, I guess.

[Martijn Geerts]

I use sass for bigger projects. I like to separate parts of the stylesheet to individual files as it is easier to maintain. Especially with media queries & stuff...

scss:
   _mq-mobile.scss
   _mq-tablet.scss
   _mq-normal.scss
   _mq-huge.scss
   _default.scss
   _helpers.scss
   _icons.scss
   _normalize.scss
   _print.scss

in style.scss:
@media only screen and ( max-width : 479px) {
   body:before { content: 'mobile'; };
   @import "mq-mobile";
}
@media only screen and (min-width : 800px ) and ( max-width : 959px) {
   body:before { content: 'tablet'; };
   @import "mq-tablet";
}

For smaller projects, just plain old CSS. For the preprocessing I used codekit, love the xtra's you get for validating css & js etc.

The reason I use sass is that the syntax looked great, then I decided to stick with it & not look anymore for Stylus or Less.

In bigger projects, a time saver.

[teppo]

@yellowled, I think you've proven your point; that looks really neat and (even better) re-usable.

That said, I'm still not 100% sure that this is something we need enough to justify the hassle involved. I'm painfully aware of the fact that most developers are always tempted to make everything look and feel cool and re-usable code wise (or markup / stylesheet wise) even if there's very little (or none at all) real, measurable value to be gained. Lately I've been trying to eliminate any and all extra steps in my own work -- as hard as it can sometimes be.

Will have to go through some older projects to see just how much trouble this could've saved me though. Hopefully I'll come to the conclusion that it's well worth it, since it really does make things much more beautiful (and to be completely fair I have to add that there's some real value in that already.. )

[yellowled]

That said, I'm still not 100% sure that this is something we need enough to justify the hassle involved.

I can only speak for Sass here, but I'm wondering what the hassle involved actually is. You need to set it up once, yes. It's not that painful on Linux, I assume it's about the same on OSX, but I have no idea how easy it is to set up Ruby on Windows. You mentioned working in teams – not my expertise, but I would assume that any team nowadays uses some kind of versioning system, so you would compile CSS from Sass files in the repository. So the team would only edit Sass files, and a Sass or Compass compiler running in the background would compile it to CSS files your project uses.

Then there's the syntax – are you aware you don't have to use Sass/SCSS syntax at all? You can just convert your current .css files to .scss files, and the preprocessor will compile them properly right away. Of course, you'll want to use Sass/SCSS syntax to make use of its benefits, but you can do that step by step. I would recommend starting by splitting up CSS files the way Martijn outlined above. I think we all love to work with small, maintainable files, and this is actually possible with Sass @imports (doesn't work well with plain CSS @imports). The next steps would probably involve using variables and nesting (beware, nesting can result in very bloated CSS results if applied where not necessary). Then one would probably get into using functions, calculations and mixins.

[teppo]

I can only speak for Sass here, but I'm wondering what the hassle involved actually is.

It's about the fact that we're developing solutions in our own environment where we have to consider long term performance, reliability, scalability and maintainability of every new solution we implement and mainly because of that I'm always very conservative when it comes to implementing anything that I don't consider "necessary" or (at least) "very advantageous." Everything we implement also has to support team work properly -- thus "write SASS / LESS code locally, compile and move to remote host" method is pretty much out of consideration.

There are various other things to consider too, but the main point here is that I'm not comfortable implementing anything new without knowing thoroughly what it does, how it does it and what are the benefits / costs involved (and in my humble opinion there are very few web-related techniques with no costs at all)

Edit: just wanted to clarify that while things like that mixin you posted definitely are neat, I would still argue that compared to raw CSS they are more complex and thus require more effort (which is multiplied if neat tricks like that are used on a regular basis) especially if you're not too familiar with SASS syntax -- thus they would need to provide some very real extra value to be considered "worth it." My point here is that just looking cool isn't always enough. I know that I'm being somewhat uptight here though, sorry for that

You mentioned working in teams – not my expertise, but I would assume that any team nowadays uses some kind of versioning system, so you would compile CSS from Sass files in the repository. So the team would only edit Sass files, and a Sass or Compass compiler running in the background would compile it to CSS files your project uses.

This is exactly what I'm worried about, quite possibly because I just don't know SASS / Compass well enough and SASS documentation isn't very helpful. They did mention that I can run sass with --watch param (I think it was something like that anyway) but what does it actually do -- is sass going to run as a background process and grab any .sass / .scss files that have changed automagically, or..?

If that's the case, then this sounds easier than I expected

Then there's the syntax – are you aware you don't have to use Sass/SCSS syntax at all?

I was aware of this and this is not such a huge problem really, though it's still something to consider if I did (and I can't imagine any reason not to) use SASS-specific syntax. Everyone else would also have to learn at least the basics so that they'll know what to do when things need to be changed -- not that it would be difficult to learn, but still. In environments heavily relying on team work you just don't go changing stuff / implementing new technologies without discussing it properly with other members of the team.

The next steps would probably involve using variables and nesting (beware, nesting can result in very bloated CSS results if applied where not necessary).

That's actually a shame, since this is one of the reasons why I've considered SASS / LESS so beautiful. Nesting FTW

[Nico Knoll]

I'm always using only CSS.

[Soma]

Only... I lol as if it were something less. *sssssasss*

[yellowled]

First of all: I get that it's hard to "just switch" from something that works. It took me 3 attempts to switch my text editor, so …

thus they would need to provide some real extra value to be considered "worth it." My point is that just looking cool isn't always enough.

I don't think it's about being cool, it's about not having to type the same goddamn thing over and over again. (It really does save a lot of typing.)

is sass going to run as a background process and grab any .sass / .scss files that have changed automagically, or..?

It can, yes. Let me briefly describe how I work with Sass/Compass, but note that it's not they only way to use it (in fact, it might not even be the most common one): I have a boilerplate config.rb file, which contains some configuration options for Sass projects, most notably locations for scss/css/img/js files. So basically it "tells" Sass where to find files needed and where to put files created. I set up a project folder which contains all the files required, including the Sass files. In that folder, I run "compass --watch" from a terminal.

That's it.

The compass command runs in the background (if you don't use Compass, "sass --watch" is just the same) and every time a sass file in said project is changed (i.e. saved), it re-compiles the resulting CSS file(s). No notable delay, but that might depend on the machine it's running on and the complexity of the project, i.e. the number of files involved.

[apeisa]

For me CSS is the "fun, easy and quick" part. I don't feel like I am wasting my time there and I feel like I can make much bigger gains by improving on other aspects of my work. There are so few browser quirks today and so many well supported new stuff on CSS that I find it almost relaxing. But I don't use reset.css or ie specific stylesheets either and I have pretty much dropped using browser prefixes... I don't organize my CSS much and I enjoy "clever chaos" on that stuff. Developer tools give me exact line number for the selector and that's it. I'm kind of oldschooler here

Of course if I would be doing more experiments and design on css or maintain large (= really huge) sites etc then I think it might be much more valuable for me. I am pretty sure that in some personal project I will try some css pre-processor, and if I find it huge improvement (like 5 times cleaner and faster than pure css) then I might start thinking how to make it part our workflow at Avoine. To be honest, I don't see that happening anywhere near though.

[teppo]

@yellowled: thanks for your patience and explanations. You have definitely persuaded me to at least give SASS a fair chance. Not saying that I'm still completely convinced, we'll just have to see how well that goes.

@apeisa: you're saying some things that I find a bit worrying (I love organized content and that concerns stylesheets too.. which is probably one of the reasons why SASS / LESS sound so tempting to me) but for the most part I believe that I share your view here. New features must prove their value before going into production, so to speak. Bad metaphor, but I hope you get my point

[Adam Kiss]

Oh my god, you're such an oldschoolers.

LESS/SASS FTW!

And let me repeat myself: you don't have to go to to CLI to install nothing. There are simple apps for everything; And there are even more advantages, if you design in browser, mainly variables.

Also I find something like this much easier on the eyes:

 font: 1em/2.5em $family;
 // make it or for

[Soma]

What Apeisa sais is also how I feel exactly.

If you find yourself repeating over and over you're doing it wrong.

I developed a style over the last 10-12 years where I need less and less very little CSS and thin code, it payed a lot and saved me a lot of time also from the experience of all the browsers and especially IEs.

But lately it has and will shift with the whole new palette of browsers evolving, devices, displays, tv's (next?) bandwidths etc. I remember where we followed ~50kB rules for a page. And it would be still possible in that range, and we can use lots of new techniques aswell. Requirements are different now and I felt less or sass brings in what CSS maybe missing and I find it really refreshing having the possibility there if really needed. Not the big part maybe. I've been using it in some projects to try and was quite happy to be able to define some stuff and it really allows for very different workflows which is pretty cool if you think about it and play around with it. Not creating another dependency is I think the important part here. If a team really is trained to use a defined workflow and they have fun doing so it sure can help on really big and complex projects.

[Adam Kiss]

Also, something else: since I've started using LESS/SASS, not once I needed to 'look up CSS by line', mainly because everything is neatly tucked in their own partial files...

[apeisa]

This is actually pretty interesting topic, started googling for more: http://blog.millerme...pre-processors/

My feeling for these pre-processors is the same feeling I have for CoffeeScript, nice syntax and features but too much overhead for no “real” gain. Syntax isn’t the real problem in Javascript for me the same way that it isn’t the real problem in CSS (and most of the languages). You still need to understand how the box-model works, specificity, cascading, selectors, floats, browser quirks, etc… you are just adding another layer of abstraction between you and the interpreted stylesheet, adding yet another barrier for future developers and increasing the chance of over-engineering. Markup may become simpler (with less classes/ids) but it comes with many drawbacks.

For me the greatest problem are developers that code CSS without the knowledge required to build a maintainable and scalable structure. A stylesheet full of mixins, if/else, loops, variables, functions, etc, will be as hard to maintain as a bloated hand-crafted stylesheet, if not harder. Developers have an inherited desire to be “clever” and that is usually a red flag.

Then there is this from 2009: http://nathanborror....0/sass-isnt-me/ and in comments Jeff Croft says:

Couldn't. Agree. More.

I keep checking in with Sass and LessCSS every month or so to see where they're at, and while I think a lot of the concepts are great, I just can't actually make myself use one, for the reasons you state.

I really think the biggest problem here is that the developers behind these things aren't designers, CSS gurus, or even front-end developers -- they're programmers. They don't really understand the real problems us CSS'ers face, because they generally don't use CSS in the kind of advanced ways we do. That's not a slight against them -- it's just reality.

They've built tools that allow them to scratch their itch with CSS -- but their itch is apparently very different then mine, or yours.

Forward few years and from Jeff's own blog (http://jeffcroft.com...eature-of-sass/):

If you read my blog, or follow me on Twitter, you know that Sass is one of my favorite tools in my web stack. It makes writing css so much more efficient and painless, and I really can’t imagine living without it.

[MadeMyDay]

My first contact to a preprocessor was "turbine", a PHP based one which is quite comparable to stylus and SASS. Now I use stylus for every project. I don't like curly brackets, I don't even need colons. For me it is really pain in the a.. to modify older projects or projects from others which use plain CSS. I am writing my CSS pretty fast and the cascading is so much easier to follow once written. Since one writes HTML from the outer elements to the inner ones, I am very comfortable with writing CSS the same way.

For example:

<header>
<nav>
 <ul>
  <li>
   <a>home</a>
  </li>
  <li>
   <a>products</a>
  </li>
  <li>
   <a>services</a>
  </li>
 </ul>
</nav>
</header>

isn't it natural to write the CSS the same way?

header
max-width 1280px
height 200px
margin 20px auto
padding 10px
position relative
nav
 width 750px
 right 0px
 top 100px
 height 50px
 position absolute
 > ul
  > li
   float left
   position relative
   height 50px
   display block
   line-height 50px
   text-align left
   padding 0 20px
   transition(all 0.3s ease-out)
   background weisstrans
   > a
 headline(18)
 white-space nowrap
 padding 10px 0px
 transition(all 0.3s ease-out)
   &:hover, &.active
 background blautrans
 transition(all 0.3s ease-out)

You also see other benefits like mixins, variables and so on. I would miss the advantages a lot, really! And it doesn't matter if LESS, SASS or stylus. You will never go back, promised!

Sorry, indentation is wrong with this forum editor, but I think you get it.