Pardon my French about CSS Pre-Processors

What Are You REALLY Saving?

I do not use pre-processors.  I am not a fan of SASS or LESS.  That in itself may mark me as a pariah in the front-end web development community, since it’s almost an unspoken decree that SASS and LESS are the only ways to train the next generation of web developers.  I’ve looked at both SASS and LESS when they first hit the scene, learned them, and have walked away with the conclusion that they aren’t for me.

What is a CSS Pre-Processor?

Whenever you load a website, several things always happen.

  1. The browser reads the direct HTML provided.
  2. The browser then reads any and all CSS attached, be it inlined or in it’s own CSS file, and uses that information to start styling the HTML.
  3. The browser then reads any and all javascript attached, be inlined or in it’s own .js file, and uses that information to start writing to the HTML.

Regardless of whatever you do beforehand, these three things always occur.  The Browser will always read only three languages: CSS, HTML, and Javascript.  SASS and LESS are CSS-Like languages created that follow the same basic syntax of CSS, but with added features in the syntax.   There’s an easier way to explain this:

Imagine CSS is Latin.  For the sake of this example, the browser understands only Latin.  Now imagine SASS is French.  SASS, like French, is derived from Latin, but it is not Latin.  It shares lots of things with Latin; the most notable being a common alphabet and some base grammar rules.  But, if you speak French to a Roman at around 100AD, they would not understand you.   This example is a bit extreme, since the overall syntax of SASS is nearly the same as CSS, save for variables, nesting, and extensions.

  1. Variables in SASS are much like variables in any programming language.  You set a variable, like $main-font to be something, like arial, sans-serif.  This way, every time you want to call the main font family, you just insert $main-font into the font-family declaration.
  2. Nesting in SASS is basically a way to write styles for children of a parent object by implying the child/parent relationship with a tab versus writing the parent name.
  3. Extensions is basically making an entire style block a variable that you can insert multiple times in a document, but declare only once.

The Downside to Pre-Processors

Now, while these things do sound nice, let’s talk about the downsides to using SASS.  The first being, as I said, the browser can never ever be able to read SASS files, much less interpret them as CSS.   As I said, it would be like speaking French to a Latin-speaker.  You would need to pre-translate the SASS into CSS.   Lots of tools exist that compile and create a CSS file for SASS file changes, but most of these tools are paid tools.   You can also do this server-side, if you are willing to install RUBY.

This is the part where the advantages of a Pre-Processor starts looking less glamorous and more cumbersome.  Specialized tools?  Installing a whole other server-side language on your environment just to interpret a front-end language?  Isn’t the purpose of tools to make our lives easier, not harder?   That’s not to mention that, as the CSS spec itself matures and changes, the features of SASS that made itself useful are becoming parts of the CSS spec itself, albeit in it’s own way.

CSS has announced variables becoming a part of the language for some time now, and with the pace of browser updates, it will be rather soon that we can adopt this standard.  What’s more is, CSS variables are in a very different syntax than SASS variables.  Why learn two different standards of writing something?  Also, the SASS language syntax and it’s similarity to CSS might seem like a strength, in reality it’s also it’s greatest hindrance.  I have worked with several other developers in my career, and I have seen times when a front-end dev pops into a CSS file to make a quick fix and accidentally throws a mixin into a CSS file.  The languages being too similar invites this sort of accident into happening.

Also, let’s say that you need to make a quick CSS change to an existing site, and you’re away from your usual toolset.  If the site was built on Vanilla CSS, all you need is an FTP client and a text editor.  IF you’re using a pre-processor, you can certainly make that quick fix with the same tools, but you would then need to make an edit to your SASS file and CSS file, or just the CSS file and note to yourself what the change is so you can make it in your SASS file, thus creating what is known as a maintenance nightmare.

And What They’re Taught in School

I was working as Lead Developer at a shop, and we were interviewing several front-end devs for an open position.  We gave the applicant a working interview(meaning he was paid for his time and effort); a simple project with a designed PSD file and told to do front-end development ONLY.  I remember this gentleman well because he was a recent college grad, and had some very peculiar habits that bugged me; habits I learned are taught to pretty much every web developer now.

This gentleman spent a good 3 hours setting up his environment to develop, including wrestling with a bower.js file.  Twice during this painful process, I told him that he needn’t bother with this; this is a front-end only examination.  He has the PSD file, he had an HTML editor; he didn’t need anything else.  He disagreed; he felt that it was more important he got his environment set up perfectly; his SASS working and compiling versus writing HTML and CSS to pass an employment test.  And this wasn’t the first time.  Every time I meet a young developer who just graduated or just finished an internship, they are always busy with every project setting up an elaborate environment, getting SASS and pre-processing working.

Getting their environment perfect seems to be more important to teach than teaching CSS nowadays, it seems.  Out of 5 young devs I’ve met, 3 didn’t know what the box-model was.  4 of them didn’t know what the checkbox hack was.  2 didn’t know how to vertically center an object without display: table.  But, ask them to set up a SASS environment, and all 5 could probably do that.

In Closing

CSS is a very mature and powerful markup language.  Could it benefit from variables?  Absolutely.  Is SASS the end-all, be-all that teachers try to preach it to be?  Most certainly not.  Does it speed up development?  In MY case? No, I write Vanilla CSS faster than those 5 young devs writing SASS.  Your own cases may vary, but all I ask is that you look at the scope of your next project before you decide that it warrants SASS and maybe… just maybe…. tinker with some good old Vanilla CSS and expand your knowledge on some of the newer things you can do, like with nth-child, flexbox, or even calc before you run on over to SASS.