I just spent about 3 hours last night research­ing LESS/SASS method­olo­gies, play­ing around with mix­ins and vari­ables, check­ing out usage exam­ples, and read­ing var­i­ous argu­ments for and against one or the oth­er. This is on top of the aggre­gate 5 hours or so I’ve spent read­ing or think­ing about such a thing in the past and oth­er­wise not doing any­thing more pro­duc­tive.

Front-end devel­op­ment makes up a large part of my per­son­al tech­ni­cal skill set. As Price­less Misc grows and projects increase in scope, more and more of the tech­ni­cal aspects of this work gets passed on to oth­er devel­op­ers, and with that comes a bit of detach­ment from the day-to-day best prac­tices. Late­ly, though, I’ve been mak­ing time to play some catch-up, and one thing that has always been con­cep­tu­al­ly appeal­ing but nev­er made its way into my per­son­al prac­tice is the use of CSS pre­proces­sors.

I don’t care about sim­pli­fied syn­tax though, or nest­ing, or selec­tor inher­i­tance. CSS is easy enough already, and I use Espres­so and a healthy selec­tion of pro­gram­mat­ic text snip­pets to quick­ly cre­ate selec­tors, and gen­er­ate the more ver­bose and brows­er-spe­cif­ic styles I need.

And CSS vari­ables are a nice idea for broad­ly apply­ing relat­ed design char­ac­ter­is­tics through­out a site, but not strict­ly essen­tial if your markup is struc­tured some­what sen­si­bly and hier­ar­chi­cal­ly to begin with.

This is all stuff to just make the act of writ­ing CSS faster, not inher­ent­ly more pow­er­ful. So in my case, I use oth­er tech­niques to speed up my cod­ing that I pre­fer over these pre­proces­sors, at least for the most part.

Where it gets inter­est­ing are the func­tions, which extend what CSS is capa­ble of on its own by let­ting you com­pute dimen­sions, col­or vari­a­tions, and oth­er inter­est­ing math­e­mat­i­cal maneu­vers. Def­i­nite­ly cool. Noth­ing you couldn’t accom­plish by writ­ing a bit of Javascript, but the beau­ty here is in being able to ref­er­ence that JS log­ic from inside the CSS itself by way of the pre­proces­sor. I can imag­ine a lot of sit­u­a­tions where this would be the sim­plest, most ele­gant solu­tion.

But that kind of func­tion­al­i­ty only makes up at most 10% of what a CSS pre­proces­sor is com­mon­ly used for, while the oth­er 90% is (sup­pos­ed­ly) for sav­ing time and sim­pli­fy­ing the cod­ing process.

When you fac­tor in all the time spent becom­ing pro­fi­cient in these, recon­fig­ur­ing your work­flow to incor­po­rate them, get­ting your clients and free­lance devel­op­ers bought in and inte­grat­ed, actu­al­ly build­ing the pre­proces­sor-spe­cif­ic log­ic, and then the extra care need­ed to reverse-engi­neer the pre­proces­sor-gen­er­at­ed CSS dur­ing test­ing, I seri­ous­ly doubt most peo­ple using them are actu­al­ly sav­ing much if any net time.


Not to men­tion most of this func­tion­al­i­ty will like­ly find its way into the core CSS spec soon enough, leav­ing the pre­proces­sors out to dry. It’s not exact­ly build­ing on sol­id ground.

Maybe pre­proces­sors will con­tin­ue to stay one step ahead. Maybe this is the realm of the ear­li­est of adopters (there’s noth­ing wrong in that) and I’m just miss­ing the point. Maybe it’s bet­ter suit­ed to an inter­nal team man­ag­ing a sin­gle prod­uct or suite of prod­ucts, and not to a shop pro­vid­ing client ser­vices on a wide range and vari­ety of prod­ucts.

But for some­thing that’s tout­ed as a time-sav­ing and sim­pli­fy­ing approach, I see it as the oppo­site. Orga­ni­za­tion for organization’s sake.

I’m sure I’ll use them in the future on a case-by-case basis for their com­pu­ta­tion­al abil­i­ty. A cou­ple of our projects right now actu­al­ly already use a bit of LESS. But as for inte­grat­ing CSS pre­proces­sors into our base­line work­flow, for now at least, it’s just not a smart use of time or ener­gy.

Make that anoth­er half-hour or so for writ­ing this post, by the way.

Am I wrong?


Human being, husband, friend, designer & partner at Priceless Misc.

Go top Google+