re: Explain Sass Like I'm Five VIEW POST

VIEW FULL DISCUSSION
 

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.

 

Thanks! It's the automation process with Gulp that had me confused the most before.

 

I've built some fairly complex workflows with Grunt and Gulp in the past but at this point I think the only compelling reason to go back would be if you absolutely have to build on Windows as well as *nix. Otherwise they don't bring anything you don't already have with scripts in package.json and maybe a directory of Bash scripts to keep it manageable.

code of conduct - report abuse