I was just reading a post by Chris Ferdinandi -- Is it time to drop Sass? -- I want to speak on the topic.
Why drop Sass?
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.
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.
Dave Bushell wrote about CSS nesting in a recent post too, and he also concluded that he no longer needs Sass because he has the features he needs in CSS now. 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. [...] With calc(), custom properties, and now CSS nesting, my need for Sass is all but gone.
Dave is using Post CSS to produce unnested CSS that works in all browsers.
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.
A corollary of "dropping tools" 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. Do you use the same technology on every project?
I see style technologies, whatever format you write your webpage styles in, 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. Replacing something like Sass can be a big undertaking. It is wise to at least understand the differences between Sass features and the equivalent CSS features before you transition! How much work can it really be?
As the Sass blog points out: native CSS nesting is subtly incompatible with Sass nesting. 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. When David Bushell replaced Sass with CSS on his personal website, it required him to restructure his list styles.
You need to consider the others bits of Sass syntax you have used in a project and decide how you will port those styles. For example, Sass variables and CSS custom properties are intrinsically different. Sass variables are imperative, which means if you use a variable and then change its value, the earlier use will stay the same. CSS variables are declarative, which means if you change the value, it’ll affect both earlier uses and later uses. You will need to review your variables to ensure that the result is the same.
Also, it is easy to forget that Sass offers some niceties that you may think are in CSS but aren't! Jim Nielsen discussed how much he misses single-line comments from Sass recently in a post:
Then Brad Westfall reminded me of a Sass feature that, while small, is probably the one I miss the most every single time I write vanilla CSS: single line // comments.
You will need to convert single-line comments into multi-line comments to be valid CSS! 😰
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.
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 are trying something new, like using a different feature set or alternative style technology, it will take you longer. You should budget time for that.
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. People gloss over the time required to learn the "new way" properly. This is time that could be spent shipping features.
Also, if you think tools like Sass are disposable, you will repeat this process again soon for a similar case. When do you say: "No, I think I will stay on this course". Wisdom is knowing what to overlook.
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 analogous 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 it was no longer needed. 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 longer than people think, or openly admit. For some projects, it is probably marked as technical debt, and will be removed when there is an opportunity to do so.
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 it comes with a price.
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, type of project, or methodology.
Let's focus the discussion on why you would choose one thing over another with appropriate context and nuance. Recognize that switching from Sass to CSS has costs and benefits on existing projects, for green field projects you have a lot more latitude.
Brad Frost expressed similar thoughts in a Twitter thread recently when he made a one-page website with HTML and vanilla CSS, which I will paraphrase:
I've always seen a lot of all-or-nothing zealotry on both sides when it comes to tools and abstractions. Going without any sort of tooling/abstraction is tedious and inefficient. Going all in on tooling/abstraction is like taking a firehose to a teacup.
Every project has different needs that influence what/how much tooling/abstractions are necessary. My biggest piece of advice is challenge all-or-nothing thinking and be pragmatic about it all.
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, and they continue to evolve.
CSS has come a long way. Over time, we are able to achieve more without tools, but it is a process of evolution. Keep in mind that nesting being adopted by CSS is partly due to the success of the feature in Sass. Let's give tools their dues and not be signing their death certificates when other tools adopt some of the things that made them great.
I do not see myself replacing Sass in existing projects soon. I will consider CSS in a different light for new projects going forward as it is growing more capable. That's all good in my book.
You can subscribe to my RSS feed to get my latest articles.
Top comments (26)
I think most of us are missing the point there is no use in arguing which is better its just a matter of using what fits your project and shouldn't be about disposing of other frameworks/libraries, in my understanding what the writer was trying to say was to look at features needed in your website/projects and figure out what works best most of these frameworks we dispose of are still used in tech companies because that works for them the basic idea is still stop riding on these ridiculous hype train and focus on user experience
Yes, this has long been a thing. When you combine this human tendency with the fact that people often assume newer is better, you end up with some teams making decisions that actually undercut their ability to quickly deliver value to their customers (I've been on a couple of those teams).
I see some people commenting on the merits of Sass, but I think the takeaway from your article is just to be thoughtful about these kinds of decisions rather than whether Sass is a "good" tool. As you point out, there's a difference between moving away from older tech you're already using and choosing to use older tech for a new project. In the former case, it's wise to do some cost-benefit analysis, and make sure you analyze hidden costs as well.
Thanks for this article Rob. I really do not get why people be dropping one preprocessor or framework for another. IMO I personally pick a preprocessor or framework depending on what I am building.
If you're only using Sass for basic variables and nesting, it might be time to switch to CSS, but there is so much Sass offers that CSS likely will never incorporate.
Mixins, extends, and the @at-root function are very useful tools to keep code organized, readable, and DRY. If you're making a library, using variables set to !default prevents unnecessary duplication.
However, the feature of Sass that I find invaluable is the ability to loop through lists and complex multi-level maps. For example, my fonts setup converts a Sass map to class names, mixins, extends, and CSS variables, providing vastly more functionality with a much more readable configuration (generating hundreds of lines of CSS from dozens of Sass).
CSS will (probably) never have this capability. There are many people for which CSS now has all the functionality they used with Sass, but there's so much more in this language worth experimenting with if you never have.
+1 for @at-root :D
I agree - we should only drop things if there's actually a benefit, not just because we can.
I'm not saying this is the case here, but I've known some people who are dismissive of the 'easy' way of doing things because they think it makes them look more technically impressive. In my view, tools are tools; why make things more difficult if you can achieve the same result with less effort?
In my view, JQuery's a little different from Sass. With JQuery you have to bundle it and it adds an overhead to downloading a website; this is the case even if only a small part of it is used. That's not really the case with Sass, as it's compiled into CSS.
I haven't added sass to any project for like 5 years.
Postcss can do everything sass can with better performance and without node gyp errors.
The node gyp issues usually arise from node-sass. I've run into this, especially with newer versions of node. Instead I use the sass library (npmjs.com/package/sass) and I can skip the node-sass issue. Works well with Webpack and Gulp.
I have to agree. I have been using Postcss for many years after using sass for many.
Hi Willi
By better performance, do you mean it processes the CSS more quickly? And are there any plugins you recommend?
Ususally I only use postcss-nested, postcss-import, autoprefixer and a custom plugin for stripping the color function. It's basically just for DX.
There is plenty more on preset-env.cssdb.org
Depending on your stack you are already using postcss with some plugins.
E.g. Tailwind runs via postcss and includes autoprefixer and postcss-nested
Vite includes postcss-import by default.
yes. not sure about the current "sass" package, but "node-sass" was always a pain for me.
Thanks for insight. I'm currently using Angular/Sass; pretty sure postcss isn't in the build chain.
👏 Wonderfully put!
nice article
Another benefit that preprocessors like SASS provide you over CSS are features. Since SASS does not have to bend to any standard, it can ship changes much quicker. CSS on the other hand has to go through a hassle of discussions of what to implement in the next standard and consequently waiting until said changes are implemented in all browsers. Whereas SASS avoids this by compiling down into CSS whilst having all the modern features.
A new SASS-like language is coming!
Meet Bro 😋 github.com/openpeeps/bro
... and more!
It really boils down to functionality and personal preference at the end of the day. I would hate to see Sass go, but I don't imagine that day is near -- especially if Sass continues to play the role of shaping CSS's future and supporting a more rich feature-set than plain CSS.
One of my biggest gripes dealing with plain CSS is cross-browser support. Sure it is better than the lack of standardization 1 to 2 decades ago, but we would still be at the mercy of browsers deciding to support something. Browser vendors can simply not support them. Arguing that it is fine since most browsers use Blink is equivalent to someone stating IE would dominate for a much longer period. Better to somewhat independent from the changes in standard if we have tooling that acts as a translation layer.
Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more