SASS: next-level CSS?

With CSS, you can design your website exactly the way you want it. But the stylesheet language has its limits. Many web designers wish for a more com­fort­able way to work on website design. This is where CSS pre­proces­sors come into play. With the help of a stylesheet language, which is an extension to the un­der­ly­ing CSS, design work can be made sig­nif­i­cant­ly easier. The most well-known of these extension languages is SASS. What exactly is the “Syn­tac­ti­cal­ly Awesome Style Sheet”?

To un­der­stand what SASS is and why you might need the language, you should first make sense of CSS. Websites are initially based on the markup language HTML. If you want to design in HTML, then you have to link the content directly to the design – on every single HTML page. Simply said, HTML is not intended for design, and so is severely limited in this area. Cascading style sheets (CSS) set the pre­sen­ta­tion of HTML pages. CSS sits on top of the HTML code, like a template, and defines the design for each element on the page: Font, font color, back­ground – web designers can set all of these design elements with CSS.

For example, to set all headlines in 22pt Calibri, define this in the stylesheet where all guide­lines for the ap­pear­ance of your website are given. These rules are usually in a separate file, which the HTML pages then refer to. This enor­mous­ly shortens the amount of in­for­ma­tion per page.

But CSS has its limits, which is es­pe­cial­ly clear if you’ve been working with the language for many years. The advantage of CSS is actually a dis­ad­van­tage at the same time: the language is designed very simply. SASS makes it all a little more so­phis­ti­cat­ed, and greatly sim­pli­fies the work of creating a design.

All modern browsers can display CSS with no errors, but that’s not nec­es­sar­i­ly the case for SASS (which has been in use for over 10 years) or other extended stylesheet languages. For this reason, SASS is con­sid­ered a pre­proces­sor. The code in the SASS document is first converted to CSS before the source code, i.e. the website, is delivered to the system.

At first, there doesn’t seem to be any reason that SASS is necessary. After all, CSS has made it possible to develop at­trac­tive­ly designed and technical pages for decades. Even if you want to work with SASS from here on out, you can’t avoid CSS. The old-fashioned stylesheet language will continue to stick around in the future as the foun­da­tion of the pre­sen­ta­tion. SASS and other languages simply build on the skeleton of CSS.

Of course, with SASS you have some options that aren’t offered by CSS alone:

• Variables: With SASS, you can save in­for­ma­tion in variables to be used again later. So it’s possible, for example, to centrally store a color value under a catchier variable.
• Math­e­mat­i­cal functions: In SASS, you can also use math­e­mat­i­cal op­er­a­tions like +, -, *, /, or %. This allows you to influence size spec­i­fi­ca­tions, for example.
• Functions: Other functions also make it easier to work on the design. These allow you to modify color values or analyze lists, among other things.
• Loops: Another advantage of SASS is the ability to set up loops. These are repeated until they reach a status defined by you.
• Case dis­tinc­tions: These have a similar function to the con­di­tion­al in­struc­tions “if” and “else.” The given commands are only run if specific con­di­tions are met.
• Mixins: Mixins, simply said, are templates. You can either create them yourself or simply integrate them into your own code when using a framework.
• In­den­ta­tions: The original SASS (as opposed to SCSS) works with in­den­ta­tions and line breaks to structure the code. You don’t need paren­the­ses to display nesting or semi­colons to mark line ends.
• Nesting: CSS doesn’t allow you to work with nesting in the code. SASS, though, gives users the option to present de­pen­den­cies visually to reduce re­dun­dan­cies and simplify the writing process.
• In­her­i­tances: It’s possible to inherit prop­er­ties from one selector to another. This saves some writing effort and keeps the code slimmer.
• Partial files: To integrate code elements into a SASS file, you can also use partials. These are files that only have to contain a few lines of CSS and are imported into a SASS file by command.

Helpful frame­works and libraries already exist for SASS. Compass or Bourbon do a lot of the work for you when designing a website.

So that the created SASS code has the desired effect, you first have to convert it into ordinary CSS. The com­pi­la­tion functions very easily over the command line:

This command compiles the source code from your created example.sass file into a new CSS file. In doing so, the syntax of SASS is au­to­mat­i­cal­ly modified to fit the rules of CSS. For example, in­her­i­tance is done away with and the syntax is adjusted.

Work on a website is rarely finished, and you could po­ten­tial­ly make regular changes to the design. This is why SASS uses the “--watch" parameter to give you the option to monitor folders or files. If you make changes to them, then the system au­to­mat­i­cal­ly re­com­piles them.

There’s not only one syntax that you can use SASS in, but two: One has the original form, which is usually referred to as “indented syntax” or simply “SASS” for short. But there is also a new variant, which is more strongly oriented to the standards of CSS and so is called sassy CSS (SCSS) – so, SASS-style CSS. Version 3 of SASS has SCSS as an official syntax. The biggest dif­fer­ence: the use of paren­the­ses and semi­colons.

The original SASS syntax works with indents and line breaks, a process adapted from YAML. To finish a line of code, it’s suf­fi­cient to insert a line break – so press the enter key. Indents function simply using the tab button. Groupings, called de­c­la­ra­tion blocks, are formed by changing the position in the typeface. This isn’t possible with CSS itself. Here, you have to use paren­the­ses for the groupings and semi­colons for the property de­c­la­ra­tions. This is exactly what’s necessary for SCSS.

The vari­a­tions command fierce loyalty: Some users swear by the simple handling of the original SASS, where you don’t have to pay attention to the correct po­si­tion­ing of the paren­the­ses when moving snippets of source code and can generally create slimmer, clearer code. You end up with fewer char­ac­ters and lines overall as a result of the “indented syntax.” The SCSS en­thu­si­asts, on the other hand, are happy to take the ad­di­tion­al effort in stride, because it’s more similar to what you already know from using CSS.

SCSS is a superset of CSS, which guar­an­tees that the CSS code fun­da­men­tal­ly works in SCSS as well – but not the other way around. The functions of SASS are still fully contained, though. This makes it easier to work with both languages at the same time. In addition, people who already work with CSS and are com­fort­able with the syntax have a much easier time switching over. Even though SASS supports both syntaxes, you still have to decide for each project: to be able to dis­tin­guish between the different formats, give the files either the file ending “.sass” or “.scss.”

SASS brings a lot of benefits to the table, but the pre­proces­sor still doesn’t convince everyone. The ad­van­tages are obvious: The pre­proces­sor language gives users more pos­si­bil­i­ties when creating code. Many web designers, for example, love the function that allows you to store colors as variables instead of always having to enter the color value as a hexa­dec­i­mal number. Mixins, variables, in­her­i­tance, and nesting do a better job than tra­di­tion­al CSS in ensuring that you follow the principle “Don’t repeat yourself.” This theory pushes for avoiding rep­e­ti­tion in code and keeping source code slimmer. These changes also sig­nif­i­cant­ly reduce the effort required. Instead of having to make changes in multiple different places, you can just make one change at a central position.

The dis­ad­van­tages of SASS apply to basically every pre­proces­sor, and refer to the fact that the created code first has to be compiled. This adds another step to the de­vel­op­ment process. This makes the process a bit lengthier. Instead of being able to make mod­i­fi­ca­tions directly in the CSS file and see the effects im­me­di­ate­ly on the website, changes in the design first have to be trans­lat­ed into CSS. This allows errors to slip in and makes debugging more difficult.

Before using SASS – just like with any other un­fa­mil­iar tech­nol­o­gy – you need to take the time to learn the new language. In addition to CSS, which you should already know in any case, it’s simply another language to master.

In addition to SASS, LESS has also es­tab­lished itself in developer circles. This stylesheet language is strongly oriented around CSS and resembles SCSS in its syntax. Both pre­proces­sors share some of the same prop­er­ties: Both SASS and LESS allow for the use of mixins and variables. One dif­fer­ence, though, is that SASS is based on Ruby, while LESS uses JavaScript. But even this doesn’t give either of the pre­proces­sors an advantage over the others.

The real dif­fer­ences are found instead in the logical functions: LESS gives users the op­por­tu­ni­ty to only activate mixins when specific sit­u­a­tions occur. This is a helpful feature, but it rep­re­sents the extent of logical links in LESS. SASS, on the other hand, offers loops and case dis­tinc­tions as known from pro­gram­ming languages.

With SASS, users are free to choose between “indented syntax” or SCSS. Each developer can decide for them­selves whether they would like to move away from the CSS rules or stay closer to the original. LESS doesn’t offer this choice. Here, users have to stick with the old rules. Code in LESS is au­to­mat­i­cal­ly a superset of CSS: All source text for­mu­lat­ed in CSS also functions in LESS – just like with SCSS.

SASS is much more popular among web designers. But this could be because SASS is a bit older. LESS was orig­i­nal­ly supported by the well-regarded frontend framework Bootstrap, which relied on the younger pre­proces­sor. But with version 4, the project of­fi­cial­ly switched to SASS, which boosted the pop­u­lar­i­ty of syn­tac­ti­cal­ly awesome style sheets even further.