I’ve been investigating Less vs Sass the last little while. This came about because I was looking at instituting CSS Spriting for a project I’m doing some work on.
The project is currently using Less, but after a little investigation, I discovered that Compass (which is built on Sass) has functions for easily managing images, and converting them to sprites. No more external tools, or modifying existing spirited images. Just work with the individual images, and Compass takes care of the ‘grunt’ work.
So, I began investigating Less and Sass, and started doing comparisons. Both can be very useful, and both are powerful, but they take slightly different views on how CSS should be written. Sass even has two camps internally. The original Sass format (indentation based, so no semi-colons or curly braces) and Scss format (which more closely resembles CSS formatting).
There are many articles comparing the two frameworks from a functionality perspective, and strictly based on that, Sass is the winner. It’s more of a programming language that generates CSS, and therefore allows for something like Compass, and automated sprite generation.
But the more I looked at the code on the project I’m working on, the more I realized that Less wasn’t helping them. There are currently 48 Less files, and the generated css file is 570 lines (and that’s compressed). In those 48 files are about 7200 lines. Is this good? How much duplication is there here? Is Less really helping (and it’s not Less’ fault, as this would exist using Sass or Stylus too)? Can you imagine trying to have a designer look at this? How much duplication is there in here?
So, perhaps using straight CSS is a better option. It takes more effort to learn it and to really think about how the selectors are used, but I suspect this would be a larger pay off. Once you’ve considered your CSS, then perhaps a pre-processor like Less or Sass can be helpful, but not until.
And after coming to this conclusion, the following article came across my ‘desk’. It’s written by a major contributor to Less (Luke Page), and his first section is about ‘Why you shouldn’t use any CSS pre-processor at all’. I agree.
Less vs Sass vs Stylus: http://www.scottlogic.com/blog/2013/03/08/less-vs-sass-vs-stylus.html
His viewpoints, and design philosophy are also very interesting, and have me looking at Less and Sass in a different light. So now I’m stuck on the fence about which I’d recommend, but definitely think the first place is native CSS, and doing that as well as you can. Then, and only then would I consider adding the convenience of a pre-processor.
On the topic of Sprites, there’s some minor debate occurring right now around the topic. There are only a few choices.
- Keep them as separate images
Spriting images can be a time-consuming process. Creating the sprited image from the individual images, and then updating the stylesheet correctly. There are various tools to help with this process, but it still takes time.
Then, to make the time consumption worse, if an image changes, or a new image is added, or image dimensions change, then you have to find the original images to put it all back together.
Also, modern browsers generally support more concurrent connections http://www.browserscope.org/?category=network. Looking at this report, it appears most of them now allow 6. So, it’s less of a problem.
This reduces the number of requests, and I believe the browser’s are very fast at doing the computations required to render the images. This has the downfalls mentioned in 1, although if you were to use something like Compass, that can help minimize the pain.
This is a technique I did not know about, and yet, it’s been around since 2009. It involves base64 encoding the image directly into another file. For files that change frequently, this wouldn’t be a good idea, as the image ‘inherits’ the caching policy of the file that contains it. But for CSS files, this could work well. Yes, it makes the CSS file larger, but with GZip enabled, the image won’t be too much larger across the wire than transmitting a png file.
It’s not clear whether Data URIs perform well enough, but it’s worth being aware of them. The article CSS Sprites vs Data URIs did some testing of smaller images on mobile browsers, and found the sprites consistently outperformed the Data URIs, so that’s something to keep in mind.
- Data URIs make CSS sprites obsolete http://www.nczonline.net/blog/2010/07/06/data-uris-make-css-sprites-obsolete/
- Data URIs explained http://www.nczonline.net/blog/2009/10/27/data-uris-explained/
- CSS Sprites vs Data URIs: Which is faster on mobile? https://www.mobify.com/blog/css-sprites-vs-data-uris-which-is-faster-on-mobile/
- The Mystery of CSS Sprites: Techniques, Tools and Tutorials (A little older (2009) but still relevant)http://coding.smashingmagazine.com/2009/04/27/the-mystery-of-css-sprites-techniques-tools-and-tutorials/
- Sass vs. Less http://css-tricks.com/sass-vs-less/
- Too LESS? Should you be using Sass? http://metaskills.net/2012/02/27/too-less-should-you-be-using-sass/
- An Introduction to LESS, and comparison to Sass http://coding.smashingmagazine.com/2011/09/09/an-introduction-to-less-and-comparison-to-sass/