Why Bootstrap 4 Means Sass Has Won

CSS preprocessors like Sass and Less are tools that greatly enhance CSS development. Sass and Less have been around for a while now and are widely adopted by the web development community. CSS preprocessors bring real language features to CSS such as variables and mixins (functions) which result in clean, extensible and reusable CSS code.

Stack vs Stack

Over the past five years I have advocated the use of CSS preprocessors in general because of the countless hours that I have personally saved using them. I have always shared my advice on CSS preprocessors from the stance of “use the tool that fits your development stack.” While Sass and Less have always been closely matched on a feature-by-feature basis, they have historically had advantages for specific technology stacks.

Ruby vs JavaScript

While both Sass and Less started in the Ruby community, Less switched to JavaScript, making it ideal for developers who were reluctant to use Ruby as part of their development process. Throughout the years both Sass and Less have been ported to many languages including C++, JavaScript, and Java.

A popular Sass port, Libsass (C++) has addressed the issue of Ruby dependencies as well as improved the performance of Sass compilation. Amazing contributions like this from both Sass and Less communities have made dependencies a trivial issue when choosing a preprocessor today.

Foundation vs. Bootstrap

Front-end frameworks were another consideration that motivated me to discuss the developer stack. In the recent past Foundation and Bootstrap used different preprocessors for their CSS source code.

Foundation by Zurb chose Sass as its preprocessor and heavily relied on its ability to use variables and mixins to customize the framework and use it in a modular way. On the flip side of the coin, Bootstrap chose Less and also incorporated a massive amount of customization through Less variables and components.

While the reasons to choose between Foundation and Bootstrap are an entirely different debate on their own, it’s important to understand that choosing one versus the other changed which preprocessor was beneficial to your development process. Also consider the overall market share of each of these frameworks.

Bootstrap is without a doubt the more popular choice. Less having such a influential use case made it an easy recommendation throughout the years. Bootstrap 3 offered a Sass alternative recently, however it still may not have been enough to sway users away from Less.

This story changes entirely when you consider Bootstrap 4. Why? Because Bootstrap 4 is being built entirely from Sass instead of Less. This marks the first time in Bootstrap’s history that the official source code has been developed using Sass. Because of this, moving into the next generation of front-end frameworks the consideration of Foundation versus Bootstrap results in the same choice of CSS preprocessor – Sass.

Bootstrap 4 and Furthermore

Considering the history of Bootstrap, its move to Sass took me a little by surprise. Out of curiosity, searching for a compelling reason that Bootstrap made this change, I looked at the numbers. Researching stats on RubyGems.org and npm-stats.com paints a convincing picture, with Sass downloads exceeding Less by almost double.

It appears that the Sass community is just simply larger than that of Less. But is this the reason to change the codebase?


I reached out to the Bootstrap team to see if they had a definitive answer on the matter and the graciously replied, saying, “More people use SCSS, libsass is crazy fast, syntax is more explicitly clear, and I’m lazy and use SCSS at GitHub.” So there you have it, straight from the source.

Moving Forward

With the formalities out of the way, does this spell the end for Less?

I’m not one to bandwagon against a framework or tool just for the sake of declaring something dead. While I’m sure Less will “live on,” it looks like the market share is about to swing even more heavily in favor of Sass. The factors that were once prime for healthy debate like dependencies and use-cases are now trivial.

When Bootstrap 4 emerges from beta, it will most likely bring even more developers over to Sass. I feel it’s safe to say, if you’re working on front-end web technologies and you touch CSS on a regular basis, now is the time to learn Sass. It’s almost inevitable that Sass code and compilers will be part of some future project.


  • Pingback: Dew Drop – December 18, 2015 (#2155) | Morning Dew()

  • Natan Souza

    The next fight? Sass and Stylus 🙂

    • hogash

      Nope, surely it’ll be Sass vs PostCSS . It’s already starting to get heated.

      • Dominio Público

        Preprocessing and postprocessing should be kept separate.

        Sass need only compile into the latest CSS. PostCSS’s only job is to makes sure that the latest CSS will work for the set of older browsers being targeting.

        If PostCSS tries to do everything Sass does then:
        – I need two packages that do mostly the same thing, but differ in the few aspects I actually require.
        – Those of us only writing the latest CSS with no need to support older technology use bloated packages with features they don’t need or use.
        – People with already written CSS looking for compatibility use bloated packages with features they don’t need or use.

        How about one petabyte-magnitude library with configuration longer than War and Peace that takes in the files of any language and spits out exactly what you want? Things are heading that way and it is getting confusing (and when it doesn’t work you are screwed). It doesn’t fit your use case? Too bad. This package does everything and does it all terribly!

        I have not forgotten the Unix philosophy:
        – Write programs that do one thing and do it well.
        – Write programs to work together.

        Let us separate our concerns for the sake of sanity and not be so preoccupied with marketshare.

  • Ben Coveney
  • PAEz

    I would have thought one of the big reasons sass has managed to get so popular is thanks to codepen and sites like it (but mainly codepen).
    Before CodePen you had to install stuff just to try it and then anything you released would have to be compiled. So the person viewing it wouldnt be inspired to look at it and learn it. Now they see the sass code and can play with it without any hassle on their part.
    I had no idea just how cool sass could be until I started browsing codepen.

  • I will help Boostrap4LESS. Sass is the worst because who wants to use Ruby in a Javscript, PHP or .NET project? No one.

  • I will help Boostrap4LESS. Sass is the worst because who wants to use Ruby in a Javscript, PHP or .NET project? No one.

    • vgavro

      Have you even read an article? Libsass is PURE c++ implementation.

      • Libsass doesn’t impress me. Who cares if it’s PURE C++ when it’s not supported very well for actual languages. For .NET libsass-net is worth a damn but that’s about it. The only pure JavaScript implementation is sass.js which is clunky and bloated at almost 4mb. SassPHP hasn’t been updated in two years and seems dead. Don’t even get me started on the Python compilers. And while node-sass does work great you have to be running NGINX. Nah. SASS sucks for anyone other than Ruby programmers or CodePen kids.

        • Mario

          What a looser… keep on hating hater.

          • What an idiotic response. It doesn’t matter though. This debate is largely irrelevant now that CSS4 is right around the corner as it ensures the death of SASS and most of the compilers except for maybe PostCSS.

          • Mario

            What a coincidence…. I was thinking “what an idiotic comment”. Perhaps the brashness of your comments is counter intuitive to what you wish to accomplish, unless of course your goal is to come across as an arrogant asshole that just hates ruby and sass — in which case: GOAL ACCOMPLISHED!

          • Mario

            I had to track down this comment, since I’ve recently come across more information on the topic and I want to hear your response.

            1. There is no CSS Level 4. Independent modules can reach level 4 or beyond, but CSS the language no longer has levels. (“CSS Level 3” as a term is used only to differentiate it from the previous monolithic versions.) — https://www.w3.org/TR/CSS/#css-level-4

            2. DartSass will be the new reference implementation, it compiles to JS and is available through npm. Please note: the DartSass announcement is from 10 months ago, 4 months before your original comment.

            Sources: https://github.com/sass/dart-sass, http://sass.logdown.com/posts/1022316-announcing-dart-sass

            3. CSS custom properties, bracketed lists and ::slotted() pseudo-element support.

            The fact that they are adding new CSS features, should indicate that they aren’t just slipping into irrelevancy and are staying current and relevant. (Yes, they could still fail; but keep up with recent developments is not usually a sign of a dying project).

            Source: http://sass.logdown.com/posts/2026639-sass-35-is-released, http://sass.logdown.com/posts/809572-sass-35-release-candidate

            Bonus: I want to address this: “Sass is the worst because who wants to use Ruby in a Javscript, PHP or .NET project? No one.”

            I do! I recently (last week) used sass (the ruby implementation) when creating a custom WordPress theme for a client. Why? Because it was really really easy and I love sass! Already had RVM installed so getting sass up and running was trivial. Edit the README, create Gemfile, .ruby-version and .ruby-gemset files and it’s pretty damn portable too.

          • Concerning CSS4, that’s true. But everyone I know and everyone on the internet refers to the new cutting edge CSS updates as CSS4. It’s just a convention. Search for CSS4 on YouTube and you’ll find a lot on level four modules but if you searched for CSS Snapshot and the year you won’t get too many. It’s just easier to say CSS4. If you want to call it CSS snapshot release number whatever that’s completely fine and certainly more accurate and I wouldn’t fault anyone for accuracy.

          • Mario

            @spencerthayer:disqus Yeah, the CSS4 point was a bit of a jab. “CSS4” is fine, I’ll concede that it’s the easy and common way to refer to the new features.

            Regarding mixing languages; minimum web development seems to be HTML, JS, and CSS. Does one more (that I use anyway) really hurt that much? I am kind of an old fogey as well and try to keep my projects simple without too many dependancies, but sass empowers me to so so much right now that i enjoy using it when I can. At first I despised the concept of CoffeeScript, Haml, Sass, etc, however when I gave it a fair shot I found myself delighted by their elegance. I’m a stickler for proper formatting so languages that rely on indentation to define blocks are a natural fit for me, but i understand but that it’s not for everyone.

            As for your comment on DartSass, completely reasonable, can’t really add anything there.

            Lastly, I don’t know what the future holds for Sass, but I also don’t know what the future holds for any technology. I’m concerned about what helps me be productive right now. I keep trying to learn new things and try to pick what’s best for the jobs at hand as well as my workflow and for right now Sass is fantastic.

            Anyway, cheers to you mate. Our last exchange here is much better than the first.

            Edit: Fixed a typo.

          • DartSass is very interesting to me and I may one day need to use it and will likely be fine with it. As I understand it, it’s very slow in it’s current version, but that’s not really a big deal.

          • Fair enough on being okay with using Ruby in a PHP project. I’m not interested in quilting together separate languages unless absolutely necessary. Maybe I am old.

          • ldlework

            Learn to build your systems with containers and this entire class of rhetoric about mixing languages (for which you are hammering pretty hard with) becomes completely obviated…

          • @ldlework:disqus you must work at a Startup where you are not constrained by very specific business rules.

          • Concerning irrelevancy, I am certain SASS will be used for the next decade. But as CSS improves with new modules that solve existing problems the use for a SASS compiler will become less appealing and it will cease to be popular. Maybe not. But I don’t see the justification for using SASS when CSS level four modules will soon do everything SASS has been doing for a while.

          • Jurann McRea

            Yeah, you realize that as of June, 2017 the CSS steering committee is strongly considering making SCSS (aka SASS) the new CSS standard, right? Meaning that browsers will be asked to directly support .SCSS/.SASS files directly without need for pre-processing at all. Keep on hating it though, be my guest. =) You’re really going to hate it when it becomes the new norm and you don’t get to choose.

          • Dude, Sassy CSS is not the same thing as SASS. The whole point of my post (clearly you didn’t read it) was that SASS is a Ruby-like syntax and requires Ruby or a shitty alternative to process while SCSS is by default fully compatible with CSS. And while the CSS steering committee is strongly considering making SCSS the standard it would only be done as part of the CSS Level 4 syntax which was discussed in the thread below. Keep up man.

          • Jurann McRea

            Ohnoes, dat Ruby is hella hard install!
            sudo apt install ruby
            sudo apt install sass
            How hard was that? I put both packages in my provisioning script and whenever I stand up a new container they’re there.
            Did you not read the OP article about Bootstrap 4? Keep up man!

          • Yeah I get @jurannmcrea:disqus you are a fan boy and you’re likely a new programmer so you’ve never had to develop within an extremely restricted environment. Good luck with all that.

          • Jurann McRea

            I’ve actually been doing web development professionally since 1994. Before divitis. Before AJAX. Before CSS. Before JS did anything useful. When NCSA and Netscape Enterprise Server dominated the professional market. Unlike you, though, I’ve kept up with the times. Your “maybe I’m old” comment was right on the mark – good for me that being old and experienced doesn’t mean getting left behind. Why’d you stop evolving when the web hasn’t? Nor have OSes. Nor has deployment. Nor has web distribution. I’m guessing you either don’t live in Silicon Valley or you work for a dinosaur company in a position you’ve toughed out for far too long – so you’re probably also underpaid.

    • uberliberal

      It’s great to help both communities, but you can compile SASS with libsass and use gulp or grunt too to make it seamless.

  • Pingback: Create Google-Styled Bootstrap Layouts with Bootplus Framework – My Updates()

  • Pingback: Create Google-Styled Bootstrap Layouts with Bootplus Framework - MadoxWeb Internet Marketing()

  • Pingback: Create Google-Styled Bootstrap Layouts with Bootplus Framework | Latest News and RSS Feeds()

  • Pingback: Create Google-Styled Bootstrap Layouts with Bootplus Framework | TechnolAG()

  • Pingback: Create Google-Styled Bootstrap Layouts with Bootplus Framework - Atlans - Web Hosting, Web Design, and Pysics()

  • Pingback: Getting Started: WP Web Development | brian jones francis()