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.

The explosion of smart phones usage and the rise of the app stores has created a huge market for apps – these small, task-oriented software applications that most of us use daily. Meanwhile, recent development in web clients has made it possible to achieve similar user experiences using web apps – that is, apps that are built using the standard web technologies HTML, CSS and JavaScript. A lot of times, a web app works very well as an open, cross-platform replacement for a native mobile app that is built for a specific platform – although there are still a lot of cases where native apps, built specifically for a particular device platform, are the only option.

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.

Examples of phone/tablet apps that are in fact web apps are Wikipedia for Android and Ars Technica for the iPad.

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.

The increasing importance of client-side web programming is not new. We have come to expect good web interfaces to give quick feedback to our actions using different ajax-ish techniques, and to integrate with third-party web services in all sorts of creative ways. Now however, things like local storage, app cache, File API, and various other novelties in JavaScript APIs, CSS3 and HTML5 are becoming actual game changers in this area.

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

So what, specifically, is it that separates a rich client web app from a classic web application? Moving responsibility for application and UI logic to the client means a lot more JavaScript code, and new dependencies on libraries like Backbone. It also means a smaller amount and a different kind of server-side code. You may still need a good amount of application logic on the server side as well, but most if not all of the UI related code that web frameworks and CMSs usually have become redundant.

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 modelWeb app model
Building an app-like experienceLimited possibilities.“Proper” app experience with app logic and UI rendering happening in the client.
Performance, distributed processingAll logic and UI rendering happens on the server.Client offloads server by taking care of UI rendering and some business logic.
Backward compatibilityCompatible with all standard web clients.Requires modern browsers. (May need to be complemented by a classic web site.)
Development/software stackMany existing tools and frameworks.Less mature solutions, likely that more custom code is required.
AccessibilityPlays 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 appsAlways runs in a web browser.Can be packaged as native mobile app using PhoneGap. Can use hardware features like camera and compass.
Offline modeGenerally 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.

Kommentarer

This is a great summary, and I have forwarded it to a couple of friends / clients because it is so clear. Drupal 8 is striving to keep up to date. I wonder how Drupal's competitors, TYPO3, Wordpress, Joomla, and the big commercial CMSs are reacting to the 'appification' of the Web? Any system which requires backward compatibility may have more trouble keeping up?

Lägg till ny kommentar

Mer Kunskap

Några av våra kunder