18 Months of HTML5 - Will this work for me?

(This is part 1 of a series of posts.)

One of the main questions I usually get from our clients when talking about these ideas is: Will this HTML5-thing work for us? While I can understand the importance of the question, I think it really depends on “what do you want to get out of it”? Or to ask differently: “where do you feel the limitations of your current environment”?

For me, the limitations I personally felt (when creating WPF or Silverlight applications) were the following:

• I want an easy way to reach both desktops and tablets (iPad, essentially)
• But I still want to run the same apps on the web
• I need to create interactive applications which work with locally stored data. Apps which also work when offline.
• I want to support Android and iOS phones

And quite importantly: I am looking mainly at business applications. Things which help people get their jobs done. Not games. Not apps people run for fun. (Is this important? I don’t know. I want to create business apps which people actually have fun to use. But I digress …)

So, I think the main drive for me was the increased reach. If this is your goal, then HTML5 (and of course, whenever I mention HTML5 in this series, I’m always talking about HTML5 and the related technologies like JS and CSS3) might be a nice way to get there. Is it the only way? Definitely not. And if you or your team are absolutely uncomfortable with the idea of writing JavaScript, not too happy about working with the idiosyncrasies of CSS and don’t really want to get used to constantly seeing rendering differences in HTML markup itself then you might want to stay away from it. You’d have a tough learning curve ahead of you and there might be lower hanging fruits which yield dramatically better ROI for you.

Browser Differences and Standards Support

One of the main points of criticism towards HTML5 is the lack of consistent (and - of course - the lack of complete) standards support. This drives one of the most important decisions you’ve got to make: what amount of support and functionality do you want to provide to downlevel browsers? (and “downlevel” might involve a feature-by-feature check for small-grained decisions). For the systems I’ve worked on, it was usually ok to fall back to classic client/server web behavior or to provide alternative plugin-based solutions for older browsers (for example, to use Flash-based charts instead of Canvas-based ones for older browsers). Some purists might object to this, but for me, HTML5 is only a means to an end: if it allows me to use Canvas-based charting and HTML5-based local storage in mobile devices, I’m still more than happy to use Flash-based charting and storage for older Desktop environments.

I also think that life might be easier if you are mainly addressing web savvy consumers or users in small companies, as you might be able to get by with targeting only the newest browsers: after all, these users will usually take advantage of their browsers’ and operating systems’ auto update functionality. Enterprise users however are usually very different: IE7 and Firefox 3.0.x are still very much a reality in early 2012. So while HTML5 might get you onto your enterprise clients’ iPads and iPhones, it might not get you onto their desktops.

For my new company’s product, we’ve for example decided to support the latest two versions of all major desktop browsers, as well as Android >= 2.2 and iOS >= 4.0. (We’re actually supporting more browsers than this, but this selection is at least our baseline). Our product is commercial software, so we expect clients to spend some time evaluating it before committing to purchase access to it. We also believe that we can convince them that our software saves them more than enough time to make it worthwhile for them to switch to a newer browser to get access to all features.

Ship Your Own Browser

At the first glance, this situation would be hugely different if you’d target the “Enterprise Market”.

Let’s just assume that you today create WPF applications on Windows and you’ve been toying with the idea to move forward towards HTML5 to get bigger reacher. The above analysis might seem to settle matters for you: with IE7, there simply is no HTML5. And the whole idea of creating your own levels of abstraction on top of fallback solutions for different browsers might not be your cup of tea at all.

In this case, you’d always have the possibility to simply bring your own browser.

Now, of course, I’m not talking about shipping IE10 with your application. Instead, you might think about wrapping your application in the reusable rendering components of one of today’s browsers (some of these approaches even work without any installation on a target machine). When looking at today’s browser market, you are basically looking at three different browser engines which make up the majority of desktop and mobile browsers: Internet Explorer, Gecko (Firefox) and WebKit (Apple Safari, Chrome, Android, iOS, Blackberry, …). WebKit itself has been open-sourced by Apple quite a few years ago and has been embedded by a multitude of applications and in a lot of places you wouldn’t expect them.

When following this bring-your-own-browser approach, you could basically create an xcopy-deployable (or maybe also an installable/MSI-deployable) shell application with a single GUI element: one large Web Browser control. You’d ship HTML5, JS and CSS files alongside your application so that these elements can run inside the Web Browser control. Yes that’s a bit simplified, but you get the idea: Your enterprise customers can then take your HTML5 application (the same one which would also run in a regular browser if they’d update their infrastructure) and deploy its MSI/installer-package using their usual management tools. All of this without you having to support the old and outdated browsers which are way too common in this environment.

And if wrapping WebKit’s C code on your own sounds like a bit too much complexity for you: don’t worry. There are ready-made implementations like Adobe’s free Air SDK (not “the Flash thing”, just the SDK) which provide exactly this: a known version of WebKit with a known API which you can ship alongside your application. If you are a more adventurous developer, you might even want to look into hosting your own WebKit environment directly — maybe by wrapping it in (the unfortunately currently somewhat outdated) WebKit.NET. And last but not least: for all kinds of mobile phones and tablets Apache’s Cordova project (formerly known as PhoneGap) might present a very reasonable shell. (And of course, in the not-so-distant future, this approach might also help you to get a substantial part of your application logic onto Windows 8’s WinRT-Environment as well.)

But isn’t this a lot of work?

But, yes, porting your application is a lot of work and you should be very careful to avoid overly optimistic ROI planning. In a lot of cases, it might simply not be worth the risk of abandoning a platform you’re very experienced with, in favor of cutting-edge, moving targets and unknown environments. In other cases, this increased reach might be exactly what you need to distinguish your application from your competitors’  …

But even then, there’s still the language! But that’s something for the next post in this series …

Comments

[Terry]

The popularity of apps written specifically for smart phones and tablets seems to indicate users' preference for these types of apps over apps written to run in a browser.

[Ingo Rammer]

Terry: absolutely! Depending on the type of application, the native look (and especially feel) is extremely important. For other applications, however, it might be more important to provide feature equivalence between different platforms and quicker time-to-market. As always, it's a trade-off ...