Announce Dart Sass

For the past several months, we have been quietly working on a new project. Today I am ready to announce Dart Sass to the whole world. This is a completely new implementation of Sass, created to be quick and easy to install and develop. It is not yet complete - I am working to bring it into compliance with the Sass specification - so today I just publish version 1.0.0-alpha.1. But it is reliable enough to be able to download, play with it and start reporting bugs .

You can download the archive from the release page - just unpack it, add the directory to the path, and run dart-sass . Dart is also compiled into JavaScript, so if you have npm installed, then you can install the JS version by running npm install -g dart-sass . And if you yourself are already a Dart user, you can install it via pub global dart-sass .

Why rewrite Sass?

Over the past few years, there have been two major implementations of Sass. Ruby Sass was the first one written mostly by me with substantial support from Chris . It was high-level and easy to develop, and was the place where we ran in and released new features. Then LibSass appeared - an implementation in C ++, originally created by Aaron and Hampton , and is currently supported by Marcel and Michael . This is a low-level version, which makes it quick and easy to install and embed in other languages. In particular, the use of Node.js is a very popular way to use Sass in the JavaScript world.

The strengths of each version complement the weakness of the other. Where LibSass is fast and portable, Ruby Sass is slow and difficult to install by non-Ruby users. But Ruby Sass is easier to develop, while in LibSass it is much more difficult to add new features due to the low-level language. Although complementary relationships can be healthy, it also means that none of the solutions are as good as they should be. We found this when Marseille officially left the LibSass team in May. ( Author's note: I say "officially" because he still takes part in the project as much as possible, but not to the extent as the official developer).

Deprived of the efforts of two people, we were not sure that LibSass would be able to keep up the pace, so Chris and I wanted to make changes to the language used. For a long time, it has been understood that Ruby Sass is much slower when processing large style sheets. We needed a new implementation that could quickly generate CSS and quickly add new functionality.

Why dart?

We looked at several possible languages ​​and settled on Dart for several reasons. Firstly, it is really fast - Dart-VM is generally much faster than JavaScript VM and preliminary benchmarks show that for large Dart Sass files it is 5-10 times faster than Ruby Sass and only 1.5 times slower than LibSass. ( Author's note: I am not an expert in benchmarks, and non-representative source files were selected (ad hoc) in the tests. If anyone is interested in working on more scientific dimensions, let me know). With caution, I suppose that it will be 1.5–2 times faster than a specialized JS implementation, but I cannot say for sure. In addition, Dart performance improves with time.

While Dart is easy to work with - much easier than with C ++, and somewhat easier than with Ruby for such a large project. Of course, not many people are familiar with it, as with JavaScript, but working on the implementation of the language does not imply a lot of external participants in any case. I will do most of the work on the new implementation, and Dart is the language with which I personally feel comfortable at the moment (at the time when I am not working on Sass, I am in the Dart team). Using Dart gives me a speed boost.

Unlike Ruby or JavaScript, Dart is statically typed , so the type of each value can be inferred without the need to run the code itself. Also, unlike C ++, it is garbage collection , that is, we do not need to worry about tidying up after ourselves. This makes it easy to write, edit and maintain. Perhaps even more importantly, it is easily translated to other programming languages, which will allow LibSass to get new features faster.

The final reason for choosing Dart is what few languages ​​can boast of: compatibility with JavaScript. Dart can be compiled into JavaScript, which can be directly used in Node.js, and even possibly in a browser. Most of the Sass ecosystem is built on node-sass, and we intend to make the JS-version of Dart Sass as API-compatible as possible with node-sass, so that existing tools and build systems can be easily transferred to the new version.

The only drawback here is a failure in speed: Dart Sass is about twice as slow when running on a V8 compared to a Dart VM. However, it still gives a steady increase of 3-4 times compared with Ruby Sass. As a result, we also hope that we can provide the users of the JS version with the migration path to Dart VM as easy as possible.

What happens to the other implementations?

No change in the development of LibSass. Michael is working hard on adding new features from Sass 3.5 , and we expect that this process will continue as new features are added. The only difference is that LibSass will no longer have to be strictly compatible with the latest version of the language, before launching this version itself, since it will no longer be the only version with reasonable performance.

More flexibility will result in faster LibSass releases, which bring to the forefront the opportunities that users want most. Strict compatibility meant that important innovations, such as, for example, support for custom CSS properties, could not be released until all the small and tricky boundary cases that were in the corresponding version of Ruby Sass, for example, were :root We are still trying to achieve maximum compatibility, as far as possible, but we will not allow her to stand in the way of speed.

Ruby Sass will eventually go away completely, unless a new developer appears for him. We don't want to make the transition sudden, at the risk of splitting the ecosystem: me and Chris are going to maintain it for one year, which includes maintaining the functionality at the same level that will be added to Dart Sass. If someone is interested in participating as a developer after this period, we will be happy to introduce him to the code during the coming year. And if no one performs, then Ruby Sass will be officially recognized as obsolete and unsupported.

I want to emphasize that we are not making the decision to stop the development of Ruby Sass just like that. This is a big and not simple change for me, I have continuously worked on it for almost 10 years, and it is difficult for me to let this story go. But Chris and I discussed this carefully and were inclined to think that this was the right move. We have devoted so much time to Sass that it no longer makes sense to spend this time on implementing, so slow that it is unacceptable for our largest users.

What's next

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

• Full compatibility with the Sass specification. There are still moments where Dart Sass behaves incorrectly, especially with regard to @extend . I do not expect any particular incompatibility, which will be difficult to solve, the Sass specification is quite exhaustive, so this is just a matter of reducing the number of unsuccessful tests to zero.

  
  

• Close enough compatibility with render() from node-sass. This API is the main entry point to LibSass in the JavaScript world. This is how build systems launch Sass, users define their own Sass functions, and Eyeglass transfers its modules to Sass. We want to support the API with enough that the existing ecosystem works with Dart Sass.

  
  
• Dart and Ruby Sass compatibility. There are several cases where the Dart functionality is intentionally different from Ruby, in particular, where Ruby's behavior is regarded as a bug. We need to add warnings about this in Ruby Sass or, if we can do this with minimal edits, add a new behavior to Ruby.

There are a few more points that we would like to do in the long run, such as Sass support in the browser and providing a node-sass-compatible wrapper for Sass on the Dart VM, but this does not block the initial release.

Further future

Over the next few months, I see a lot of work on becoming a Dart Sass more stable and compatible, as well as adding features of Sass 3.5 in LibSass. I think that most likely in the beginning of 2017 we will see a stable release of Dart Sass and LibSass version 3.5. At this time, we will define our view on major functionality and start working on Sass 4.0 and its completely new system of modules.

Dart Sass is not a big change, but at the same time exciting. This will allow us to quickly deliver new functionality into the hands of users, as well as make this functionality work faster. In addition, it will allow users to easily install and run the reference implementation. And finally, for the first time, this will give us a productive way to run Sass in pure JavaScript. The benefits are so big and tangible that I’m sure it’s worth the cost.