- Importing modules with zero performance impact. - Variables! Think how they help you in other languages. $primary is much more readable than some random hex code. - Functions! darken($primary, 10%), again much more readable than hex codes. - Helps avoiding duplication through several means, like mixins, loops and so on. - Forever forgetting vendor prefixes and effortlessly keeping up to date. - Creating sprites or base64 images automatically, never having to "craft" those by hand ever again.

The list goes on and on. And the best thing, SCSS and Less are CSS backwards compatible, so you can choose whatever features you want and pretend you're writing just CSS.

I was super anti-preprocessors for pretty much the same reasons you are. But the one day I tried them out and never looked back.

Ignore gulp, grunt, webpack and whatever people tell you to use. Start super easy, with just the "compiler", and once something annoys you, look for a solution.

Also pick up the features you want. I started using only variables and ignored the rest, and added more tricks to my repertoire as needed.

I understand where you stand from, I've done quite a lot of work on support / upgrades of existing websites. I still think you may benefit from a workflow that uses a local build system... and once you use a build system, why not throw a preprocessor in?

I can give you an exemple of my workflow for simple websites using Gulp.js (I used to use grunt.js, but really, it's all the same)

I have a frontend folder structure that I carry around projects. There's a components folder and a build folder. The build folder is for minified files only.

The components folder is split between components of the website, a bundle folder and a common folder. So I have /frontend/bundles, /frontend/common and let's say, /frontend/core-navigation.

Under frontend/core-navigation, I have /styles (and scripts but let's ignore scripts for now). Under /styles, I have a main-menu.scss file. This allow me to have in there only the styles of the menu of the website. However, I don't want to burden this stylesheet with font-sizes, browser hacks, media queries definitions, etc.

That's where the /frontend/common/styles folder come into play. In this folder, I have a config.scss file. This is where the preprocessor really shines. All the reusable and common variables, styles and mixins are there.

Let's say $brand-color: #b41e3c; which is a blood red. Then, I have all the colors that starts from this color. The color for the titles of my website has to be the brand color but a bit lighter. That would be $light-title-color: adjust-hue(desaturate(lighten($brand-color, 20.58824%), .47553%), -4.28571deg);. Repeat for every color.

Then, I have my font variables, $text-font: 'pier sans', sans-serif; $light-weight: 300; $extrabold-weight: 800; $letter-spacing-normal: .05em;

I also have a bunch of mixins that are going to be used all over the website. @mixin icon-bag-white {@include scalable-icon-mixin('icon_bag.svg', 'common', $color: $white);} %hover-transition {transition: all #{$konstan-transition-hover}ms ease-out, z-index 1ms;} %form-label { display: inline-block; font-size: rem-calc(11); text-transform: uppercase; &.required em, .required { float: right; color: $brand-palette; } } etc.

My media queries are also all predefined. $xlarge-up: "#{$screen} and (min-width:#{lower-bound($xlarge-range)})"; which allow me to easily use mediaqueries this way: @media #{$xlarge-up} { /styles for xlarge-up/}

Back to frontend/core-navigation/main-menu.scss. Now that I have all those variables, I can easily style my main menu using the existing variables and styles definition that are in my config file. If I want to have a form label, I can simply @extend %form-label and I don't have to rewrite all those style definitions. I work in team with other developers, so it really help to have those definitions written only once so that we don't end up with code duplication.

All of those styles sheets are bundles under the /frontend/bundles folder. In this folder, I have multiple files filled with @import definitions. All those are bundles and using Gulp.js, I can output them wherever I want. Most of the time that's going to be under /frontend/build/stylescore.css. However, if I'm working on a CMS website, I can output the minified stylesheet in let's say, /magento/skin/styles.

I use gulp.js to minify my stylesheets, to compress my images, to generate multiple versions of my share icon for every device out there, etc.

Something really cool too is a task which write browser prefix and browser hacks for me. I simply write display: flex; and when I save the file, it's going to put display: -webkit-box; display: -webkit-flex; display: -ms-flexbox; display: flex; in the build file for me. There's one for polyfills too, so you can use rounded corners on IE7, etc.

All of my files are put under a watch task, so whenever I save a file, the workflow starts by itself. If make changes to main-menu.scss and save it, it's automatically going to minify the file and send it in the right folder. I can work as if my .scss file is a normal .css file. And the beauty of it? It's all done locally, no dependancy on a server or a backend guy. I don't need to install any php module on the server or anything. I simply throw the /build file on the production server and everything is going to work the way I want it to.

I have a similar workflow that use the same folder structure for my scripts.

That's a pretty elaborate setup.

I have my own toolbox of scripts and plugins, but they're all written in CSS, HTML, and JS. I have CSS files like http://staticresource.com/basic.css upon which I can layer other colour styles like: http://staticresource.com/template/css/themes/swiss.css

I also have plugins that I've written like http://staticresource.com/notifications.html

But this year I decided to do something crazy and put them all together in a really simple site layout: http://staticresource.com/template (source https://github.com/tomhodgins/template-factory)

In the Template Factory you can test all of the themes and the plugins, and add theme support so they work together.

For me to define a new 'brand' on top of this would just mean to author one more CSS stylesheet on top of basic.css and the various plugins used.

Still, if I've gotten this far without Less or Sass - where should I add them where it would benefit me?

I find I do end up hacking on iPad a lot, I can just write HTML, CSS, and JS and create things, then move it to a computer for further work. Here's a super simple HTML utility I made last week to help me build mailto URLS: http://staticresource.com/mailto.html It uses basic.css and the notifcations plugin, but check out the source. You could write a little HTML page like that anywhere, on any device.

For me to introduce some kind of a build process with all these different moving parts would severely restrict the situations when and where I can get work done! I'm a freelancer, I don't get paid by the hour, I get paid for the amount of value I can provide, so it's always in my be$t intere$t to break down any barrier that stops me from being able to work.

I'm able to do a surprising amount of work from mobile, despite mobile browsers lacking a lot of development features desktop browser make available. I have a little app that lets me test responsively on mobile: http://staticresource.com/speedtest.html and another that lets me view the source of any site on: http://staticresource.com/inspect/?

So for me to abandon this freedom and flexibility to only be able to work from one machine, with all these processes running and up to date sounds like a massive step back in productivity for me.

It does sound like you have a beautifully amazing system set up, but it feels full of potential points of failure that don't need to exist. If you need to update one line of text on a website, you should be able to open up a text file on any device, edit one line, and save. Having to do anything else to get something updated seems like intentionally going out of your way to create work for yourself, no?

Also, doing a lot of responsive stuff I've been turned off the idea of using pre-defined breakpoints for responsive design. Your @media (or other) queries need to respond to the elements in your layout and when you feel they need to adapt, which means those breakpoints are defined more by the design than the device. I use a solution that lets me scope responsive styles to the elements themselves, which is an even better solution for high precision responsiveness! Check out http://elementqueries.com It doesn't work so well with SASS, but here's an example of something I built with it recently: http://staticresource.com/reports.html

This design isn't responsive, it's designed to be printed 8.5x11 actually, but you'll notice in my code I have defined color variables in JavaScript and used them both in the JavaScript I send off to Google Charts, as well as in my styles. You wouldn't be able to do that with SASS/Less variables, but this is a real-world use case where I thought using variables might be better than not using them :)

I like all those tools, plugins, etc. you have going. They are great.

As for the build system that I use, I can update it via the command line and I can also install it on any machine via npm install. I do agree that with this, I couldn't work on an iPad, but I have that 11inch macbook air for that job already.

Here's the open sourced version that is the base of my workflow (this one is the one we use where I work, my own is a bit simpler but based on the same concepts). Take a look: https://github.com/absolunet/nwayo/tree/master/src

As for the breakpoints, I use the variables as a starting point (small mobile, large mobile, tablet, desktop, big desktop, etc.) but do end up using hardcoded breakpoints for small components or in betweens.

edit: Mail me if you want to chat more, contact info in profile!