Sassy!

SCSS is the primary language syntax. We do try to keep support for the original syntax. Sometimes things slip through when we forgot to test on it, but that's usually just new features. No reason to remove it, in our book. It's the same backing code.

With postCSS.

No, really, that's what I do in my build-stack.

Eventually we want that in Node-Sass as an extension, but for now... I just use autoprefixer

We also use autoprefixer. It's the right tool for the job :)

I can't think of any, but adopting CSS Modules into your tool chain if you're already using webpack and React gets most of the way there.

Oh, simple. SCSS is CSS compatible. So, if you are at a company, you can add Sass to your build-chain and coworkers who don't want to use it... don't have to!

Also, all of your old code works (as long as it was valid!)

Adoption was slower when you had to 'learn a new syntax'. SCSS made Sass just... CSS++

I use SCSS syntax now (it's the default), but I do really miss the +myMixin syntax.

Check out the reply to another question

There's never a one right answer. It depends on your team, your constraints, and your tools. I personally love BEM.

A couple years we broke up our monolithic Sass framework into individual components backed of Bower. The design process for how we make those many components fit together easily, and maintain painless theming was fun!

There's no one right way. Do what works for you and your team. Most of my dat to day is still stand-alone compiled CSS and JSX files. On newer projects I like using CSS Modules to import my Sass into React.

This is a great overview https://www.youtube.com/watch?v=aIyhhHTmsXE

CSS fucking sucks ¯\(ツ)/¯

Check out my response to a similar question.

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.

I think it's fine. Sass is a fairly thin abstraction over CSS so when you're writing Sass you are writing CSS.

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'm a command line junkie. I use git for source control, Vim for text editing and Twitter when I'm compiling.

Most of my day to day front-end work is React. Webpack, Chrome devtools, Google, and console.log are my most valuable tools :)

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 think @apply and :matches selector will be interesting.

Okay, well, I immediately know one. @extends in the browser. Right now, we have to do all sorts of gross-dark-magic things to make @extends work in Sass. It's complex and it mostly-works... but it's complex because we don't know the DOM. If we knew the HTML, we could be super efficient about it.

Something with the functionality of @extends would be trivial in the browser, and then we wouldn't have to do it. We only built it because there were so many good use-cases that it overrode our concerns about complexity and maintainability.

Another thing I really want is a good CSS-JS bridge.

Oh, and I'd love it if nesting was supported. We could still compress our output, but we wouldn't have to repeat selectors over and over in our output!

I'll plug my Sass framework Eyeglass here. It allows you to distribute Sass files and related assets as npm modules. At my work we use this to distribute re-usable parts of our style like our theming system to many applications.

Lots of people like to have a variables file and mixins and partials directories. I'm really not a fan of this approach. Keep related code together and minimize bouncing around from file to file.

To that end, within an application, I suggest organization by product and feature with cross cutting theme or design language shared by all of those.

Follow-up: might there be room for a kind of Sass intermediary that could be manipulated at runtime?

Well, there are two ways to do this. First, there are adding hooks that would allow server-side or compile-time Javascript to hook in. We already have a large number of these implemented in Node-Sass, however, (Michael can correct me if I'm wrong) we still haven't exposed our whole tree in Javascript objects yet for wholesale manipulation. I know we've talked about it, and I know some work has been done on it. Something we definitely would love to support in Node-Sass.

The second way is integrating with browser JS. This is something that Tab Atkins has been working on.. and in fact, functions like calc() and variables are the first steps in integrating JS and CSS in the browser. This is something I'm personally really excited about. Would allow for some really interesting future developments (alternate layout methods!)

Honestly, not a ton. I mean, variables are an obvious example. And tons of things that were proposals, but if you look at how CSS is actually expanding as a language, it's generally not expanding as a "language", which has always been Sass' focus. CSS is expanding it's features with new selectors, new attributes, and new ways to integrate with browser-based JS.

We always hope and work with the W3C to help push Sass-like features that should be in the browser. For instance, we <3 Tab Atkin's CSS variables, not because they 'replace' pre-browser rendering, but because they allow users to work with browser-only constructs like 'em' units, etc. Something we just simply can't do until the font is chosen in the actual user's browser.

Fantastic question!

Hell yes this is going to be a thing (sort of). In fact, things like calc() and CSS variables and browser-based-units (em, etc) are already doing this kind of thing.

I don't think the right mental model is 're-processed' though. I think the right way to think of it is the Javascript execution environment will be deeply intwined and communicating with the current styles and styling rules. Right now, there is communication mostly moderated by the DOM. CSS => DOM <=> JS... I think the new model will include a full two-way conversation between CSS and JS, including manipulation and response.

For instance, wouldn't it be cool to implement a JS-based constraint system? Imagine if you could say body { display: constraint-based; } and it would trigger whole new CSS properties and layout behaviours!

To me, it's definitely Sasstronaut.

We even have bands that say it! twitter.com/MinaMarkham/status/584363699298668546

I've always liked "Sass Assassin". But honestly, I don't care... just don't be a Sasshole.

With node-sass it's just as easy to get started with Sass now as is it with Less.

I only have one problem with Less, and it's the way they use classes-as-mixins. It just makes me uncomfortable somehow.

But, that's personal preference. Honestly, they are pretty similar, but Sass is a little more standard, plus I invented it, so obviously I have to say that. :)

Personally I'm fan. Co-location of styles and components is a really great experience, but they don't necessarily exclude using Sass. Using Sass with CSS Modules is 👌

Yeah, before this AMA, I was coding in my StoreSelector.scss file in a React app. I love styling components individually. Especially I like organizing my SCSS with my JS into Atomic Design elements. :)

Honestly, I challenged myself to use plain CSS in that build platform, and it just started to get really freaking annoying to do BEM. Not having nesting and some basics was :thumbsdown:

Unfortunately, backwards compatibility and the need for very fast parsing on the client has forced the official specs to resort to syntax that is less than ideal. I do think there will be a time in the next few years where people can reasonably get by without Sass, but it's our plan to provide better ergonomics to the upcoming CSS features and compile to more optimal output that CSS provides.

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.