Hot or Not – Less.js

When designing web pages, one of the key components of any site is the CSS (Cascading Style Sheets) file, which defines the font sizes, colors, design, and website layout.  The style sheets also allow a website to change appearance based on the user’s browser and device, so that the website will look great on both mobile phones, desktops, and tablets.

In an effort to make CSS design more streamlined, Less.js adds programming functionality to style sheets.  Essentially, Less.js functions as a pre-processor, enabling nested selectors, variables, math operations, and functions within CSS code.  Although it doesn’t add any actual new functionality to the resulting CSS (everything created in Less.js eventually translates to a standard CSS file), as its namesake suggests, it can sometimes shorten the code required.

First and foremost, Less.js brings variables to CSS files.  Instead of embedding hexadecimal color codes into the style sheets, all the colors can be declared at the top of the file and used throughout.  For example:

@primary: #5E412F;
@secondary: #78C0A8
@accent: #F0A830;
 
#head {
  color: @primary;
}

The primary benefit of variables is that colors can be changed from a central location, reducing design time if the client is unsure about the color selection.

Next, nested selectors allow coding one style inside another.  This is derived from the DRY concept of “Don’t Repeat Yourself”:

/* Traditional CSS */
#head {
  margin-left:auto;
  margin-right:auto;
}
#head h1 {
  font-size:40px;
}
/* Nested Less.js */
#head {
  margin-left:auto;
  margin-right:auto;
  
  h1 {
    font-size:40px;
  }
}

Another benefit of LESS is the ability to perform math operations right inside the CSS code.  This can be useful for making a color lighter or darker, or changing width based on a variable:

@primary_light: @primary + #333333;

Finally, functions, or mix-ins, enable writing CSS that can be re-used throughout the style sheet.  For example, borders can be added using a short-hand notation that is previously defined:

.border3d {
  border-top: solid 2px #999999;
  border-right: solid 2px #999999;
  border-bottom: solid 2px #666666;
  border-left: solid 2px #666666;
}
/* And then used */
#popup {
  width:300px;
  .border3d;
}

The primary benefit and use-case of Less.js is in template development.  If a CSS file is designed to be used in a large variety of implementations, Less.js can be an excellent way to allow users to tweak colors for their specific brand.  Less.js can also be great for toolkit development, such as the jQuery-UI framework.

Unfortunately, for any sites with a real brand that aren’t looking for cookie-cutter templates, Less.js is not particularly useful.  The problems Less.js solves (CSS code overhead) are usually only created by novice designers.  Most well-built style sheets do not require constant re-writing of colors, and the color palette is usually defined far in advance.  Next, the nested styles are really a matter of preference; some designers may think that nested styles actually make code longer and more difficult to read.  And while the math operators are a neat trick, the actual formulas used in CSS are simple enough that an interpreted language can often create more overhead than it solves.

These drawbacks can be forgiven if a quirky developer simply loves the latest technology, even if it doesn’t provide a tangible benefit.  Design nerds may try the latest fads, and hopefully move on once they realize it doesn’t significantly improve their workflow.  What can’t be forgiven, however, is the performance hit a website will take if a Less file works its way into the production environment.  Since the end-result is a static CSS file, a Less interpreter add unnecessary overhead to the web pipeline.  Be sure to use the offline precompiler, or limit Less.js usage to a development machine, if the framework is part of your production workflow.

While Less.js may be excellent for creating cookie-cutter themes such as Flat UI, it has little compelling use outside the tool-developer workspace.

Hot-or-Not Verdict: Poor toolkit is out of its league

 

Written by Andrew Palczewski

About the Author
Andrew Palczewski is CEO of apHarmony, a Chicago software development company. He holds a Master's degree in Computer Engineering from the University of Illinois at Urbana-Champaign and has over ten years' experience in managing development of software projects.
Google+