Sassy!

I like zero amounts of nesting for large projects. But some aspects of state are best managed at the document or module level so for those, I allow 1 level of nesting. This is a great article on this subject .

Check out my response to a similar question .

CSS fucking sucks ¯\ (ツ) /¯

A front-end developer told Hampton "Wouldn't it be neat if CSS was like Haml?" and they were wrong but Hampton did it anyway. A couple years later, I found mixins were a great way to create very bloated CSS and so I worked with Natalie to make them more powerful and built a framework based on it. Over time, we discovered the actual good use cases for the tool we had made :)

I'm a command line junkie. I use git for source control, Vim for text editing and Twitter when I'm compiling.

I do think it helps, but I know there's a vibrant discussion within the community on this. In my opinion, it's easy to get stuck in the weeds and lose your momentum when you're first learning CSS. With Sass you can find your stride sooner even if you don't fully grok what's going on under the covers. And then, over time, you can read various mixin definitions and see how they work. I think it's good scaffolding for learning but it really depends on if you're a project based learner or a first-principles based learner.

I use several postcss plugins along side Sass in development: autoprefixer , rtlcss , postcss lang optimizer . The ability to work directly with the AST in postcss is very powerful for a certain class of CSS processing -- especially those cases where you rarely, if ever, want to opt-out of the change.

CSS optimization is very hard to do outside of the context of a document -- but it's not clear how it would work client side as dynamic changes occur. Like a JIT, you'd need to know when you've violated your optimization assumptions and deoptimize. In general, I see atomic css as being very fast for browsers to match against, but lacking the ergonomics I crave. I'd like to see tooling bridge this gap, but my sense is that it has to be done at build time with template awareness/rewriting and requiring hints for dynamic changes.

Sass modules are the big feature of Sass language version 4. I wrote about them in this question Once we have a module system, we intend to greatly expand on the Sass standard library. In the near future you can look forward to being able to invoke a mixin whose name is stored in a SassScript variable.