How to Revolutionize your Front-end Workflow

Recently, I have found a front-end workflow that revolutionizes the way I build websites and saves me hours of time a week. This workflow is the way of the future and an absolute game-changer for front-end developers who design. All you have to do is… drop your preprocessor and start writing pure CSS again.

This may seem counterintuitive. You may be thinking…

What is this guy talking about? Sass/LESS are like CSS on steroids. They let you output CSS by writing in a cleaner, more succinct fashion. On top of this, they give you a lot of awesome extra features like mixins, partials, and extends.

Over the last few years, I felt the same way about Sass/LESS. It has occurred to me, however, that the advantages in using these preprocessors are outweighed by the negative impacts they will have on your front-end workflow.

Note: This article is not going to propose a front-end workflow using PostCSS. Many are already switching from Sass and LESS to a PostCSS workflow. Ben Frain has published a very sad and emotional article about why he had to break up with Sass. While PostCSS is an improvement from Sass and LESS, it runs into a lot of the same problems. In this article, I propose a different workflow that makes only limited use of PostCSS.

First let’s talk about workflows. There is no such thing as the “perfect front-end workflow.” What may work for one person, may not work for another. The workflow that I propose is a “design-in-the-browser” workflow that’s greatest asset is its speed of development. The other major benefit is that, as with any design-in-the-browser workflow, this workflow allows the developer to make smart and precise design decisions as he or she can see his or her design update in real time. Ideally this workflow is for jobs where the design isn’t totally set-in-stone. If all you need to do is convert a mockup to code, you may not need a design-in-the-browser workflow (although it wouldn’t hurt).

Positives of Using Sass in Your Front-end Workflow

Let’s talk about what Sass offers its users. If you go to the official Sass documentation, you’ll see that the major features that Sass offers are:

1. Variables
2. Nesting
3. Partials
4. Imports
5. Mixins
6. Extends (Inheritance)
7. Functions (Operators)

That’s a lot of features! Unfortunately, every single one of them is either 1) unnecessary or 2) could be achieved with a simpler technology. Let’s go through them one-by-one:

Variables

Not everyone may be aware of this, but CSS already has variables. If you haven’t heard of them, that’s because browser support for CSS variables isn’t very good. Phillip Walton, an engineer at Google, explained in his blog that CSS variables aren’t an exact imitation of Sass variables, but in many ways are actually more powerful. “But if they aren’t well supported, what’s the point?” For the front-end workflow that I propose, we use CSS variables however we want in our development code, then use PostCSS – CSS Variables to convert all of our CSS variables into their static representations in our production code.

Nesting

Nesting was no doubt one of the coolest things about Sass when we first discovered it. Instead of writing:

.container {
    color: blue;
}

.container > ul {
    color: green;
}

.container > ul > li {
    color: yellow;
}

.container > ul > li > a {
    color: red;
}

we could write:

.container {
    color: blue;
    ul {
        color: green;
        li {
            color: yellow;
            a {
                color: red
            }
        }
    }
}

The second version of the code is nicer because 1) it quickly lets us identify the structure of the code 2) we don’t have to rewrite the parent selectors in the selector chain. Nesting has always been a user favorite. Here’s the problem… nesting only helps in cases where you are going to write some really bad CSS (such as the one above). The consensus among CSS professionals is that chaining selectors is very bad practice, since it couples CSS to the DOM. In Jonathan Snook’s Scalable and Modular CSS, he emphasizes that selectors should be as shallow as possible. Nesting, while really cool, is not a benefit that you should depend on. I believe it’s said that nesting two levels deep is as far as you should go.

Partials

Partials let you split up your Sass files into smaller files and join them together into one CSS file after processing. While you may find that splitting up files keeps you more organized… it can be easily accomplished using Grunt or Gulp’s Concat.

Imports

Like Partials, Grunt or Gulp can be used

Mixins

Mixins, for me, were the greatest thing since sliced bread when I first discovered them. I remember writing all these mixins that I thought would be of such great help. Unfortunately, mixins are really not very useful. The Sass website shows a few examples of using mixins. One involves defining a mixin for border radius:

@mixin border-radius($radius) {
  -webkit-border-radius: $radius;
     -moz-border-radius: $radius;
      -ms-border-radius: $radius;
          border-radius: $radius;
}

I’d bet most people who use Sass already know this particular use case isn’t important, since Grunt and Gulp’s autoprefixer will take care of this whole mess for you. Another example that the website provides, however, uses mixins to define clearfix:

@mixin clearfix {
  display: inline-block;
  &:after {
    content: ".";
    display: block;
    height: 0;
    clear: both;
    visibility: hidden;
  }
  * html & { height: 1px }
}

It wouldn’t surprise me if a lot of Sass users are doing this. I found using mixins this way to be troublesome. Let’s say I include this mixin on a div. Then later I try to define an :after pseudo element on the div. I run my code and see that it doesn’t work… This happens all the time using this mixin workflow, since writing @include clearfix isn’t explicit. Many people use mixins as a shortcut for rewriting commonly occurring code patterns. By doing this, they sacrifice explicitness in order to save time. Don’t do this! You will inevitably forget what is being defined on the element, and this will lead to problems down the road.

Instead, you should make clearfix it’s own class OR use a feature such as Sublime Text’s snippets. Mixins should NEVER be used for the sake of saving you time in writing repeated code. Sublime’s snippets accomplish everything mixins accomplish without obscuring the code.

Extends

Coming over from LESS, I immediately saw that the Sass community was very excited over extends. The community believed that by using extends… they would cut down on the size of their stylesheets and their sites would load faster. Eventually, the community came to the realization that because of the way that technologies like gzip work, extends don’t actually offer any performance benefits. Hugo Girauldo was once a big fan of extends, but has since changed his mind

Functions

Just because it’s cool, Sass offers its users functions that will allow you to perform any type of mathematical operation on your stylesheets that Albert Einstein could have thought of. You could even find the cosine of a value in your CSS! Unfortunately these are also very unnecessary. The only math you should ever need to do in your CSS is simple addition, subtraction, multiplication, or division. For this, we can use CSS’s calc(), and then use PostCSS – Calc to return the calculations in our production code.

Negatives of Using Sass in Your Front-end Workflow

So now that I have gone through why Sass is all frills, I will discuss how it actually prevents you from achieving a super awesome, kick-ass front-end workflow. The workflow that I propose involves writing CSS through Google Chrome… AKA “designing inside the browser.” Google Chrome’s web inspector has this awesome feature called Workspaces. This allows you to link a CSS file on your local machine to the browser through a source map. Now from the Elements panel in the web inspector, you can make live edits to your styles that will get updated in your CSS files.

Using the Chrome’s Elements Panel

A lot of people may be thinking… a very similar front-end workflow can be accomplished with Sass. Yes, this is true. One could make live edits to their Sass through Chrome’s Sources panel as opposed to editing the CSS straight from the Elements panel. This method involves finding the element in the Elements tab, right-clicking on its reference in a Sass file, making the changes from the Sources tab, and then saving the file. The problem is that this method is slower. How much slower? In terms of quantity, only a few seconds. In terms of rate… it may take about twice as long to make changes this way. That is “no bueno”.

Using the Chrome’s Sources Panel

One may typically make hundreds of changes to their CSS in an hour. Adding a few extra seconds to the time it takes to perform a small operation such as a simple CSS change will actually make a huge difference in the long run. Imagine if it took you just one extra second to take a step when you walk. It would probably take you about twice as long to get anywhere.

So as you can see, working with Sass prevents you from achieving this ideal design-in-the-browser workflow. There is really no way around this. For many people, design-in-the-browser is an amazing, game-changing workflow that will allow them to produce way better work than they ordinarily could through a text editor. If this is you, drop Sass!

That’s not it. There is still another HUGE benefit to using the Elements panel over the Sources panel and using CSS over Sass. The Elements panel allows one to increment numerical values by precise measurements and see the changes in real time! Let’s say you wanted to test font sizes from 1rem to 1.3rem for an element. Using the Sources panel, you would have to manually plug in values and see what looks the best. You might try 1rem… decide that it’s too small… try 1.3rem… decide that it is too big… and then split the difference and try 1.15rem. After an unnecessarily long process of guess-and-check, you eventually find a value that you think works. By doing things this way, however, you usually wind up settling. You may decide to go with 1.15rem, but maybe 1.18rem would have looked better, but you didn’t feel like testing it. Well the Elements panel has a way better solution. By clicking inside the value and pressing up-arrow or down-arrow, you can increment values up or down by 1. By pressing shift + up-arrow or shift + down-arrow, you can increment values up or down by 10. Perhaps best of all, you can increment values by .1 by pressing alt/option + up-arrow or alt/option + down-arrow.

Incrementing using Chrome’s Elements Panel

The Elements panel also lets you increment color values (which are still just numerical values after all). Perhaps even more useful, however, is Chrome’s color picker. First you define a color that you think would work. Then you can use the color picker to pinpoint which exact hue, saturation, and lightness values work best.

Using Chrome’s color picker in Elements Panel

No more are the days of settling for colors that are “good enough.”

As you can see, there are major speed benefits to this “Sass-less” design-in-the-browser workflow. I understand that the idea of dropping a preprocessor that you know and love may be a scary proposition. This article definitely goes against the grain in suggesting that Sass is no longer a necessary tool and is more trouble than it’s worth. To me, however, Sass is like these really awesome diamondesque paper weights:

They look awesome, you were so excited when you first got them… but at the end of the day they don’t do a whole lot. I was as big a preprocessor enthusiast as anyone when I began using LESS/Sass. After experimenting with many different technologies in order to find that “perfect front-end workflow,” however, I have reached the decision to drop the preprocessor.

Annotations

There is a Chrome Extension by Sergey Chikuyonok called LiveStyle that lets you modify your Sass from the Elements panel in Chrome. Sergey used a technique called source patching to accomplish this complex task. If you want to develop in the Elements panel and don’t want to drop Sass, you can use LiveStyle to accomplish this workflow. I did, however, run into a few problems while using LiveStyle with Sass. I was experiencing a bug that may have been related to my Sass code. Also, LiveStyle requires you to add all the partials that you want to edit, which can be time consuming.

In order to use this front-end workflow most effectively, you should define the classes that you intend to use in your text editor before editing them in the Elements panel. Now when you inspect the element, it will have a declaration that you can add styles to through the Elements panel.

The front-end workflow that I proposed lets you quickly adjust values and see them updated in real time both in the browser and in your stylesheets. These values include numerical values such as margins, paddings, font-sizes, etc., as well as color values. The only value you can’t quickly experiment with is the font value you provide the font-family property. To test fonts on your website, I recommend Google Font Previewer for Chrome and WebFonter. The Google Font Previewer is nice because you can use the up and down arrows to quickly test different Google Fonts. Unfortunately, although free, Google fonts typically range from poor quality to medium quality. WebFonter lets you test premium, high quality fonts on your website. The downside, however, is that WebFonter doesn’t currently let you quickly cycle through the fonts on your site.

Google is constantly improving their Developer Tools inside Chrome. At the time I’m writing this article, Chrome’s DevTools offers developers a front-end workflow that is much more powerful than coding solely through a text editor. Over time, however, Google plans to make DevTools even more powerful. Paul Bakaus, a Developer Advocate for DevTools at Google, covers the ways Google plans to make DevTools even more powerful. As you can see, developing in DevTools is the way of the future!