Home » Blog

Why I advocate for HTML5 Apps

HTML5 logo“HTML5 or Native?” – this question is quickly taking its place among the intractable arguments of the computer age along with Mac vs. PC and iOS vs. Android. Full disclosure here: I am a strong supporter of HTML5 applications. Our moderately successful start-up in the residential home services industry was able to more than triple its user base in a single year by switching to an HTML5-based app while making it easier to find talent to develop the software.

Of course, it hasn’t been all roses. We developed our solution targeting iOS and Android using a combination of Sencha Touch framework and Apache Cordova, writing our own native plug-ins where necessary to accomplish integration with third-party peripherals. We’ve had a number of technological issues along the way and some of them are because of the choice that we made to use an HTML5 implementation. But we had many of these same issues with the native application we developed prior to switching to HTML5 and in my estimation the benefits we have received far outweigh the negatives.

One area that causes a lot of confusion is that the term HTML5 app is used interchangeably for a lot of things. It can mean a mobile web site that the user is expected to save to their home page, a wrapper app that just loads a mobile web site, or as in the case of our app, a native application that hosts an HTML5 application that runs locally on the user’s device. Even in the case of an application like ours, three fundamental arguments are often repeated when discussing why Native apps are better than HTML5 applications:

  1. Native app UIs perform better than HTML5.
  2. Native apps perform more consistently within a platform than HTML5 apps.
  3. Dealing with browser differences across platforms eliminates the argument that HTML5 is a “single platform” and in the long run won’t cost any less than supporting multiple platforms.

Despite my advocacy for HTML5, I can accept all of these arguments. I won’t try and suggest that these points are invalid. The question is not whether these arguments are true… it’s whether they are meaningful to the business and its users.

For the performance argument, I’d say that any Maserati ‘performs’ much better than a Ford Fusion. Why then isn’t Maserati the world’s most popular car? The immediate answer is, of course, price (which we will address shortly). But there are other reasons: not everyone can work a manual transmission; some people have more than two people that they need to take somewhere; some people need to get more economy than 13 MPG just to get to work. In other words, the best performing option rarely meets the kinds of criteria that drive business decisions: supportability, utility, and sustainability. Like everything in life, we take lots of factors into why we choose one option over another and performance simply won’t always be the deciding factor. It has to be acceptable. Just ask any Carl Edwards fan and they’ll tell you a Ford Fusion can perform just fine. Matt Asay looked into the issue last year for ReadWrite and found that while consumer-based applications were weighted heavily to native implementations, businesses were overwhelmingly using HTML5.

One of the biggest issues we’ve struggled with in our application ties directly to the second argument that I see most often – that within a platform, native apps are more consistent. On iOS, this hasn’t been an issue, but on Android we see this frequently. The issues we’ve seen are almost always a function of OEM changes to Android for their devices. Samsung and HTC are notorious for modding Android on their deployments and we’ve had firmware updates break the simplest of things in the UI. But back when we were developing native apps only we saw the same kinds of issues, although then they were typically related to interoperability and networking instead of the UI. Across default installs of Google’s Android, we haven’t experienced this issue but we aren’t going to tell our customers that they have to all buy Nexus tablets. Even Google seems to be aware that something has to be done, given their recent flap with Samsung.

The final argument is that because of browser compatibility issues, HTML5 developers have to do the same amount of work, if not more, to support multiple platforms as developing separately for each. Under a narrow set of circumstances, I can accept this. Our experience has been that the WebKit-based browsers used in recent versions of Android and Safari are closely compatible and that by using a framework (Sencha Touch) we have very little device specific code.

On top of this, there is a whole other set of factors that support an HTML5 development. First, HTML5 developers have typically come from the desktop world, which has more than twenty years of experience in dealing with browser compatibility issues. The same HTML5 developers can write for each platform, including your web site. There is no reason much of the application code used for your mobile apps can’t be reused in a web site, furthering the value of your development dollar. You may be lucky enough to find a great developer who knows Objective C and Java and can develop apps for Android and iOS, but its far easier to find qualified HTML5/CSS/Javascript programmers… especially on a budget. Plus, more developers mean it is easier to quickly roll out releases to each platform simultaneously and those updates can be made without having to do a complete redeployment of the software through channels like Apple’s App Store. There are other technical considerations, too. Device emulators are notoriously bad (especially Android) and HTML5 development allows a lot of early interactivity to be done in a simple browser window and easily shared with team members for feedback.

Peter Traeg captured the essence of the core values of hybrid applications in his 2013 article for Smashing Magazine. HTML provides a rich document layout and, when combined with a single page application designed to run offline, the native features of the application allow integration with additional services and third-party devices. To summarize, I’d identify the core benefits of hybrid HTML5 application development as follows:

  • High level of performance sufficient for any business application, especially on newer devices
  • Supported by all three major platforms: Android, iOS, Windows Phone.
  • Consistent and widely available set of skills to develop that apply to all platforms – HTML5, Javascript, and CSS.
  • Can be used across platform with little additional effort, including web sites
  • Updates don’t require the typical application deployment channels. For complete clarity, I would certainly be open to a better option than HTML5 and we have continued to look. We even considered using Unity3D for a third release of our software thanks to its strong cross-platform support and unified language. But for most business scenarios, I still strongly support HTML5 development in a hybrid model and think anyone should give it a serious look.

Page-Level Container Discussion for HTML5

This post originally appeared on my blog.

HTML5 logo — I am the 'alt,' not the 'title' As I started down the path of my first HTML5 web page I spent a good deal of time trying to understand the sectioning elements of HTML5 — nav, article, aside, and section — as well as the major structural elements such as header and footer.

Trying to find the container to wrap the content of my page turned out to be the hardest part of the process.

Are We Talking about a Content Element?

Some elements more obvious in their intended use than others, but I felt that there was no specific element to denote the main content of the page. I struggled with trying to figure out whether my content should be in an article, a section, or even just a div.

Apparently I am not alone. Even folks on the WHATWG mailing list were asking the same question. And then I saw this feedback from Hixie:

The element that contains “a website or a blog entry’s main content” is
body, as far as I can tell.

It seemed like that was the end of that. Clearly he had considered it and felt that there was no issue.

But in the past week on both the WHATWG mailing list and the W3C HTML Working Group list this topic has resurfaced. And there are some good arguments in its favor.

Why Should We Get a Content Element?

One argument is that developers are already coding a solution to this, often by specifying a div with an ID of “main” or “content.” In this scenario, the concept of paving the cowpath, where HTML5 is intended to reflect how developers actually code web pages, comes into play. If it’s already appearing in code, perhaps formalizing it can allow for consistency in structure and semantics. This is, after all, how we got nav, aside, and others.

Another argument centers around ARIA use for accessibility. Since elements like header and footer have built in ARIA roles, developers who care about accessibility want an element with a similar built in role for the main content. Currently, these developers put role="main" into the div or other element that wraps their page.

The argument in favor of a content / main / maincontent element is then a matter of demonstrating an existing pattern and an end-user benefit, in this case in the form of accessibility.

Why Shouldn’t We Get a Content Element?

The flip side of this argument is that we’re just creating another element to add to the tag-soup that developers are already contending with in HTML5. Evidence today shows us that 95% of the pages that use ARIA ultimately use role="main" properly. Those pages that use ARIA at all only make up 1.3% of a 10,000 page poll, however.

Those users who understand and want to provide accessibility are already doing it with ARIA. Adding a new element may help get more developers to accidentally support accessibility, or it may confuse the issue if its use isn’t restricted to one instance per page.

What Might This Content Element Look Like?

Steve Faulkner proposed a new element, maincontent, on the W3C HTML Working Group list yesterday, pointing to his own draft to start discussions. Ostensibly he concatenated the commonly used IDs of “main” and “content” that already exist in the wild when naming this element.

Where it goes from here is anybody’s guess. Discussion is happening on both lists, but with all the other activity and the push to start to wrap up the specification it may get pushed out. Perhaps this time next year there will be a solid proposal with well-formed arguments on both sides, but I wouldn’t expect to see a new element by then.


HTML5 and Enterprise on Mobile

This post originally appeared on my blog on Saturday, March 10, 2012.

An Argument

HTML5, CSS3Early last week .net Magazine posted an article Why HTML5 is not the choice for enterprise mobility by David Akka. The article starts off with the statement HTML5 is being hailed as the programming language… That’s as far as I got before I realized this article had a fundamental misunderstanding of HTML5.

If you’ve read my blog enough, you know that I have been constantly struggling with how developers have shot themselves in the foot by allowing HTML5 to mean far more than just the HTML5 specification. Reading the comments to the article you can see that some people think the author is talking about just the mark-up language, and others seem clueless that there is a markup language.

I soldiered on and read the rest of the article. I realized that the main thrust of the article is less a technical assessment of HTML5, but is instead a discussion of how this collection of specifications is seen by so very many as a panacea for web application development. The author makes some valid points about security (specifically user-based, such as phishing scams thanks to bad browsing habits), lack of robust synchronization, and the ongoing changes to the W3C standards that can wipe away development efforts when the browser makers decide to change direction to match.

The author’s inability to clearly and correctly identify the appropriate specifications and speak to examples left the door wide open for anyone who rails against words such as “enterprise” to attack the article on its lack of technical merits.

A Response

In a response post, Why HTML5 is a choice for enterprise mobility by Kevin Sweeney, the three core arguments from Akka are challenged. The security issue is brushed aside as a function of poor development. The asynchronous nature of the web is addressed out of hand as a function of images and CSS, not so much about client-server communication and how best to lock and release records (for example). The argument about HTML5 as an unfinished specification isn’t addressed any more than to suggest that using it will make it wrap up sooner, but still with a fundamental misunderstanding of just which of the W3C specifications are really the ones in question.

A Response to the Response

Akka responded with another post, Why HTML5 is not the right choice for enterprises right now – or the defence of David Akka, which gets into some more detail on the technical side, but still gets some terminology wrong. As the one comment on the post demonstrates, people will skip the arguments within just to go after the technical detail, making the response effectively moot.

My Thoughts

When I get past all the misunderstandings of the specifications in the posts, including HTML5, I tend to agree with the overall message of the original post that rapid adoption, possibly for the sake of being cutting edge, is a real issue. This also assumes, of course, that the writer of (and responders to) the original article actually understand what “enterprise” means.


So much of modern web security is about defending against user-initiated attacks — phishing scams, malware, adware, viruses-as-email-attachments, and so on — that I think the real issue with security is really a combination of keeping users from doing daft things and protecting your environment when they do.

Add to this developers who haven’t been inculcated in an enterprise environment and maybe don’t think about the sensitivity of data passed over the wire, or enterprise developers re-positioned to use these new web technologies, and you have some further risk.

Factor in web beacons that seem to come with the territory of developing all the “new shiny” and there is also an end-user security factor to consider. While a developer may not embed a Facebook button or an ad banner on an enterprise web app, that doesn’t mean they aren’t in the code borrowed from somewhere else, especially if the developer is new to the game.


I’d like to think every developer has already built a system to lock records — ideally one that doesn’t halt all other operations on the system. This should always happen at the server level. The challenge here is how to handle dropped connections, users who don’t “log out,” and the other trappings of a stateless protocol propped up by a scripting language that has to manage calls to an API on the server that actually does the real work.

This can be addressed and has been successfully on the desktop. On mobile it’s a bit trickier with more likelihood of flaky connections and long wait times. It doesn’t need to be, but too many scripting solutions that ping the server (maybe for XML, maybe to order a pizza) don’t have clean methods of handling dropped connections and can end up leaving users stranded.

While that’s not the technology’s fault it is something that, lacking a clear standard, requires each company to re-invent for itself.

Unfinished Standards

Many sites are leaning on the W3C Web Storage specification (which is not HTML5, but is lumped in with it). If you’ve been paying attention over the last week you have seen a battle over this specification, with some developers calling for its termination in favor of a solution like Mozilla’s IndexedDB or the now defunct WebSQL W3C specification.

Those developers who might have wanted to use WebSQL only to see it get pulled may now fear the same thing happening to the localStorage API (Web Storage). Web applications they built to support it may need to be revisited. Clients, projects, etc. may need to be updated. Dollars will need to spent. This is enough to make a company hesitate.

If you aren’t in the loop, check out some of the ongoing discussions and remind yourself that anyone in enterprise development through web apps (mobile or otherwise) needs to stay on top of these battles to make ongoing informed decisions.


Look to the business case. Don’t fall for the arguments against enterprise mobile web applications just because someone is afraid of a new paradigm, but instead make sure the resistance is based on sound business and technical considerations. Don’t fall for the arguments in favor just because of a knee-jerk reaction against “stodgy” enterprise models or a gee-whiz fanboy/girl mentality to all things mis-labeled as HTML5.

Ongoing Misunderstanding of Flash and HTML5

This post originally appeared on my blog on Saturday, March 3, 2012.

The latest article that uses absolutes and broad generalizations to imply an otherwise non-existent struggle between Flash and HTML5 is from UX Booth, “What the Demise of Flash Means for the User Experience.” To be fair to this article, I see regular missives on Flash vs. HTML5 and this particular UX Booth article is just an example of many of them in one easy to cite place.

The opening gives away the false premises for the rest of the piece:

Adobe’s decision to cease development of the mobile Flash platform and increase their investment in HTML5-related efforts created perhaps the final piece of conclusive evidence that HTML5 is the current go-to technology for creating ubiquitous user experiences regardless of device.

First I have to accept that the author is talking about more than the HTML5 specification and is also referring to CSS3, JavaScript, and the W3C specifications that are related to HTML5. This lack of clear delineation chips away at the argument.

Adobe has held that the fragmentation of mobile devices is too hard to keep up with on its own. Flash will still exist for mobile wrapped in AIR applications instead, and Flash is not going away from the desktop. Adobe’s decision to increase investment in HTML5 (via Edge and to a lesser extent Muse) is mostly unrelated since there is a market for an HTML5 authoring tool independent of Flash.

Not only is this neither conclusive nor the final piece of evidence that HTML5 is the current go-to technology, this is anecdotal evidence at best. In addition, HTML5 itself is nowhere near complete and the element often regarded as the Flash-killer, canvas, isn’t anywhere near as robust as Flash and still lacks strong scripting or styling support in the specs.

I think it’s fair to challenge the claim that HTML5 creates “ubiquitous user experiences regardless of device” when you consider all the polyfills and shims that need to be implemented to create similar experiences on a few devices. It’s also fair to say that my netbook does not handle some of the related HTML5 specifications the same as my tablet or mobile phone, partly due to various levels of hardware and browser support. Let’s not even get into video and audio codecs or the touch events specification (neither of which are part of the core HTML5 specification).

HTML5 excels at giving users a delightfully inconsistent experience on any device through the concepts of “graceful degradation” and “progressive enhancement.”

Those terms pre-date HTML5 and I can do both with HTML4 and CSS2. The author continues on and cites responsive design as a feature of HTML5, even though my own site is an example of an HTML4 site using responsive design to adapt to assorted displays.

Additionally, more than 90 percent of all smartphones and tablets are HTML5-enabled, which means that all the benefits of HTML5 can be utilized today to provide impressive mobile websites.

The author’s math doesn’t bear out the assertion — by the author’s numbers, 10% are not HTML5-enabled and so cannot benefit from HTML5. For the other 90% that are, even they cannot enjoy all (author’s word) the benefits of HTML5 today.

Making or upgrading to an HTML5 site can be as minimal as simply using HTML5’s doctype […]

The implication here is that simply changing a doctype gets you all the benefits of HTML5, when in reality you still have the same HTML, CSS and script.

The post never does answer its own question — what does the demise of Flash mean for the user experience? From the article, more HTML5 use. In itself that doesn’t tell me how the user experience is affected, just how developers are affected. If the developer does a good job, the user experience doesn’t need to change. The user shouldn’t need to worry about the underlying technology.

Too many HTML5 articles and posts today, like this one, work to promote the markup language (and usually CSS3 and JavaScript, even if they don’t know it) by contrasting it against another technology that is falling away or is just a popular target of derision. The pro-HTML5 cheering is easy when another technology has already been recognized as out-of-date, but this doesn’t do anything to advance HTML5 and its related specifications.

I’d love to see more practical discussions of what HTML5 (and related specs) can do today along with all the nifty experiments that are moving the collection of specifications along.

HTML5 Will Play Nice with Translation

This is an update to a note originally posted on my blog on January 17. As of yesterday (February 7, 2012), this new attribute is officially part of the HTML5 specification. If you are interested you can read the part of the bug report where this change was accepted.

HTML5 Logo with character for Chinese number 5.Back in late 2009 I wrote a little something talking about Google Translate and the risks associated with relying on machine translation for anything critical (“Facebook and Google Want to Translate Your Site“). I even offered some examples of things that are tough to translate.

One real-world example I did not list was when I used machine translation to process a page with someone’s name. The first name we’ll say was “Bill,” but the last name was definitely “Belt.” Somehow instead of “Bill Belt” being retained as his name throughout the article, he was renamed to “Bill of Leather Strap.”

This particular example is one step closer to being a thing of the past. In the latest W3C Open Web Platform Weekly Summary, a new attribute has been announced for HTML5 that will allow authors to exclude specific content from being translated — for any service that will honor it. The announcement:

A global translate attribute will be added to HTML5. The values are yes or no with the same inheritance policy than the lang attribute. The goal is to specify if a piece of text should or not should not be translated automatically.

Of course, if I want to exclude Bill Belt from being translated, I’ll probably have to wrap his name in a span in order to throw a translate="no" in there since I doubt I’ll have an otherwise semantic or structural element in place already. This does, however, offer a far better solution than the previous suggestion of using a class to achieve the same effect.

To be fair, Google Translate already has its own support for excluding content from automatic translation, specifically using class="notranslate". Head over to the Google Translate Help page and expand the bottom-most option, “General information for webmasters” (nice to see they make it easy for a direct link).

If you are curious about the process this went through to become a change for HTML5, you can see the bug report that started it all back on April 4, 2011: Bug 12417 – HTML5 is missing attribute for specifying translatability of content.

I don’t believe that machine translation is ever a good way to translate or localize content for anything more than casual use. For example, legal matters, healthcare, and things like that are poor candidates for machine translation (I have far more to say on this point in the post linked above). For organizations that do provide manual human translation, this attribute can be a boon to them as well, allowing them to understand pieces of content that do not need to be processed, saving time, effort and cost to everyone in the translation workflow.

As developers it’s our responsibility to make sure it is used correctly, most likely by helping to train content authors.

Flash is Dead! Long Live Flash!

A lot of news has been made of Adobe’s recent move to end development of the Flash player for mobile devices (such as your smartphone or tablet). Even people outside of the tech community have heard about it and are trying to understand what it really means. I wrote up the details last month (Flash Isn’t Going Away, Except from Your Mobile) and tried to remind everyone that Adobe isn’t giving up on Flash, it’s just changing its direction on its mobile player based on industry trends.

Consider that Apple won’t allow the Flash player on its iOS devices, and that the mobile version of Windows is following suit. Consider that web developers are (finally, after a decade now) starting to focus on standards-based web development and accessibility. Consider how many different mobile devices and browser combinations exist, requiring Adobe to develop a Flash player for each.

Much of Flash on the web has been used to deliver rich multimedia experiences that either don’t translate well to mobile browsers (giant file sizes, areas too small to “click” with a finger, optimized for large displays, etc.) or can be replaced with new HTML capabilities which mobile browsers tend to support now without the Flash player (such as the lowly Flash video player).

Add all these factors together and it doesn’t make sense to push the Flash player to mobile devices any more. Adobe is instead using AIR to allow Flash developers to build native apps on the phone, bypassing the hassle of the browser plug-in altogether and still allowing those legions of Flash developers to do what they do best.

Here’s where people get confused — Flash as a platform isn’t going away. Regardless of the hype you hear about HTML5, HTML5 (including CSS3, SVG, and so on) just doesn’t have the capability (whether via the specification or by browser support) to do what Flash does. Flash is the only technology that can currently do what Flash does for such a broad audience. Its ubiquity across the web (98% installation) has guaranteed that users see what the developer wants, regardless of platform; regardless of whether or not what the developer created is any good.

This doesn’t mean we are Flash-crazy over here. Quite the opposite — we have historically counseled against Flash for web sites for many reasons, some of which are simply because it doesn’t address the goal. As we develop sites that are both mobile-friendly and desktop-friendly, we are increasingly coaching our clients on the right technologies to use to achieve their goals. Our position on Flash isn’t changing because of Adobe’s move, Adobe is simply reflecting the trend.

You can expect to see less Flash in web pages on your mobile, but you can also expect to see more of it behind the scenes in apps for mobile devices. As for your desktop browser, Adobe will release Flash players for years to come and people will still develop in it for as long as it takes HTML5 and its related specifications to finalize the rules and for the browsers to support them.