It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
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:
Write your Sass file.
Create a public/styles directory structure in your project.
In your html files, change your <link rel='stylesheet' href='...' /> declarations to point to the compiled output in public/styles.
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.
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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:
public/stylesdirectory structure in your project.sass path/to/something.sass public/styles/something.css<link rel='stylesheet' href='...' />declarations to point to the compiled output inpublic/styles.Once you've got that down you can automate step 3 using anything from
maketonpm, 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
scriptsin package.json and maybe a directory of Bash scripts to keep it manageable.