The article you’re reading was written in April 2013, nearly three full years since Ethan Marcotte first wrote his article about Responsive Web Design. However in those three years I think that we have collectively thought our way into a dead end. I’m going to try and convince you that we should stop focusing on RWD so much and instead look at Responsive Web Development.
Responsive Web Design is dead.
We, as an industry, have had three full years to understand RWD. Steve Fisher wrote an article that outlines how his process has changed as a result of RWD. To compress his points: he now puts a focus on content at an earlier point so that he can ensure that it fits a responsive site. I have no problems with Steve’s article. Every point he makes is correct and accurate. My problem is that this is not new news, we already know how to think about RWD.
This has been becoming a trend over the past few months. Another example is in a recent ShopTalk Show Chris Coyier and Dave Rupert talk about various methods of working with responsive images. At the end of this discussion Chris says, “I feel like it’s months and months go by and we’re no closer to a perfect solution”. Now, it’s this very sentence that made me realise that we need to stop talking about Responsive Web Design so much. We’re not getting anywhere with it.
The problem is that there is no perfect solution.
The perfect solution
Except that there is a solution, embrace the imperfections and work with them.
Let’s work with the example that Chris and Dave were talking about, responsive images. There is a lot to take into account here. Chris actually maintains a file to keep track of various techniques that can help us come to a solution. We need to be aware of server-side solutions vs client-side, multiple file downloads, valid syntax, file size, compression, retina displays, the possibility of using multiple files for each image, backwards compatibility, and even more when we’re thinking about what image solution to come up with.
Our problem with Responsive Web Design is that we’re spending too long trying to find the perfect solution to this and other responsive conundrums. We should instead be focusing on the solution that best suits us for right now. This is not new, experienced back-end developers will have a preference for certain languages for certain situations. Having tried a range of languages (maybe Ruby, PHP, Python) an experienced developer could recommend one of these to use over the others, in different scenarios. I think trying to find the one perfect solution to RWD causes us a lot of frustration as a community. I’m sure I’m not the the only developer that’s felt slightly uncomfortable implementing a RWD solution that is “the best solution for the moment”, but definitely not the perfect solution for the problem at hand.
Experienced back-end developers can make recommendations on different languages because they have tried each language in similar situations and can compare them. They have found the advantages, flaws and quirks. I feel with Responsive Web Design there is very much a trend that whatever is the new, or popular, is deemed to be the “best” solution. People then blindly follow these practises because they feel it must be better, because its new. However, Chris’ file shows us that there are many possible solutions to the responsive picture issue, each with their own advantages, flaws and quirks. There is currently no one answer. The solution then is, when we’re taking on a new project, we should look at that file and figure out what solution best suits our situation, and try that out. Maybe a few more so we get a feel for whats best. This will then give us the confidence that what we’re working with is the perfect solution for this one project.
There’s a problem with the perfect solution? Yeah, confusing isn’t it?
To be honest I would guess that most responsible developers genuinely want to do these kinds of tests on different possible techniques. The problem is that it can be quite time consuming, and trying to understand all these various techniques can be complicated, especially with a deadline. Then you (and I) ask the question “In the end, will it be worth the time it takes to try all these different techniques?”.
I’d wager that it’s that question that all this hooks on. It takes time, and lots of us are lazy. I’m one of the lazier people I know. I did about an hours extra work on a recent Friday evening because I was too lazy to get up and walk home! Fear not though, there is a solution to the problem with the perfect solution to Responsive Web Design.
Responsive Web Development
I believe Responsive Web Development to be our equivalent to Paul MacCready’s solving human powered flight. He stopped focusing so much on trying to create the perfect aeroplane, but instead focused on trying to make a system where he could make rebuild a plane in hours, rather than months, and test out all the possible solutions. If we can find a system that allows us to try out different responsive
We can already do this today. We have tools like Bower and Grunt that let us automate things like installing our favorite web frameworks, compressing images, running tests, minifying, concatenating, auto-
Using a tool like Yeoman, and its build process, you could very quickly create a small BackBone app to try out one responsive image technique. You could then create another version of the app, with a different responsive image technique, to compare against the first . This way you have two completely functioning web apps that are server ready / optimised and you can be sure you know which technique might serve you best for your current project.
This is the essential aim of Responsive Web Development: make something fast, try some alternatives, go with the winner. That way we can feel much more confident that we have the best solution for our problem, for right now. I think it is these techniques that we need to push forward, and they in turn will push us forward.