Is it Time to Ditch Sass?

Several weeks ago, I joined the Front End Study Hall, an HTML and CSS-focused Zoom meeting held bi-weekly. It offers a chance to learn from each other by discussing our shared interest in these web essentials. Some sessions are more structured, while others are open-ended, allowing members to raise questions or topics of interest.

Joe, the group moderator, typically initiates the discussion with a topic on his mind. During this meeting, he inquired about Sass—whether we use it, like it, and our experiences with it. I intended to respond, but the conversation shifted before I could. This inspired me to write and share my recent thoughts.

Beginnings

I began using Sass in March 2012 after hearing about it through various sources, including Chris Coyier’s new podcast, ShopTalk Show. I was redesigning my personal website and saw learning Sass as a great opportunity. I purchased the Pragmatic Guide to Sass and applied my learning while building a new site version. The book recommended using Compass to process Sass into CSS. I chose SCSS syntax over indented syntax due to its similarity to plain CSS, wanting to maintain my CSS skills.

Getting started with Sass was straightforward. I used a GUI tool called Scout to run Compass, avoiding command-line usage initially. Later, I learned to use Compass via the command line, appreciating its simplicity and wishing for similar simplicity in modern build tools.

I quickly enjoyed Sass, especially its reusable variables, allowing consistent colors and typography across code. Though I hadn’t planned on using nesting much, I was captivated once I tried it, appreciating the reduced code and manageable relationships it offered. Nesting media queries inside selectors was particularly beneficial.

After successfully using Sass in a personal project, I adopted it professionally and encouraged my team to do the same. I appreciated Sass’s flexibility, allowing as much or as little use as desired. Despite not delving deeply into Sass, I used the @extend rule initially but didn’t explore features like placeholder selectors or for loops. I rarely rely on shortcuts, preferring to write things out.

Is it time to un-Sass?

I’ve used Sass for over 13 years, choosing it over Less.js, which proved a wise choice. Navigating the tech space involves selecting tools that may rise or fall in popularity. I’ve been fortunate with my choices, as all agencies I’ve worked for used Sass.

This year, I began a personal project—a memory keeper inspired by Facebook’s Memories feature. I wanted a way to view memories beyond Facebook’s offerings and from different dates. To keep my prototype simple, I initially wrote CSS without Sass but soon realized I was using nesting. Remarkably, native CSS nesting works similarly to Sass’s, prompting me to question if it’s time to un-Sass.

Credit to Stu Robson for the term “un-Sass.” I’ve been contemplating it while considering:

Custom Properties

Many Sass features have made their way into native CSS, starting with custom properties. They’re more powerful than Sass variables, allowing new values in media queries or theming systems and updates via JavaScript. Custom properties work with inheritance and have a broader scope than Sass variables.

I first used CSS Custom Properties for light and dark themes in a client project and several times with JavaScript, enhancing CSS and JavaScript integration. At my new job, we extensively use custom properties, and I’ve fully transitioned to them in new code. I utilized them for a light and dark theme on my personal site and with Utopia for typography and spacing utilities.

Nesting

Sass’s nesting simplified CSS by allowing style rules within another rule, eliminating the need for full descendent selectors. It also allowed nesting media, feature, and container queries, grouping code and enhancing readability.

Discovering native CSS nesting for my memory keeper prototype excited me. Initially, the specification required starting nested queries with &, differing from Sass. However, this changed, allowing syntax similar to Sass, which I appreciate.

Native nesting doesn’t support concatenated selectors like Sass, impacting BEM users. The & symbol in native CSS is a live object, always a separate selector, preventing concatenation. I never used concatenated selectors, so this change doesn’t affect me. Native CSS nesting matches my Sass usage, supporting un-Sassing.

Be cautious with nesting, limiting it to three levels to avoid long selectors that are difficult to override. Keep it simple.

The color-mix() function

I enjoyed using Sass’s color module for hover colors, easily darkening or lightening colors. The native CSS color-mix() function offers similar functionality, which I’ve extensively used since learning about it from Chris Ferdinandi.

Mixins and functions

Sass users often extensively use mixins. I used many mixins in the past, but often pasted them from previous projects, forgetting their existence. They were helpful for techniques like clearfix or font smoothing, but I used them less over time.

I also used Sass functions, creating custom ones for on-the-fly math, mainly converting pixels to