Sass vs. Stylus: Who Wins the Minimal Syntax Battle?
Today we’re going to pit two CSS preprocessors head to head. You’ve no doubt seen lots of discussion about how SCSS compares to LESS, but where does Stylus, the new kid on the block, factor in? Can it possibly match the power and versatility of SASS?
We’ll jump head first into both syntaxes and compare them side by side to see which is more logical and versatile. We’ll also talk about features and give you a clear argument for why one preprocessor is more powerful. You can rest assured, we’re not going to wuss out and give you some crap about a tie, there will be a winner!
2 Million+ Digital Assets, With Unlimited Downloads
Get unlimited downloads of 2 million+ design resources, themes, templates, photos, graphics and more. Envato Elements starts at $16 per month, and is the best creative subscription we've ever seen.
Sass, Not SCSS
One little detail needs to be addressed before we dive into this any further. The syntax we’ll be using today is Sass, not SCSS. The latter of these is the newest form, so it’s likely the one that you’re most familiar with.
However, for the sake of comparison, Sass is actually much closer to Stylus than its sibling SCSS. While SCSS was an attempt to reign Sass back in and make the syntax more closely mirror CSS, Stylus follows the ways of the original Sass language in its abandonment of most structural syntax such as semicolons and curly braces.
Alas, this is not an article on the merits of Sass vs. SCSS though so I will refrain from waxing on about this topic. If you’re looking for a good discussion on this topic, check out “Sass vs. SCSS: Which Syntax is Better?” from The Sass Way. In general, just keep in mind that Sass and SCSS are largely the same feature wise, the only difference is how you write them.
Basic Syntax
Let’s start with a direct comparison of both syntaxes at their most basic level. We’ll write the same declaration both languages and see where the differences lie.
As you can see, they’re almost identical. Neither syntax requires curly brackets or semicolons, which of course means that they both are fairly dependent on whitespace for proper compiling. The big difference that we see at this point is with colons: Sass requires them, Stylus doesn’t.
Flexibility
One thing that I’ve always appreciated about LESS and SCSS is that I can still write plain old vanilla CSS within my stylesheet. These syntaxes are so close to CSS that you can pick and choose key points to implement their special features, but you don’t have to really retrain your brain to write CSS.
As far as I can tell, Sass doesn’t have this ability but Stylus apparently does (demonstrated here). However, I use CodeKit to compile my Stylus, which doesn’t let me mix pure CSS with Sass or Stylus. If I throw a simple line of pure CSS at either, the code won’t compile (both languages have error reporting).
That being said, there is a little bit of flexibility with Stylus and Codekit that you won’t find in Sass. For instance, Stylus does not require the use of colons or semicolons, but it allows for both to be used. It simply doesn’t like curly brackets. Sass on the other hand, required colons and will not compile if you use semicolons.
Basic Syntax Winner: Stylus
If you’re going to use a stripped down preprocessor syntax, Stylus is the better of the two in my opinion. The simple answer is that Stylus allows you to choose your level of verbosity while Sass forces you into a set method.
In all honesty, the very reason I’m declaring Stylus the winner here could make you consider it the loser. Flexible syntax is a dirty word with lots of coders because it can lead to sloppy, inconsistent coding. If you’re going to use Stylus, you should choose one method of declaration and stick to it. Don’t write two lines of code that uses only semicolons, then switch to tossing in colons, then switch again to using neither.
Nesting
Nesting allows you to save yourself some repetitive coding by nesting selectors within one another. So when a “p” selector is nested in a “div” selector, the compile result will be both “div” and “div p”. This functionality is nearly identical in Stylus and Sass.
Sass actually takes the concept of nesting one step further and allows you to save yourself the trouble of typing repetitive property names. For instance, consider the example below. In Stylus, you have to repeat the “font” part, but Sass allows for nesting as an alternate method.
Winner: Sass
The simple fact here is that Sass has a cool feature that Stylus doesn’t. I’ve never used it, and am not sure I’ll start now, but I can see how it would be useful, especially in cases like text-align, text-shadow, text-decoration, etc. where no shorthand alternative exists.
Variables
One of the biggest draws to preprocessors is the inclusion of variables. Many old school developers think that that variables have no business anywhere near CSS, but countless others think that variables are one of the coolest possibilities to ever hit CSS. I personally find CSS variables to be immensely useful.
Both Stylus and Sass include variable support. Here’s what each looks like using a variable to declare the font-size on a paragraph.
Once again we see that the Stylus syntax was is a little more succinct. Notice how Sass requires the use of an extra character (the dollar sign) to reference variables. Stylus also takes the route of using an equality symbol instead of a colon, which should feel familiar to JavaScript developers.
Both languages also allow for variable operations, so you can add, subtract, multiply and divide variables to your heart’s content.
Winner: Draw (I prefer the Sass syntax)
Let’s get this straight, if we score everything purely on verbosity, Stylus is going to keep winning. It’s the briefer syntax, period. But the assumption that briefer is better isn’t always a correct one.
Interestingly enough, on a personal level, I think I prefer the Sass way here. The colon syntax just feels more like CSS. Also, people are so unaccustomed to seeing variables in their CSS that the dollar signs really help them stand out. I can easily scan through hundreds of lines of Sass and spot the variables, a task which is considerably more difficult with Stylus.
Property Lookup
While we’re on the topic of variables, it’s worth mentioning that Stylus has a unique “Property Lookup” feature that allows you to actually spare you some of the variables that you’d normally have to employ with Sass. For instance, let’s say you wanted to set the padding on an element to half its margin. With Sass, you have to use variables to accomplish this (as far as I can tell), but with Stylus you can use the “@” syntax to reference the value of another property within the same declaration block.
Winner: Stylus
Sass doesn’t even have an equivalent to the property lookup feature so this one is no contest. I personally really like having this ability and hope the Sass folks consider adding it in.
Mixins & Functions
Next up, we’ll take a look at mixins. These are sort of like variables for large chunks of code instead of a single property or value. Mixins are perhaps one of the most powerful tools that CSS preprocessors have as far as saving you time and energy. Knowing how to properly leverage mixins will make your job so much easier!
Here’s an example of the Stylus and Sass syntax on a typical border-radius definition. The benefit here is that you only have to write out all those browser prefixes once, then allow the preprocessor to work its magic anywhere else you implement them.
Again we see that Sass requires a bunch of extra symbols and syntax while Stylus keeps things pretty clean. Also Notice that Stylus has the option of utilizing something called “transparent mixins” where you don’t even need to use parentheses when you call the mixin. It looks like I’m just using the default border-radius property when in fact I’m utilizing my mixin.
Functions are a similar construct, only they are typically meant to perform an operation and return a value. Here’s the function syntax for each language:
Winner: Stylus
After writing out the mixin and functions with Stylus, then reverting to Sass, the latter just seemed like so much more work. The Stylus way is really effortless while Sass has you constantly writing out “@mixin”, “@include”, “@function” and “@return”, which feels superfluous.
The Meat of The Argument: Which Is Better?
I’m not the first to do a straight up comparison of examples like the one above, though I did intentionally go a step further than others by clearly declaring my preference in each case.
In all honestly, both Sass and Stylus are far too huge for me to continue on this path of syntax comparison. There are lots more cases where you could find that Stylus and Sass are almost identical in their approaches. Here are some features that both share:
- Interpolation
- Selector Inheritance Through @extend
- If and else style conditionals (control directives)
- Built-in color functions
- Iteration
- Import directives
You should have a feel for how each language works now, so let’s move onto some pure discussion on where they differ and why that’s important. One thing to think about right away is that Stylus is specifically built to partner with Node.js, so if your’e a Node fan, this might be the way to go.
For the most part, it seems that Stylus is the more flexible and even more powerful option. There are a few cases where Sass pulls off a trick that Stylus can’t, but I haven’t come across a “Stylus killer” feature that would make me clearly state that Sass is the best.
Conversely, there seem to be tons of little things that you find when digging into Stylus that you miss when you switch back to Sass. I’ve mentioned a few already such as the property lookup feature, another interesting one is the “arguments” automatic local variable for mixins, which allows you to skip the step of creating your own variable to duplicate all of the arguments from a mixin. There’s also the rest params feature that consumes the remaining arguments passed to a mixin or function (this feature might be in Sass, but I haven’t found it):
box-shadow(args...) -webkit-box-shadow args -moz-box-shadow args box-shadow args #login box-shadow 1px 2px 5px #eee
Finally, Stylus also takes a lot of the pain out of media queries, which are a bit bulky and awkward with all those brackets. Here’s a Stylus print media query:
@media print
#footer
display none
What About SCSS?
My actual preferred every day preprocessor is Sass with the SCSS syntax. Until writing this article, I hadn’t experimented much with any of the stripped down syntaxes because I found it to be a little scary to throw away all of the rules that I had so ingrained into my brain.
Further, I like the idea of something just plugging into my current CSS workflow rather than trying to completely change it from the ground up. That being said, I’ve quickly adapted to the Stylus way of doing things and don’t mind it as much as I thought I would. It’s pretty nice to ditch those colons!
Let’s say though that you just can’t get used to it or think that it’s a bad practice to use a stripped syntax because it’ll make you forget how to write proper CSS, in this case SCSS is the way to go right? Perhaps not. As long as you’re using the command line or a better compiler than CodeKit, Stylus lets you adopt the “CSS style” of syntax, meaning that you can take advantage of all of the goodies found in Stylus without accepting the scary minimal method of CSS authoring.
What About Compass?
One absolutely fundamental piece of this puzzle is Compass, which takes Sass to new heights of awesomeness. Obviously, if you depend on this tool, then switching to Stylus is going to be a lot more difficult. However, there is a closely related project called Nib that attempts to bring some similar CSS3 goodness to Stylus.
Conclusion
It pains me to say it but Stylus really does seem to have the upper hand in many regards. It has the benefit of learning from and improving upon what was done with Sass, and comes out better for it. That being said, I’m probably not going to give up SCSS any time soon. I believe in the Sass project and am confident that its widespread adoption will continue to bring about lots of improvement. I’m not sure I have the same faith in Stylus.
Leave a comment below and let us know what you think. Which preprocessor do you think is better and why? Regardless of which has more tricks up its sleeve, which one will you use in the long run?