A year with PostCSS
So long, farewell, auf wiedersehen, goodbye
Sass, it’s been a hell of a ride, I like you. It’s just… too complicated. I found a new processor and we’re fine. We like each other. It is lighter, easier, flexible and so much more. I can even choose everything I want. Goodbye, I wish you all the happiness in the world.
A new hope
It’s been a year since our team in Mono is actively using PostCSS. It was a difficult transition. From Sass into the unknown.
We had many questions in our heads:
Can we replace all necessary Sass functionalities with PostCSS plugins? What about grid system, typography, Compass, etc.
We knew that we must step into the unknown and deal with it on the go. PostCSS was luring us with its freedom, independence, and ability to develop our way of the development environment.
Back to the future
We dissected all things we need and want from a processor. We loved nesting — it helps us writing more clearer, and it’s ideal for BEM. We loved variables —they assist us in writing more consistently media queries, color scheme, typography and much much more. We loved mixins — great solution for DRY approach.
Some more tools/plugins in our build:
We wanted to reduce Sass syntax, its functions, and produce a cleaner CSS code in our source files. Extends, mixins, functions, etc. — at the end, it’s all CSS.
I hate this baseline…
For typography, we rewrote our “old companion” Typomatic (developed by our friend and ex. colleague Andrej) with a little math, variable, and mixins to create a vertical rhythm and type scale. It’s not perfect, but it serves it’s purpose well. It is just 28 LOC with comments :)
Oh yes.. the GRID
Well, to be honest grid was our greatest concern. We had this beautiful thing called Susy, and we didn’t know how to let it go. I know that there’s this excellent lost, neat and flexbox, but neither of them can support some old browsers we need. And clients just looove ❤ Android 4.4, 4.4.3 and 4.4.4 browser. Many of the new grids are using calc, and this version of Android browsers lack the ability to multiply and divide values in calc(). So, that was shitty. If anyone has a solution, please write back!
So, again, we went with “our” solution. It’s similar to many existing grids we just tweaked ours to fit our needs. A simple custom grid based on vars, mixins and multiple classes for responsiveness.
Example of grid usage:
<div class"col col-sml-12 col-med-9 col-lrg-6">Content</div>
Our setup is based on gulp, and it is simple for configuration. You just kick in plugins you want to use and configure their options in PostCSS gulp task. The best part of PostCSS is their plugins ecosystem. It’s so diverse and adjustable, and it fits all your needs. And on top of that, you can easily write your plugins. Yes, there’s a repo with boilerplate.
Consider that Libsass has 21 300* LOC. That’s a lot of lines.
I mostly use few plugins, and this is their LOC:
- postcss-simple-vars — 122 LOC *
- postcss-nested — 88 LOC *
- postcss-mixins — 174 LOC *
We all love those numbers, so here it comes — PostCSS Benchmarks:
PostCSS: 40 ms
libsass: 77 ms (1.9 times slower)
Rework: 87 ms (2.2 times slower)
Less: 159 ms (4.0 times slower)
Stylus: 224 ms (5.7 times slower)
Stylecow: 232 ms (5.9 times slower)
Ruby Sass: 872 ms (22.0 times slower)
*lower numbers are better
It’s still a wild year
It’s never peaceful with PostCSS, thankfully. Its constant evolution, upgrades, new plugins, and community are what makes it a great tool for all frontend developers, whether working on a small or large scale projects.
We love PostCSS with all its flaws and advantages. It will remain our tool of choice as long as it provides freedom and modularity in its system.
It transforms your code into gold; you just have to create a perfect formula to get the 24K gold.