Amber Weinberg: Freelance Web Developer specializing in semantic WordPress, Mobile, CSS and HTML5 Development

The Blog

January’s 12412: Researching LESS & SASS

Posted on 01/31/12 in blog, development about , , , ,

My first 12412 project was to research and learn about SASS. After the recommendation from several people, I also decided to check into LESS. I’d been hearing a lot about the two techniques and was quite skeptical – in fact it seems I’m often skeptical of new things out on the web. Most frameworks, shims and other “add-on”s are only a passing faze and tend to do more harm than good – and so with some trepidations I jumped in.

What is SASS & LESS?

Both SASS & LESS are CSS preprocessors, basically they’re created to help you code CSS quicker by allowing the use of basic programming principles. Both allow you to use variables, mixins, nested elements, functions and operators.

You basically put your CSS into a special file, and then when finished, your CSS is run through the preprocessor and it kicks out “normal” CSS. Huh.

I found LESS to be a lot easier to understand and install, although both of them worked pretty much the same way. You’re able to create variables within your CSS so you can reuse certain elements (for example, a hex code), and if it needs changing, you only have to do it in one place. Here’s where my inner-awesome-developer-sense kicks in. You can pretty much already do this with a basic class.

Another major feature in both SASS and LESS is the use of nesting, where you can “save” on repeating code by indenting elements instead of having to retype them, for example, if you indented p {} underneath an id of #header, then the CSS that’s printed out is actually #header p {}

While this seems pretty cool at first, I can easily see this as becoming cumbersome and crazy really quickly. When you’re not paying attention to what’s being outputted, your’re more likely to be lax in your coding.

Important Questions

I had several important questions before and after I read up on the technologies, and most of them really weren’t answered by any of the articles I read:

  1. What happens if another developer needs to edit the CSS and doesn’t know or realize a preprocessor is being used? How do you sync the two?
  2. When no longer writing CSS yourself, how do you control the structure and organization of the code? How do you ensure you’re optimizing it correctly?
  3. What happens if JS is down?
  4. Does it work with one line CSS?

All in all, I don’t think I’ll be using either SASS or LESS. Installation time, upkeep and the fact that it ruins the simplicity of CSS will keep me away. If you’re a developer who’s spent a lot of time optimizing your code and really learning the in’s of CSS (not just top level stuff), then you’ll find this pretty useless, as you already can quickly do the type of code it spits out.

I’m also worried on our recent reliance on Javascript and the trend of forcing languages and browsers to do something they’re not meant to do. It wasn’t even a year ago that everyone was worried about best practices and making sure we didn’t rely on Javascript for anything but the beauty layer. Now this is one more thing that can break.

Some of the features, like mixins and operators actually made the code a lot moreย convolutedย an jumbled, and seemed to take a lot more code than if you were just to type it out correctly in the first place. I also don’t see the point of operators – CSS isn’t a programming language and you can’t dynamically update styles so why not just type in the correct number in the first place?

Final Thoughts

Perhaps I’m wrong and you disagree – maybe you think SASS or LESS is the greatest thing since sliced bread. It’s just not for me. I would love your thoughts on it though!

Amber Weinberg specializes in clean and semantic HTML5, CSS3, responsive and WordPress development. She has over 15 years of coding experience and is super cool to work with. Amber is available for freelance work, so why not hire her for your next project?

Like this post? Please share it on Twitter or Facebook.

  • Ash Connell

    I agree. I came to the conclusion of keeping it simple by not employing these extra layers of complication.

    When I was mucking around with LESS I used a preprocessor that had a .less file and a .css file. You wrote everything in the .less file and everytime u saved it it would compile into the .css file. In production you would just upload the CSS file so future developers wouldn’t even know it was written using less.

    All in all I like the effort that went into this, but like you said, it just complicates something that was never complicated in the first place.

  • Exactly my thoughts – I love the simplicity of CSS by itself ๐Ÿ™‚

  • INow that I have switched to LESS, I’m personally not going to go back. Here’s my opnions on the questions you raised Amber:

    Point 1: Communication is always key. If you are working with another developer you should agree a set of standards to adhere to. This could be a problem if you were using CSS or LESS. They would still need to know how to format the code, naming standards etc.

    Point 2: You have to trust the LESS author(s) in this case. It’s an open source project with a number of people using it. So if it didn’t optimize properly, it would get fixed quite fast by the commonity.

    Point 3: I would never use the JS version on a website. It’s just too fragile as you said. The key is to precompile beforehand and push the final CSS up. This could be done as part of a build process that also does things like minimize CSS/JS. There are plenty of nice tools like CodeKit (http://incident57.com/codekit/) or LiveReload (http://livereload.com/).

    Point 4: I believe it does. Whitespace isn’t important like in normal CSS.

    I personally find preprocessors like LESS make development a lot easier. Variables are fantastic and I think make the code easier to read. The nesting helps keep your CSS grouped nicely. No more defining a rule in one place & then accidentally doing the same 100 lines down!

  • Ah there’s an ultimate problem with your point #2, look at the code for WordPress, Magento and other open source apps, the code is always a mess…might be a problem with too many cooks in the kitchen ๐Ÿ˜‰

  • I still have my reservations, but have now started tinkerining it with it a bit more now that I have discovered http://incident57.com/codekit/, (As lee has already mentioned). I too wouldn’t rely on js, but love the powers of codekit to auto generate the output files and generate a preview.. I am still learning, so seems quiet straight forward to me to start to use some of the basic features and start from there. I does make the whole thing a little simpler.

  • Hi Amber,
    I guess I am at the other end of the spectrum, I love LESS! There are so many reasons to use it that I am surprised to hear that you are not going to.

    First off, I guess I should clarify, we take all of our designs to a CMS, before we build the actual template we do an HTML prototype, this is not everyone’s workflow. And when we are prototyping LESS is a godsend, when the prototype is templated only CSS is used. I would never use LESS on a production site and I do not believe it was ever intended to be on one.

    Like I said once you start using LESS or SASS you will appreciate how much time they really save you. The excellent Bootstrap from Twitter is a great example of how to use it correctly.

  • I’m a huge fan of LESS. Ok, now that we have that out the way. I totally understand and can agree with a lot of your reasons for NOT using LESS. In the end, I believe the benefits outweigh the disadvantages.

    1. When using CSS3, having mixins saves soooo much time and is usually a lot easier to remember.
    2. Having variables for brand standards/style guides becomes extremely helpful in large sites.
    3. I like nesting, but as I stated to you over twitter….it can definitely lead to CSS bloat if you don’t pay attention. Too many developers fall into the “nest like your HTML”, which is not the way to use LESS.
    4. I just like the ability to use the built-in functions like lighten and darken.

    My biggest fear when using LESS is that another developer will follow me and NOT use LESS, but update the CSS file. I currently don’t have a pragmatic plan to prevent this, so all I can do is note it and hope they follow.

  • Hey Jake, your last paragraph is one of the biggest reasons I decided not to use them, it’s not like GIT where you can sync the CSS file after it’s been altered by a nonprocessor. ๐Ÿ™‚

  • Hey Amber. Nice post. I would agree with you CSS preprocessors don’t work well in a workflow where not all members of the team are using it.

    But isn’t this true of pretty much everything? You said: “What happens if another developer needs to edit the CSS and doesnโ€™t know or realize a preprocessor is being used? How do you sync the two?” Couldn’t I just as easily say, “What happens if another developer needs to edit the HTML and doesn’t realize you’re using PHP?” Everything is pre-processed today. PHP, Ruby, Python, etc. — all being used as a way to pre-process your HTML output. If that’s okay, why it is wrong for CSS to work the same way?

    To your point about Javascript. DON’T use the Javascript version. Ever. Frankly, it’s incredibly irresponsible of LESS that a Javascript version even exists, and it’s one of the main reasons I prefer SASS. It’s just bad for the web.

    I hesitated on CSS preprocessors for a long, long time for many of the same reasons you are (here’s evidence of my hating on SASS three years ago: http://nathanborror.com/posts/2009/nov/30/sass-isnt-me/ — a lot has changed since then). They may not be for you at all, and that’s fine. Or you just may not be ready for them yet, and that’s also fine. But my feeling is that virtually all CSS is going to be written this way in the relatively near future, just like virtually all HTML is now pre-processed through PHP, Python, Ruby, or whatever. So at least keep them on your radar — I have a feeling they’ll be an important part of developer’s toolkits going forward.

  • Hey Amber,

    I’ve been using SASS with COMPASS (http://compass-style.org/) for a little while now and I find it works well for me, especially when I’m kicking off a project. Honestly, above all else and possibly completely over-used, I love to use the compressed output of CSS, which compiles all of your css into one line (for production). I find that alone saves me a lot of time when I deploy a site. (The functions and mixins are pretty sweet, too.)

  • JohnJF

    looks like a waste of time to me.

  • While true, using PHP doesn’t fundamentally change HTML itself and the way HTML works. PHP is PHP and HTML is still HTML, whereas SASS/LESS are forcing dynamic elements into a language and changing the way it works. Or maybe I’m missing something here ๐Ÿ˜›

    I’ll definitely keep my eye out on it though, will be interesting to see if it’s just a passing fad or something that will stick.

  • Ah I didn’t know it did that, that’s pretty handy!

  • I don’t know if I can agree with that. Sass and LESS wrap programatic logic around a declarative language in CSS, giving it the ability to use things like functions, variables, loops, etc.

    That’s exactly why PHP was created, too — to do exactly that for HTML. It wraps programatic logic like functions, variables, and loops around HTML. It’s almost exactly the same concept. Certainly, PHP has grown a long way from where it started, but it began life as an HTML preprocessor. In fact, PHP itself stands for “PHP: Hypertext Preprocessor.”

    So my contention is simply that if we love hypertext preprocessors, why would we hate CSS preprocessors?

  • Bobby Juno

    Have a look at this article which I found to be very useful on grid systems. ( http://coding.smashingmagazine.com/2011/08/23/the-semantic-grid-system-page-layout-for-tomorrow/ ).

    However when using .LESS in test on local for Chrome there is an issue but apart from that it saves a lot of time for me.

  • I like using Less, as you can choose to use only the features you want, so if there is something you don’t like, you can just write normal css with no disadvantage!

    My primary use of it is having mixins when using CSS3 as it saves me soooo much time and is usually a lot easier to remember. E.g only having to write

    .border-radius(5px)

    instead of writing

    -webkit-border-radius: 5px;
    -moz-border-radius: 5px;
    -o-border-radius: 5px;
    border-radius: 5px;
  • Why do you use prefixes for border-radius? Every browser supports it.

  • Every *current* browser. The prefixes are still useful if you want it to work in older versions.

    Also, Liam: what you say is true of Sass, too — you can simply right straight CSS and it will be valid Sass code, just as it is valid LESS code.

  • True, but there have been so many browser versions since they dropped the prefixes, that would be akin to supporting IE1 ;P

  • That’s true but I take the few that for an extra few characters, I prefer to be safe than sorry. Also the plus with a border radius mixin like that is if you decide that you no longer want to use the -o-border-radius property for example, all you’d need to do is remove the one line from your mixin and not the X lines where it might occur in your CSS. Less lines to delete = less chances that a mistake can be made.

  • @Amy: border radius was just meant as an example. There are many other css3 properties that are not so widely supported without the prefixes, and that using Less (or Sass) saves me a lot of time.

    @Jeff: Thanks for pointing out that it can be done in Sass as well. I was not trying to start a debate over which is better, just that I personally use Less.

  • Sublime Text 2 has a package called prefixr (yes, that site).

    I simply select any CSS3 declaration, hit CTRL+ALT+X and boom, all vendor specific declarations are added ๐Ÿ˜‰

    Much quicker than installing any preprocessor.

    Ontopic: I guess they might be useful for very large sites, but indeed – what happens if the company switches devs/agencies and the followers dig in directly? Maybe they never worked with preprocessors…

    +1 on Amber’s pov.

  • Just a little vote from me on the benefits of using LESS (or SASS). It’s all been said above so I won’t recap it all, but I personally find it speeds up and streamlines my workflow. Mixins and variables are an absolute godsend, but I don’t use nesting as it gets too confusing. Originally I thought “oh god not some other new thing for me to learn”, but now I wouldn’t be without it.

    I’ve never used less.js to precompile the css ‘in-browser’, that sounds like a recipe for disaster. I use the LESS app for OS X, which ‘watches’ my Sites folder and automatically precompiles my less files to minified (or un-minified if you so wish) css files when it sees they’ve been updated or when you save them – it’s really very straightforward.

    Sure, there’s the issue of other people not realising I’ve used LESS and they could start editing the css directly, but I work in an environment where everyone’s roles are defined, so that shouldn’t (in theory) happen – I don’t touch the devs code and they don’t touch mine ๐Ÿ˜‰ Plus, I always put the .less and .css files together, so anyone with a passing knowledge of web design/dev should spot them and at least ask themselves the question “what is that”?

    Either way, it’s about what’s comfortable for you and what helps you, and if LESS or SASS aren’t your thing then that’s absolutely fine ๐Ÿ™‚

  • Just to add something else, if you haven’t already seen it, here’s a link to another interesting article on preprocessing CSS.

    The article talks about SASS, but the principles are obviously the same for LESS: http://css-tricks.com/musings-on-preprocessing/

  • Ah use I read Chris Coyier’s thoughts on the subject. I’m still of the opinion that this is somewhat a passing fad, even though it seems to be wildly popular at the moment, it’s just something I’m not interested in. In the end I think the results are the same, so I don’t see it harmful for someone not wanting to use them, especially if CSS is something they specialize in.

  • There’s absolutely nothing wrong in thinking that way, but if you were up for it how about a little challenge? ๐Ÿ˜‰

    Give LESS or SASS a go on one project and see how you feel about it afterwards. If you’re still not convinced then fair enough, you can’t say you didin’t give it a fair shot.

  • I share Amber’s sentiments. I love CSS and I’m a firm believer in keeping it simple.

    I work primarily with advertising agencies, filling in the role of their web/interactive developer, and it would be SO cost and time prohibitive for me to explain (and teach) the designers at these agencies how to use a CSS preprocessor to make a simple change to a text color or some such. These people are hiring me because they are NOT developers, so I’m certainly not going to force them to become one. One of two things would happen — they’d either stop using me and go find another developer that DOES keep it simple for them, or they’d just contact me to make every little CSS change the client requests 1, 2, 6 months or even a year down the road.

    Also, comparing SASS/LESS to PHP (or any interpreted language) is kind of misguided. It’s impossible for a new developer to open up the codebase of a PHP site and not know that the site was built in PHP. PHP doesn’t, in normal circumstances, generate .HTML files as output.

  • I share Amber’s sentiments. I love CSS and I’m a firm believer in keeping it simple.

    I work primarily with advertising agencies, filling in the role of their web/interactive developer, and it would be SO cost and time prohibitive for me to explain (and teach) the designers at these agencies how to use a CSS preprocessor to make a simple change to a text color or some such. These people are hiring me because they are NOT developers, so I’m certainly not going to force them to become one. One of two things would happen — they’d either stop using me and go find another developer that DOES keep it simple for them, or they’d just contact me to make every little CSS change the client requests 1, 2, 6 months or even a year down the road.

    Also, comparing SASS/LESS to PHP (or any interpreted language) is kind of misguided. It’s impossible for a new developer to open up the codebase of a PHP site and not know that the site was built in PHP. PHP doesn’t, in normal circumstances, generate .HTML files as output.

  • CSS preprocessors like LESS can, or could be used when appropriate (like anything else).

    If you’re working with a large team on an existing project, who all need access to the css files and where there aren’t the resources to train them in how to use something like LESS (although you can use regular CSS in a LESS file so it’s really not that much of a stretch to learn) then sure, just stick to standard CSS.

    However, I can guarantee using LESS will dramatically save you a whole lot of time after a (very small) learning curve. I’m speaking from personal experience here. It’s one of those things – until you’ve really tried it you won’t believe the difference it makes.

    Oh and correct me if I’m wrong but isn’t that what PHP does, outputs HTML files? I mean it stands for Hypertext Preprocessor doesn’t it?… ๐Ÿ˜‰

  • I’d agree with you on this whole /”PHP is just like a CSS preprocessor”/ argument if LESS/SASS and others had positioned themselves as the next big INTERPRETED technology that your average $10/month host would now need to support on their LAMP hosting accounts. Just like what has happened when those LAMP accounts started supporting RoR, Python, etc.

    If the preferred method of implementation for LESS/SASS was to interpret upon page load (or via a cache) then I’d totally agree with you.

    But, the workflow in using both is dramatically different. You need tools installed on your development machine to compile your CSS before upload. You don’t need that with an interpreted language.

    And, yes, PHP does stand for PHP Hypertext Preprocessor. So, we can beat that until it’s dead in the ground. But PHP is not unique in what it does. There are tons of other interpreted languages in use on the web. Nobody ever called into question what PHP does, exactly, but rather how the resulting output is handled. With PHP (and other interpreted languages), once the output is sent, in basic practice, it’s gone until it’s requested again. Day-to-day use of an interpreted language does not require you to redirect the output to a .HTML file and then serve that to every visitor. That would be a little bit ridiculous. So, the comparison of LESS/SASS to PHP doesn’t really work.

    In the end, I agree that there is a time and a place for LESS/SASS. Larger teams obviously have the most compelling use-case. But, larger teams always had the flexibility to create their own custom tools for the product they’re creating anyway, so the emergence of LESS/SASS is really just a timesaver to them as I’m sure somewhere, someone in a large team created a CSS pre-processor before LESS/SASS showed up.

    Use what you like. It just seems that the more visible people advocating LESS/SASS are living in a world where everybody is a full-time employee and works on the same product for 2 years. A lot of us are freelancers and don’t have the flexibility you all have, thus we can’t employ tools like this, even if we wanted to.

  • > If the preferred method of implementation for LESS/SASS was to interpret upon page load (or via a cache) then Iโ€™d totally agree with you.

    That’s exactly how I, and many serious front-end developers, implement Sass. Glad we agree!

  • ๐Ÿ™‚

    After doing some research it looks like there are some runtime compilers for various languages (since we’ve been talking about PHP, there’s LessPHP (http://leafo.net/lessphp/)). I may check it out on my next personal project, just to get my feet wet. I am a little concerned though that these projects (or at least LessPHP) are not using the actual code from LESS, but rather re-implement it from scratch. If the author suddenly stops working on the project or doesn’t keep it in sync with the latest LESS features, then you’re at a disadvantage. It would be nice to run LESS natively, but a lot of hosts out there don’t natively support Node and 99% of the time I’m given a hosting account to upload the site to, I don’t get to choose the host.

    I still don’t think I want to use this tech on my production projects, since I deal with some very non-technical people who I know from experience like to muck about with the code after I’ve been paid and then expect me to warranty my work after they break it if I want to continue to remain in their good graces and get more business. So, this just seems like it would add another layer of complexity to my life, un-doing any net benefit from making CSS ‘better’ for me.

    I think you have to agree though that the vast majority of walkthroughs, screencasts and tutorials out there for these preprocessors has been geared towards using Ruby or Node as your intermediate step to compile the LESS into CSS, and then uploading that resulting file to your server. I think that’s where the big disconnect is for a lot of people, as it was for me.

  • I think you’re at a higher level of development than me ๐Ÿ˜‰ I simply use an app called CodeKit (http://incident57.com/codekit/) to compile LESS into a CSS file whenever I hit save. The .less files never go on the server at all. The browser is just loading regular css files as normal – no compiling in browser or on the server, no ruby or node. Simple ๐Ÿ™‚

    Of course the issue then (and this is what most people are concerned about) is that no one can edit the css files anymore (because any subsequent LESS saves will simply overwrite them).

    I can see where this would be undesirable, like in your situation where you’d have to educate lots of people in how to edit the LESS files and not the CSS directly.