Here's why HTML-based apps don't work

There have been a few recent examples of companies making headlines by announcing they were ditching their HTML-based mobile apps and moving to native.

Two examples: Facebook, and accountancy startup Xero.

Two questions: Why is this actually newsworthy, and why have they been unable to make HTML5-based (more properly called "hybrid apps") work?

Mixed bag

Building a hybrid app means you build your software using HTML5/JavaScript and package it up in an app that can be installed on a device. Because it's running locally and in a native device package, hybrid apps can do things like access the GPS, camera, etc.

Managing to get an app working on multiple platforms is a huge pain. Somehow we've engineered (no pun intended) our way into a situation where we can't easily take code from, say, iOS to Android and then to Windows Phone. Any hop between platforms needs reengineering. If you build a hybrid app, you should, in theory, just be able to get away with writing it once and repackaging the same code for other platforms. That's a huge win.

Read: Building tablet and smartphone apps for the enterprise

I think the reason why initiatives to build hybrid apps that fail become newsworthy is that people really want this idea to work. It seems logical. It seems proper. Failure piques the interest of those developers following the story.

The only problem with hybrid apps is that it's nigh-on impossible to make them work. And that's quite a big problem.

90 percent

Over the past 18 months, I've worked on a number of different projects based on PhoneGap/Apache Cordova, some for clients, some for personal interest. I've also taught a couple of three-day classroom training sessions on the technology.

I've put this stuff through the mill, just for you.

Well, not exactly "just for you." But I will say this: it doesn't work.

I'd like to leave this story at "it doesn't work," but I guess my job is to actually provide you with more information.

We know that the ratio of "effort to progress" in software engineering is not a straight line. You can get through 50 percent of a project in four weeks, but getting through the remaining 50 percent can take you an additional sixteen weeks.

Closing in on the last 10 percent of a project with hybrid apps is always, always like that. At some point, you will always hit a brick wall that you need to get through. In fact, it's not a brick wall — you just hit glue. Regardless of how fast you're going, at some point you just stop moving and whatever effort you expend getting out of the glue exceeds the advantage of using the toolset in the first place.

Desire

It's well-understood that hybrid apps represent a compromise in terms of user experience when compared to native. What I think people are generally getting wrong about the compromise is that they look at this compromise in terms of the user interface only.

In fact, as a developer, you are a million miles away from where the vendor's engineers want you to be, and that's where everything falls apart.

When Google's, Apple's, Microsoft's, or BlackBerry's engineers sit down and design how they want you to work with their platform, they put a lot of thought into that. Each set of engineers is totally barking mad and they'll do things that drive you crazy (I mean, mash up C and Smalltalk? Come on!), but they want you to have a good experience at developing software. If they give you good tools, you will build good apps.

That's the compromise you are making as a developer. It's not the user's experience, it's your experience that's being compromised.

It seems a bit wrong to be prioritizing our experience as developers over the user experience. But it's like this: Imagine a wood carver trying to make a beautiful chair. The wood carver can either use a set of designed-for-purpose tools, lovingly maintained and passed down for generations, or he can go down to Home Depot and buy a two-dollar chisel and a lump hammer.

This is not an issue of "a bad workman blames his tools."

As developers, we need good tools to create good results. The hybrid toolset is so far away from what the platform's engineers envisaged that it simply becomes bad tooling. In a nutshell, that's the basic reason why hybrid apps don't work.

It all comes down to the fact that you're trying to make the system do something that it was not designed to do. When the Google engineers sat down and designed the API to let you access the file system, they were expecting you to use that, not to use whatever file API ends up being implemented in WebKit.

There is no part of the development process that is not like that.

Every single thing you look at or try to use is done differently than how the platform's engineers intended the platform to be used. As a result, every single thing you do is difficult and the chances of you landing in a giant puddle of glue multiple times per day, per developer, is about "one out of one."

That said, rendering some markup on the screen and doing a bit of jQuery, plus making odd Ajax call back to a server is easy enough. After all, what you're doing is a web app and WebKit is good at that.

It's this that lulls you into a false sense of security when you start because the approach delivers immediate positive feedback. That, combined with a developer's natural desire to work this way because it "feels right," pushes people out of the tools' comfort zone. But when you do that, as I say, it's gloopy glue time.

I should say that the Apache Cordova and PhoneGap developers particularly do a really good job of supporting, maintaining, and developing the platform. I know some of them, and they're lovely to work with and very talented — it's just what they're doing is fundamentally broken.

A better path

Where I've seen hybrid apps work when you need to get something off the ground very quickly, but the level of sophistication stays at quite a low level, and you don't need the app to have a very long life. That seems to work.

I've also seen it work when a team more or less kills themselves making it work on one platform, and subsequently making it work on the other platforms is generally easy.

Where hybrid doesn't work is if you're trying to build anything of any size. You'll run in the glue and expend so much energy trying to get out of it that you might as well have just gone native in the first place.

Go native, try Xamarin. But in terms of hybrid: avoid.