January 20, 2016
I just spent about 3 hours last night researching LESS/SASS methodologies, playing around with mixins and variables, checking out usage examples, and reading various arguments for and against one or the other. This is on top of the aggregate 5 hours or so I’ve spent reading or thinking about such a thing in the past and otherwise not doing anything more productive.
Front-end development makes up a large part of my personal technical skill set. As Priceless Misc grows and projects increase in scope, more and more of the technical aspects of this work gets passed on to other developers, and with that comes a bit of detachment from the day-to-day best practices. Lately, though, I’ve been making time to play some catch-up, and one thing that has always been conceptually appealing but never made its way into my personal practice is the use of CSS preprocessors.
I don’t care about simplified syntax though, or nesting, or selector inheritance. CSS is easy enough already, and I use Espresso and a healthy selection of programmatic text snippets to quickly create selectors, and generate the more verbose and browser-specific styles I need.
And CSS variables are a nice idea for broadly applying related design characteristics throughout a site, but not strictly essential if your markup is structured somewhat sensibly and hierarchically to begin with.
This is all stuff to just make the act of writing CSS faster, not inherently more powerful. So in my case, I use other techniques to speed up my coding that I prefer over these preprocessors, at least for the most part.
But that kind of functionality only makes up at most 10% of what a CSS preprocessor is commonly used for, while the other 90% is (supposedly) for saving time and simplifying the coding process.
When you factor in all the time spent becoming proficient in these, reconfiguring your workflow to incorporate them, getting your clients and freelance developers bought in and integrated, actually building the preprocessor-specific logic, and then the extra care needed to reverse-engineer the preprocessor-generated CSS during testing, I seriously doubt most people using them are actually saving much if any net time.
Not to mention most of this functionality will likely find its way into the core CSS spec soon enough, leaving the preprocessors out to dry. It’s not exactly building on solid ground.
Maybe preprocessors will continue to stay one step ahead. Maybe this is the realm of the earliest of adopters (there’s nothing wrong in that) and I’m just missing the point. Maybe it’s better suited to an internal team managing a single product or suite of products, and not to a shop providing client services on a wide range and variety of products.
But for something that’s touted as a time-saving and simplifying approach, I see it as the opposite. Organization for organization’s sake.
I’m sure I’ll use them in the future on a case-by-case basis for their computational ability. A couple of our projects right now actually already use a bit of LESS. But as for integrating CSS preprocessors into our baseline workflow, for now at least, it’s just not a smart use of time or energy.
Make that another half-hour or so for writing this post, by the way.
Am I wrong?