Stepping Away from Sass
cathydutton.co.uk
Stepping Away from Sass
1–10 of 157 posts
Re: Stepping Away from Sass
#2Variables are still new and not fully supported.
Being able to nest css selectors is major win for me.
Reusable mixins is another.
I just don’t see a compelling enough use case today to switch to pure css for non trivial applications.
Re: Stepping Away from Sass
#3Nowadays I just do functional CSS (Tachyons, Tailwinds, Fractures, etc). It has some drawbacks but you can go faster and change things more atomically without breaking everything when changing a class, and you have the safety given by the fact that every property have the same level of specificity (which can be overriden by JS generated style attributes, in case you need to manipulate the DOM directly)
Also, you can address your rendering needs atomically which works very nicely when you're writing components in isolation. They also are an excellent approach when doing server-side rendering since you can store classes combinations in variables that can be passed from one template to another or used and overriden in the same template as it gets evaluated by the server. It's almost like a pre-processor without the hassle of recompiling your sheets.
Re: Stepping Away from Sass
#4Does a preprocessor really complicate the workflow? Variables are still new and not fully supported. Being able to nest css selectors is major win for me. Reusable mixins is another. I just don’t see a compelling enough use case today to switch to pure css for non trivial applications.
* Duplicating the effect of mixins by just... having another css class for the mixed-in stuff works well enough for many cases (though this hurts most where you're trying for semantic selector naming conventions, with mixins adding in rulesets behind the scenes).
* Nesting selectors save thinking and some typing regarding where styles cascade out to, but... tbh, yanking a high-resolution selector into the buffer and chucking it out onto another line was never a burdensome part of my pre- processor workflow.
* Pretty sure free-use of nested selectors and mixins is trading larger CSS files for developer attention (which may or may not be a valid trade).
* Variables... yeah, they're handy. Search-and-replace only goes so far. IE seems to be the holdup.
For small or disciplined teams with the freedom & skill to really think about their CSS starting from a style-guide-first perspective rather than every-page-a-custom-layout perspective, I can see making the choice to do without. Especially if you've already ditched IE 11 support for other reasons.
Re: Stepping Away from Sass
#5Does a preprocessor really complicate the workflow? Variables are still new and not fully supported. Being able to nest css selectors is major win for me. Reusable mixins is another. I just don’t see a compelling enough use case today to switch to pure css for non trivial applications.
Re: Stepping Away from Sass
#6Is this a common pattern in industry as well?
Re: Stepping Away from Sass
#7I honestly have never seen the value in pre-processors when writing CSS. I think they abstract a lot of low-level understanding of your UI and make your stylesheets overly complex. They definitely keep things sane when doing CSS at very large scale (for example dealing with color palettes, fonts, etc) but are not that useful when you're writing different components with different rendering needs. Nowadays I just do f…
As mentioned, theming and consistent ux requires far less writing and copy paste with a preprocessor than in pure CSS.
I think React's approaches make CSS feel simpler but often just sweep the inefficiencies under the rug.
A lot of this is being fixed with CSS4, so these will go the way of jQuery. And while you don't need jQuery today, it served as an important polyfill for a long time.
Re: Stepping Away from Sass
#8Does a preprocessor really complicate the workflow? Variables are still new and not fully supported. Being able to nest css selectors is major win for me. Reusable mixins is another. I just don’t see a compelling enough use case today to switch to pure css for non trivial applications.
Re: Stepping Away from Sass
#9CSS is the #1 place where I spot those cases. And I feel that Sass and other CSS preprocessors mostly lend themselves to shooting yourself in the foot with abstracting similar things that aren't actually of the same category.
Re: Stepping Away from Sass
#10Does a preprocessor really complicate the workflow? Variables are still new and not fully supported. Being able to nest css selectors is major win for me. Reusable mixins is another. I just don’t see a compelling enough use case today to switch to pure css for non trivial applications.
I just looked it up and css variables are available on all current version browsers and have been available since about 2016/2017
They also aren't a full sass/less replacement, just one aspect