The appification of the web
The web is an ever changing beast, and it feels really hard to keep up sometimes. Recently it seems like we’re at a tipping point, where a new generation of the web is being born. One aspect of this is the “appification” of the web. In this post I’ll try to give a bird’s eye view of this development, hopefully providing some guidance for anyone who is planning future web projects.
A recent example of a powerful, modern web app is Amazon’s Cloud reader which has replaced their previous Kindle iOS app. It was released as a reaction to the restrictions that Apple puts on anything sold through its App Store, and by being available directly through the browser, it allows Amazon to sell their books without paying the usual 30 % cut to Apple. Services like Trello, Toggl and Github also serve as examples of successful implementations of modern web technologies.
Beyond the web page
But it’s not just about mobile apps. The web in general can be said to be entering a "post-page era", where the old one-to-one relationship between clicks/URLs and web pages is being challenged. What it really comes down to is moving the responsibility for rendering web interfaces from web servers to web clients.
You could describe it as a shift from the classic web site model (left) where a server application generates complete, static html pages that are pushed to "dumb"/"thin" clients – to the web app model (right) where rich/"thick" client side web applications build the pages/interface themselves and pull (and push) data to and from a server application.
Letting the client side take control of rendering the user interface has several benefits. One is the possibility to create a much richer user experience, simply because the client is in control. There is a lot less latency when the user is interacting with the application, and the application can react instantly to the client side context in various ways. It’s also a great way to increase performance by relieving web servers of some of their most resource heavy tasks. In addition it allows server applications to be used by several different versions of the application simultaneously, since it’s more or less independent of the user interface.
On the flip side, a client side web app requires a modern browser, and you have to make sure it’s not too demanding on devices, performance-wise. Another potential downside with putting more business logic into the client is that you may have to target a wide range of devices, which may require more testing and support.
A richer user experience
It’s interesting to see how the web is slowly but steadily picking up more and more of the qualities of modern apps, making it more interactive, responsive, and focused. The old static, portal type web page feels increasingly outdated. Instead, we are increasingly aiming for an online experience that has a clear goal and is both empowering and simple at the same time – an interface that exposes just the right information depending on the user’s context, and responds instantaneously and intelligently to user actions.
These qualities can also help deal with the increasing diversity in target devices. The specific characteristics of phones, like a smaller screen size and possibly a limited bandwidth, but also added features like geolocation services and cameras, are forcing (and helping) developers to come up with new solutions to optimize the user experience on these devices. With the client app model, it’s possible to adjust the user interface significantly to various devices and browsers. A classic, prerendered web page is more limited in this respect, although a responsive web design is often enough to cater for different screen sizes.
Focus on the frontend
Existing web frameworks and platforms will need to evolve, or find themselves being replaced by a new generation of tools. At the same time, an app may still need to be accompanied by a classic website, in which case the good old web framework is still needed. As an example, this article has a nice overview (scroll down a bit) of how Drupal 8 is planned to tackle these challenges.
Pros and cons
To summarize, there are in essence two main types of web applications these days: classic server-generated web sites, and client-side web apps. They both have their advantages and drawbacks, and deciding which model is right for a particular project really comes down to the specific requirements. The table below specifies some of these characteristics.
|Web site model||Web app model|
|Building an app-like experience||Limited possibilities.||“Proper” app experience with app logic and UI rendering happening in the client.|
|Performance, distributed processing||All logic and UI rendering happens on the server.||Client offloads server by taking care of UI rendering and some business logic.|
|Backward compatibility||Compatible with all standard web clients.||Requires modern browsers. (May need to be complemented by a classic web site.)|
|Development/software stack||Many existing tools and frameworks.||Less mature solutions, likely that more custom code is required.|
|Accessibility||Plays nice with accessibility tools like text-to-speech. Also works well for SEO.||Needs to be able to fall back to a classic mode in order to be 100 % accessible and search engine friendly. May not have proper URIs for every resource/view.|
|Packaging as mobile apps||Always runs in a web browser.||Can be packaged as native mobile app using PhoneGap. Can use hardware features like camera and compass.|
|Offline mode||Generally requires an Internet connection.||Can work in offline mode, with cached content/data.|
Choose the Classic model if:
- The product is mostly page/document based.
- Accessibility for people with disabilities and SEO is non-negotiable.
- Your project scope is large and the budget is limited.
Choose the App model if:
- You have specific requirements that are difficult to fulfill with ordinary web pages.
- Your project is focused and feature-driven, and you can afford some extra effort.
- You want to package the product as a “native” mobile app.
- You need offline capabilities.
A golden mean
But the decision isn’t necessarily as hard or definitive as it may seem. Even if you go with the “classic” approach, there’s nothing stopping you from using client side features to augment the server-generated pages and create a richer user experience. pjax is a great example of how you can apply client side page handling on top of a classic web site and get a nice improvement for modern browsers while maintaining backward compatibility.
I actually think a good middle ground is to use very simple server-rendered pages as the basis for an application, and think of them as structured information objects or user interface components rather than complete pages. You then read and combine them on the client side into a rich user interface on the fly. This is basically an evolved version of the classic website model, that can fall back to work in legacy browsers and has all the benefits of the classic web – proper URLs, accessibility and search engine friendliness – while allowing for great flexibility on the client side as well.