State of the union of html5 in the mobile revolution

Being relatively new to html5 and mobile development I spotted an excellent opportunity to catch up with the latest trends during the QCon conference in San Fransisco where they offered a wide variety of html5 and mobile tracks.
In this blog I’ll share the insights I gained during the conference. After reading it you should have an overview of the following:

where html5 is right now and where it is heading to with regard to mobile development
the benefits and drawbacks of html5 for web-apps compared to native apps
how to bridge some of the shortcomings of html5 with regard to native apps
valuable pointers to resources helping you to get started with html5 mobile development

Overall impression

Having followed several sessions featuring html5 and mobile it felt like riding on a tremendous high-way that is heavily under construction. I got a notion of how the final result is going to look like but in the meantime we have to drive around obstacles, deal with changing detours, take risks to end up in dead-end streets and continuously worry whether the chosen vehicle, our browser can handle the freshly paved lanes (html5 standards). Nevertheless, it became evident that the web is moving hard and great new possibilities are waiting to be exploited.

From html4 to html5: the paradigm shift

The classic web architecture for html4 applications is based on a document centric approach, where client browsers request html-documents from the server and simply render them. The server handles all the conversational state and business logic whereas the client is nothing more than a dumb render engine.
Html5 on the contrary offers a truly stateful runtime environment. This allows for a shift from a document centric request/response approach to an application centric one, where data is synchronized when there is connectivity rather than continuously requested from the server. In other words, the html5 runtime offers support for rich clients that can operate in a standalone, disconnected fashion.
The classic web architecture is nor particularly outdated nor bad. There are definitely cases where stateless clients make sense. However, by supporting stateful features html5 gets much closer to native apps, which are stateful by nature. Statefulness opens a wide range of new possibilities and applications all within reach of the web developer. Let’s briefly touch on the stateful features of html5.

Html5 and state

In the section below I will describe the most important stateful features html5 offers, which are crucial for mobile devices to be connectivity agnostic:

Application Cache

The application cache feature of html5 allows for files to be pre-fetched from a server. It is similar to browser caches, with the significant difference that you can fetch any file of choice eagerly. A cache manifest file is used to configure a selection of files that need to be pre-loaded regardless whether they will be used by the markup or not.

WebStorage

WebStorage is an easy API to store small amounts of textural information in a name/value pair format locally. This offers a wide range of possibilities. Imagine you have a wizard consisting of several pages. All intermediate data can easily be stored by means of the WebStorage API. Furthermore, imagine you have completed the wizard and want to submit the form but there is no connectivity. With WebStorage you simply save the form and show the user a message that the form content will be submitted when connectivity has been reestablished.

Connectivity and Offline/Online Events

The state of the current connectivity can be verified with offline/online events. These events go hand in hand with WebStorage. Instead of relying on connectivity, application state, such as form data, could always be stored locally prior to sending. Before sending we check the connectivity status. In case there is no connectivity we wait for an online event to happen before the state is synchronized with the server.

File API

The File API allows for reading local files and directly assign the content to a html element or render it on a canvas.

IndexedDB

IndexedDB is a lean object store, which stores data in the form of key(s)/object pairs. All keys are indexed. Queries can only be performed on keys not on the object itself. Compared to the WebStorage API, IndexedDB should facilitate bigger datasets, which can be stored and queried locally.

Current support for html5’ stateful features

Almost all current mobile browsers support ApplicationCache, WebStorage and Connectivity events , whereas the File API is still work in progress. The IndexedDB is heavily under construction, therefore it is not surprising that almost no mobile browser supports it.
With the stateful html5 features available a great variety of mobile applications can be built, which can operate in a standalone mode and do therefore not depend on connectivity anymore.
Nevertheless, especially older mobile browser versions will lack the above and other html5 features, making your html5 application useless for such device groups. Currently, there are several remedies to cope with this problem.

Dealing with cross-browser/device compatibility issues

Currently, the following remedies are available in order to deal with missing html5 features:

Feature detection

If you want to check at forehand which features a certain browser supports have a look at CanIUse.
To verify the availability of html5 features at runtime Modernizer is the best library choice. Modernizer offers a straightforward API through which all html5 traits can be tested. Depending on whether a feature is enabled adequate action can be taken, such as using a polyfill alternative.

Polyfills

Polyfill libraries are fallbacks in case a html5 feature is not supported. A good example is socket.io, which provides support for realtime (push) communication. The html5 answer to push are WebSockets. Because not many mobile browsers support WebSockets yet, socket.io bridges this gap by providing other communication mechanisms, such as long-polling in case WebSockets are not available.
There is a vast choice of polyfill libraries, which are preferably used in combination with Modernizer. Should Modernizer see that a certain feature is missing a polyfill counterpart can be loaded.

Native look and feel

Html5 does not offer OS native look and feel out of the box. However, there are some great javascript frameworks/libraries available that offer native widgets and touch support:

Pros and Cons of Html5 Web-Apps vs. Native Apps

With the features html5 offers combined with polyfill libraries we are able to write ‘decent’ web-apps, which can run standalone, use some device capabilities etc. However, competing with all the possibilities native apps offer is out of the question. Nevertheless, html5 also offers great advantages native app development can only dream of. Let’s have a closer look at the differences.
As follows the pros and cons of html5 web-apps compared to native apps:

html5’s Pros

One stack to rule them all:
Use one technology stack (html5, css, javascript) for all platforms.
Faster time to market:
Because only a single technology stack needs to be mastered expanding to other platforms is not that hard. However, be aware that ‘write once run everywhere ‘ is still an illusion for a complex html5 web-app. Various projects have proven that getting a complex html5 web-app work on all browser platforms can still be a considerable investment.
Reuse of skills:
A single team of web developers can write web-apps for all platforms. Even though it can be expensive to make an html5 web-app run on all platforms, it will probably still be cheaper than a native approach. The reason is that one web developer team can support all platforms instead of having a native developer team for each one. Also costs for maintenance and expansion towards new platforms can be much lower than a native approach.
Less Code:
Having only one stack to master will result in less code. Less code means less maintenance, less bugs, less complexity and therefore lower costs.

html5’s Cons

Limited access to device functionality:
Most Html5 browsers do not support access to device functionality such as camera, filesystem, contacts, SMS, gyroscope, cross-app messaging etc. Proposals are available but actual implementations are not within reach yet.
No monetization and distribution:
Html5 web-apps cannot be distributed and monetized, which means they cannot be offered in an app-store. For companies who want to make a living with apps this shortcoming is a serious issue.
Worse render performance:
Html5 cannot match native performance since it does not yet have direct access to the hardware render capabilities of the device. Simple renderings such as scrolling a list, feel nowadays like native. Complex renderings in html5, however, can’t compete with their native counterparts.

Depending on what kind of app you want to write the list of drawbacks can leave you with no other option than going native. When render performance is your killing feature the odds are bad: native is your only choice.
The limitations imposed by html5 for limited access to device functionality and monetization/distribution, however, can be bridged. The answer is: hybrid apps.

From Web-app to Hybrid app

What are hybrid apps? Hybrid apps are html5 web-apps that do not run in a browser but instead in a native wrapper. A native wrapper can be seen as an embedded browser. Such a wrapper is launched within a native app giving the user the impression that he/she is interacting with a traditional app.
To make this work all that is needed is a very thin native code layer that embeds a headless browser wrapper in the app, which loads the html5 web-app at startup and runs it as a normal browser would do. Moreover, this thin native layer can bridge almost all html5 gaps, providing access to device functionality, such as camera, SMS, contacts etc.
There are several hybrid projects out there: PhoneGap (Apache Callback), AppMobi, NimpleKit etc. The most popular one is probably PhoneGap, which has been donated to Apache. It is now an Apache project called Callback in the incubator phase. In the coming section I’ll touch on PhoneGap in order to give you an idea of it’s tremendous potential for mobile development with html5.

A popular hybrid app stack: PhoneGap (Apache Callback)

PhoneGap is fully open source. It is not only widely used but also widely supported by major vendors such as Adobe, IBM, Microsoft, RIM etc. By now there are already ~15.000 PhoneGap apps available in app-stores for various platforms.

How it works

Writing applications with PhoneGap is very straightforward. In essence you write a traditional html5 application including a reference to a phonegap js library in your html. Upon completion you can use PhoneGap’s build service, which wraps the html5 web-app in all native wrappers of choice. In addition, it makes the resulting hybrid-app available in the app-store where it can be downloaded on the corresponding device for use or testing.

Development with PhoneGap

For development convenience and short roundtrips using emulators is desirable. Most major IDEs have a PhoneGap plugin, which allows for quick deployment in the SDK emulator. Other emulators are WebKit and Ripple. I saw the emulators working for XCode and eclipse. Many more are available here.
During an impressive demonstration it took people from Adobe less than a minute to make a html5 application available on an iPad and an Android device. Weinre was used to remotely debug the application that was running on a real device. The same debugging technique can be used when running the application in the native SDK emulator.

Access to device functionality

Because the html5 standards for accessing device functionality is leaky and still heavily under construction PhoneGap chose to write their own PhoneGap javascript API, which bridges all gaps. There are APIs for Sensors (GPS, Accelerometer, Compass, Network and Camera), Data (Contacts, Media, File system, Notifications) and Events.

PhoneGap and other JS-Libraries

Besides PhoneGaps’ own API to access device functionality all commonly used javascript APIs can be used, such as JQuery Mobile, Sencha Touch for GUI, JQuery, XUI, Zepto for DOM etc. With regard to these third party JS libraries PhoneGaps does not impose any restrictions. You only have to make sure that the chosen library works within the embedded native browser.

Access to native code

In case PhoneGap does not bridge all the ‘gaps’ for you it offers a plugin architecture, where you can write your own PhoneGap plugins. With plugins you get direct access to the underlying platform with all the possibilities thereof. However, platform specific knowledge will be required.
So all in all, hybrid approaches such as PhoneGap are great alternative to native apps. They pick both of best worlds: a single technology stack, reuse of skills, shorter time to market and access to device specific capabilities.

Overall Conclusion

Polyfills and hybrid apps prove that html5 is still far from being mature. However, it is moving fast. The Html5 objective of delivering a native user experience for all platforms with one technology stack is not reality yet but frameworks such as PhoneGap do a good job in simulating this utopia.
Html5 and mobile have just taken off. Even though the two will still have to grow on each other the future looks promising with a great variety of new possibilities awaiting us. My advice is: embark the ship to witness the web’s next (r)evolution that will rock this planet 😉

Acknowledgements

The following presentations from QCon have served as input for this blog: