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 know...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
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.