I was just reading a post by Chris Ferdinandi — Is it time to drop Sass? — I want to speak on the topic.
Chris is known as the “vanilla JS guy”. He favours using JavaScript and eschews many tools. This contrarian opinion is important in a noisy frontend world that is constantly pushing the use of particular frameworks and tools. As Mark Twain said: “Whenever you find yourself on the side of the majority, it is time to reform (or pause and reflect).”
Why drop Sass?
Chris says the following in his post:
I’ve been using Sass for a decade, but recently, I’ve been wondering if it’s time to ditch it and move on.
The thesis in the article is that CSS now has almost every feature that he uses from Sass. Nesting has been added to CSS recently and this prompted the article, I guess. One exact feature that is missing for Chris is the @import declaration to bundle styles from different partial files into a single file.
Chris favours using the ESBuild bundler to work out the shortcomings. ESBuild can bundle CSS files into a single CSS file. ESBuild can transform your natively nested CSS to “flat” CSS — this is important since nesting is not in Firefox currently. Therefore, with the aid of ESBuild, Chris has feature parity for his usage of Sass. The other Sass features like mixins and inheritance do not appeal to Chris.
Frankly, none of these seem like deal breakers. I think it’s time to go vanilla CSS
The thrust of what Chris is saying is that CSS has grown a lot and this reduces the need to reach for a CSS preprocessor. Being able to do more with CSS is a good thing. However, Chris is using one tool (ESBuild) instead of another (Sass) to get the same outcome. Is it a step forward?
Let’s look at it from the other side.
Why shouldn’t you drop Sass?
I want to zoom out for a moment and make a more general point about choosing technologies in the frontend world.
Dave Bushell wrote about CSS nesting in a recent post too, and he also concluded that he no longer needs Sass. He said the following:
Goodbye Sass!
With these updates I no longer need the Sass preprocessor. A little sad to let such a useful tool go. I’ve been using Sass for longer than I can remember.
A corollary of this type of thinking is that it portrays technologies as disposable commodities. It projects “Yes! Finally CSS has the best of Sass. Let’s chuck Sass”. The perception is that you can switch quickly, and at a low cost.
Another facet of this is that choosing a technology is often construed as being mutually exclusive: Sass or CSS. This can led to bad decisions.
I see Sass, other CSS preprocessors, CSS postprocessors, and CSS as a major building block on the web. You don’t replace the bricks in your house, just because another brick offers similar benefits at a slightly cheaper price. Why would you think that way about CSS?
Progression of one technology does not mean that you will stop using another technology in a punctuated manner. Established technologies are a part of many, many existing websites. Replacing something like Sass can be a big undertaking. As the Sass blog points out: native CSS nesting is subtly incompatible with Sass nesting. It is wise to at least understand the differences before you transition!
You cannot use native nesting in a Sass file. This makes a progressive switch difficult. You will need to replace every Sass file to make a complete transition. It is not just a find-and-replace operation across files because of the subtle differences with nesting, and there is the other bits of Sass syntax you have used in a project to consider.
When David Bushell replaced Sass with CSS on his personal website, it required him to restructure his list styles. It is a considerable amount of work to ensure it is done correctly. And what is the benefit of transitioning from Sass to CSS on an existing website exactly?
In the short-term, the only significant benefit may be that your build process is simplified. There is a cost to get there. You must learn some new things, and it takes work to get things setup correctly.
If you are making a new website, then it is a different proposition. You have less constraints and more freedom. Choosing a CSS preprocessor or CSS is open. Your choice is contingent on other decisions, and other tools you may wish to use.
If you want to build a performant website these days, you are likely to have a build step with some tools. It would be great not to need any tools, but to scale a website, it is difficult to forgo all tools. That’s why it may seem like a step forward to use one less tool in your toolchain. I think that this is the primary benefit people are chasing. I think that the panacea of zero tooling can be blinkering.
Ask yourself what is the benefit of making a change?
Often, substituting tools does not benefit the user. The payoff is on your side. The payoff for you should be large enough that the user sees a benefit because it enables you to deliver in a superior way. In some cases you are just learning to do the same thing, another way, somewhere else. If you think tools like Sass are disposable, you will repeat this process again soon for a similar case.
My question to you is it better to drop a tool, or is it better to drop this mindset?
Reminiscent of jQuery
The story of jQuery is analagous to this story with Sass. jQuery helped usher in an era of building reliable websites and web applications. It provided a consistent cross-browser API for working with the DOM. It eventually led to part of the API being adopted by ECMAScript. We can thank jQuery for querySelector().
When React was taking over the frontend world, jQuery was treated with ire in some quarters. A view developed (pardon the pun) that if you are using imperative style of programming in the browser that you are a chump. Using jQuery and React were seen by some as mutually exclusive decision. You are either a trendy declartive cat (React camp) or a churlish imperative dinosaur (jQuery). It had a tribal aspect to it. And it had the capriciousness of fashion — this season we are rocking React dungarees.
React and jQuery are different. You could build web interfaces with both. However, jQuery had a wider application, and it was a product of its time. It was not designed to solve the problem space of complex state and user interaction. It was concerned with improving DOM manipulation, animation, events, and AJAX in browsers. People built tonnes of utilities and widgets using jQuery because they wanted a pleasant API and things to work everywhere. It gave superior interoperability. The web platform did solve many interoperability issues at time went by.
Understandably, jQuery is not used by people very often to build user interfaces now. People chose UI frameworks for that task instead. I think that jQuery was brought up in conversation alongside React in that era because of their mammoth popularity and wide adoption, rather than as a thoughtful debate on how to build great web applications. Now that people’s first choice for building user interfaces is React, you find some people clawing at React for being too bloated, being all about SPAs, and so on! It’s a peciular cycle.
Today, jQuery is still used a lot. People did not just rebuild everything that used jQuery because something “better” came along. According to W3techs, as of August 2022, jQuery is used by 77% of the 10 million most popular websites. I do not know how reliable that figure is, it is more than I expected, but the point I am making is that technologies stick around much longer than people think, or like to admit. People like to categorize this as technical debt these days. You don’t replace a core building block of a website willy nilly.
Whatever your thoughts on Sass is, it is worthwhile to think of Sass in a similar vain. Don’t make it a popularity contest, or a tribal conflict on using one or the other. Recognize what technologies are good at and use them accordingly. If you want to make a change, then realise that it is likely to be troublesome if you make a big bang change.
CSS and CSS preprocessors have a common purpose, but they also serve different needs. Sass is a superset of CSS, similar to TypeScript and JavaScript. It has a compile step that offers things that CSS does not. CSS preprocessors are great at avoiding repetition and expressing more complex design patterns. CSS preprocessors can create new features that do not require browsers to implement anything. They can be a vector for innovation. Sass is evolving still.
You may rebuild your personal website to use CSS instead of Sass today, but you are unlikely to be doing the same thing in a workplace any time soon. The payoff is too small, and the risk is too large for a business to bother. This context is important.
Closing thoughts
I think that you should choose the tools that fit your project requirements, that produce a great outcome for the user, and that work best for you.
I would encourage you to drop the “either/or” mentality around technologies. Don’t talk about dropping tools, talk about preferring a tool. Maybe one is more suitable for a certain task or type of project. Let’s focus the discussion on why you would choose one thing over another with appropriate context and nuance.
CSS has come a long way. Nesting being adopted by CSS is partly due to the success of the feature in Sass. Let’s give great tools their dues and not be signing their death certificates when other tools adopt some of the things that made them great. It is fine to have a preference but you don’t need to be dismissive about other technologies that are not en vogue. You can’t chase ever incremental improvement here and there without wearing yourself out. There are too many things changing, too many things on offer.
I see myself using Sass for prototyping and creative coding for a long time. I do not see myself replacing Sass in existing projects soon. I will consider CSS in a different light for new projects going forward because it is evolving. That’s all good in my book. I will use them both in different circumstances! Usage is not mutually exclusive!
