Why We No Longer Use SASS or LESS

CSS (Cascading Style Sheets) is a styling language that allows web designers and developers to change the look and feel of their HTML markup. It is the language responsible for making the web a user-friendly place (most of the time). It was officially introduced in the mid 1990's and remained relatively unchanged until 2007 when Nathan Weizenbaum and Chris Eppstein embarked on a mission to relieve CSS of what they believed to be it's limitations through a pre-processor called SASS. In 2009, another pre-processor called LESS was introduced with very similar features, but it compiled client-side rather than server-side.

The use of a pre-processor meant that developers could do some pretty cool things through the use of:

  • Mixins – Reuse sets of properties.
  • Parametric mixins – Mixins that take arguments and act like functions.
  • Nested Rules – Allow selectors within selectors, which cuts down on repetitive code.
  • Operations – Math within CSS.
  • Color functions – Brighten or darken your colors.
  • Scope – Make local changes to styles.
  • Variables – Give nice names to your values and easily change them everywhere.

But as CSS has continued to rapidly evolve over the past several years along with our company and it's best-practices, we have noticed that we really only use a few of these features on a regular basis and no longer believe that the pro's outweigh the cons of pre-processing our CSS files. Here's what we no longer find useful and why:

Pre-processing takes time.

Here at Dumbwaiter, we are always looking for new ways to speed up our development cycle. For us, the first step was removing our preferred pre-processor, SASS. Pre-processing adds an unecessary step and slows down reload time, which is the exact opposite of optimizing our workflow. Then we went a step further by utilizing a browser extension called LiveReload which reloads the page automagically when a change is detected in the CSS file so we never have to unfocus our editor, which dramatically speeds up development time. Speeding up the edit/feedback cycle keeps you in the zone as you develop.

Nested Code

We actually find this feature to be a bit cumbersome primarily because it quickly becomes impossible to see the entire CSS selector/declaration at once, which means lots of potential scrolling if we ever forget what bit of code we are currently workin within. Sometimes this approach requires us to override styles we otherwise wouldn't have because they were already inherited in the DOM. Nesting code reduces repetition but often does so at the expense of proper inheritance, alignment, spacing, and legibility which quickly become a burden in more complex style sheets. See the following two code samples:

Using SASS


Using traditional CSS

Vendor Prefixes

Vendor prefixes such as -webkit, -moz, and -o were originally introduced so that indivudual browsers could experiment with new functionality before the official spec was finalized. They were meant to indicate that a feature was experimental (and should not be used in production) so that browsers could change their implementation of a feature without breaking websites. Unfortunately web developers were so excited about the new features that they used them in production anyway. For this reason, and also because many of these features are in the official spec, browsers have been dropping many of the vendor specific prefixes. This eliminates (most of) the need for a SASS mixin which handled the vendor prefixes for us.

Caniuse.com showing that vendor prefixes for border-radius are no longer needed.


Most commonly, we find ourselves using SASS variables to define colors so we dont have to memorize the HEX values or continue grabbing them from a PSD file. However, this feature is easily substituted with a simple declaration through comments at the top of the file and a simple find and replace when it's necessary to alter the HEX value of a color used throughout a large file.

In Conclusion

We do not find these pre-processors useful based on our common CSS needs, but this may not be true for every developer or for every company. SASS and LESS do have their benefits, but we hope that after reading about our decision to revert back to vanilla CSS that you will consider how much you really benefit from using these tools.


UPDATE: After a fair amount of negative feedback from our readers on this post, we've decided to share some clarifying details. We are not encouraging you to stop using SASS or LESS as a pre-processor. What we are doing is encouraging you to evaluate whether or not a pre-processor's benefits outweight the disadvantages and make your own decision. The answer is not always "yes" and we found that the SASS features we used internally were not rewarding enough to outweigh the downsides. Happy reading.