It seems like a lot of Developers have the wrong idea when it comes to Responsive. After reading what a lot of nay-sayers say like it’s “impossible to make a web app responsive” or that Responsive means redirecting users to a different URL based on device type, I’m hoping to clear up misconceptions about Responsive and provide a conceptual basis for how to build a Responsive web app.

Think Responsive

According to CNN, Mobile devices recently overtook Desktop internet usage in the U.S. with the U.K. trending toward this in Summer 2014. People will be using mobile devices and desktops relatively equally this year. That’s not to say people are using the internet the same way on all devices or even more performing the same tasks. On the contrary, the use cases on a smartphone are probably different than even a tablet device. There certainly is a need to think Responsive when a large share of users are viewing your content between several different device types.

So what does Responsive mean? Responsive web apps adapt to the viewport and input of any device with a single codebase.

“Mobile First” has been a favorite slogan of Responsive advocates for some time, but I disagree with this statement. A lot of people take this literally to mean smartphones, while forgetting about tablets in Responsive design. In my opinion, Responsive sites need to be considered holistically between all the different devices: Mobile, Tablet, and Desktop.

Everyone in the process of creating a website from the Project Managers to Developers needs to think Responsive. Art Directors need to create modules that react to different viewport sizes without redesigning the entire interface between states. UX needs to realize that when a decision is made for desktop it impacts mobile and visa versa. Developers should react to decisions by advocating a similar look and feel and functionality for elements in every Responsive breakpoint.

A misconception about Responsive is that it only it is only a visual design challenge. Responsive web apps do not only need to react to screen resolution but also input devices. With the proliferation of wearable devices like Google Glass and Smart Watches, Responsive web apps will have to adapt to technologies that aren’t necessarily visual. Google Glass, for example uses voice as a primary controller for the device. Responsive for the past few years has been only an exercise in visual design for most people it seems, but it is my opinion that Responsive means much more.

CSS Doesn’t Completely Solve The Problem

Foundation and Bootstrap are put on a pedestal as the standard, however both frameworks do not deliver the goods without a lot of bloat. For instance, Foundation 5 still promotes classing the same DOM element multiple times just to align elements to a responsive grid, rather than advocating for an approach solely using a preprocessor like SASS (eventhough this option has existed in earlier releases of Foundation). Building out a grid with SASS can result in less markup and faster development.

Javascript architectures ignore Responsive while striving to be agnostic, offloading this responsibiliy to CSS driven media queries. Media queries are great for creating different grid based layouts, but are unweildy when it comes to supporting a modular design. The proposed element queries spec is supposed to remedy this, however this Developer is skeptical it will solve a lot of problems, mainly because it’s currently a bad idea to litter your CSS with dozens of queries because it effects browser performance. In short, CSS isn’t a cure all for making a website Responsive.

Javascript Architectures Need To Be Responsive

Javascript often comes in handy on a Responsive site. Responsive modules often need to support touch events and mouse events simultaneously, content needs to be hidden or shown based on state or device, image URLs need to be swapped per screen resolution. These are only a few of the tasks Javascript is great at supporting.

One very problematic way Developers tackle Responsive is by delivering different views based on responsive state. This becomes an issue of efficiency, especially if mobile devices are downloading all that hidden content meant for tablets and desktops. If a modular view doesn’t use the same source throughout responsive states, it often becomes a maintenance nightmare. Javascript architectures need to have built in methods for dealing with views in a responsive, efficient manner. A truly responsive MV* that doesn’t rely on Bootstrap or Foundation for Responsive remains to be seen. Developers shouldn’t have to hack a framework to make it Responsive.

Javascript can easily be used to make controllers and views stateful. Nicolás Sanguinetti’s Stateful.js provides a decent structure to follow when creatinga stateful Javascript object. Recently I released Res.js, which I call a swiss army knife for responsive sites. With Javascript objects like these, Developers can easily build Responsive into thier framework of choice. For instance, I recently made Res.js a dependency in Angular.js by creating Services and Directives that make Views stateful. It is possible to make any MV* responsive, but it has to be done early on in the development process to ensure success.