I’ve been hanging out on the outskirts of the ‘preprocessor wars’ for the last two years. I got sucked in around 2012/13 but I pulled out pretty suddenly after that. I’ve tried both Less and Sass on actual projects from scratch and dabbled in a few others (Stylus and Myth). Out of the four, I found Sass to be the one I most ‘enjoyed’ writing, but it never really stuck. I was overcomplicating a task that was already incredibly simple. Additionally, I didn’t feel right writing code that required a developer to know not only CSS but also the particular ‘flavour’ of CSS syntax I used.
My first website
I can open my very first website I ever built and still run it in my web browser, sure, the blink tag doesn’t work anymore, but that red background with blue text sure does look mighty fine.
After having my eyes destroyed by my 1999 visual torture machine by a simple glance at my computer screen, I decide to edit the html file (that’s right, 50 lines of inline css baby, or as Google calls it “Performance Optimisation“). I go in, change my red background to white and my text colour to black, save file and reload the page. My eyes scream a cry of relief.
The point being that the website is still editable today without any preprocessors or the like. Now I’m not one for getting hung up on the past, sometimes you just need to pull the plug (www.dpgraph.com). The stylesheet language of CSS Preprocessors are not standards compliant, they are not even a standard and hence will not stand the test of time in an environment where open standards are continuing to make real headway. Yes, I understand that this is just the source file and not the file served to the end user, but that’s exactly my point. It’s the developers who will be editing these files down the track. The last thing they would want to be doing is having to convert your Sass / Less / Jive / More into normal CSS before they can make changes (if only Jive / More were CSS preprocessors. I joke, we don’t need any more than we already have). It should also be noted, browser vendors, such as Google Chrome, are adding support for inline editing in the browser for preprocessor files.
Let me be clear, I’m not against preprocessors as a concept, I raise issue with the source stylesheet language that you as a developer write to generate your final CSS file.
I think the early days of CSS preprocessors opened our eyes to the additions / improvements (depends who you talk to) for CSS as a stylesheet language. However, since then, it’s got slightly out of hand.
Here is a (incomplete) list of CSS preprocessors currently available:
That’s going to be fun in 5 years time.
Where I see things for the short-term future is CSS postprocessors, in particularly cssnext. Which will then be superseded by then ‘normal standards-compliant’ CSS. I’m not going to bore you with all the particulars of the language, you can read about it yourself. Sufficed to say, it is super easy to learn and takes a lot of the best bits of other CSS preprocessor languages.
cssnext (part of the PostCSS environment) allows for you to write your stylesheets in a standards (albeit draft) compliant fashion and then down mix it into CSS that can be read by web browsers of today. Seems like a pretty nifty idea? Everyone wins: present Marty McFly; future Marty McFly; well, not past Marty McFly, but he had blink tags so he still wins.
It’s able to be integrated into your gulp / grunt / yeoman workflow so there isn’t a major disruption to how you do things.
Issues
- It’s a draft standard: Yeah, it is. It’s not final but at least you’re on the right path. Things will no doubt change, but the same can be said for other CSS stylesheet languages.
- Syntax not supported in my dev tools of choice. This is a big one for me and very frustrating. I use Intellij (IDEA / PHPStorm) and syntax for future draft CSS isn’t yet supported. This sucks, and is a big sticking point for me at the moment. For those using Intellij you can trick it into thinking your CSS files are SASS files to get partial syntax highlighting, but it’s not great.
- Migration from a CSS preprocessor language. Depending on which language you use the migration curve shouldn’t be too bad, it realistically should be easier than going from native CSS.
Final Thoughts
I would probably cautiously pick cssnext if:
- You’re developing a new project from scratch and,
- You’re confident writing it without syntax highlighting support. I can live without syntax support, if anything, it makes you double check your work and ensure you’ve written the correct code.
I wouldn’t move to cssnext on existing projects at this point in time or in teams greater than 2 or 3, as it’s simply too new and as previously noted, support in editors doesn’t really exist yet which can cause headaches for some people.
Feature image by chris.alcoran used under the following Creative Commons license.
The Author
