Six Reasons Why I Love Sass

By David Simpson

My first use of Sass in a production environment came when I started working as a designer and developer on Product Marketing at HubSpot. I had read a lot about LESS and Sass and the concepts of CSS pre-processors, and even dabbled with how they worked, but didn’t fully understand how powerful they could be in my daily development workflow. In this article I plan to explain the reasons why Sass has become an indespensible tool for myself and my team.

Background

Before I start, however, I wanted to share a little background on my team and the project we work on as it sheds some light on how using Sass benefits us.

When I started at HubSpot I was tasked with starting the team that manages the HubSpot portfolio of websites from design, development, and general project management needs surrounding them.

The Interactive Content team manages multiple sites, as we’ve grown our dedicated web team we’ve added some awesome people (Shoutout the current and past members of the Product Marketing Interactive Content team! Ben Lodge, Matt Lawson, Laura Marelic, Gabriela Lanza, and soon Stephanie Lee).

Without diving to deep, here are some quick datapoints on these sites:

• 1500+ site pages across multiple domains
• 3,200+ landing pages with offers across multiple domains
• 650+ page layout templates
• 7-8 Million unique pageviews across all domains

Managing this portfolio of sites with those numbers is a daunting task. Fortunately the new HubSpot Content Optimization System (COS) is a big step ahead of the Legacy HubSpot CMS platform, but dealing with thousands of pages is never easy, no matter what platform you are on.

With the help of two Senior Product Engineers (Tim Finley and Adam Schwartz) the team architected a Git repository where all the Sass and CoffeeScript is committed and versioned allowing us to meet the demanding needs of the marketing team at HubSpot.

DISCLAIMER: HubSpot most certainly does use the new COS for a significant amount of our site needs. All of our styling could be handled entirely internal to the product however we have chosen not to.

So, with that basic understanding of the project and its scale, here are my six reasons for really loving Sass and why it is now crucial for my development workflow.

1. Scale & Versioning

When you have thousands of pages in a large scale site or app, Sass is especially helpful in helping reduce the stress of managing such a large scale. Even if you aren’t dealing with a large scale website, Sass is still a powerful weapon to have for building a small scale style guide. Being ready for growth is always a good thing!

A big part of the scaling solution for us is the version control we get with Sass in our infrastructure. At a high level, every file we commit to GitHub is automatically queued up in Jenkins to be compiled and written to Amazon S3. This allows us the flexibility to push out new code at a moments notice while we do QA testing to make sure it won’t break anything.

2. Variables

This is a pretty simple feature, yet it is incredibly powerful when working with a large scale website. By creating variables you can easily pull them over and over to help create consistency with colors, sizes, etc… If you need to change the color of multiple elements, simply update the variable and, voila, it reflects in all those places.

https://gist.github.com/simpson/7805997

3. Organization & Commenting

Having your code organized and commented well can save you and others a lot of headaches over time. With Sass you can separate out all of your different sections into different files and compile them at runtime. This saves you the pain of having one monster CSS file over time. Even if you don’t have a large complex site, just being able to break up your simple style guide into different sections makes life much easier.

Another nifty little tidbit that I particularly like, when you put all your comments in Sass, when it compiles to CSS at runtime it doesn’t bring over the comments into my clean minified CSS file. The larger the scale of your site the more size matters, but as a best practice keeping your stylesheets lean and clean is the way to go.

https://gist.github.com/simpson/7806220

4. Imports

With traditional CSS imports you have the waterfall effect of all the CSS files you declare load one at a time. In this way every single CSS file is a separate request and this increases the server/browser load time with the increased requests. No one likes slow load times. With Sass being a preprocessor, it pulls all those includes first and only delivers the single compiled version at runtime. This is huge a huge win!

https://gist.github.com/simpson/7806065

5. Mixins

Mixins are essentially a way to create reusable blocks of code. A good example of a simple mixin would be a form button, you can create all the standard attributes and simply mixin the colors anywhere you want to make a variation.

https://gist.github.com/simpson/7806144

6. Extensions

Last but not least, Sass extensions. Even on it’s own, Sass is very powerful, but with the addition of custom extensions it becomes even more of a powerhouse. I use a great deal of small extensions in my workflow, but here are two of my favorites.

Compass

Compass helps Sass authors write smarter stylesheets and empowers a community of designers and developers to create and share powerful frameworks. Put simply, Compass is a Sass framework, designed to make the work of styling the web smooth and efficient. A simple example of using Compass is below, instead of writing out all the vendor prefixes for a border-radius, Compass can compile them for us.

https://gist.github.com/simpson/7806357

Breakpoint

Put simply, Breakpoint makes writing media queries in Sass super simple. I combine the use of Breakpoint with variables to build standard breakpoints that I know I’ll typically need to build media queries around. Below is an example of how quick I’m able to do that!

https://gist.github.com/simpson/7903255

Conclusion

All in all, Sass has become a necessary part of my development workflow. The speed and agility that is gained by all of those above categories is crucial to us being able to ship updates regularly to all of the HubSpot websites.

What do you think? Has Sass worked or not worked for you? Have you found other preprocessors are better? Leave a comment below or send me a note via Twitter @simpson and lets chat.

This article was originally published at https://blog.simpsn.com/six-reasons-why-i-love-sass