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

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

Summary: So you want to build an app. You're thinking if you do it in HTML, you can take your existing skills and port it to other platforms? You're in for a rough time...

No HTML5 on Mobile
That whole "build hybrid apps using HTML5, trust us, it'll work as well as native" thing? Turns out it doesn't.

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.


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.

Topics: Software Development, Apps

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Not sure but ...

    "Well, not exactly "just for you". But I will say this -- it doesn't work. and 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.

    I expected you to provide some examples of what exactly didn't work, what problems you ran into, etc... Unless I missed it you did not give us good examples of what didn't work. You stated more general instances of it not working. It would be a more interesting and valuable article if it was more concrete in discribing where you ran into problems.
    • Exactly!

      Examples are required for an explanation. Better yet if you say you worked on some of your own projects post some code, make it open source to deter others from making the same mistakes. But a generic "it doesn't work" doesn't cut it.
      Lorant Domokos
      • Drop me an email

        Thanks guys -- an early draft did have examples, but it made the piece too complex.

        If you contact me through the contact form I can share specifics with you both.
        • Wow

          Love my job, since I've been bringing in $5600… I sit at home, music playing while I work in front of my new iMac that I got now that I'm making it online.(Click Home information)

          • Dear ZDNet Moderators - Could you please filter this out

            once and for all.

            Thank you.
        • Instead of an e-mail...

          ...why not a follow-up companion article that gives the examples?
    • Thank you for pointing out the writer's fallacy

      Seriously, if you are going to write an article on a topic like this, some details would be prudent no? Are we suppose to guess why it doesn't work or it doesn't work specifically for the writer? Who knows because the article doesn't have substance.

      I can tell you if you work in a large company and expect your in house heavy duty applications to be fully functional and convenient to use on your cellphone/tablet vs on your desktop browser..well then you are truly out of touch with reality. Last I check nobody in my office is analyzing their reports on their tablets.
    • HTML5 doesn't work FOR EVERY MOBILE APP

      It's funny to mention Facebook as a counter-example, when their HTML5-hybrid mobile app has been quite successful for quite a long time. Even if they move away from it, the success of it is still apparent.

      Since the author grandstanded without any examples, let's consider a few constraints of HTML5 apps...

      (1) Mobile OS security restrictions so far prevent JIT in HTML5/Cordova apps. As a result, HTML5 apps actually run faster in the system browser than they do in Cordova/WebView. This could be fixed in the future.

      (2) It's extra work (if not impossible) to produce platform consistent UI behavior using HTML5.

      (3) Javascript's dynamic nature can be fragile and challenging for large shipped software. Generally dynamic languages like Python, Ruby, and Javascript have fared better for cloud servers where problems can be instantly seen and fixed by operators. Though this is a bit of a religious debate.

      These constraints don't mean HTML5 "doesn't work", they just mean it's not right for everything. Use HTML5/Cordova when...

      (a) the UI is content-centric not application centric
      (b) ubiquity and app-consistency is more important than platform-consistency
      (c) development costs need to be kept to a minimum

      There are quite a few apps where this is true and where HTML5 UI is a good choice, just not all apps.
      • Hybrid UI does it

        For the platform consistent UI and performance, you should check AppGyver. It uses native UI smartly where CSS/JS doesn't cut it. For non-games (data driven apps etc.) it's the best way to build fully native-performing apps with HTML5.
    • Comparing Apples to orange and trucks and cars.......

      Residential apps that designed to run in Chrome and Firefox specifically are very easy to port and have less issues. Html apps that are designed to run in a web server on the device will have the issues tied to the specific web server (therefore not truly cross platform). If you are taking about an app that has code residing externally and on residential storage then it will be a complete mix depending on the app and the language it is coding in won't dramatically change the complexity.
    • Crap article; HTML5 fine

      Yes this is a terrible article with lots of hand-waving and word-wasting to fill up space. ZDnet should get its money back on this one.

      I currently make an in-house HTML5 app which works quite well, thank you, on most platforms and browsers as well. Some of the newer Android browsers are not ready for anything, much less HTML5, but this will change.
      William Donelson
  • This is a subject line

    I'm guessing Firefox Mobile OS (or whatever it's called) addresses these concerns to a large extent.. given that's it's a HTML5 platform itself.. i think... maybe.. ?

    Tools like phonegap etc just make life easier for a developer in my opinion. There's no real focus or concern given to the end user. It's all about supporting many devices without writing it many times. UX is an after thought. The Facebook adriod app is testament to that. Then again, I used to argue the same about responsive web design.. not so much now.
  • I am setting out to prove you wrong

    We have a native Windows Phone 8 application that we are currently finishing up. After that we will be building a HTML5 hybrid app so that it works on iOS and Android as well. It does require background file transfers, capturing images, access to storage, but that all can be done in PhoneGap. I would like a concrete example of this "glue" that you are talking about because from my experience, when PhoneGap is used properly with stubs you can run the application inside a browser and that way you have access to a lot of tooling like debugging, profiling, automation with Selenium, etc. TypeScript allows you to write proper OO code easily, Durandal and Knockout gives you easy view composition and binding for a nice MVVM architecture, Breeze exposes a very nice client side data access API, PhonGap gives you access to the file system, camera and you can write some custom code for things like background transfer. If you can impose some constraints on the OS versions like requiring Android 4's modern browser to run the application I fail to see where you are hitting the puddles of glue.
    Lorant Domokos
  • Native apps are a pain...

    The problem with native apps is that you end up having to program several different applications for all the platforms out there. HTML5 and CSS3 might not be 100% supported the same way on all browser but at least there are ways to mend the problems. You don’t end up having to rewrite the entire thing.

    There as to be a better way than native apps. What HTML did is to create a simple markup language that can be read on any platforms. Efficient and democratic. What separate platforms are doing is the exact opposite and then there is the problem of having to have you app distributed on a market.

    I truly hope that a universal runtime environment for all platforms come to life.
  • But Xamarin IS a hybrid app

    I've done a fair bit of Android development using PhoneGap/Cordova and it definitely has its strengths and weaknesses. Building my first plug-in wasn't the easiest thing in the world but since I wasn't native Android developer to start with I was able to leverage web development to get going a lot quicker.

    Xamarin is also a hybrid app since you're using C# for your development instead of the native SDK's of either system (iOS and Android). Maybe it's a little "closer" to the native code but it's still not native. You're still going to have to do things "their way" instead of the SDK's way. (I would be surprised if both native SDK's do certain tasks the exact same way.)

    I think the real take-home lesson from this is to work to the strengths of your developers. If you've got a stable full of C# programmers then maybe it's Xamarin. If you're starting with a bunch of web application developers then look at PhoneGap. If you've got a bunch of native mobile developers then let them at it with the native SDK's.
    Robert Crocker
    • xamarin produces _native_ binary code

      there is no such thing as native programming language. as long as the development tool compiles an app into native binary form, and the app uses native APIs the compiled app is native.

      an htm5 app is not compiled into a native binary form, it is technically a web site packaged and delivered via the platform's store in a single blob instead of being downloaded from a web site. most html5 apps are not nearly as fast and fluid as native apps. except maybe windows 8, where html5 is considered a first class citizen
      • Two things

        The fact that it may produce native code on the back-side doesn't remove the fact that there is some translation being performed. One of the objections listed about the other tools was that they didn't invoke API's like the "native" tools did. Xamarin has this same issue/limitation in order to allow for support of both iOS and Android.

        PhoneGap/Cordova not just HTML5. The UI is HTML5 and JavaScript but there is the whole Plug-In interface that allows you to access the native functionality of each platform. This does mean that you have to maintain a separate code base on the plug-in side (one for each OS) but you're not limited to simply what you can do in HTML5 and JavaScript.
        Robert Crocker
        • Xamarin is the way to go

          Xamarin gives you full access to each system's API. It's not limited.

    • xamarin uses native APIs, has no cross platform sdk

      Xamarin is not a cross platform API. It is simply a C# compiler and thin import of native libraries. You write to native APIs for your platform of choice. Your C# code is compiled to ARM just like objective-c or c++ is.

      The only thing non-native about it is that C# code runs under the mono-runtime. This creates some lifetime management wrinkles, because iOS APIs are reference counted, while mono (like dalvik and jvm) is a precise garbage collector.
    • Xamarin's approach isn't to enable cross platform dev with the same code

      It's to make it easier to develop Android and iOS apps with the same language.

      That means there's no common way to perform the same task in both platforms, instead they expose the different APIs in c#. If you want, you can write code to abstract those platforms (MvvmCross and MonoCross do that on top of Xamarin)

      If you look at the naming of the Xamarin.iOS API for example, you can see the names are very similar to the ios methods they end up calling