AMA with

Sass Team

CSS with superpowers

Hosted by

Hampton Catlin's photoMichael Mifsud's photoChris Eppstein's photo

22nd March 2017, 6:00 pm

This AMA is over!

Thank the host

Message from the host 馃挰

Looks like we answered all the questions on here!

If you have other questions, we aren't a hidden team! We're all over that new Twitter-thing. Thanks for tuning in to our AMA and hopefully we provided some laughs, some tears, and maybe... just maybe... a little love.

/queue Dionne Warwick

Do you see CSS4 as the end of CSS preprocessors?

No. First of all, there's no such thing as CSS4, new CSS modules will roll out as needed. CSS Preprocessors allow us to do optimizations before we transmit over the wire. For example, asset inlining and concatenation, calculation precomputation. I hope that some day we have CSS that is as expressive as Sass is now, but the need to do preprocessing for efficiency once instead of on every client will never go away.

The way I think of it, Sass is only as powerful and CSS allows it to be. As CSS get more features and extensibility, Sass can leverage that to be a better abstraction.

We see this happening in JavaScript where ES2015 and better DOM APIs have seen the rise of paradigms like React.

If you look at the progression of the CSS specs, they honestly aren't focusing on increasing the complexity of the language and it's syntax. What they are instead focused on is what you can do with the selectors and properties you have. Think, Flexbox and all the lovely features we've been getting.

Further, there are things that just don't make sense for the browser to ever implement.... Sass (and other processors) do a lot of bundling, merging, splitting, importing, etc. Things that just simply make sense on the server side.

No matter how powerful the low-level OS language Assembly gets, your probably going to prefer to use a language one step up, so you can compile and optimize and handle all sorts of nice things we get from higher-level languages. CSS is the core of what's possible, and Sass is trying to make it powerful and easy from a coders perspective.

What's your opinion on Styled Components and "CSS in JS" techniques in general?

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:

Are there any major benefits of using Sass over Less ?

A better question is there any benefit of using Less over Sass. As I see it, there's very little. The main reason used to be in-browser implementation, but the upcoming release of Dart Sass will enable that. I honestly don't see any reason to use Less anymore, unless you like the syntax better but it's purely an aesthetic choice at this point. Sass has a bigger community, more robust implementations, and is faster with libSass.

What advices would you give to developers learning Sass for the first time?

Great question!

Sass is often times one of the first languages people learn. One of the great parts, is that if you only know CSS and HTML, you can just start using Sass just like you used CSS, and you can slowly add in features as you learn them. Nesting is usually the first thing people refactor their CSS to do, but there are lots of other features to familiarize yourself with.

If you are familiar with other languages, then there are only a couple unique concepts that you need to learn. Most everything else is pretty freaking boring (in the good way!).

There are a lot of great resources out there for getting started with Sass like

My suggestion is to not over use Sass. Instead focus on writing good CSS and incrementally adopt Sass features a bit at a time as they make your life easier.

With native variables coming in, a nesting spec in candidate recommendation and other interesting features pouring into CSS, Do you think there will be a time when Sass will no longer be needed?

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.

I don't know... maybe!

But, not everything is appropriate to do in the browser. I'd be surprised if we ran out of language-and-syntax improvements that wouldn't be worth the compile time while devving.

What is the correct term to refer to a developer who uses Sass:

  • Sasstronaut
  • SCSSling
  • 鈥ther?

To me, it's definitely Sasstronaut.

We even have bands that say it!

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

Whet is next on the Sass Roadmap? Are you looking to enhance performance on the framework - or implement any new features to help make the Saas experience better?

I can't speak to new features, but LibSass and Dart Sass have addressed the performance of Sass - they're fast!

What new features/updates can we look forward to in the future?

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.

Are there any major benefits of using Sass over postCSS?

Honestly, we have no beef with the postCSS team, but if you checkout their marketing, they definitely aren't fans of ours!

postCSS is great for prefixing and other last-second optimizations... in fact, I use it with Sass in most of my projects. They can do some stuff we just can't (or don't think we should) do magically with an actual language like Sass.

And yeah, you can use postCSS with enough addons and magical features to make it pretty much look and act like Sass, but the downside is that you've built an entirely non-standard sub-language yourself.

One thing that we really pride ourselves on in the Sass-team is that we really think through every single language feature we add. Natalie, the lead designer of the language, is extremely picky about what goes in. We consider all angles of how a feature would affect our user base now, and with respect to what the W3C is planning in the future. It's a lot more complex than you'd think!

So, I use Sass still, because I want some more powerful language features but I also want to make sure that the next maintainer of the project will have a standard understanding of the code. And, I know how strict we are with ensuring that we do right by our users with stability and predictability.

The big thing that keeps bringing me back to Sass is that it's batteries included. When a codebase is using Sass I immediately know which features are available to me. With postCSS offloading it's features to plugins, I need to know which plugins are being used in a project.

Additionally in a plugin based world there are ongoing costs like handling plugin upgrades, and dealing with plugins that get abandoned.

Batteries included solutions like Sass let me focus on my code.

How are the module features coming along?

The module features got very delayed as Sass has moved away from Ruby first to enable the libSass port and then as the reference implementation is moving to Dart. The initial design phase is complete. It's heavily inspired by Dart's module system in terms of how things are imported and exported from modules.

You'll be able to do things like import a CSS file as a mixin and include it where you want it in the current stylesheet.

A main goal of the module system is to avoid namespace collisions. Sass's global namespace has long forced Sass libraries to do namespacing on their own which was annoying and error prone.

Another big benefit of Sass modules is that they form a scope for the @extend operation -- this means that you won't have to worry about @extend .last accidently bleeding into a part of your website that you didn't intend.

Should browsers support .scss in future, by-default? Will that be a good option?

No. Sass was designed to be compiled to CSS. It has proven the demand for more powerful syntax and abstractions, but the right thing to do for CSS is to design new language features that can take full advantage of the runtime nature of CSS and the document in scope. A prime example of this is CSS custom properties (CSS Variables) which inherit down the document -- a capability that Sass could never have implemented as a preprocessor and wasn't ever considered when we were designing it.

What difficulties did you face when producing the Saas framework? Also what are your thoughts on CSS preprocessors? Thanks.

That first question is pretty tough to answer. Honestly, one of the hardest things to do in an OSS project is keep your effort up and make sure everyone is getting along. It's working for free, in public, with your personal time. There are great benefits, knowing you are helping the world, but the sheer amount of continuous effort is staggering. I mean, Natalie has been coding pretty consistently on the project for EIGHT years now. I only coded a little in the beginning, but she's just kept it up. Maybe taking 6 months here and there to focus on herself. I think Chris has been doing it for 7 years too!

Burn out is all to easy.

Now, the second question... that's easier to answer. I think they're fine. I use autoprefixer in most of my projects. It's cool.

But, I don't use it for hand-constructing a kind of one-off language with a lot of transformers. The fact that Sass is a stable language to build off of is something I think that's a Good Thing(TM).

Also, I do like the idea they have of exposing the tree for manipulation. That's something we've been looking at in the LibSass/Node-Sass project for a while and postCSS is a great example of why that kind of thing is powerful.

This is a general question for all three of you! :)

What dev tools do you use daily?

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 :)

Languages: Java 8, ES6, Ruby, SQL.

IDEs: Jetbrains based IDE's... specifically Webstorm and IntelliJ

Frameworks: Create-React, Dropwizard, Rails.

What are some of your tips for organizing huge CSS projects?

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.

My team also uses Eyeglass. We distribute all our components as npm packages. Each component has a first class mixin API, and a settings map.

A lot of the newer features people are experimenting with in CSS are client-side only, and can't be compiled, predicted, or rendered in advance. Do you foresee the need (or popularity) of client-side re-processors in addition to preprocessors? What new features could client-side re-processed Sass include that aren't possible to support in its current form as a preprocessor today?

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!

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.

As you mentioned "Sass is only as powerful and CSS allows it to be"..

What are the top 3 CSS features is in your wishlist that Sass can leverage?

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!

Except Sass, which CSS preprocessor would you recommend?

If you like.... .....a lot more features use Stylus .....building your own bespoke language use postCSS .....javascript-purity use Less

Each have their own strengths, but there is a reason why Sass has only gained in usage over time. In fact, while we're the first CSS processor, we were for quiet a while not the most popular. But, over time, we've just kind of stuck to our slow, methodical improvement cycles and positioning... ending up being a kind of de-facto standard. And, that's due to Natalie and Chris' amazing stewardship of the language, plus the awesome LibSass/Node-Sass team (Michael and company), plus the awesome community organizers we have.

But, hell, there's no ego in web development. If one of those solutions works better, then party on Wayne.

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.

For traditional preprocessors I couldn't imagine using anything other than Sass.

Things like Styled Components are really great too.

How might Sass evolve to support deeper integration with JavaScript-oriented front end toolkits?

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!)

Thank you, Hampton! I put calc() and variables together based on your earlier answer, and I'm curious to run some experiments with that approach in the future.

What inspired you to create the Saas framework?

CSS fucking sucks 炉\(銉)/炉

Name one word to describe your framework.

What's your opinion on beginners learning CSS preprocessors without learning CSS properly? Do you think it'll help them?

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.

As a beginner which one is better to learn Sass or Less?

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. :)

Which is the recommended way to use Sass with React? Should I merge my Sass code with the .js code, or should I put my Sass code apart from the .js code? Do you guys know a tutorial, article or something about this? Hampton, please, show me some light about this, you are using React in Rent the Runway, right?

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

The official "Create-React" app puts a twin CSS file next to the JS file. That's what I do.

Store.js and Store.scss sit next to each other. And in Store.scss I wrap everything in .Store which is the class of the React Component.

How did you get the idea to develop Sass?

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 was working with two really great CSS developers back in 2006-ish when I worked at a company called Unspace in Toronto, Canada (no, I'm not Canadian). They were both brilliant and the tooling they had was shit. They would hand code ONE GIANT CSS file for our projects, and they would scope their selectors by hand-typing over, and over again the root selector... it would look like this:

.parent .child a { ...... }
.parent .child a:hover { ...... }
.parent .child .under { ...... }

They'd have hundreds of these. And, my god... if we had to change a color, it was find-and-replace-hell.

Anyhow, I went to Rails Conf 2007. At the time Natalie was just graduating high-school and living in Seattle and she had basically taken over development of Haml at this time. So, we asked her mom if we could fly her to Portland to hang out with the Unspace team and attend her first conference. And, amazingly, after some awkward parent-adult phone calls, she was allowed to come.

While there, I had been drawing up some plans for what Sass could be ('Sasstastic' was the original name). That was the original syntax that was inspired primarily by Haml. I remember between some talks, I found a side conference room, and I pitched Natalie and Jeff Hardy (now at Basecamp) about my ideas.

I think at first Natalie was pretty skeptical, but by the time she was flying home, she had taken my original testing commit and was starting to build out the Ruby Sass engine.

Originally, that interpreter was a sub-folder in the Haml project! In fact, I think it lived as part of Haml for a long time.

A couple weeks later, we released a version of Haml (would have to google to know which one) that included the first version of Sass. Whitespace sensitive. Nestied. Simple variables. I think mixins were there too.

It took us until after Less was released to actually break Sass out into it's own project.

Looking back at the history of CSS & Sass, is there a list of new CSS features that you attribute to direct influence from Sass? For example, jQuery is credited with bringing things like document.querySelector() to JavaScript, after years of Sass how has it shaped CSS as a language?

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.

Sass has inspired CSS Custom properties, the calc() function. There's a CSS @apply directive coming which is a barebones @include without mixin arguments. CSS will soon allow nesting. The ability to nest @media and @supports etc came first from Sass. The new CSS color module is inspired by Sass's color functions.

The CSS working group watches what we do here and reacts. That we're able to prove demand with Sass really greases the wheels in those discussions. For many years, the working group held that concepts like variables were just too complicated for CSS developers -- Sass showed them it wasn't. :eyeroll:

Will CSS go SASS only? Meaning that browsers will supports SASS?

What's about the two language modes .scss and .sass. It feels to me that the former one is far more supported and widely used in contrast to the latter one. What are your thoughts about it and how do you handle current feature releases for both modes?

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.

What was the most interesting scssy code refactoring you've ever done in a project? Could be just the concept not the actual code. (although that would be awesome!)

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!

What is the difference between SaSS and CSS?

Sass' SCSS syntax is largely a superset of CSS so the difference is whatever you want it to be. Variables? Mixins? Functions? Maps? Pick whichever feature makes your life easier.

Are there some weird bugs in the Twitter Bootstrap Sass project? I'm getting this horizontal scrolling bar only during specific widths. The row class is causing it. It's unusual.

That's a great question for the Bootstrap team. You can file a bug against them here:

Sass is so good that I can't stop myself from using nesting feature. What level of nesting is good according to you?

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.

What future awaits Sass regarding features? Anything new planned to come and make our web dev lives easier?

Check out my response to a similar question.

When React Native comes, will sass/less die?

Hmmm... I'm not really sure what you mean. React Native is already out. I've been playing with it.

I'm not sure how it's related to Sass and/or it's death.

Why SCSS? Just to make the Sass syntax easy or was there some other reason behind it?

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.

I can't speak as to why, but I can say that I would never have used Sass if it weren't for the SCSS syntax. It greatly eased the transition of the 1000s of lines of CSS we had.

Sass is so close to CSS that a new syntax, wildly different syntax, is a cognitive burden.

Are there any projects out there that use Atomic design principles with Sass, webpack, vue/React/any component structure that you'd refer someone to if asked how to implement a maintainable large scale application in a team environment?

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.

I have one at Rent The Runway... but it's not open source. :)

How do you autoprefix in Sass?

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 :)

What CSS naming convention would you suggest for the most optimal use of Sass?

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