There was a time when you could experience the web in only one way: on a computer. Today we know that’s no longer true. We have a plethora of devices that can connect to the web. Even our watches can get connected. Soon enough, with the Internet of Things, our toaster will serve us a toast with the most popular tweet of the day written on it. Web pages are no longer web pages but web applications. Therefore, we can’t build them the way we used to. With all these different devices consuming your application you’ll want to provide them with the best experience. Hence, you’ll have to adapt your web application, to not only fit in their smaller screens but to behave in the way their native applications do. If your application is not capable of adapting to these devices you’re missing quite a lot of potential customers. In fact, there are whole countries for which the majority of people experience the web only through a mobile phone or tablet. In order to make these applications adaptable we have to move out from traditional software web development strategies and gather a more modern approach.
In traditional web development the applications behavior is tied to the code running in the server. What you get in the browser is the rendered version of the output produced by that code. With this approach you have two options when it comes to supporting multiple devices. You either have to make code in the server to handle the different cases or do some magic with CSS and JavaScript to alter the experience on the smaller screens. Either way, every time there’s a new device on the market you’ll have to go and change your code again. Soon you’ll end up with a large and unmaintainable system.
So, how do you develop your web application so that it can handle all of these devices and the ones to come? Well, “the secret to building large apps is to never build large apps” (Justin Meyer). You build smaller components that can be managed and tested independently and used them as building blocks for your large software applications. And we’ve known this for years but is more apparent now with the uprise of the web and mobile market.
The first piece of our application starts in the server. The server is the brain of the application; it implements your business logic and manages the information that comes and goes from your database. Usually, it’s also responsible for formatting that data in a presentation language, such as HTML, before sending it back to the client. The problem here is that your client may not understand HTML, or may need to access just a portion of the data you sent. Reading those bits of data from an HTML document is hard and sometimes impossible. With native apps for mobile devices, if you want them to be connected in some way, your best option is to build a RESTful web service that exposes an API your application can call and get back something the app can read easily such as JSON or XML. With web applications you can do the very same thing. By removing the responsibility of the server to present your data you’re then free to consume that data in the mobile application, in a watch, or even on a toaster. The client will decide how to present and manipulate the data.
The second piece is our client, the face of our app. The client’s task is to present your data to the world and provide the mechanisms of interaction to manipulate it. By building the server as an API, our client becomes totally independent. We can change the server in any way, switch languages or frameworks, even change platforms. But as long as we’re serving the same data, our clients won’t be affected at all. However, this flexibility comes with a price. If you’re building your client as a web application you’ll have to work with JavaScript and, even though JavaScript is a powerful language, that means your code can get messy very fast. To avoid this, apply the same principle as before: divide your code into small, independent pieces. Frameworks, such as Backbone.js and AngularJS, help you do just that. They use the MVC pattern to separate your code into independent chunks of functionality that are responsible for one thing and one thing only. By building your web clients this way you make sure the code is easier to understand and more maintainable.
With both the client and server being completely decoupled you’ll have the flexibility required to compete in the fast moving world of technology. When a new device comes into play, such as that write-a-tweet-in-your-toast toaster, you just have to implement a new client for it. No need for touching the old code that runs your web application. When that new and faster framework comes out you can switch to it and your clients won’t have any problems. Your web application will be ready for the future.
