Join John Riviello for an in-depth discussion in this video Decide between Ruby Sass or libSass, part of CSS to Sass: Converting an Existing Site.
- View Offline
- In this lesson, we'll go over the two versions of Sass, Ruby Sass and lib Sass, and explain why they exist, what the differences are, and determine which is the right one for your project. Sass was originally written in Ruby by Hampton Catlin, as a new way to write CSS using a syntax similar to Haml, which is a popular Ruby templating market plan which he also created. Up until a few years ago, if you wanted to use Sass, you needed to either use Ruby to run the Sass compilation, or use an open source or paid third-party tool to do it for you.
And since it's written in Ruby, which is an interpretive language, it can be slow to run on large codebases. So to address these two issues of requiring Ruby to run it, and it's potential slow compile times, Hampton's company sponsored the creation of a project called libSass, which is a C/C++ port of the Sass engine. The result is compilation times that are orders of magnitude faster, anywhere from 10x to 40x. Also, since it's a C library, it can be used in many different languages with a custom wrapper. For the list of currently supported languages, check out the libSass page on http://sass-lang.com.
So if libSass is so fast and potentially easier to use, why would you choose the Ruby version of Sass over libSass? There are basically three reasons. First, if you're building a website using Ruby, the most popular web frameworks like Rails, Sinatra, Jekyll, and Middleman, all have native support for the Ruby version of Sass. So it's slightly more work to run libSass in those frameworks. The main development of the Sass language happens in Ruby, so libSass may be missing features that are part of Ruby Sass. To easily determine if a feature is supported by libSass, check out the website http://sass-compatibility.github.io.
Also, some Sass plug-ins only work with the Ruby version of Sass, so if you want to use a particular plug-in, you have to verify its capabilities with the libSass wrapper you plan to use. For example, Urban and Compass are two popular libraries for Sass. Urban supports libSass, while Compass does not, although there are other tools that duplicate Compass's mixins and functions for libSass. So since you're taking this course because you want to switch from vanilla CSS to Sass, I'm going to assume that you're not building your website with Ruby.
At the time of this recording, if you look at the Sass compatibility page and scroll to the bottom, you'll see that the current version of Ruby Sass is at 100% with libSass. So actually you're getting the same features in libSass as you do with Ruby Sass. So it makes sense to take advantage of the speed improvements libSass provides. This is especially important if you're trying to get a team to start using Sass, as you're going to want the easiest path to implementing it, with the least amount of impact on your application's build time, to prevent others from pushing back on its adoption.
In these Sass tutorials, students will learn the benefits of libSass over the original Ruby Sass, and set up a Sass-friendly development environment with Node.js and Grunt. A unique aspect of this course is learning how to handle challenges specific to integrating Sass with an existing website, such as new debugging workflows and the variables and mixins worth the effort to define. Author John Riviello also introduces a few Sass tools that speed up media query handling, automatic browser prefixing, and sprite generation. At the end of the course, he shows how your setup work pays off, styling a whole new section of the practice site in just 15 minutes.
- Deciding between Ruby Sass or libSass
- Installing Node.js and Grunt-Sass
- Converting CSS to SCSS
- Creating core variables and mixins
- Abstracting units and values
- Applying advanced mixins
- Generating image sprites with eyeglass-spriting
- Creating high-DPI sprites
- Building new styles