Dart Sass 1.15, released today and available on npm and all other distribution channels, brings with it a number of highly-anticipated new Sass features. This is also the first release of Dart Sass with major new language features that aren't just for CSS compatibility. That's a big accomplishment, and we intend to continue that pattern moving forward!

@content Arguments

Mixins that take @content blocks can now pass arguments to those blocks. This is written @content(<arguments...>). If a mixin passes arguments to its content block, users of that mixin must accept those arguments by writing @include <name> using (<arguments...>). The argument list for a content block works just like a mixin's argument list, and the arguments passed to it by @content work just like passing arguments to a mixin.

// style.scss
@mixin media($types...) {
  @each $type in $types {
    @media #{$type} {
      @content($type);
    }
  }
}

@include media(screen, print) using ($type) {
  h1 {
    font-size: 40px;
    @if $type == print {
      font-family: Calluna;
    }
  }
}

/* style.css */
@media screen {
  h1 {
    font-size: 40px;
  }
}
@media print {
  h1 {
    font-size: 40px;
    font-family: Calluna;
  }
}

For more details, see the feature proposal. This feature isn't yet implemented in LibSass. Since Ruby Sass is deprecated and this isn't a CSS compatibility feature, it won't be implemented in Ruby Sass.

Color Level 4 Syntax for rgb() and hsl()

The CSS Color Module Level 4 has introduced new syntax for the rgb() and hsl() functions, which has begun to be supported in browsers. This syntax makes these functions more compact, allows the alpha value to be specified without needing additional rgba() and hsla() functions, and it looks like rgb(0 255 0 / 0.5) and hsla(0 100% 50%).

To support this function, Sass's rgb() and hsl() functions now accept a space-separated list of components as a single argument. If this last argument is a slash-separated pair of numbers, the first number will be treated as the blue channel or lightness (respectively) and the second as the alpha channel.

Be aware though that the normal rules for disambiguating between division and / as a separator still apply! So if you want to pass a variable for the alpha value, you'll need to use the old rgba() syntax. We're considering possible long-term solutions for this problem as / is used more prominently as a separator in CSS.

In addition, the new color spec defines the rgba() and hsla() functions as pure aliases for rgb() and hsl(), and adds support for the four-argument rgba() and hsla() syntax to rgb() and hsl() as well. To match this behavior, Sass is also defining rgba() and hsla() as aliases and adding support for all their definitions to rgb() and hsl().

All in all, this means that the function calls like all of the following are newly supported in Sass:

• rgb(0 255 0), rgb(0% 100% 0%), rgb(0 255 0 / 0.5), and rgb(0, 255, 0, 0.5);
• hsl(0 100% 50%), hsl(0 100% 50% / 0.5), and hsl(0, 100%, 50%, 0.5);
• rgba(0, 255, 0) and hsla(0, 100%, 50%);
• and rgb($color, 0.5).

This change is fully backwards-compatible, so all the arguments to rgb(), hsl(), rgba(), and hsla() that previously worked will continue to do so.

For more details, see the feature proposal. This feature isn't yet implemented in LibSass or Ruby Sass.

Interpolated At-Rule Names

This feature is a little smaller than the last two, but it's been on the to-do list for even longer: adding support for interpolation in the names of at-rules! This works just how you'd expect:

@mixin viewport($prefixes) {
  @each $prefix in $prefixes {
    @-#{$prefix}-viewport {
      @content;
    }
  }
  @viewport {
    @content;
  }
}

For more details, see the feature proposal. This feature isn't yet implemented in LibSass. Since Ruby Sass is deprecated and this isn't a CSS compatibility feature, it won't be implemented in Ruby Sass.

Dart Sass 1.11 has just been released, and with it a handful of new features. This is an exciting moment, because it marks the first major new feature that's been added to the language since Dart Sass was launched. It's also the first release with features that have gone through the new process, from proposal to tests to implementation.

CSS Imports

The biggest feature in Dart Sass 1.11 is support for importing plain CSS files. This is a long-awaited feature, and while we'd initially planned on waiting on it until we launched the upcoming module system, we ended up deciding to implement it earlier.

You can now import a CSS file, say styles.css, just by writing @import "styles". That file will be parsed as plain CSS, which means that any Sass features like variables or mixins or interpolation will be disallowed. The CSS it defines will become part of your stylesheet, and can be @extended just like any other styles.

There are a couple caveats: because SCSS is a superset of plain CSS, it will still compile @import "styles.css" (with an explicit extension) to a CSS @import rule. If you want to import a CSS file into your Sass compilation, you must omit the extension.https://github.com/sass/libsass/issues/2699

Also, this feature isn't fully implemented in LibSass yet. It still has its old behavior, where it imports CSS files but parses them as SCSS, with all the extra Sass features allowed. This behavior will be deprecated soon, and eventually it will produce errors for anything other than plain CSS, just like Dart Sass does today.

CSS min() and max()

Dart Sass 1.11 also adds support for CSS's min() and max() mathematical functions. For those unfamiliar, these functions work a lot like calc(), except they return the minimum or maximum of a series of values. For example, you can write width: max(50%, 100px) to make your element either 50% of the parent's width or 100px wide, whichever is greater.

Because Sass has its own functions named min() and max(), it was difficult to use these CSS functions... until now. Dart Sass 1.11 will intelligently decide whether to use the plain CSS functions or the built-in Sass functions based on whether or not you're passing in dynamic Sass values. For example:

• The Sass function will be called if you pass a variable, like max($width, 100px).
• The Sass function will be called if you call another Sass function, like max(compute-width(), 100px).
• It will compile to a plain CSS function if you just use plain CSS numbers, like max(50% + 10px, 100px).
• It will still compile to a plain CSS function even if you use interpolation, like max(50% + #{$width / 2}, #{$width}).

This preserves backwards-compatibility with existing uses of the Sass functions, while also users to use the CSS functions the same way they would in plain CSS.

This feature isn't yet implemented in LibSass or Ruby Sass.

Range-Format Media Queries

CSS Media Queries Level 4 defines a range syntax for defining certain media queries:

@media (width > 500px) {
  /* ... */
}

Dart Sass 1.11 adds support for this syntax. It works just like existing media query support: you can either use interpolation or plain Sass expressions to inject Sass logic into the query, and they can still be nested.

@media (width > $width) {
  @media (height < #{$height}) {
    /* ... */
  }
}

This feature isn't yet implemented in LibSass or Ruby Sass.

Normalized Identifier Escapes

The last compatibility improvement is a bit of an edge case, but it's still worth mentioning: the way Sass parses escapes in identifiers has been improved to better match the CSS spec.

Escapes are now normalized to a standard format, which means that (for example) éclair and \E9clair are parsed to the same value (in this case, éclair). Prior to this change, if an escape was written, it would always be preserved as-is, so str-length(\E9clair) would return 8 even though that identifier means exactly the same thing to CSS as éclair.

We don't anticipate this affecting many users, but we always strive to bring Sass as close to the semantics of CSS as possible. This is a small but important step on that path.

This feature isn't yet implemented in LibSass or Ruby Sass.

As Dart Sass catches up with Ruby Sass in terms of usability, we're starting work on adding new features to the language. The first feature we're looking at is one that's long been requested by users: adding support for importing plain CSS files without having to rename them to .scss. Not only do we expect this to be very useful, it's already partially implemented in LibSass, so this will help bring the implementations more in line with one another.

We're also trying out a new process with this feature. In order to help keep the behavior of different implementations in sync, we're starting with a prose specification of the feature before moving on to writing code. We're also taking this as an opportunity to solicit feedback from you, the Sass community! We want to hear your thoughts on the new feature while we have a chance to revise it based on that feedback.

Background

Historically, the reference implementations of Sass—first Ruby Sass, then Dart Sass—only supported importing other Sass files. However, LibSass supported importing CSS files as well, interpreting them as though they were SCSS. Although this technically violated the implementation guide's prohibition on unilaterally extending the language, these CSS imports were useful and were widely adopted in the Node.js community.

This became particularly clear when, at the language team's urging, LibSass added deprecation warnings for CSS imports and users were left without a suitable replacement. The language team came together to discuss the problem, and decided to move towards allowing CSS imports but forbidding the use of non-CSS features in the imported files. The proposal describes the specifics of that idea.

LibSass's behavior at time of writing is to import files with the extension .css at the same precedence level as those with the .scss and .sass extensions, and to throw an error if an import is ambiguous between a .css file and a .scss or .sass file.

Summary

The proposal seeks to strike a balance between preserving compatibility with LibSass's existing behavior and moving towards a more principled scheme for loading CSS. This is particularly important as we intend to allow @use to load CSS files without Sass features, so we want the existing CSS loading support to be as similar as possible.

Locating CSS files for import works similarly under the proposal as it does in LibSass currently: a relative .css file takes precedence over files with any extension on the load path, a .css file earlier on the load path takes precedence over a file with any extension later on the load path, and foo.css takes precedence over index/foo.scss.

The only difference in loading scheme occurs when an import is ambiguous between a .css file and a .scss or .sass file at the same path. LibSass currently produces an error here, but in order to maximize compatibility with existing Dart Sass (and Ruby Sass) behavior, the proposal has the .scss or .sass file taking precedence. This is not a breaking change to LibSass's behavior, since it only applies in situations that would previously have produced an error.

The proposal diverges significantly from LibSass in parsing the imported CSS files, though: it forbids all use of SCSS features in the parsed files. Most SCSS features produce errors (rather than compiling to plain, likely-invalid CSS) in order to help users who accidentally wrote SCSS in their CSS realize what's going wrong. However, features like @import that overlap with plain CSS continue to be rendered as CSS.

In order to avoid a sudden backwards-incompatible change in LibSass, this also includes a proposal for a set of deprecation warnings that can be added to LibSass's existing behavior to steer users away from using Sass features in their imported CSS without entirely breaking their build process.

Giving Feedback

If you want more details on exactly how the proposed behavior will work, head over to the sass/language repo and read the full proposal. You can skip the Background and Summary sections, since they're included above. Be aware, though, that it's written to be a specification; it's a great for figuring out how exactly an edge case should work, but it's not as conversational as the sections quoted above.

If you have any issues with the proposal as written, or if it doesn't cover a use-case that's important to you, please bring that up in the sass/language issue tracker. We'll be leaving it open for discussion for at least two weeks before we mark the proposal as "accepted" and move on to the implementation phase.

Please be aware, though, that while we welcome community feedback, the design of Sass is ultimately in the hands of the language team. We'll absolutely consider the perspectives and use-cases of users who speak up, but it's also our job to consider all the users who are new to Sass or even to CSS and who don't yet know to read blogs or comment on issue trackers. Remember that our careful decision-making made Sass what it is today, and have patience with us if we don't make the decisions you would have!

With the release of Dart Sass 1.0.0 stable last week, Ruby Sass was officially deprecated. I'll continue to maintain it over the next year, but when 26 March 2019 rolls around it will reach its official end-of-life. I encourage all users to start migrating away sooner rather than later.

The Deprecation Period

Over the next year, I'll continue to work on Ruby Sass in a limited capacity. I'll triage and fix any bugs that are reported, unless they're minor or obscure enough to be unlikely to pose a practical problem over the next year. I'll also add support for any new CSS features that require changes to the Sass parser or other parts of the language.

I won't be working on language features that aren't necessary for CSS support, though. The latest and greatest features will be appearing exclusively in Dart Sass and LibSass from here on out.

I also won't be accepting pull requests for new Ruby Sass features. While pull requests are a great way to contribute to projects, they still take work on my part to merge in, and it just doesn't make sense to spend time on that work when the project is being turned down. If you're interested in contributing to Sass, I highly recommend contributing to Dart Sass—Dart is an extremely easy language to learn!

We're also be migrating the Ruby Sass repository to https://github.com/sass/ruby-sass, so be sure to update your Git URLs. The old repository URL will continue to work during the deprecation period, but it will be frozen; all ongoing maintenance will happen at the new URL. Once the deprecation period is over, the Git history for the old URL will be wiped and replaced with feature specifications. See this issue for the full plan.

Migrating Away

We want to make it as easy as possible to migrate from Ruby Sass onto an actively-maintained implementation. The best way to do that depends on how you use Ruby Sass today.

If you use Ruby Sass as a command-line tool, the easiest way to migrate is to install Dart Sass as a command-line tool. It supports a similar interface to Ruby Sass, although it currently doesn't support the --watch or --update flags—adding them is high priority, though!

If you use Ruby Sass as a plugin for a Ruby web app, particularly if you define your own Sass functions in Ruby, the sassc gem provides access to LibSass from Ruby with a very similar API to Ruby Sass. In most cases, you can just replace the Sass module with the SassC module and your code will continue to work.

If you're using Rails, I particularly recommend using the sassc-rails gem, which wraps up the sassc gem and integrates it smoothly into the asset pipeline. Most of the time you won't even need to change any of your code.

We're also planning to add support to Dart Sass for embedding it in Ruby (and other programming languages). This will allow Ruby users to get the latest and greatest features as soon as they're implemented.

End of Life

On 26 March 2019, the deprecation period for Ruby Sass will end and it will no longer be maintained. The new sass/ruby-sass repository will be archived, which means no changes will be made and no new issues or pull requests will be accepted. The old sass/sass repository will have its Git history replaced with feature specifications that have historically just been scattered around issue comments.

Leading up to the end of life, we'll be migrating the user-focused reference documentation from the Ruby Sass repository to the Sass website. We could use some help doing the migration and touching up the documentation, so if you're interested please chime in on the tracking issue!

Unless...

We're turning down support for Ruby Sass because the Sass team just doesn't have the bandwidth to maintain it along with the other major implementations. But there could be another solution. If someone from the community is willing to step up and take on the mantle of maintainer, we'd be more than happy to show them the ropes and help them keep Ruby Sass going.

Maintaining a language implementation isn't necessarily easy. It requires keeping up with features as they're added to Dart Sass, as well as fixing bugs and fielding pull requests. But it's also a great opportunity to work on a big project with a lot of impact, and I'm happy to help get a new maintainer up to speed. If you're interested, please email me and Chris and we'll talk about how to get started.

I've just uploaded Dart Sass 1.0.0, the very first stable release, to GitHub, npm, Chocolatey, Homebrew, and pub. After working on it for almost two years, I'm thrilled to have a stable release out there and officially ready to use in real-world applications. All the reasons we chose Dart as the implementation language are bearing fruit: Dart Sass is much faster than Ruby Sass, much easier to make available across operating systems and language environments, and much more maintainable.

The 1.0.0 stable release indicates that Dart Sass is fully compatible with the Sass language as defined by the sass-spec test suite, and that its npm package is compatible with the Node Sass API, with the exception of source map support which is coming soon.

I've also updated sass-lang.com to cover Dart Sass. The release bar now shows the latest version of all three major implementations, as well as links to their release notes and documentation about each one. The install page covers Dart Sass instead of Ruby Sass, and the Dart Sass page talks all about what Dart Sass is and the various ways it can be used.

What's Next?

At first, the focus of Dart Sass was on compatibility with the Sass language. Once we reached that and graduated to a beta release, we shifted our focus to compatibility with the Node Sass API. Now that we've reached that, our primary aim for the next several months will be bringing the usability of Dart Sass up to (at least) the standard of Ruby Sass and Node Sass.

This means focusing on a number of features outside the language that make working with Sass pleasant. This includes generating source maps from both the command-line interface and the JavaScript API, adding a live watch mode, and integrating Dart Sass into the Node ecosystem. We've also got our eye on the possibility of creating a Ruby gem that embeds Dart Sass with a Ruby Sass-like API.

Of course, I'll also continue to keep on top of bug fixes and new CSS features. I probably won't personally have a lot of bandwidth for adding new language features, but if anyone else is interested there are a number that wouldn't be too hard to add. Dart is a very easy language to learn, and I've written up a helpful guide on contributing.

What About Ruby Sass?

I'll be posting a more detailed post about the future of Ruby Sass soon, but the abbreviated version is that it's now officially deprecated. I'll continue maintaining it for one more year from the date this blog post goes live, including fixing bugs and updating it to support new CSS features, but it won't be getting any new language features. Once the one-year deprecation period is up, the repository will be archived and no new versions will be released.

Of course, all that could change if someone is willing to step up as a new maintainer! It's not an easy task, but it's a chance to work on something that's used by tons of people every day. If you're interested, please email me and Chris and we'll talk to you about next steps.

Give It a Whirl

One of the big benefits of switching to Dart is increased portability, which means it's easier than ever to install Sass. Give it a try on whichever is easiest for you:

• Standalone tarballs are available on GitHub, which you can just download and run from the command line.

• You can get the pure-JavaScript version from npm by running npm install -g sass.

• Chocolatey users on Windows can run choco install sass (or choco upgrade sass if you already have it).

• Homebrew users on Mac OS X can run brew install sass/sass/sass (or brew upgrade sass if you already have it).

• Or if you're a Dart user, you can run pub global activate sass.

Now, get styling!

I'm excited to announce that I've just released the stable version of Sass 3.5. This release focuses on compatibility with new CSS syntax, and helps lay the groundwork for the upcoming module system and compatibility with Dart Sass.

Most of the major features in 3.5 were already in the release candidate, which you can read about here. But there are a handful of other changes that have been added since then:

• Sass now supports the the ::slotted() pseudo-element, including extending its selector arguments.

• The var() function may be safely passed to the CSS color functions rgb(), rgba(), hsl(), and hsla().

• Transparent colors created by Sass's color functions will now be written as rgba(0, 0, 0, 0) rather than transparent to work around a bug in Internet Explorer. Colors written as transparent in the document will still be emitted as written.

Dart Sass Compatibility

I wrote last month about our plans for keeping Ruby Sass compatible with Dart Sass in the short term. Sass 3.5 begins to implement those plans by adding support for a number of small behavioral extensions added by Dart Sass:

• It's no longer an error to @extend a selector that appears in the stylesheet, but for which unification fails. The purpose of extension errors was to prevent typos, which weren't occurring in this case.

• Pseudo selectors that take arguments can now take any argument that matches CSS's <declataion-value> syntax. This will provide better forwards-compatibility with new selectors.

• Pseudo selectors that contain placeholder selectors as well as non-placeholders—for example, :matches(.foo, %bar)—will no longer be eliminated. This matches the definition of a placeholder as a selector that matches nothing.

• You can now vary the indentation within an indented-syntax file, as long as it still defines a consistent tree structure.

There are also some deprecations for functionality that's not supported in Ruby Sass:

• Extending compound selectors, such as @extend .foo.bar, is deprecated. This never followed the stated semantics of extend: elements that match the extending selector are styled as though they matches the extended selector.

When you write h1 {@extend .a.b}, this should mean that all h1 elements are styled as though they match .a.b—that is, as though they have class="a b", which means they'd match both .a and .b separately. But instead we extend only selectors that contain both .a and .b, which is incorrect.

• Color arithmetic is deprecated. Channel-by-channel arithmetic doesn't correspond closely to intuitive understandings of color. Sass's suite of color functions are a much cleaner and more comprehensible way of manipulating colors dynamically.

• The reference combinator, /foo/, is deprecated since it hasn't been in the CSS specification for some time and is being removed from Chrome soon.

• The old-style :name value property syntax is deprecated. This syntax is not widely used, and is unnecessarily different from CSS.

LibSass Compatibility

LibSass, the C++ implementation of Sass, is well on its way to compatibility with all these features. It's not quite there yet, but we decided we didn't want to block the 3.5 release on 100% compatibility. LibSass will release these features as it implements them.

What's Next?

In the most immediate future, I'm going on leave for a few months, so there's not likely to be a huge amount of work. Once that's over, I'll be focusing on getting Dart Sass to a full 1.0.0 release, which means spending a bunch of time making its JavaScript API compatible with node-sass.

As far as Ruby Sass goes, I'll continue to fix bugs and add support for the CSS features as browsers start to support them. Once Dart Sass 1.0.0 is out, I'll add new features concurrently across both Ruby and Dart until the one-year support period is up.

But for now, run gem update sass and enjoy 3.5!

Last weekend was three days long and the weather in Seattle was gorgeous. Contrary to stereotype, spring here is often characterized by bright sunny days that aren't too hot, and on days like that I love to curl up on the armchair in my living room and write some code. This weekend, that meant finishing up the last few outstanding @extend bugs, finally making Dart Sass fully sass-spec compatible¹.

This is the milestone we've decided would mark the transition from alpha to beta releases of Dart Sass. Dart Sass 1.0.0-beta.1 is up now on npm, pub, and Chocolatey, and I encourage people to start trying it out in their own applications. We've fixed all the bugs we know about, so now we need our diligent users to find the rest of them and tell us!

Next Steps: Ruby Sass

There are a number of intentional behavior differences between Dart Sass and the existing implementations. All of these differences are things we think improve the language, and many of them have also made Dart Sass much easier to implement, but we recognize that they can make migration more difficult. That's why our next priority is updating Ruby Sass by deprecating old behavior or adding new behavior, as necessary.

Our long-term compatibility goal is to ensure, as much as possible, that if a stylesheet compiles without warnings on Ruby Sass, it will also work with Dart Sass. So a substantial portion of our effort in the near future be spent on ensuring all the compatibility issues are fixed. Once that's done, we'll release those changes as part of Ruby Sass 3.5.

Next Steps: Dart Sass

On the Dart front, we have a number of issues outstanding that we want to resolve before we release a stable version of 1.0.0. The majority of these issues are focused on one thing: compatibility with the node-sass render() API. This will make it easy to integrate Dart Sass into existing JS ecosystem tools and workflows, since anything that works with node-sass will automatically work with Dart Sass as well.

Try It Out

As with all Dart Sass releases, 1.0.0-beta.1 is available on many platforms. Give it a try on whichever is easiest for you:

• Standalone tarballs are available on GitHub, which you can just download and run from the command line.

• Chocolatey users on Windows can just run choco install sass --pre (or choco upgrade sass --pre if you already have it).

• You can get the pure-JavaScript version from npm by running npm install -g dart-sass.

• Or if you're a Dart user, you can run pub global activate sass.

I'm very pleased to have 1.0.0-beta.1 tagged and out in the world, but the work of a language maintainer is never done. I'm back to work, and if I hustle, hopefully I'll be writing about 1.0.0-rc.1 soon!

One of the core design principles of Sass has always been to understand CSS as little as possible. As a CSS preprocessor of course we have to understand the syntax of CSS, but as much as we can we try to avoid caring about the semantics—the meaning behind the styles. This means that Sass has no idea which properties are valid, which HTML elements actually exist, or even to a large extent what the syntax of most @-rules is.

We get a lot of benefit from this. The less built-in knowledge Sass has about CSS, the less likely it is to work poorly with new CSS features. Imagine having to file a feature request every time you want to use a new CSS property—that would suck! Instead, older versions of Sass will happily keep working unless the actual syntax changes, which is much rarer.

Because of this decoupling, we've never needed to worry much about browser compatibility. Sass just passes whatever CSS its given on through. It's up to the user to determine what works where, which gives them a lot of flexibility and gives us designers one fewer tough decision to make.

But despite this general policy, there are always a few cases where CSS knowledge turns out to be necessary. A big one is @extend, which needs to know a lot about the meaning of selectors to properly unify them and weed out duplicates. Property values sometimes require semantic knowledge as well—we have to know how to interpret colors, for example.

One of those cases has leapt up to bite us. Long ago, we made the decision to always emit transparent colors as the keyword transparent, because it was supported on IE6 through 8 and the alternative rgba() syntax was not. But it turns out that the opposite is true for more recent versions: in IE10, :hover styles aren't triggered for elements with background-color: transparent but they are with background-color: rgba(0, 0, 0, 0). Thanks, IE!

So we were faced with a dilemma. Keep the existing behavior which was compatible with old outdated browsers that no one uses, or choose a new behavior that works better with modern browsers? The choice was pretty clear: we decided to always emit rgba(0, 0, 0, 0).

In addition, we wanted to come up with a general rule to guide us in determining which browsers we were willing to consider outdated, and which we would continue to support (whatever that meant for the behavior in question). We decided that if a change would negatively affect less than 2% of the global market share of browsers according to StatCounter GlobalStats, we were willing to make it.

This limit isn't set in stone. We reserve the right to change it in the future, and to make individual decisions that may affect more browsers. But this is the general guideline we're paying attention to, and we wanted you all to know.

One of the quieter benefits of moving to Dart is how easy it is to distribute Dart applications. The Dart VM is able to bundle all the sources for an application into one easy-to-load binary snapshot, which means running a Dart application requires only three files: the dart executable, the snapshot file, and a tiny shell script to invoke the app¹. This is a huge relief coming from Ruby, which required a whole installation of executables and libraries in order to run a single app.

Those three files are what we distribute today on our GitHub release page. But finding, downloading, and opening an archive and adding it to the command-line path is still a barrier to entry that we'd like to avoid where possible. Today we're taking a step in that direction by releasing a Dart Sass package on Chocolatey, the Windows package manager. You can install it now using:

$ choco install sass -prerelease

This will give you a sass executable that runs Dart Sass on the (really fast) Dart VM.

A large percentage of Sass users are on Windows, and it hasn't always been easy for them to get the latest and greatest Sass versions without a bunch of installation headaches. I'm excited that we can start taking advantage of our new infrastructure to fix that.

In addition to Chocolatey, we'd love to get Dart Sass on Homebrew for our OS X users. If you're interested in helping out with that, let us know—this issue would be a great place to start!

Over the past few months, I've been quietly working on a new project. Today I'm ready to announce Dart Sass to the world. It's a totally new implementation of Sass, designed to be fast, easy to install, and easy to hack on. It's not yet complete—I'm steadily working my way through sass-spec—so today I'm just releasing version 1.0.0-alpha.1. But it's solid enough for you to download, play with, and start filing issues.

You can download a standalone archive from the release page—just extract it, add the folder to your path, and run dart-sass. Dart also compiles to JavaScript, so if you have npm installed you can install the JS version by running npm install -g dart-sass. And, if you happen to be a Dart user yourself, you can install it using pub global install sass.

Why Rewrite Sass?

Over the past few years, there have been two primary implementations of Sass. Ruby Sass was the original, written mostly by me with substantial help from Chris. It's high-level and easy to hack on, so it's where we iterate on new features and where they first get released. Then there's LibSass, the C++ implementation, originally created by Aaron and Hampton and now maintained by Marcel and Michael. It's low-level, which makes it very fast and easy to install and embed in other languages. In particular, its Node.js bindings are a very popular way to use Sass in the JavaScript world.

Each implementation's strengths complement the other's weaknesses. Where LibSass is fast and portable, Ruby Sass is slow and difficult for non-Ruby-users to install. Where Ruby Sass is easy to iterate on, LibSass's low-level language makes it substantially harder to add new features. A complementary relationship can be healthy, but it can also mean that neither solution is as good as it needs to be. That's what we found when, in May, Marcel officially left the LibSass team¹.

Without two people's worth of effort, we were no longer sure that LibSass could keep pace with the speed Chris and I wanted to introduce changes into the language. And it had been clear for a long time that Ruby Sass was far too slow for use cases involving large stylesheets. We needed a new implementation, one that could generate CSS quickly and add new features quickly.

Why Dart?

We considered a number of possible languages, and ended up deciding on Dart for a number of reasons. First, it's really fast—the Dart VM is generally much faster than JavaScript VMs, and early benchmarks² indicate that, for large stylesheets, Dart Sass is 5-10x faster than Ruby Sass and only about 1.5x slower than LibSass. I'll hazard a guess that it would be about 1.5-2x faster than an idiomatic JS implementation, but I can't say for sure. And Dart's performance continues to get better all the time.

At the same time, Dart is easy to work with—much more so than C++, and to some extent even more than Ruby for such a large project. Granted, not as many people are familiar with it as with JavaScript, but language implementations don't tend to get many external contributions anyway. I'll be doing most of the work on the new implementation, and Dart is the language that I'm personally most comfortable with at the moment (when I'm not working on Sass, I'm on the Dart team). Using Dart gives me a lot of extra velocity.

Unlike Ruby or JavaScript, Dart is statically typed, so every value's type can be figured out without running the code. Unlike C++, it's garbage collected, so we don't have to worry as much about cleaning up after ourselves. This makes it easy to write, easy to modify, and easy to maintain. Maybe even more importantly, it makes it easy to translate to other programming languages, which will help LibSass get new features faster.

The last reason we chose Dart is something that only a few other languages can boast: JavaScript compatibility. Dart can be compiled to JavaScript, which can be used directly in Node.js or even potentially run in a browser. A huge chunk of the Sass ecosystem built on node-sass, and we intend to make the JS version of Dart Sass as close to API-compatible with node-sass as possible, so that it can easily drop into existing tools and build systems.

The only downside is that there's a speed hit: Dart Sass is about twice as slow running on V8 as it is running on the Dart VM. However, this still puts it solidly 3-4x faster than Ruby Sass. Ultimately we also hope to provide an easy path for users of the JS-compiled version to move to the Dart VM version as little friction as possible.

What Will Happen to The Other Implementations?

Nothing's changing about LibSass's development. Michael's hard at work adding features from Sass 3.5, and we expect that process to continue as new language features are added. The only difference is that LibSass will no longer be required to be strictly compatible with the latest version of the language in order for that version to launch, since it will no longer be the only implementation with reasonable performance.

More flexibility translates into faster LibSass releases that prioritize the features users want most. Strict compatibility meant that important features like CSS custom property support can't be released until all the tiny tricky edge cases that were in the corresponding Ruby Sass release, like :root unification, are implemented as well. We'll still strive for as much compatibility as possible, but we won't let that stand in the way of velocity.

Ruby Sass, on the other hand, will eventually go away unless a new maintainer appears. We don't want to make the transition sudden and risk fracturing the ecosystem: Chris and I are committed to maintaining it for one year, which includes keeping the language in sync with any new additions in Dart Sass. If anyone is interested in volunteering as a maintainer after that period, we'd be thrilled to mentor them and teach them the codebase over the coming year. But if no one steps up, Ruby Sass will be officially considered deprecated and unmaintained.

I want to emphasize that we aren't making the decision to stop developing Ruby Sass lightly. This is a big change, and it's not an easy one for me—I've worked on Ruby Sass continuously for almost ten years now, and it's difficult to let that history go. But Chris and I have discussed this thoroughly, and we're convinced this is the right move. We only have so much time to devote to Sass, and it no longer makes sense to put that time into an implementation that's so slow as to be infeasible for many of our largest users.

What Next?

Before we release the first stable version of Dart Sass, there are a few big things on our to-do list:

• Full sass-spec compatibility. There are still a bunch of corners of the language where Dart Sass does the wrong thing, especially with respect to @extend. I don't expect any individual incompatibility to be especially difficult to address, and sass-spec is pretty comprehensive, so it's just a matter of steadily reducing the number of failing specs until it hits zero.

• Close-enough node-sass render() compatibility in the npm package. The node-sass render() API is the main entrypoint to LibSass in the JavaScript world. It's how build systems run Sass, how users define custom Sass functions, and how Eyeglass passes modules to Sass. We want to support this API with enough fidelity that the existing ecosystem works with JS-compiled Dart Sass.

• Dart Sass compatibility in Ruby Sass. There are some cases where Dart Sass intentionally differs from Ruby Sass, particularly when Ruby Sass's behavior is considered a bug. We should add deprecation messages in Ruby Sass and, if we can do so with minimal disruption, add support for the new behavior.

There's plenty more we'd like to do eventually, like supporting Sass in the browser and providing a node-sass-compatible wrapper for Sass on the Dart VM, but those aren't blocking the initial release.

Onward Into the Future

The next couple months will see a lot of work go into getting Dart Sass stable and compatible, and getting Sass 3.5 features into LibSass. I think it's likely that early 2017 will see a stable release of Dart Sass and a 3.5 release of LibSass. At that point we'll set our sight on the big features and start working towards Sass 4.0 and its brand new module system.

Dart Sass is a big change, but it's an exciting one as well. It'll allow us to get new features into users' hands faster, and to make those features run faster. It'll make it possible for users to trivially install and run the reference implementation. And it'll give us a performant way to run Sass in pure JavaScript Sass for the first time ever. The benefits are large and tangible, and I'm confident they're worth the costs.