Menu
27/01 2018

The Evolution of Sass

In recent years, the use of preprocessors has become commonplace for Front End Development and many do not even write raw css anymore. As a direct result of the rise of Responsive design, the requirement for css preprocessors went from a nice to have, to virtually mandatory for some projects due to the scale of dealing with media queries and the plethora of new technology being leveraged on the Front End of Web sites today.

How it all started for Sass

The first ever css preprocessors I can remember were written in php to allow rudimentary grouping and general tidying of css to reduce overhead and make it less unwieldy, reducing the danger of mouse overuse. This idea grew into full blown bespoke languages like Less, Sass and Stylus. The amount of preprocessors around today is huge but one in particular was adopted by the community more than the others due to its logical syntax. Sass was first introduced back in 2006 and was one of the first dedicated css preprocessors to appear. This could be why it was never really bettered.

Concepts like nesting and importing are ones which largely mirror how Front End Developers think about css when they write it in raw form. This is elevating Sass above other preprocessors such as Less or Stylus. Developers are comfortable that this preprocessor makes it easier to deal with css containing many varied media queries, emerging prefixed styles and inheritance of styles between elements.

If it makes sense, use it

Familiarity with a tool and what it can do means css is quicker to write, quicker to maintain and quicker saves everyone time and money. Obviously you still need the skills to work with these tools and they cannot just be picked up in 5 minutes. Choosing the right one to learn and run with, is very important for longevity and on going maintenance of projects, as is the fact that other Developers need to be able to pick up the project and understand how things are put together quicker too. This is especially important when you are dealing with large monolithic Websites or apps with many components and features.

Sass’ popularity is two-fold - on the one hand it means that Developers adopt it over others which allows the language to move forward, take feedback from the community and improve the way it works. On the other are all of the things that can plug into it. Workflow tools like Grunt and Gulp have their own ways of helping improve a Front End Developers Sass workflow, such as compiling on the fly and automating certain things. Checking and correcting issues within the Sass itself are among these processes. None of this would happen if the language as a whole didn’t have the uptake to make it worth improving upon. All of this attention has a huge impact on this and only serves to boost Sass’ popularity even more.

Where now for Sass?

As with anything that needs to progress, Front End technology is moving fast at the moment but we need to be aware that if something is moving fast, it is unstable and needs to be carefully developed and tested before adding anything new.

There are some new languages coming to the fore right now and there has been some traction from languages like Postcss and Cssnext though my take on this is that if anything is going to take over the mantle that Sass currently resides upon it’s hard to imagine it would be anything vastly different to Sass as it currently is. It is likely to be a variation of Sass which includes features that Developers have grown fond of. If they do, they will need some very useful features that no one has yet thought of.

Leave a Reply

Your email address will not be published. Required fields are marked *

This article is in the html and css category. Here are some other related articles also in this category.