Native vs. Web apps: Is HTML5 still relevant for the enterprise?

451 Research

Analyst: Vishal Jain

12 Feb, 2013

Open source ERP vendor xTuple has launched an HTML5-based mobile Web app built entirely on JavaScript and HTML5, and claims to have tested it with a hundred or so private beta users. Similarly, smartTrade Technologies, a vendor of financial services products, has now launched all of its trading platforms as Web apps using HTML5. Market intelligence and data provider Thomson Reuters launched a mobile Web app on iOS and Android for investor relations professionals. As organizations like these invest in HTML5, it brings to the fore the power of mobile Web apps for enterprises. However, the slow pace of adoption is affecting the debate between native and mobile Web apps.

In autumn 2012, when a beleaguered Facebook, facing criticism from the market for a tepid mobile strategy, finally shunned Web apps for native apps, it sounded like a death knell for the future of HTML5. So when Facebook said it 'relied too much on HTML5,' it summed up the frustration of app developers around the inability of standards organizations to keep pace with the growing complexity of mobile platforms. It also brought to boil the growing discontent within the HTML5 Working Group, since just a few months earlier the key standards bodies WHATWG and W3C parted ways to lead their own efforts on HTML development.

These events brought the need to engage with developers and address interoperability, testing and performance issues. In order to give a sense of urgency, WHATWG chose to drop the '5' from HTML5, preferring to term its work as a continuous evolution of HTML. W3C has finally completed its definition (i.e., candidate recommendation phase) of HTML5, choosing to add future iterations into a new version called 5.1. In parallel, W3C has launched new working groups to extend HTML5 into other industry segments, such as television, automotive and digital publishing.

Enterprise expectations from HTML5
One of the key criticisms of HTML5 is its inability to provide the same level of performance and support as native apps. Typically, these criteria become indispensable in the case of gaming or consumer apps. As organizations such as Facebook and Financial Times have found out, reusing the same HTML5 code from one mobile OS to another OS and device is easier said than done. YouTube, New York Times, BBC and The Economist have started experimenting with HTML5, but they have not entirely ditched native apps. Since JavaScript is an interpreted language, performance optimization is key on mobile devices. Perfecting simple things such as scroll, touch events, canvas elements and offline cache has taken days of precious developer time, escalating project costs.

The variation of feature support across mobile browsers has meant that enterprises have to build for the minimum set of features when building a multi-platform mobile Web app. That strategy can work in case of apps that require server-side processing, and companies like xTuple and smartTrade have made good use of such architecture to extensively use HTML5. The marketing arms of enterprises, which currently spend on native apps for each of their marketing campaigns, could turn out to be the biggest consumers of HTML5. For example, Pfizer has a portfolio of 500-plus iOS apps for its marketing campaigns across different geographies. At the moment, most of the HTML5 in mobile is being used for mobile website development. British Red Cross, Burberry, MIT and Bain Capital mobile websites are built using HTML5.

Although enterprise requirements, in terms of user experience, are converging, they are not as demanding yet. In the case of custom-developed internal apps, enterprises do not have to worry about app store pricing issues, which hitherto had been one of the major drivers for the likes of Financial Times and New York Times to go for HTML5. With OEMs rolling out enterprise-focused app store distribution programs, the problem of procurement and distribution of third-party apps has been solved to some extent. Instead, they are more concerned with security and back-end integration tasks, multi-platform distribution, and reusability of code and tools. Since HTML5 extends upon existing Web capabilities, enterprises expect abidance with OWASP (Open Web Application Security Project) guidelines, which are quickly becoming the de facto standard for Web application security.

As the security model on the mobile browser matures, enterprises are closing the gap by pursuing hybrid approaches, such as wrapping the HTML5/JavaScript code within a native shell. By some estimates, more than one-quarter of native apps on the Apple App Store are native-wrapped Web apps. We are seeing several point solutions for mobile Web apps – some are UI frameworks, others are server-side frameworks, and the rest abstract HTML5 into their proprietary app development and hosting platforms. Enterprises need a truly HTML5-based robust framework or platform that can provide multi-platform mobile Web app capability and scale up to testing and performance requirements. An example is BlackBerry WebWorks, which allows app development in HTML5, provides the platform APIs and allows distribution as native apps on its app store. Even better is Apache Cordova, which is cross-platform and now claims to support multiple Web views; however, it requires extensive integration work for analytics, testing and performance management.

Where HTML5 scores
A lot of the initial focus on HTML5 was owing to its emergence as an alternative to Flash on iOS devices. In our recent discussions, several enterprises have wanted to know what utility HTML5 fulfills in the enterprise if one does not already have Web developers. There are two ways to look at the answer – one of which is content enablement, and the other is productivity gain. 'Mobile first' has become the starting point for any organization's renewed digital strategy. They do not want to maintain separate servers, objects and code to maintain different websites or pages for different devices, including desktops. By leveraging HTML5 across all of its apps – iOS, Android and Web app – LinkedIn found that it could reuse code and derive productivity benefits. However, it was not HTML5 across the board – the company tried to take the best of what was mature in HTML5, while relegating other tasks to native code.

While adaptive rendering has worked well for enabling existing Web content, 'responsive' is coming up as the preferred model for building new Web content. Using HTML5, one can implement responsive Web design either through CSS3 or JavaScript. Using CSS3 and a grid-based layout, different templates are made for the same Web page. The media-queries feature within CSS3 calculates and returns information about the display screen, such as size, orientation and color that the user is looking at, to provide the right context for the template. A JavaScript can also detect the screen display attributes and apply the CSS for that size. Hence, the same content can be used across different devices and form factors. Since most of the mobile browsers now have a minimum level of HTML5 support, it is becoming the preferred way to develop websites. Starbucks, People magazine (Time Inc), BBC One and The Boston Globe (New York Times) are some examples of responsive Web design. It has become so common that even open source CMS tools like Wordpress and Drupal now support responsive Web design.

Evolution of mobile Web standards
As the torchbearer of Web technology standardization, W3C has a lot at stake in the era of mobile devices. However, getting its 200-plus-member organization to agree on a set of interoperable and loyalty-free technologies is a mammoth, if not improbable, task. It has now pulled up its sleeves by forming working groups to address mobile Web app specifications around native APIs, security and protocols.

It has set up a System Applications Working Group to build a runtime environment, security model and associated APIs comparable to native apps. It is addressing other parts of the mobility problem through groups such as Web Cryptography Working Group, Technical Architecture Group and Web Application Security Working Group, as well another dozen or so groups that are taking a more granular view of device API, NFC, etc. For example, Web Cryptography Working Group recently published a JavaScript API specification for use in user or service authentication, document or code signing, and the confidentiality and integrity of communications. Some of these specifications can be seen implemented in Tizen or Mozilla OS; however, there aren't any that are easily and independently available for interpretation and deployment by enterprises. The young Core Mobile Web Platform Community Group (Coremob) is combining the work of all these groups, and has just compiled a set of use cases and Web standards that can be applied for mobile Web apps. An important initiative of Coremob has been to identify issues that plague the performance of mobile Web apps – directly from the developer community. Issues compiled include memory management, GPU access, JavaScript implementation and new API suggestions. It is expected that such feedback would make the HTML5 specifications more realistic and more palatable in the enterprise developer community.

Web technologies to watch in mobile
The current state of implementation of HTML5 on mobile leaves a lot to be desired around new features and performance optimization. We expect more JavaScript APIs that can deliver better native integration. We also anticipate better graphics and animation capabilities that can deliver better controls and a rich native-like experience. Beyond these, here are our picks of Web technologies that will increasingly become important, even for native apps.

WebSocket – allows Web applications to maintain bidirectional communication with server-side processes. It is particularly useful for real-time event-driven communications, such as stock tickers, betting and streaming media, and is coming up as an alternative to Comet, HTTP Ajax and iFrames. After the initial connection is established using an HTTP request, the WebSocket protocol replaces HTTP over TCP/IP, and maintains the connection as long as it is not terminated. Since it does away with header and footer information, the traffic payload and connection latency are minimal, and hence, less taxing on mobile devices and the server. Popular mobile browsers support WebSocket, and the server-side frameworks such as Node.js have built-in support. Vendors such as Push Technology, Kaazing and Lightstreamer (Weswit Srl) support WebSocket protocol. Layer 7 Technologies provides a gateway to manage WebSocket-based communications.

webRTC – is still in its early days, but the potential is immense, owing to its peer-to-peer communication capability. Hence, it can potentially replace the server, allowing two clients to directly establish a connection and share all kinds of data, such as audio and video. The protocol enjoys support from Microsoft; however, there is still a lack of interoperability between the protocol used by Google and the carrier-developed RCS-e specification. Although Cisco, AT&T and Ericsson have launched prototypes, these are early times for webRTC.

WebGL – provides the capability to render hardware-accelerated 3-D graphics on the browser. It is derived from the same specification that is used in native app development. Supported by Apple, Google, Mozilla and Opera, WebGL is currently being tested on mobile browsers, but with quad-core chipsets. It is expected to soon be generally supported across the next iteration of major smartphone platforms.

State of tooling
In the last couple of years, the tooling marketplace has evolved to boast better capabilities and better options for app developers. Also significant is the availability of benchmarking tools, such as Caniuse and Ringmark, which provide a benchmark for HTML5 support within mobile browsers. Even W3C is becoming developer-friendly – through a dedicated wiki called WebPlatform that aims to provide all HTML5 resources through a single source. We see frameworks such as Sencha Touch, Corona, Enyo, jQMobi, jQuery Mobile, jQtouch and Zepto, which provide JavaScript libraries to build mobile Web apps. On the server side, we see frameworks like Node.js and backbone.js. Hybrid app frameworks such as Apache Cordova fill the packaging gap.

There are several app development platforms that bank on these frameworks to provide a complete development environment, along with simulators and the server-side hosting. HTML5 use in app development is becoming commonplace; however, the task of picking the right components from a basket of native and HTML5 components is getting even more complex. As enterprises seek a multi-platform and extensible capability, the maturity of these technologies rests on support from mobile browsers, frameworks, app development tools and other Internet infrastructure components, such as servers and message gateways. There is also the need to manage these mobile Web apps, something which we cover extensively in our forthcoming 451 Research long-format report on mobile app lifecycle management in the enterprise.

Reprinted with permission from 451 Research

mead