Explain Sass Like I'm Five

I'm more familiar with Less but they're both CSS preprocessors, the idea being you write almost-but-not-quite-CSS with tidy nested hierarchies and so forth, which they transform into actual browser-compatible CSS for inclusion into your website.

The setup isn't too bad but it's a little strange if you're used to saving a file and seeing the results immediately on refresh. The bare minimum:

1. Write your Sass file.
2. Create a public/styles directory structure in your project.
3. sass path/to/something.sass public/styles/something.css
4. In your html files, change your <link rel='stylesheet' href='...' /> declarations to point to the compiled output in public/styles.
5. If you change your Sass file, run step 3 again.

Once you've got that down you can automate step 3 using anything from make to npm, handle multiple source files (Less version: mkdir -p public/styles && find assets/styles -name *.less -exec lessc {} \\; > public/styles/site.css), and use something like nodemon or chokidar to watch files for changes and rebuild without manual intervention.

I think the explanation below/above is great. However, one wrinkle to keep in mind is this. Sass started out as its own language for implementing styles. That is to say, it was not based on the CSS syntax and was read/written very differently.

When version 3 of Sass came along it was still called Sass but it became SCSS, with the corresponding .scss file extension. This version of Sass IS based on the CSS syntax and any valid CSS is also valid SCSS.

There are still people who prefer the old syntax and use that. So both exist in projects in the wild. If you're interested in learning more this is a good primer: thesassway.com/editorial/sass-vs-s....