Is that the right tool?
This weekend, I needed to fix a wobbly chair. There was a bolt that was a little loose and needed to be tightened. I asked Evan to grab me a wrench. He went off and handed me a screwdriver.
“What’s this?”
“It’s a screwdriver.”
“But I asked for a wrench?”
“Yes, but this is a screwdriver. It can screw in things, and even wedge out things that are stuck. It is much better than a wrench, I only do work with screwdrivers and not wrenches.1”
The internet is littered with blog posts arguing for one technology over another. There are many posts about needing to use the next shiny tool, some arguing for more stable technologies, some even positing we should stop writing “Stop Using” posts. Generally, these posts all articulate the benefits of one technology— but rarely do they answer the question that is needed: Is this the right tool for the job?
Just like the conversation above, many developers tend to stick with the technologies that they are familiar with. Many others do the opposite, moving towards the latest bleeding-edge tool that is built. More often that not, a middle-road needs to be take, considering both the familiar and the bleeding-edge, the mature tool and the new tool, taking an honest look at the capabilities of each technology.
Familiarity vs. Bleeding-edge
There is a fine balance that needs to be struck in any project between utilizing the new bleeding-edge technology and reverting back to what is familiar. There are problems with always using the newest tools, as they tend to have more bugs than relying on tried and true methods. There are also issues when working in large, enterprise organizations, because constantly changing the tools that are used is not feasible. There are too many developers all contributing to a codebase and cohesion amongst them is a must. But if we always use the familiar, then we would still be using table-layouts and inline styles.
Where can we draw the line when it comes to adopting new technology? I think every team needs people focused on the latest and greatest in their specialties. When a specific technology comes to fruition that can make a substantial impact to our workflows, then it should be seriously evaluated and possibly adopted.
A great example of a technology that made a serious disruption in how we build websites are CSS preprocessors. Although they did take some getting used to, and most of us ended up make many mistakes with their use— the gain that came from being able to more easily organize our codebase was immeasurable.
Holy Wars: Sass v Post-CSS
How many times have we heard this argument starting as of late? The war of pre-processors vs. post-processors has been raging on across the internet. With posts such as Ben Frain’s Breaking up with Sass and the A List Apart article on the dark side of CSS pre-processors, the popularity of CSS post-processors has been gaining momentum. With this momentum has come many heated arguments across the internet over which tool will “win” or which tool is better.
In reality, they are just two different tools, with two different methods, and two different purposes. From my viewpoint, I see them as working together solving two types of problems within our CSS workflow. Scott Kellum put it best when he stated “The goal of preprocessors is to be explicit, the goal of post-processors it to be implicit. You can use both!2”
I am not trying to advocate for one or the other, because I see them as two tools— a wrench and a screwdriver. Both have their purpose and both have their reasons to use them. Knowing the strengths, weaknesses, features and limitations of both will allow greater use of the tools that we have available to us.
What can I do?
Step back, breathe, and learn your craft. Part of working on the web is knowing that technology changes constantly— and that is okay. Luckily, while the tools keep changing, the foundations of the craft (HTML, CSS, JavaScript) are relatively stable. Instead of focusing on the next chrome-covered, shiny tool, focus on bettering the craft. You can then select the tools best suited for the job at hand.
There will always be posts that extol the virtues of the tool, but if you know the underlying technology then it will be easier to find the right tool for your work.
1 Let it be known that this conversation never actually happened, and if something was broken it is more than likely that Evan would have fixed it, not me.