Question Your Best Practices
Starting at Viget a little over a month ago inspired me to take stock of the best practices that I’d developed over the years. From whole workflows to the smallest code snippet, I decided it was time to upend everything that I thought was perfect and bomb–proof to see what still made sense. The result was that I uncovered a few IE6 cockroaches hiding in the corners as well as a few other things that I had lazily relied on, without question, for years.
What did I find?
I discovered one surprising, and embarrassing, theme: forward–compatibility can make us, as front–end developers, complacent.
Tried and true techniques that worked in IE6 will, not surprisingly, still work in IE9 (and every other modern browser) — and that’s not necessarily a good thing. As browser development marches on and we stop supporting older versions we also need to re–evaluate the techniques we had been using to support those browsers.
Dropping support shouldn’t just mean not firing it up in a virtual machine to see how things look and work. It gives us the opportunity to clear out the cruft and move forward.
For Example
Look at the good old Suckerfish dropdown menu technique. I’ve been thoughtlessly, but successfully, using JavaScript to aid dropdown navigation and other hover interactions for years. Why? Because IE6 didn’t recognize the :hover pseudo class on elements other than links and JavaScript intervention was necessary. When you take IE6 out of the equation (and we all should) things get much simpler and you can use pure CSS.
So why was I still using this antiquated technique? Because browsers happily run whatever error–free code we give them — even when it could be better, or more modern. Quite simply: it worked. It has always worked and always will work and no browser is ever going to complain about it. Talk about a smooth–running bomber technique — and a perfect example of something that had to go.
We’ve all done it
By now you’re thinking “duh, Jeremy, I haven’t used JavaScript in my dropdowns for years”. Good for you! But I bet you’ve got something else hiding in the attic. Care to share one?
Moving Forward
So where’s the impetus to change when there’s virtually no friction? Refactoring code and removing unnecessary parts makes it simpler, smaller, more easily maintainable and less error prone. I think we can all agree that those are good things.
But there’s something more — it’s about being actively engaged in our craft. The speed of progress can cause us to hide behind best practices like a shelter from the storm of blog posts touting the newest thing. The key is finding a balance between stability and progression — or maybe you just need to upend everything once in a while.
Think about your favorite code snippet. If you had to rebuild it today, wouldn’t it be better? What’s your technique for keeping things current while still maintaining standards that speed up your day–to–day work?
