Is LESS a practical alternative to CSS?

Posted on Feb 19, 2010 in Web Dev | 5 comments

As a standards-focused web developer, I spend much of my development time (at least, the client-side portion of it) writing CSS. If you’re not familiar with Cascading Style Sheets, you can learn more about it on Wikipedia or the beautiful CSS Zen Garden. I also invest time in learning about new design and coding techniques, which is how I learned about LESS, the so-called “Leaner CSS.” Though I’ve not used it (yet) I have read the LESS website and documentation and understand what it does.

LESS aims to correct what its authors deem as failings in CSS’ static nature. LESS touts a number of benefits, three of which I’ll briefly describe below (but all can be found at the LESS site):

• Variables – Using the @ symbol, developers can define CSS variables in much the same way programmers do. So, to define a consistent color, you could write: @siteColor: #20AC01 at the head of the LESS file and then reference @siteColor wherever you wanted that color. Useful, though technically not a true variable as it cannot be assigned a new value through programmatic interactions; it’s really just a defined constant.
• Mixins – “Mix-Ins” allow developers to define a set of style rules as you would for a class or an ID, then use that set of rules within other selectors. For example, say you had a number or boxes, sidebars, etc. within your site that you wanted to all share a common rounded-corner appearance.  You could first define a class called .rounded with the desired rules (-webkit-border-radius and -mozilla-border-radius). Then other classes, like .sidebar, .infobox, etc. could include within their rules the .rounded style to inherit its rules. In essence, it’s another defined constant, this time for a whole set of rules, not just one value.
  What’s even cooler is the ability to pass a parameter to the included Mixin as you would with a function. In my example above, that means you could change the radius of the .infobox class by passing in “5px,” while for .sidebar you might chose only “2px.”
• Nested rules – No more redundant selector strings in which you define different styles for anchor (along with their :hover, :visited, and :active states), heading, or input tags. Nested rules allow you to embed whole style declarations for other selectors within another selector’s declaration. So, any styles declared for selector a defined within .sidebar‘s declaration will only apply to anchors within a sidebar.
• Operations – Developers can now run simple calculations (add, subtract, multiply and divide) within their CSS code. Though specifying a border width or radius as twice another value (perhaps a LESS “variable” defined at the head of the document?) is cool, I think color operations are more useful. If you want your footer darker than your sidebar, you can specify background-color: @sidebarColor * 2. Not only does it save a trip to another program or site to determine a good color, it allows you to set up your site’s aesthetics using proportions and relations and have them all change when another value is changed.

These and other features of LESS really are cool and would be beloved aspects of CSS were they supported by the actual CSS specification. Sadly, they’re not. LESS makes writing code easier, but it cannot be used by browsers; it must be compiled into true CSS first. And that’s why I posed the question “is LESS a practical alternative to CSS,” not whether LESS is better than CSS; I think the answer to that is: yes, it is better. But am I willing to go through the additional step of compiling my LESS files into CSS as I develop? The answer for me is: no, probably not.

In a word, the reason is friction. Mental friction. Switching to LESS first requires that the a compiler be installed. Sure, that’s just a one-line command run in the terminal on a Mac and probably not a ton of effort more on a Linux server system. And LESS can be set up to “watch” a directory so any changes made to a .less file will prompt an auto-compile (and there are also LESS applications for Macs and .NET developers to do the same thing with a nice interface). Trouble is, I develop web sites on no fewer than five different web servers, only one or two of which my access level would allow me to install a compiler. I don’t want to code with LESS features on some projects but not others because of the cognitive gear-switching that would require.

Another reason the efforts outweigh the benefits for me might be the size of the sites I typically work on. If I were tasked with building a large enterprise site or set of web applications (or be part of a team doing so), the higher efficiency LESS code would be more attractive when managing the project’s styles. Most projects I work on have just a few stylesheets so old-fashioned copy-and-paste and search-and-replace work decently.

Granted, the benefits of LESS are nice. But none of them are so indispensable that I cannot develop without them, so for now my workflow will remain LESS-less, at least for now.

Related: If you liked this, check out:

1. Little-known CSS selectors Anyone worth his or her proverbial web development salt knows...
2. Link icons through CSS After a dearth of design-related posts, I finally have a...
3. Web 2.0 quiz Update: had two “entries” on this quiz: surprisingly, one of...
4. What color is your body? You’re sporting a killer hat. Wearing the best pants you...
5. Mock-up to valid XHTML: how to build a web page – part 2 This is the second in a two-part series on the...