HTML5 really could be the next app platform for business, but there still some kinks to work out

Last week at BriForum, I had a chance to attend a session given by Ericom's Dan Shappir on HTML5 applications. The session, titled "HTML5: The New Application Platform" was interesting because it provided an overview of the technology that was understandable by anyone, not just purple-haired web programmers.

Last week at BriForum, I had a chance to attend a session given by Ericom's Dan Shappir on HTML5 applications. The session, titled "HTML5: The New Application Platform" was interesting because it provided an overview of the technology that was understandable by anyone, not just purple-haired web programmers. It both confirmed my feelings on HTML5 apps now and gave me hope for the future.


Right now, the rage is HTML5 this, HTML5 that, but all the conversation boils down to a few important topics in the space that we cover: Rich applications across device types and Mobile access to Windows desktops. There are other things, like games or how built-in H.264 support are pushing out Flash, but from an enterprise standpoint, we care about the apps and the desktops.

Windows 7 rocked our world because the apps we had for Windows XP didn't necessarily work in Windows 7 (not to mention x86 vs x64). That forced companies to evaluate their application strategy, and many companies decided that they didn't want to place their enterprise applications in the hands of Microsoft anymore. This is part of that whole "post-PC era" that we've been hearing so much about. Instead, companies are evaluating new methods of delivering applications, like SaaS apps or home-grown web apps based on HTML5 technologies.

On the surface, both of these things seem like excellent candidates to replace native applications. Device ignorance is fantastic as long as the experience is the same on each device, but things start to unravel fairly quickly. There are still differences in browsers and versions that make deploying web apps hard. While backwards compatibility issues might be gone with rapid release cycles from FireFox and Chrome (which negate the need to maintain backwards compatibility for years and years because the browser is automatically updated on a regular basis), differences in the implementation of HTML5 standards exist so that each browser supported by your application requires extra bits of code here and there to maintain functionality and appearance.

That's one of the reasons HTML5 hasn't taken over the application world yet. Another is that the apps have a hard time replicating the feature set of native applications. With a browser app, the browser itself is the operating system, and it relies on HTML5 and JavaScript for everything. There is little, if any, awareness of the local device and it's capabilities. Native applications, on the other hand, exist within the device's operating system and have direct access to resources. This is why they have a much nicer experience across in a given situation. And, we're not just talking about mobile devices or tablets–the same holds true for PCs and laptops, too.

All of this contributes to a less-than-optimal experience, especially when it comes to browser-based access to Windows apps. You can read a bit more from our other articles on how HTML5 clients work for remote access to Windows, but it suffers from the same limitations: no direct access to hardware and browser inconsistency. It also has suffers from the fact that it is using HTML5 and JavaScript in ways that it was not designed for to deliver applications that were not made for half the devices that use them. Who wants to use touch as the only way to navigate Microsoft Office?

The last main issue is that of offline access. Native applications can be used offline. Web-based apps, for the most part, require a network connection. Sure, I can read GMail offline, and Google Docs has a feature, but it only allows you to read the docs. If you want to edit them, you have to copy them to Word, then wait until you're online to past them back into Google Docs. If Google can't get offline access right, it must be a tough nut to crack!

HTML5 in the Future

What I learned in Dan's session was that, while we may not be there yet (my words), the future does look bright for HTML5 and the browsers. Offline support has been an issue in the past, but with new browser-based data storage capabilities (such as IndexedDB), perhaps we can find better ways of building in offline support. Even Google's own browser, Chrome, doesn't work well with offline access to the apps and data, but you have to assume they're working on that. 

There are also new advances coming in terms of device support. Currently, there are API's in the works that will provide access to battery status, vibration, network information, sensors, and other pieces of hardware, as well as access to native device functions like contacts or calendars. All of these things can help make the HTML5 app experience more immersive. Audio support is also getting better as time goes by.

Other changes are already happening. For instance, WebSockets now supports binary data in addition to text data. For those that don't know, the way remote desktop clients are shown in HTML5 clients is by re-encoding the RDP stream in the datacenter to text data that can be interpreted by the browser. Support for binary data means that there is less translation to do, which can make the actual process of remoting the desktop more efficient and provide an overall better experience.

While the road might be a bit bumpy right now, I think early adopters of HTML5 are going to be rewarded for their headaches down the line, both in terms of usability and in strategy. Development for Windows is falling to wayside in the face of new challenges, devices, and platforms.  Keep a close eye on this, because at some point we'll reach the tipping point, and the stuff pouring out of the cup could very well be discarded Windows applications. I don't think that native apps on devices are going to go away across the board, but businesses would be smart to focus on one app that supports multiple platforms, rather than a version of the app for each platform.


Join the conversation


Send me notifications when other members comment.

Please create a username to comment.


Thank you for the mention - I hope I can provide even more info at my upcoming session at BriForum Chicago.

Regarding some of the points you raised:

1. As long as there are multiple browser vendors there will be browser compatibility issues (which in my mind is still much better than having a monopoly like IE6). That said, the situation is not as bad as it may seem. The existence of a common standard, and of libraries such as jQuery, make it possible to create sophisticated cross-browser apps. It's usually only near the bleeding edges that you run into trouble. Most web apps don't need to go there anyway.

2. The situation is more problematic on the mobile platforms. Facebook have released the Ringmark mobile browser test suite to shame the browser makers into improving mobile browsers. Now the rummer is that Facebook may buy the browser maker Opera.

3. In terms of user experience I think HTML5 apps can be on par with native apps, as long as they don't try to exactly emulate the behavior of native apps of a specific platform. In other words, if you want to create an iPad app with native look and feel you should probably implement it as a native app.

4. Creating a standard as you go means that sometimes you make mistakes, and that has been the case with browser offline operation. The browser manufacturers have recognized this, and hopefully we will see better offline capabilities sooner rather than later.



Thanks, Dan. Will offline support be tied to specific browsers, or do you think there will be universal offline support?