Why I Choose Stylus (And You Should Too)

The world of front end web development has been steadily increasing its uptake of what we call "CSS Preprocessors", which extend the functionality of regular CSS. Arguably the two most well known, with the greatest user base, are LESS and Sass/SCSS. However there is a third preprocessor that hasn't received quite as much attention, and that's Stylus.

Today we'll be discussing why Stylus is awesome, why I choose it, and why it might just become your new CSS hero.

Why LESS and Sass Are Awesome

Before we get into the specifics of how Stylus works, I'm going to start with my own take on the predominant strengths of LESS and Sass / SCSS, and why I choose neither even though they both rock.

All Three Rock

Each of the three preprocessors include the use of variables, mixins, nesting and extending, along with varying degrees of logical operations and functions. So all three are the same, in that they let you abstract key design elements, use logic and write less code, which makes all of them able to give you great gains over raw CSS when used well.

However, with all three being the same in this basic sense, it's the ways they are different that will ultimately lead to your choice on which to use.

LESS: Other Reasons It's Great

To me, the greatest strength outside of the aspects common to all three preprocessors is the community around LESS and the offerings created by them.

The most well known project incorporating LESS is the Twitter Bootstrap framework, and my guess is the desire to work with it is a big part of what leads many people in turn to LESS.

Another stand out is the LESShat mixin library, which provides an excellent array of mixins for CSS3 effects and more, and its partner the CSShat plugin for Photoshop, which generates copy & paste LESS code from PSD elements. In particular these two items in tandem create a very powerful workflow which is fantastic if you do a lot of your design process within Photoshop.

And one more big plus for LESS is the fact that most people find it quite accessible to use. You can use a simple JavaScript file to compile it on the fly, you can use an IDE with in-built compilation like CrunchApp (or CodeKit on Mac only), or you can use Node.js on your local machine for a more robust / flexible compiling solution.

LESS: Why I Still Don't Use It

I always prefer my own code over third party frameworks, and I also tend to do minimal Photoshop design these days, preferring to design dynamically in the browser as much as possible. (CSSHat can output in multiple languages too). So for me, as great as the projects I described are, they alone aren't enough to compel me to choose LESS as my go-to preprocessor.

But the biggest reason I don't use LESS is actually the significant gulf in available logic processing features between it and the other two major preprocessors.

Unfortunately, the fewer logic-based features that are available for use, the less we're able to create minimal, clean code, and the slower development and subsequent modification will be.

LESS does allow for some logic, but it is really quite limiting compared to Stylus and Sass / SCSS. You'll see why in my description of what's awesome about Sass.

Sass: Other Reasons It's Great and Powerful

Sass also has a great community with many great projects available to use. Where LESS has Twitter Bootstrap, Sass has frameworks like Gumby and Foundation. Where LESS has LESShat, Sass has mixin libraries like Compass and Bourbon.

However, where it really comes into its own compared with LESS is its powerful ability to handle logic. Where LESS is what you might call enhanced CSS, Sass behaves much more like a complete programming language.

For example, Sass lets you create efficiently written conditional checks, which is particularly useful within mixins.

This mixin checks to see if $border_on is set to true, and if so it uses the $border_color value in the output for the border property. If not, it falls back on setting the border property to 0.

It then also checks to see if $bg_on is set to true, and if so it uses the $bg_color value in the output for the background-color property. If not, it sets the background-color property to transparent

This means that, depending on the values passed, up to four different types of output could be generated from a single mixin, i.e. border and background both on, border and background both off, border on and background off, border off and background on.

However in LESS there are no "if / else" checks, so the above would not be possible. The most you can do with LESS is use what is called "Guarded Mixins", where a given mixin is output differently based on a check against a single expression.

So your mixin could check if the @border_on parameter was set to true like so:

However because it's missing "if / else" functionality it neither has the ability to subsequently check the value of @bg_on, nor to give an alternative value for the border property within the same mixin.

In order to achieve the same logic that was handled with a single Sass mixin, you would need to create four different guarded mixins with LESS, i.e. one for each of the possible combinations of @border_on and @bg_on values, like so:

And that's just with two values to check; the number increases with every value on which you want to run logic, which can become very unwieldy as you want to create more sophisticated mixins. It's also an arduous process to consider all the possible permutations of variable combinations in order to account for them all.

That's just one example of where enhanced logic makes life much easier with Sass vs. LESS, but there are many more. Notably, Sass also offers excellent iteration abilities through its @for, @each and @while directives.

And finally, very importantly, while LESS has some excellent in-built functions, Sass makes it very easy to write your own. They're simply written as:

These logical functions open up a world of possibility for things like creating your own layout engines, px to em handling, color modifiers, and shortcuts for an infinite number of things you might find yourself needing from project to project.

From everything I've read and heard people chatting about, and from my own experience, it's this greatly enhanced logical power that is the main driver for people choosing Sass over LESS.

Sass: Why I Don't Use It Even Though It's Amazing

With LESS ruled out for most projects due to its limited logical operations, it comes down to a choice between Sass and Stylus, both of which have a powerful array of features available.

And between the two, I choose Stylus. Stylus has the power of Sass, with the accessibility of LESS.

Stylus.js does everything I need that Sass does, but it only requires JavaScript or Node.js to compile. Plus, it has a particular way of operating that is smooth and easy to work with, and it has a beautiful clean syntax that I prefer.

For me, the requirement to run Ruby on Rails and deal with gems is a major roadblock to wanting to work with Sass. Ruby isn't a part of any of the projects I develop, so the only reason I ever have to deal with installing it and any gems is solely to handle Sass. That's a set of connection errors and installation issues I don't need if I can avoid it.

I suspect many other people are also in the same boat of not otherwise using Ruby, and not especially wanting to in order to use a CSS preprocessor.

Additionally, even though I need to install Ruby in order to use Sass, I still find myself needing to work with Node.js and NPM in order to use Grunt to handle other aspects of my projects, such as watching for changes, combining and minifying JavaScript and so on, as well as Bower for other package management.

Note: there is a program called Scout for Mac and Windows that will handle compilation for you, but again where possible I prefer to avoid installing something for a single purpose only, rather than working with tools I can use for multiple purposes. There is also CodeKit, but that's Mac only.

So when there's a preprocessor like Stylus that has all the logical power I need, but can be used easily with my preferred IDE and existing Node.js setup or pure JavaScript, it just makes sense to choose it.

Many people find the setup process for Sass intimidating because of the Ruby factor and choose LESS for that reason. However I find that the ease of setup for Stylus is essentially on par with LESS, while giving me the full gamut of logical functionality.

But it's not just about Ruby, or even just the logical functionality available. It's also about the specific way Stylus works and the syntax it uses, which I find to be incredibly clean, flexible and smooth in comparison to both LESS and Sass.

So now, let me tell you why I choose Stylus, and why it might be your new CSS hero.

Why I Choose Stylus

As I've touched on above, I choose Stylus for its:

Powerful logical functionality

Ability to run via Node.js / JavaScript, (no Ruby)

Ability to run as part of the Node.js setup I'd have anyway in order to use Grunt and Bower.

Clean and minimal yet flexible syntax

A general smoothness in the way Stylus approaches its various features

To really show you why all of the above make me choose Stylus, we need to jump in and start using it a little so I can show you exactly what I'm talking about.

Let's start with the biggest hurdle people run into with CSS preprocessors, whichever one they choose, and that's setup and compilation.

A big part of why I choose Stylus is that I can set it up as part of my regular project creation methods, and through that I can use it with my preferred IDE. Let me show you how.

Stylus Setup and Compilation

Yes, there are some command line processes that are involved, however take it from someone who'd never used command line for a thing before preprocessors required it - it's nowhere near as difficult as you think, and using the command line will make you feel ten percent smarter than you did before. :)

That said, I've put together a package, which you can grab by hitting the "Download" button at the top of this article, which will mean you'll barely have to think about the command line if you're on Windows. Just a few double clicks and you'll be up and running.

If you're on Mac or Linux, fear not, as there are only three commands you'll have to run to use the package, I'll walk you through how, and they're super easy.

This package will watch your source Stylus files for changes, and it will compile them into CSS files for you. You can use it with any IDE you want, which is a big perk of this particular approach.

For me personally, it's the epically awesome Sublime Text 2. It's also the IDE I recommend for using with Stylus due to the excellent Stylus syntax highlight package available for it, which I'll cover below.

Step 1: Install Node.js

Node.js is pretty much a must have these days for front end web development. There are so many amazing tools that work on top of it, so installing will get you established not just for Stylus but for plenty of other things too.

Run the installer as you would any other to put Node.js onto your system.

Step 2: Install Grunt

Grunt is an incredible tool for running JavaScript tasks. You can use it for over two thousand different purposes via its plugins, listed here: http://gruntjs.com/plugins

In our case, we're going to be using it to watch our Stylus files and compile them into CSS whenever they change.

Prepare for your first taste of command line, so open up a command window / terminal.

On Windows I find the easiest way is just to open up Windows Explorer, then inside any folder hold down the SHIFT key and right-click. In the context menu you'll then see "Open command window here", which you should click:

Alternatively you can click the "Start" button, then search for "cmd" and press ENTER to bring up the command window.

Wait until that all finishes and a new command prompt appears. That will mean the installation is complete, and you can then close the command window / terminal. You only need to do this once as it will install Grunt on your system with global access so you can use it from any future project folder you setup.

Now you're ready to setup an actual project using the StylusCompiler package I've provided. This is the process you'll repeat for each new design project you begin.

A Stylus Project

Let's take this step by step.

Step 1: Setup a Project Folder

Create a folder to house your project. For this demo, we'll just call it EGProject.

Inside that, create a second folder named css. This is the folder your CSS files will be written into.

Now extract the StylusCompiler.zip file into this folder.

You should end up with a structure that looks like this:

Step 2: Install StylusCompiler

Go into the StylusCompiler folder and, if you're on Windows, double-click the file named double_click_to_install.bat.

If you're not on Windows, open up a terminal in the StylusCompiler folder, (or open a terminal and then navigate / cd to the folder). Type the following then press ENTER:

npm install

This will install the compiler inside your project folder. Again you'll see a bunch of stuff like this come up in the window:
If you're on Windows and double-clicked the .bat file, the window will close once the installation has completed.
If not, wait till the text stops moving and a new command prompt appears. Keep your terminal open for the next step.

Step 3: Aaaaaand Engage!

Now all you need to do is initiate the "watch" function the project has you setup to use via Grunt.
This will watch the stylus folder inside the StylusCompiler folder for changes to any .styl files within it.

Just create all the Stylus files you need in that stylus folder and you're good to go.
Note: All your Stylus files must have the .styl file extension.
When changes are saved to any files in that folder, the package will then compile your Stylus code into CSS, and write it into a file named style.css in the css folder of your project.
Still in the StylusCompiler folder, if you're on Windows, double-click the file named watch_and_compile.bat.

If you're not on Windows, with your terminal still in the StylusCompiler folder, type the following then press ENTER:

grunt watch

You should see this in the command window / terminal:

Now if you save changes to any file in the StylusCompiler > stylus folder, (as long as you haven't made any mistakes in your code), you'll see the following:

When you're done working on your Stylus files you can just close the command window / terminal, or if you need to run another command, you can press CTRL + C to stop the "watch" task.

Optional Steps

Changing Project Options

One of the reasons I love working with this type of project setup is you're in complete control, so you can set your project up however you like it, and change at any time. If you want to change things like the output folder for your css, the output file name, whether the CSS is compressed or not, and so on, you can do so in the file named Gruntfile.js in the StylusCompiler folder.

Set the compress option to true for production ready minified CSS, or to false for expanded CSS while you're still in development.

Line 27, set CSS output file name

The default filename that will be written to is "style.css". If you wish the file to be named something else, replace "style.css" with your choice on this line.

Line 32, CSS output location

By default the compiler will look up one level from the StylusCompiler folder, and write into the css folder therein.

If you want your CSS files to be written somewhere else, change the value on this line from '../css' to your preferred location.

Working With Sublime Text 2 and Stylus

As I mentioned above, the beauty of this approach is you can use any IDE at all to edit your Stylus files and they'll compile just the same. However I strongly recommend using Sublime Text 2 as the Stylus syntax highlighting package available for it makes working with Stylus a delight.

Finally, install the Stylus syntax highlight package. Open up Package Control by going to Preferences > Package Control like so:

In the list that appears, click the "Install Package" option, and wait a few seconds while a list of available packages is retrieved:

Type "stylus" in the field above the list of packages in order to search for it, then click the result titled "Stylus" in order to install it:

This package will now turn tricky to read, regular CSS formatting like this:

…into easily differentiated Stylus formatted code like this:

Stylus Syntax

One of the things I absolutely LOVE about Stylus is its total flexibility on syntax.

With LESS, all code must be written in the same way you would write regular CSS, i.e. you must include curly braces, colons and semicolons in the same way you would in CSS.

With Sass / SCSS you have a choice:

You can set a compilation option in your project to use SCSS syntax, in which case you write as you would regular CSS, or...

You can choose the Sass syntax, in which case you can omit curly braces and semicolons in favor of using tab indentations and new lines, but you won't be able to use regular CSS syntax in the same file.

Stylus on the other hand is totally flexible, and you don't have to set any compilation options to handle the way you want to write.

You can write in regular CSS syntax with curly brackets and the works if that's how you feel comfortable.

Or, you can drop curly braces, colons and semicolons all together. Where curly braces would normally be, a tab indentation is used instead. Where a semicolon would normally be, a new line is used. And where a colon would normally be, a simple space does the job.

And, not only can you use either approach, but you can even combine them in the same file.

All these examples will compile in Stylus, and the approaches to syntax can be used together in the same document:

Only Stylus allows omission of all these syntax elements, to varying degrees, and the 'on the fly' combination of these approaches so you can do whatever you feel like as your project moves along.

This functionality is amazing for development. You'll be surprised to find just how much greater your flow is when you omit all the syntax "punctuation" you can. Your coding and your thought process as you move along will become so much smoother. And with the syntax highlighting provided by the package we installed earlier, you'll find your code will be every bit as readable.

But at the same time compilation is very forgiving. If you decide for one reason or another that regular CSS syntax will make part of your document better organized you can go right ahead and use it whenever you want. And if you accidentally miss out a semicolon here or there, nobody minds.

Stylus Variables, Mixins, Conditionals and Functions

You saw above some examples of how variables, mixins, conditional checks and functions look in LESS and Sass. To my eye, I find the Stylus approach to these easier to look at, read, and work with in general.

In LESS, variables must be prepended with the @ symbol. In Sass, they must be prepended with the $ symbol. However in Stylus, a variable doesn't have to be prepended with anything at all.

Note: You can optionally use the $ symbol if you prefer, but not the @ symbol as this is reserved for other purposes in Stylus.

Similarly, mixins, conditional checks and functions needn't be prepended with anything in Stylus.

In LESS, a mixin must be written in the same way you would write a regular CSS class, and there are no conditional checks or custom functions.

In Sass, mixins must be prepended with @mixin and called with @include, conditional checks are written as @if and @else, and functions must be prepended with @function and include a line prepended with @return.

None of these things are required in Stylus. You can simply write naturally as you might in regular language. For example, earlier we used this example Sass mixin and function:

This to me is very neat, easy to read and write, and in-keeping with the preprocessor goal of making code clean and minimal.

Bear in mind also that while in the example above I have omitted all the syntax "punctuation" that can be left out, it's totally optional how much of it you want to leave out in your development.

For example, I have called the border_and_bg mixin seamlessly, writing it in essentially the same way I would a regular CSS property, with no brackets around the parameters or commas in between them. However if you prefer to you can include brackets and commas when you call mixins, it's completely up to you.

The Nib Mixin Library

One of the best things about working with Sass and LESS are the Compass / Bourbon and LESShat mixin libraries, respectively. But you won't miss out on an amazing library of mixins with Stylus, thanks to Nib.

The "StylusCompiler" package I provided you with automatically installs (thanks to grunt-contrib-stylus) and includes Nib in your project, so you don't have to take any further steps in order to use it.

Nib provides mixins for all the CSS3 effects you would expect, each of which can be called seamlessly as though using a regular CSS property. It also includes an impressive array of mixins for other functions like positioning, resetting / normalizing, clearfix-ing, responsive images and more.

Other Loveable Stylus Goodness

Stylus has loads of other awesome features, done in its own unique and super clean way, and you really should check out the whole lot here: http://learnboost.github.io/stylus/

However, there are a couple in particular that I really love.

Rest Parameters

Rest parameters allow you to pass an undetermined number of values to a mixin without having to explicitly map them out in the creation of the mixin. You can pull out a particular value, and then pass the "rest" by using args... and args. For example:

Property Lookup

Sometimes you might be repeating a certain value a couple of times, but only within a single style, so having to declare a variable to hold it can be overkill.

With the property lookup feature, you can lookup the value of any property you've declared in the same style or a parent style. For example:

All you have to do is use the @ symbol before the property you want to look up. Stylus will look first in the same style, and if it finds no match it will check the parent and continue to bubble up until it either gets a match or reaches the document root and returns "null".

Wrapping Up & Some Final Stylus Goodies

Hopefully now you feel ready to tackle setting up Stylus if you've been wary of command line before, and you're curious enough to investigate if you love the power of Sass but would prefer working with Node.js over Ruby. And even if neither of those two are particularly relevant to you, I hope you're intrigued enough by some of the unique approaches taken by Stylus to spin it up and have a play with it.

To wrap up, I'd like to leave you with a list of interesting Stylus related goodies for you to have a look through, some mentioned in the above, as well as some extras.