css efficiency
Trying to come up with a checklist that constitutes the musts for becoming a good front-end developer is pretty much impossible. To make such a list one should have a selection of industry best practices, but since we never seem to be able to agree on anything we just won't get very far, even if we tried. This past few weeks I've been reading up on css selector efficiency, which seems like a prime example to illustrate the point I'll be trying to make here.
front-end quality
I'm pretty happy I joined the front-end ranks when things were still relatively calm. Sure, not much was happening in terms of technical innovation, but back then (I know I sound old) you had the time to read up on best practices and people were still actively discussing how to improve the general quality of our work. Since then our job has splintered into many different, smaller movements, all of which advance at different speeds and seem to hold to a different set of rules and ideologies.
Nowadays it's difficult to find articles that openly list pros and cons of what they are trying to preach. Blogging on web development is often about selling your idea, hoping nobody will notice the pitfalls and lapses. Some of these ideas go right against solid best practices we've helped to establish years ago, without even showing the guts to counter these ideologies directly. Especially when it comes to increasing site performance people seem to throw away all they know and go against the most basic rules we try to work by. The more vocal and charging your tone of voice, the more chance you have at succeeding. Earlier this year I already warned you about these types of articles, hopefully a live use case might prove more effective.
To illustrate my argument I'll refer to an article written a couple of weeks ago, preaching css efficiency. It's a short, smart and humorous little piece that has the power to convert many, but fails to back its claims with anything substantial.
faster is better
Knowledge is power, so when people write a detailed article about the processes behind interpreting and rendering css I can only applaud such efforts. But then others run off with that information and use it to sell their own ideas. See, they ask you if you would like to have your pages render faster. They tell you that your style of writing css is wrong and slows things down. Why not be cutting edge and improve the user experience by writing fast and efficient css, right? Right?
Nobody will doubt the fact that efficiency is good and should always be taken into account when considering multiple options. That said, it's definitely not the only factor and more often than not there is a price to pay. This is definitely the case when it comes to css selector efficiency. The idea here is to limit the elements within a selector as much as possible and to use the fastest type selectors possible (ids are faster than classes are faster than generic html elements). But no thought at all is spent on code readability, no one cares about future adaptability, no attention is paid to the actual gain of these optimizations.
Believe it or not, but some people don't even question the proposal to just add some extra classes to our html as to make certain css selectors even more efficient. And I'm not even worrying about html efficiency here, I just always figured the whole idea behind html(5) and css3 was to have better separation of style and content. I didn't know we were going to be adding classes to our html so our css would render faster when the time finally came to start using these new technologies.
catch phrases
Ideas like these are often sold on deceptive catch phrases. Faster rendering is better is what sells this particular idea, and by itself this is indeed a valid assumption. But once put into a broader context, listing all the downsides and the middle fingers to solid best practices, you should start wondering if it's really worth the gain.
You might even start to wonder what the actual performance gain is. How many milliseconds of rendering time are we winning by massacring our css files (and possibly our html too)? How much time is spent on rendering css when showing a page, and how is this theoretical gain perceived by the user? It's not because the actual rendering is a tad faster that it will be perceived as faster by the one browsing the page.
Such reservations are completely left to the people reading the article though. If you fail to notice these pitfalls (which is not all that strange if you're just starting out as a front-end developer) your trust is seriously tested by those who try to sell their idea to you.
conclusion
In the end you gain very little by posting articles like the one mentioned above. Sure you can try to form a troop of loyal followers who stand behind your own beliefs, but in the end this takes us just farther away from forming a solid set of best practices people can actually depend on, creating yet another schism within our small little front-end world.
And hey, maybe the author of the article is actually right. The gain might be substantial enough to warrant these optimizations, obliterating all the arguments against this way of working. Then again, if this is the case, you could wonder why he just didn't take the time to properly list all the pros and cons and to come to this conclusion together with his readers, rather than make fun of those who have their reservations.
My conclusion: screw efficient css, I'll rather write solid, readable and easily adaptable css code instead. And unless someone shows me some solid data that end users are effectively harmed by this, I'm not prone to changing my mind. Ridicule or not.