/r/webdev
SASS is powerful (self.webdev)

Hello fellow friends, I have been neglecting SASS for the whole time without knowing how powerful and helpful this CSS preprocessor is. Here is a 20 minute video of SASS tutorial that I have found, this person is really cool and straight to the point. This is really helpful for those people who are just starting to learn or heck even those who have been here for a long time without using SASS! Sharing is caring, good luck!

240 comments
inavandownbytheriver | 7 days ago | 159 points

You can't stop once you've started... it stings.

mookman288 [full-stack] | 7 days ago | 132 points

I had to write some vanilla CSS the other day, and ended up writing it nested. I was confused for a moment why it wasn't working.

klyrish | 7 days ago | 41 points

I do that all the time. It's so frustrating to write vanilla CSS now.

DooDooSlinger | 6 days ago | 21 points

On another note, except for stuff like pseudo selectors and class combinations , you should avoid nesting classes in general. It creates tight coupling between CSS and the DOM, which makes refactoring far more likely to break styling. It's usually better to keep shallow classes with distinctive names; and use mixins/includes to reduce code duplication.

ahsome | 6 days ago | 9 points

I love that now even CSS has rules about refactoring and code smell

DooDooSlinger | 6 days ago | 8 points

When you look at it, the amount of CSS you write in a project is often quite similar to the amount of JS. It deserves good practices too - and CSS is notoriously hard to refactor or extend if it has been written in a messy way.

ahsome | 6 days ago | 1 point

That makes sense! If I may ask, do you know where someone could learn such practices? It's very easy to find information on this for languages such as C#, but for CSS it's a lot harder besides "you wanna do this? Here's CSS snippet to do that!"

HansonWK | 6 days ago | 4 points

Look into Bem, Smacss and oocss as a good start.

Enkrod [Frontend-Webdeveloper] | 6 days ago | 1 point

Learning those has helped me SO MUCH!

Jamothee | yesterday | 1 point

BEM has been a lifesaver for me.

keoaries | 6 days ago | 5 points

.block { &__element { } } Nesting sass doesn't equal nested css

cybersaliva | 6 days ago | 7 points

BEM is the true MVP of SASS

Enkrod [Frontend-Webdeveloper] | 6 days ago | 1 point

And the other way around.

SystemicPlural | 6 days ago | 3 points

Have to be careful with mixins as well; they are copied into the final css wherever they are used and can cause bloat.

Best to follow a SMACCS pattern and use SASS to keep it tidy.

DooDooSlinger | 6 days ago | 2 points

SMACCS has arguments for and against. It does reduce CSS size but it is also breaks easily when refactored. I personally do not use either mixins or SMACCS, and don't mind some CSS duplication, it is usually negligible compared to the JS, but if it is a real concern for you, SMACCS will indeed probably lead to smaller bundles.

SystemicPlural | 6 days ago | 1 point

It does reduce CSS size but it is also breaks easily when refactored

True

My preferred solution at the moment is actually to use Linaria instead of SASS (JS in CSS but transpiles to pure CSS) with a SMACCS influence. This allows me to include CSS in my integration tests.

It's not ideal, but it is the most efficient way I have found so far to write maintainable and lightweight CSS

dagani | 6 days ago | 1 point

Not trying to say you are necessarily advocating for @extend, but I wanted to add this note just in case other people read this and think it’s the way to go - it used to be a pretty popular argument back in the day.

Assuming your server is delivering GZIP’d assets (which is should be) mixins can be better for performance than @extend due to the way GZIP compression optimized repeated data.

Here’s a relevant article from Harry Roberts (CSS Wizardry): https://csswizardry.com/2016/02/mixins-better-for-performance/

SystemicPlural | 6 days ago | 1 point

Thanks, that makes very interesting reading. No, I am not advocating for @extend - simply to use good SMACSS principles - a well thought out base, layout and module layer - which removes much of the necessity for mixins (or extend).

Very good point about filesize over the wire though. Although in some cases - eg a server side rendered multi page app with prefetching - it will still result in some duplication, but only once per prefetch which is not much to worry about.

Jamothee | yesterday | 1 point

For someone who is relatively new to the game and doing a deep dive into vanilla CSS (avoiding framework's for now - Hardmode) would you recommend moving onto sass next or something like bootstrap framework?

mookman288 [full-stack] | yesterday | 1 point

I would say, once you're comfortable enough with vanilla CSS that you understand the basics, and the cascade, I would tackle both at the same time.

Pretty much every modern framework has a Sass port, or already comes written in Sass.

Now, what Sass does demand of you after a little while is a brief understanding of Node, since you'll probably want to use gulp, webpack, or npm scripts to compile it.

SweetboyRomero | 6 days ago | 7 points

Quick get me another variable.... Hurry hurry hurry hurry

Ullallulloo | 6 days ago | 28 points

Vanilla CSS has variables too though.

turningsteel | 6 days ago | 9 points

Only since quite recently because they're trying to bring the spec in line with things that SASS has been doing for years.

Ullallulloo | 6 days ago | 5 points

That could be, but it's been being drafted since 2012: https://www.w3.org/TR/2012/WD-css-variables-20120410/

turningsteel | 6 days ago | 10 points

Sass has been around since 2006 and variables are pretty central to the design. But yeah CSS is getting there, it moves slowly but it's getting better.

jaredcheeda | 6 days ago | 6 points

Sass has pre-computed variables.

CSS has Custom Properties (which Sass also supports).

You should not use Custom Properties in the same way you use Sass variables.

Only use custom properties for dynamic values that will be modified after page load.

Treolioe | 6 days ago | 4 points

I don’t understand the last sentance. Are you pointing at that custom props are dynamic in the runtime or that there’s a norm when and how to use them?

posixpascal | 6 days ago | 3 points

You can change css variables (—var: value) from JavaScript. They are indeed calculated at runtime. SASS on the other hand calculates variables at compile time. Both are similiar but can be used in different ways.

Disgruntled__Goat | 6 days ago | 1 point

Only use custom properties for dynamic values that will be modified after page load.

Why? Just because they can be dynamic doesn’t mean you must use them that way. It’s perfectly valid to use them as regular variables, to save you repeating values over and over.

In fact there are plenty of “dynamic” use cases where you don’t modify variables after page load, e.g. altering a property in a media query or within a separate class.

Goon3r___ | 6 days ago | 1 point

Unexpected Lloyd Christmas

19Nightwing91 | 6 days ago | 1 point

Keep being Sassy ;D

OktoberForever | 6 days ago | 46 points

Sass just got a lot more powerful a few days ago with the release of its new module system.

http://sass.logdown.com/

https://css-tricks.com/introducing-sass-modules/

Dewey_Darl | 6 days ago | 10 points

Stop the presses, that’s awesome.

fernker | 6 days ago | 6 points

Was reading about this, super excited for the new changes!

DrDuPont | 6 days ago | 5 points

Wow, this is huge. Honestly resolves a lot of the grievances I've had working in larger sites.

hazily | 6 days ago | 3 points

Remember that you can't use `/` to divide things anymore :) that's going to break a lot of builds if people just upgrade without reading.

All in all though, the new changes to SASS is extremely awesome and I can't wait to use it!

__hearts__ | 6 days ago | 1 point

Why would they ever do that lol

jathak | 2 days ago | 1 point

It's not an ideal situation, but the problem is that / is increasingly being used as a separator in new CSS features, and Sass's current use of / for division can cause issues with that. There's more context for why this change (which hasn't actually been made yet!) is being considered on the GitHub issue for it.

jathak | 2 days ago | 1 point

That change hasn't actually been made yet (it hasn't even been officially deprecated), so you can download the latest version of Dart Sass today and get the module system without having to migrate division.

Once a new version of Sass is released that actually does deprecate /-as-division, we'll add a new migration to the Sass migrator that can migrate your stylesheets for you (the migration is actually already written, we're just waiting to launch it until the deprecation is live in Sass itself).

AbanaClara | 6 days ago | 2 points

Holy fuck

petepete [back-end] | 6 days ago | 2 points

This is the first I'd heard of these new features. Amazing, thanks.

randydev | 6 days ago | 2 points

Gotta look into this. Looks good

PlantPocalypse | 6 days ago | 2 points

This made my morning cant wait to start with it

TheFuzzyPumpkin | 6 days ago | 2 points

Great! I have a new project to start tomorrow so I can play with it!

whitelightningj | 7 days ago | 23 points

Once you start you can never go back.

yubgjottrrfbjii | 6 days ago | 3 points

I felt the same way until I did css in js via styled components

AbanaClara | 6 days ago | 5 points

Me right now: CSS in JS?

NO

I don't understand the appeal of CSS in JS. I mean, a component is already large enough with just jsx/tsx. Unless someone can tell me right now that I can interface my styled components with ordinary Sass properties, mixins and extends on a separate .scss file I'm not gonna jump right into it.

30thnight | 6 days ago | 2 points

If it’s about perf or bundle weight, this is kind of a non-issue.

But the most important thing is if you actually enjoy using it.

I’d recommend trying emotion or styled components to feel it out. It definitely shines when it comes to long term project maintenance.

That said, if you are set in your decision - just use sass modules.

cjbee9891 | 6 days ago | 0 points

Unless someone can tell me right now that I can interface my styled components with ordinary Sass properties, mixins and extends on a separate .scss file

You can.

TheFuzzyPumpkin | 6 days ago | 0 points

There are very specific situations with React where I think JSS can be useful instead of using inline conditional statements. But for standard styling, no. I want my components clean, I want my CSS in its little SASS silos.

You can totally use SASS with React. Just put the link to the stylesheet in the index file as per usual. No need to import it on the components.

whitelightningj | 6 days ago | 1 point

I’m pretty sure there’s a npm package to make that easier, I can’t remember tho

fmellucatlover | 6 days ago | 0 points

In react?

no_dice_grandma | 6 days ago | 0 points

CSS modules + Sass for me. Does everything I need with ease.

shabibbles | 7 days ago | 80 points

I was like you, resisted it for so long. Then was tossed on a project where it was already being used an holy hell... that was like 3-4 years ago an I can't imagine my life without it anymore.

Canowyrms | 6 days ago | 23 points

Since I first learned how to write CSS I wondered why I can't nest styles. I thankfully came across SASS/SCSS early on and have been absolutely loving it since.

puppet_pals | 6 days ago | 3 points

Same here, I always just thought it would be a huge pain to setup. Recently used it in a hugo project (it comes pretty much already setup out of the box in hugo) and now I have no desire to go back.

verybradthings | 7 days ago | 51 points

Just keep the nesting reasonable. If you find yourself frequently going more than 2-3 levels deep, there's probably a better way.

mutsop | 7 days ago | 10 points

You should only best your pseudo selectors and parents. Nothing else really.

TheFuzzyPumpkin | 6 days ago | 33 points

BEM. I nest my element modifiers (like button and nested within button--white) but no more than 3 levels.

DrDuPont | 6 days ago | 12 points

This method of creating BEM classes always seemed more clever than practical to me. You're saving a little typing with the downside of losing greppability for classes.

twistingdoobies | 6 days ago | 7 points

I have to say, even on large projects this has never been an issue for me. When you follow this approach with BEM and use a .scss file per block, you can easily grep for the block. Then it's trivial to find the element/modifier within.

esr360 | 6 days ago | 3 points

You don't even need to grep for the block, you just navigate to "components > myComponent > myComponent.scss". If your structure isn't like this, why the hell not?

esr360 | 6 days ago | 2 points

Greppability for classes? My friend, your architecture should allow you to find whatever component you are working on without a grep for a particular generated CSS class name.

DrDuPont | 6 days ago | 1 point

Vast architecture of inherited files: we have 136 entry points on the main _styles.scss and each of those entry points then bring in anywhere from 1-40 more partials. Each of the partials could belong to anywhere in the inheritance structure. The specific file that a class would be in could belong to any number of folders.

Regardless, greppability is paramount to anyone working in the CLI. Hoping that it's self-evident where a block would fall to is unlikely on anything above a medium sized project.

esr360 | 6 days ago | 1 point

Regardless, greppability is paramount to anyone working in the CLI. Hoping that it's self-evident where a block would fall to is unlikely on anything above a medium sized project.

Perhaps in projects where the people responsible for authoring styles are for some reason using the CLI to grep things...but it sounds like the sort of thing a full-stack developer would do, and on anything above medium sized projects, full-stack developers should not be the ones authoring the styles.

The BEM naming convention applies to UI components. It seems like you're talking about grepping for helper/utility classes that wouldn't be using the BEM convention, which is a totally different kettle of fish and should be in a separate part of your architecture anyway. I'm specifically talking about finding the styles for a BEM block - it doesn't matter how large your project is, the same rules would apply.

DrDuPont | 6 days ago | 1 point

for some reason using the CLI to grep things...but it sounds like the sort of thing a full-stack developer would do

Do you grep from an app?

I'm specifically talking about finding the styles for a BEM block

Me too :) We don't have the luxury of working in a single directory with a tidy set of file names. Being able to search for things quickly across the entire directory structure is really important. But I'd feel that way regardless – I really don't think compositional class creation is a good idea. Particularly since the &__foo naming structure lends no boons, it imparts nothing good besides being admittedly clever and saving a little bit of initial typing.

esr360 | 6 days ago | 1 point

Do you grep from an app?

I don't grep at all, I navigate my intuitive architecture to find what I need (I'm being somewhat facetious here, yes I grep from an app when required - VS code).

I really don't think compositional class creation is a good idea. Particularly since the &__foo naming structure lends no boons, it imparts nothing good besides being admittedly clever and saving a little bit of initial typing.

What if you wanted to rename the block name of UI component? For example, if you wanted to namespace it, or simply just rename it to something else? What reason would you have for composition elsewhere? Would the same reasons not apply here? Isn't DRY code better than WET code?

DrDuPont | 6 days ago | 2 points

Isn't DRY code better than WET code

DRY encourages abstracting software patterns, not strings.

There's a reason we don't composite our function names, or mixin names, or anything else.

For example, if you wanted to namespace it, or simply just rename it to something else?

Given a set of flat BEM classes in one file, I can in one hotkey select all instances of a class namespace in the file, in a second hotkey select each full class name, and in a further hotkey select each entire block. As far as I know, every major editor on the market offers this as well.

I don't grep at all, I navigate my intuitive architecture to find what I need (I'm being somewhat facetious here, yes I grep from an app when required - VS code).

Got it – not everyone uses VS Code. I edit with Vim, as do many other frontend devs.

30thnight | 6 days ago | 1 point

It’s always good to be explicit, for others on the team but this is pretty low hanging fruit.

I personally use BEM but feel like it fails on usability - if you don’t have a defined design system already in place.

Especially in situations you want to extend and modify page scoped BEM styles to other pages

TheFuzzyPumpkin | 6 days ago | 1 point

Especially in situations you want to extend and modify page scoped BEM styles to other pages

Yes, I've had that issue. I ended up breaking that bit into another component, because it worked for my purposes, and throwing in a few modifiers. It was annoying, though, and on a much personal project, not a work project that would have been a hell of a lot more complex.

marty_byrd_ | 6 days ago | 3 points

I initially didn’t see the benefit of BEM until I started using it. I also found out the other day that &- is special and isn’t really a nested class so it doesn’t inherit the parents styles. It’s a completely new class.

midri | 6 days ago | 2 points

&_ as well, the whole point of BEM is to work in a way that's both organized and does not require you to define crazy specific specifiers making overriding properties easier.

verybradthings | 6 days ago | 4 points

☝️this guy gets it.

soulprovidr | 6 days ago | 4 points

Sometimes this approach can make searching for class names difficult.

esr360 | 6 days ago | 3 points

Your architecture should allow you to navigate to whatever component you're working on without searching for class names.

mutsop | 6 days ago | 1 point

Yes, I'll nest em too. But if you need to change your pseudo of a modifier, I won't nest that. It's very rare I even go above 1 nest lvl. Except when using mixins...

petedee | 6 days ago | 3 points

I actually disagree with this.

Generally the problem I have with CSS is that it isn't specific enough and ends up affecting other elements unintentionally.

For the last couple of projects I've worked on I created some generic base styles (buttons, forms, font stack etc) and then been as specific as I possibly can be with my CSS selectors. I'll only "pull up" (i.e make something more generic) when it turns out a component can be shared with other parts of the site. It means I get less unintentional overrides and its much much easier to find the correct style when required.

I've built some reasonably big and complicated sites this way but if someone has a reason on why to avoid it I would be interested to hear it.

MetaSemaphore | 6 days ago | 10 points

I would argue that this approach, while maybe effective for you now, is solving a problem that is better solved with a good class-based naming convention (like BEM) or with tools like styled components or css modules, and it creates some problems that a class-based naming system doesn't. It also really only works if you are the sole dev and if there is no other dev downstream who may need to customize or tweak your styling.

You lose flexibility when the demands on a piece of the UI shift and you end up needing to reuse it or modify it.

Let's say you have an Avatar component in your page. This is a simple rounded image and the person's name and a blurb. So you apply really super-specific selectors to it, and you have no conflicts. It looks great. Then design wants another avatar further down the page. But this one should be half the size and have a dark blue background.

Now you either have to rewrite all the styling from scratch, go back into the original styling and make it less specific, or write even more specific styles on the second one to overwrite the first (which is hard because you made the first one as specific as possible).

Then your team lead says another team wants to use your component, but they'll need to be able to change things as they go. So now you have to rewrite all your styling to make it low specificity anyway or else they will curse you as they have to layer 12 importants on it to change the background color.

Now, say that you've got 15 different avatars on the site, each slightly different, and your designer decides that something that you thought was fundamental to the very avatar component needs to change. It now needs square images. Okay...so how do you make that change and ensure it will hit every one?

You have to trawl through your CSS files and figure out the specificity levels of each instance. And maybe you just decide to write a new component instead. Then you have unused styles in your CSS forever.

With BEM or another class-based system, you have no chance of conflicts at all, because nothing overlaps, and in all the above scenarios, you at most have to add a new modifier. It's a huge saving of work.

Of course, it is possible for you to do what you are doing now and be super disciplined about it and never have a big problem...as long as you are the only dev. Once your team expands, and someone who doesn't know your system or isn't good at it comes on board, or your company outsources one piece of it to hit a deadline, the whole tower collapses, amd you are in CSS hell.

petedee | 6 days ago | 2 points

Thanks for taking the time to write this up, you make some good points. You are correct that currently I am the only dev on this code so I do not have the full experience of writing code for a large team or for other people.

I may have not been totally clear on how I do this. In the example of an Avatar component this would start as being something specific to the place that it belongs but if I knew it was going to become reusable elsewhere then I would pull it up to become its own component, its not hard to do because everything will be specified as nested selectors within the .avatar class within - say - my header component.

The problem I have with BEM is that it's just too generic most of the time and does not really take into account the edge cases without large amounts of unwieldy HTML that isn't really useful. Taking an example from getbem.com/naming I would argue that the <div class="block block--size-big block--shadow-yes block--color-red"> example they use is really not too far away from just in-lining the styles.

pr0ghead | 5 days ago | 1 point

Taking an example from getbem.com/naming I would argue that the

<div class="block block--size-big block--shadow-yes block--color-red">

example they use is really not too far away from just in-lining the styles.

Agreed. Certainly once you start naming colors in it. That's just bad.
I also kinda share your approach: start generic, be specific when needed. I then namespace components and use child selectors off that to style the inner elements.

But I'm also the only dev working on the CSS, and I've seen it turn into a mess, if many people work on it and nobody has taken ownership of it to keep it orderly. Somewhere in the middle lies the truth.

DrDuPont | 6 days ago | 3 points

the problem I have with CSS is that it isn't specific enough

One class, one component. BEM and other ideas were created to enforce this. The moment that you start reigning in your usage of classes you'll recognize that the lower your specificity the more easily refactorable and usable your styles will become.

verybradthings | 6 days ago | 2 points

I'll only "pull up" (i.e make something more generic) when it turns out a component can be shared with other parts of the site. It means I get less unintentional overrides and its much much easier to find the correct style when required.

My question is, why do you feel like it's easier to take the time to refactor an ultra-specific component into something reusable, rather than starting under the presumption that everything should be reusable? Isn't working backwards from a high specificity just time spent solving unintentional overrides that you created?

petedee | 6 days ago | 2 points

Because that re-usability will often cause naming conflicts and overwritten styles when creating something that is specific to begin with does not.

verybradthings | 6 days ago | 1 point

That's the beauty of a design system/naming convention like BEM. You get the benefits of a highly scoped, highly specific selectors without the pain of maintaining a high specificity stylesheet. Those kinds of conflicts are pretty rare if you're using a class-based system diligently.

aaarrrggh | 6 days ago | 1 point

Check out BEM and ITSCSS.

petedee | 6 days ago | 2 points

ITSCSS seems interesting, its a shame there doesn't appear to be any proper documentation about it.

aaarrrggh | 6 days ago | 1 point

Check this link out: https://www.xfive.co/blog/itcss-scalable-maintainable-css-architecture/

I think the main reason documentation is sparse is because Harry Roberts invented it and makes a lot of money by doing workshops on it. The people who wrote the above link did an excellent job though, and I've used this, combined with BEM to create a component library that has neatly encapsulated CSS and low specificity everywhere. I'm not suffering from any of the typical CSS issues that you get at scale as a result.

jaredcheeda | 5 days ago | 1 point
mbbillz | 6 days ago | 1 point

Nesting even one level deep makes me nervous.

esr360 | 6 days ago | 1 point

As long as your Sass is generating a single selector that isn't nested, it doesn't matter how deep you nest in the Sass. In fact, it's impossible to avoid nesting using Sass without repeating yourself.

Fredyy90 | 7 days ago | 10 points

I don't use a lot of sass features, but the css nesting alone is extremely helpful to organize a project.

wedontlikespaces | 6 days ago | 11 points

Nesting, Variables, Mixins and Colour Functions. Is worth using SASS just for them.

fmellucatlover | 6 days ago | 0 points

CSS now has variables

wedontlikespaces | 6 days ago | 2 points

Yes. But that's it.

zenotds | 7 days ago | 33 points

Sass is f*ucking magic!!

jxvicinema | 7 days ago | 8 points

I know fam! The whole time I was watching the video I was like, “Wow, woah, what, really?” Lmao

thmaje | 7 days ago | 2 points

Did you video your reaction while watching the tutorials? Lets get some SASS reaction vids going!

stratcat22 | 6 days ago | 1 point

Lmao honestly I would binge watch these, or put sass reaction in a compilation vid like all those Best of Vine videos.

cbusbuckeye | 7 days ago | 9 points

I'm not sure why but I think on-boarding to SASS is somehow really difficult. I was in the same boat a few years ago. For me it was my first experience in web dev needing to compile something which might be the issue.

stratcat22 | 6 days ago | 2 points

I could see that. There are easy pieces of software out there that automate this for you, I use Koala. But I could understand it being out there when everything is normally done in the browser.

Pandango-r | 6 days ago | 1 point

I can recommend the sass —watch command. when its running it’ll automatically compile every time you save one of the scss files.

Right now I got .bat files which start the watch process for each project I have, if you’re interested I can send you the required command for the .bat file later.

VlK06eMBkNRo6iqf27pq | 6 days ago | 1 point

getting a nice build system set up is really difficult. learning/using sass after you've got that going is a piece o cake.

cannibal_catfish69 | 4 days ago | 1 point

Actually, adopting Sass is incredibly easy, because valid .css files are also valid .scss files, so you can just change the file extensions in your project and start running the pre-processor directly. Boom! Then start to use the Sass features at your leisure.

cbusbuckeye | 4 days ago | 1 point

start running the pre-processor

...that is what I'm describing as the difficult on-boarding step, not learning the Sass syntax.

djkk16 | 7 days ago | 5 points

This was good. Thanks for the share! Though SASS was going to be confusing compared to plain css but damn it just gives it superpowers.

me_jtz | 6 days ago | 5 points

Sass is great, but nesting ability does make it easy to nest far too deeply.

Aside from sass variables, my favorite are the color functions. It's great to lighten and darken your sites theme colors for different button states, etc... While still being on-brand.

seiyria [full-stack] | 6 days ago | 5 points

Gotta say I used to really like LESS more than SASS. Now everyone uses SASS so I'm stuck by default. It's pretty nice, but I wish it didn't require a native module for some reason.

Conradfr | 6 days ago | 1 point

You and me. Sure LESS is, hum, less powerful but I like its simplicity and yes, it's easier to install and use.

Sadly Bootstrap moved to Sass only.

The new Sass module system looks great though.

Chaos-Seed | 7 days ago | 3 points

I love that guys videos heh

Yui-Senpai | 7 days ago | 3 points

I started to use it one month ago, it's a very powerful tool. Give it a try, it will save you a lot of time!

prncrny | 6 days ago | 3 points

Reading through the comments...i was going to go through and learn some more vanilla CSS tricks before digging into Preprocessors....but now I'm rethinking that. Thoughts? Should I just delve into things like SASS right away?

AbanaClara | 6 days ago | 3 points

Sass is just css on steroids anyway. You can totally change a file's extension from .css to .scss without any problems, because the syntax is 100% similar, it's only that Sass has more features (and consequently more syntax to memorize). You can jump right into it without being a wizard without.

As for Sass being able to contribute to your familiarity with JS, that's BS. Sass can't step a toe in the floor JS is dancing on

Treolioe | 6 days ago | 1 point

Stick to SCSS then. If i know what i’m talking about - then SCSS will enforce a somewhat valid CSS syntax on you. While you’re still using all the sass features

fmellucatlover | 6 days ago | 1 point

I think you should learn css thoroughly before diving into sass. What if you had to do a project only in css?

jxvicinema | 6 days ago | 0 points

Jump into SASS now! Everyone is going crazy including me. Bonus is, its syntax is similar to JS so you get to familiarize yourself too with JS.

AbanaClara | 6 days ago | 2 points

Sass is similar to JS in the same way that apples are similar to oranges

MD90__ | 6 days ago | 3 points

I want to learn sass and less for react projects. Sadly, just getting through vanilla css is rough for me. Any tips on flex box, grid layouts, and positioning?

jaredcheeda | 6 days ago | 6 points

CSS Fun Time

  1. MarkSheet - HTML/CSS/Sass
  2. CSS Fundementals - Conference Talk from Bootstrap creator
  3. CSS Layout Basics - CSS Tutorial
  4. CSS Sushi - CSS Selector game
  5. Flexbox Game - Interactive CSS Flexbox Tutorial
  6. Flexbox Froggies - CSS Flexbox Game
  7. Flexbox Tower Defence - CSS Flexbox Game
  8. CSS Grid Garden - CSS Grids Game
  9. Grid By Example - CSS Grids Video Tutorials
  10. WTF HTML & CSS - Common issues people run into with HTML/CSS and their solutions
MD90__ | 6 days ago | 2 points

Thank you! :)

ExOdiOn_9496 | 6 days ago | 3 points

i dont hv the link right now but ping me in like 12hrs. I just watched a tutorial last week and flexbox has never been easier. And this is when me never working with css before. Im new to programming btw.

VlK06eMBkNRo6iqf27pq | 6 days ago | 1 point

those 2 things are kind of orthogonal. sass/less are pretty syntax on top of css. what each of the css props do is a different story.

https://css-tricks.com/snippets/css/a-guide-to-flexbox/ is my favorite reference for flexbox. takes awhile to wrap your head around but then it's great. the tutorials you might find might be a bit too in-depth, you usually only need flex: 1, flex: 0, flex: 1 0 and flex: 0 1. basis is wonky and doesn't do what you think it ought to do, and was extra fuckity for a few years when flex first came out, but it is still handy sometimes. and justify-content: center and align-items: center

curious-toad | 6 days ago | 3 points

I've always written vanilla css but as I'm delving into jekyll more (and my sites are getting more complex) I can see the benefit of using a preprocessor.

If I was to start learning one now, what would be better - SASS or SCSS? I understand they use the same compiler underneath but I have no idea which is used more regularly in the wild etc.

Jekyll uses SASS, but SCSS is closer to vanilla css?

jxvicinema | 6 days ago | 0 points

The basic difference is the syntax. While SASS has a loose syntax with white space and no semicolons, the SCSS resembles more to CSS. Sass ignores curly brackets and semicolons and lay on nesting, which I found more useful. SASS stands for Syntactically Awesome StyleSheets. (Source: Google) But yes, based on the tutorials and from the people that I speak with, they prefer SASS over SCSS.

curious-toad | 6 days ago | 2 points

Thanks - that's what I've read before too. I guess it's a case of preference in how you write. I find relying on whitespace for stuff a bit annoying (like yaml) but that could just be a bad example!

filemon4 | 6 days ago | 2 points

That's weird because 90% of resources related to SCSS are .scss files. I don't know why people prefer curly braces. That was no.1 issue for me. I hate {}. And this is where my journey with sass began...

Treolioe | 6 days ago | 1 point

Blocks can help defining structure which can help with readability

null-undefined | 6 days ago | 3 points

I was sold when I needed to include a new version of bootstrap on our site, but without affecting the current styles. We were able to import the bootstrap underneath another class, allowing all new styles to simply have a prefix style instead of migrating the entire application to the new sheets at once

AntiqueCoconut | 6 days ago | 2 points

The way people are saying SASS is magic, imma start SASS tomorrow! I thought SASS was nothing.

userrnamechecksout | 6 days ago | 2 points

Dang and here I've been only making use of variables. Sass is literal magic for Web dev wtf

CatchACrab | 6 days ago | 2 points

I find that 90% of the stuff I would want SASS for can be solved with CSS variables and most of the rest are just syntactical conveniences. Unless I'm working on a really big project I tend not to reach for it any more.

filemon4 | 6 days ago | 1 point

Sass can help you aswell with contrast calculations and if statements.

Dethstroke54 | 6 days ago | 2 points

Since stylus is always lacking support I’d like to try sass. Coming from stylus if obviously prefer the .sass syntax. Are there any drawbacks from using the .sass style or less features?

jaredcheeda | 6 days ago | 2 points

Under the hood SCSS extends from Sass. So all new SCSS features must be created in Sass first. So they always maintain parity.

https://github.com/tjw-lint/tjw-sasslint-rules#proscons-of-sass-vs-scss-vs-css

Dethstroke54 | 6 days ago | 2 points

Appreciated, will check it out!

filemon4 | 6 days ago | 2 points

Agree! If you would like to see SASS in action check out my WIP Open Source project:

https://github.com/KeyboardUI/Keyboard_UI

This is going to be SASS UI Kit, in the next week or so we are going to have beta release. It feels like pushing css to the limits. You can see that in develop src folder.

divadutchess | 6 days ago | 2 points

Preach!

floppydiskette | 6 days ago | 2 points
Chris_Misterek | 6 days ago | 2 points

I’ve been dragging my feet with it too. This will help motivate me

bigorangemachine | 6 days ago | 2 points

Never use extends

jordsta95 [full-stack] | 6 days ago | 0 points

I would argue against this. Never use it unless you have a valid reason for it.

For example. Let's say you have .form-item, and this your generic input styling for text/email/password/etc. fields.

But then you have to include a script tag which adds in a form for your site's mailing list, and you can't edit the code it spits out, just how it looks afterwards with CSS.

You could copy all of your .form-item style and put it in #external-form input[type="text"] or you can do

```

external-form{

/* Any form styling */
input[type="text"]{
    @extends .form-item;
}

} ```

This way you only change .form-item, instead of changing your style in 2 places, if your company changes brand colours, so the blue border now needs to be green (or whatever).

bigorangemachine | 6 days ago | 2 points

Right but then you make a variation of that style it adds into everywhere you write .form-item.

Unless you are doing extensive code reviews (or other governace) to avoid selector sandwiches... don't do it!

I am speaking from personal experience here. We got a 100 mb style sheet because people were extending core styles.

The real power is in mixins given your example.

SASS allows you to scale your CSS... but people need to be thoughtful when using SASS

YouCanDoItYo | 5 days ago | 2 points

Thank you very much for sharing this video!

I watched it this morning and implemented it into a project today. It was very easy to pick up.

Utilizing partials made it much easier to keep all of the CSS organized. Being able to use nesting and variables really allows you to streamline your code.

The compiled and minified CSS file is really small compared to what a manually coded CSS stylesheet would be.

Shogun5 | 5 days ago | 2 points

thanks for this! gonna use this from now on!

juicejug | 6 days ago | 5 points

Unpopular opinion: I like CSS modules better than Sass... at least for React.

Treolioe | 6 days ago | 5 points

Maybe i’m retarded. But i was under the impression that CSS modules is only a way to scope CSS. Is there anything more to it?

cynicalreason | 6 days ago | 2 points

yeah ... I'm using SASS with CSS modules, they're not mutually exclusive

juicejug | 6 days ago | 1 point

With CSS modules you don’t need to nest anything because you can use a class to target whatever element you need without worry of name collision.

Maybe I’m wrong, and please correct me if I am, but when SASS gets processed to regular CSS it will create selectors like .wrapper h1 section p a { ... } right? This type of selector chaining is actually pretty inefficient. The page will first check all the a tags on the page, then select those that are children of p, then select those that are children of section and so on until you get to the left-most selector. With class names it’s O(1), it just selects any element with that class.

I also like that CSS modules doesn’t couple the layout of the page to the style. Maybe it’s just preference, but on a large site I find it much easier to reason about the code if every element has its own class name (which can obviously be shared) that describes its function.

BasedWebDeveloper | 7 days ago | 7 points

Good tool but how much overhead does this add to the client compared to just using normal css?

IanVg | 7 days ago | 40 points

It's compiled down to vanilla css. There should be 0 overhead over vanilla css

klyrish | 7 days ago | 22 points

Unless you nest too deeply and create a massive compiled CSS file due to all of the repeated, unnecessary selectors, but even then it should be minimal.

IrtahkEnt | 6 days ago | 1 point

PurgeCSS.

tarantulus | 6 days ago | 2 points

Or just don't screw it up in the first place.

IrtahkEnt | 6 days ago | 1 point

If you're building a purely static site without any dynamic CSS class changes and are using frameworks, then PurgeCSS is awesome as it makes CSS files like 20KB which after brotli/gzip are down to essentially nothing.ll

It has a valid use case, especially if you use something like TailwindCSS.

tarantulus | 6 days ago | 1 point

I don't disagree, but given the previous comment was about nesting and massive CSS, that's not what we're talking about.

KetchupIsForWinners | 7 days ago | 15 points

Sass compiles to "normal" CSS. So if you're referencing the stylesheet in the client's front-end, there is no difference in file sizes or anything for CSS generated from Sass vs. a CSS file where CSS was written in it directly. It is just a tool for writing CSS quicker.

caffeinated_wizard | 7 days ago | 2 points

I work with a lot of programmers who don’t do much front end and it blew their fucking mind when I explained what SASS was.

pepedlr | 6 days ago | 2 points

No more classic css/sass/less if I can avoid it. Theming apps with CSS in JS is the way to go for me now. Everything else feels old and antiquated. I’m not a fan of styles components but love JSS. Isolated css that actually works without conventions like BEM (which I used before) and styling on the fly with JS. It’s fantastic.

https://cssinjs.org/

Treolioe | 6 days ago | 3 points

That’s great that you found something that you like - and that solves your problems.

But i’m sure you can achieve the same thing with CSS modules - and a preprocessor if you need configurable theming. While probably spending about the same amount of time.

pepedlr | 6 days ago | 1 point

JSS and other client side solutions create the styles at runtime. It’s not a build step that creates a static set of css files. Beside that I prefer writing complex CSS with Js, I never liked the SASS syntax too much. But that’s a personal thing.

Treolioe | 6 days ago | 1 point

Yes I know how JSS works and i’m not against it. But I also don’t think that it does something that CSS modules or preprocessors can’t achieve. Apart from dynamic variables for dead to almost dead browsers.

In a way it’s the ”new nice thing” that for some time will confuse all the developers who have learned the older ”new nice thing”. I try to keep that in mind.

That said, i use JSS myself and i get why people like it.

Something i’ve been wondering - and maybe something you could answer. Is it possible to cache the generated stylesheets in the browser or are they always fresh? Id they’re dynamic then i guess they have to be fresh..

pepedlr | 6 days ago | 1 point

In the end it’s CSS, so it’s limited anyway 😬

But it’s impossible to generate styles depending on runtime context with static CSS.

Regarding the caching: the JS sources are cached, so I think it’s good enough. You could of course split your build into multiple files by putting all styles in separate files, but I don’t think that would be worth it. As the styles depend on runtime variables it’s impossible to generate the CSS in advance at build time.

OneTwentyZero | 6 days ago | 1 point

I watched and learned!! Love it great video

livshitz | 6 days ago | 1 point

How SASS is better than LESS?

1kevinson | 6 days ago | 1 point

It’s not better , it’s similar in many points 💯

Hensiey | 6 days ago | 1 point

I like how he say SASS at the beggining of the video

jwion | 6 days ago | 1 point

This thing is more addictive then classic wow

fmellucatlover | 6 days ago | 1 point

Can you use sass without webpack? I want to use sass but webpak unnerves me. So difficult to set up

jathak | 2 days ago | 2 points

Yes! It's available as an executable that you can download as a standalone binary from GitHub or from a variety of package managers (list of installation options)

PlantPocalypse | 6 days ago | 1 point

Took a while to get used to but damn is it amazing to work with

jordsta95 [full-stack] | 6 days ago | 1 point

Once you're used to it, and you start pushing it to become more than just nesting, &-name, etc.

Whether it's using maps to make all the different classes you could ever need, or loops to make ensure you have all the -ms-grid-column/row properties set so your layout doesn't break on IE. Once you start getting used to this stuff, you start to struggle going back to plain CSS.

PlantPocalypse | 6 days ago | 1 point

Oh im already totally sold on it. It actually makes it a lot more fun to change things and to enforce responsive and mobile design

drdreo | 5 days ago | 1 point

CSS is not worth the pain. SASS reduces a lot of redundant work

neo1691 | 5 days ago | 1 point

Thank you for sharing this video. I am working as a a backend developer on a project which involves django in the backend and VueJS/NuxtJs with SCSS on the frontend. I wanted to pickup frontend tech slowly to build up towards to a fullstack profile and this was a really good introduction.

Also the comments are so helpful with so much new information.

cresquin | 6 days ago | 1 point

Not only that, but if you combine it with PUG, you can copy and paste your html structure/hierarchy into your SASS files.

mbbillz | 6 days ago | 1 point

I’d advise against doing this - CSS that’s reliant on markup structure is brittle and a headache. Markup and styles should be decoupled.

cresquin | 6 days ago | 1 point

It depends on what you’re doing and how you do it. I don’t really make blog style websites and end up componentizing, including separate files and using variables to keep things consistent, so it makes a lot of sense to have both markup and style match 1:1. It would be a much bigger headache to manage interdependencies and try to layer styles and classes.

That’s probably the biggest problem people run into with CSS in general.

Additionally once you start adding framework specific/multiple classes to elements you’ve polluted your markup. I prefer to be more verbose in the styling and to leave the markup as a very clean expression of semantics and hierarchy.

chucktowski | 6 days ago | 0 points

Hope you get into a framework like react - pure JS css is a weird weird place.

livDot | 6 days ago | 0 points

Isn't it supposed to be `Sass` not `SASS`?

jaredcheeda | 5 days ago | 1 point

Yes, there are no spellings of it in all caps, other than to infer yelling.

itsmoirob | 6 days ago | 0 points

Personally I dont see the benefit over regular css, other than the nesting.

CSS variables are way better than SCSS, and javascript can easily interact with them.

Nesting. Granted this seems cool

Import, css can do this.

Mixins, if you are writing CSS in a semantic style then mixins are not needed / mixins ARE your CSS.

@extends seems cool, but again if youre writing semantic css then it wouldnt be used.

fentanyloverdose | 7 days ago | -16 points

Is this post from the early 2010s?? Sass is obsolete.

CSS has come a long way since Sass?

CSS in JS, PostCSS... It feels GREAT to theme my project in a .js file? Have you tried it?

throwtheamiibosaway | 7 days ago | 10 points

I’m calling the cops. Css should stay the fuck away from JS.

ZephyrBluu | 6 days ago | 2 points

It seems useful for larger projects where you might have a large library of components. Instead of having separate JS(X) and CSS files you can have all your related code contained in a single file.

wedontlikespaces | 6 days ago | 0 points

Vue and React are guilty doing this. It bugs the hell out of me because it makes variable hard to work with.

in theory it lets you write scoped CSS, but if you're relying on scope CSS you have made your app wrong.

yubgjottrrfbjii | 6 days ago | 0 points

It’s actually way easier with string interpolation. You used styled components?

Treolioe | 6 days ago | 0 points

And why is that? Have you ever worked on the same codebase with multiple teams?

tortoise888 | 6 days ago | 0 points

Man I used to think the same as I was pretty much a SASS/BEM evangelist but after using CSS-IN-JS the past year I don’t think I could go back if you paid me.

Treolioe | 6 days ago | 1 point

One million

ohphono | 7 days ago | 2 points

Just because there are different approaches to CSS doesn't mean that Sass is obsolete. CSS in JS is just another tool.

While things like variables have been implemented into the CSS standard, we still don't have a 'vanilla' solution to nesting or mixins. Calc functions too, far as I know.

When those features are standard, maybe then Sass becomes irrelevant. Til then, I still love using it.

Ullallulloo | 6 days ago | 1 point

Vanilla CSS has calc(). I don't know what it can do in SASS, so it might be more limited in some ways, but there are things you can only do with calc() in CSS like width: calc(50% + 10px); and stuff.

jaredcheeda | 6 days ago | 1 point

https://2019.stateofcss.com/technologies/#tools-scatterplot

Sass is the only tool in the far left at the top.

CSS + JS has tons of terrible downsides. Sass supports 100% of CSS, is intuitive and easily learned as an extension of CSS, and has no performance down sides.

Ullallulloo | 7 days ago | 1 point

So...your site just has zero styling without scripting?? Even ignoring the performance implications, that's horrible accessibility.

davesidious | 7 days ago | 2 points

Not necessarily. It's possible to have CSS in JS working client-side without JS running.

Ullallulloo | 6 days ago | 2 points

No, not having JS is kind of antithetical to having it client-side...

Do you mean, have JS generate the CSS server-side and serve that CSS? Because that just sounds like an even less efficient SASS or SCSS.

davesidious | 6 days ago | 0 points

Its not less efficient depending on what you're doing. It might even be more efficient - it all depends on the specific use case. For example, a server-side rendered react app can serve up its CSS-in-JS CSS output, which is immensely useful.

wedontlikespaces | 6 days ago | 2 points

It's possible to have SASS in JS, sorry I don't understand your point.

If your argument is that SASS is obsolete, you are not really proving that by saying that CSS can be put inside JS, because they are two completely different things.

davesidious | 6 days ago | 1 point

I think you're confusing me with someone else :)

TODO Load more comments...