Home Native vs. HTML apps

Native vs. HTML apps

I wish HTML could be the future of app development but there are a number of reasons it's not there and unfortunately won't be anytime soon.

  • HTML is always one step behind native.  While HTML can continue to play catch-up with new features it'll always be a step behind when it comes to new technology.  Features like push notification, NFC, calendar, microphone, accelerometer, OpenGL, contact/calendar access and even basic things like the camera on the device are just not there on the web.  The folks that develop the browser itself are building a native app so the native app API's have to come first. Even though it seems like HTML is "close" it'll continue to be close as it's a moving target.
  • Performance is key, especially in mobile.  The best native apps crush HTML apps in performance.  Web-apps have improved a lot over the last few years. The addition of client databases, JSON & compiled javascript have all done a lot for performance.  All this is good but even something simple like a long list of 1000 items shows the performance problem.  On a native app that 1000 item table is virtualized and breezes by with a flick. On an HTML mobile app you'll experience the joy of the checkerboard pattern.  HTML isn't setup for virtualized lists. As phones get faster this problem gets smaller but side-by-side you feel the difference.
  • Platform consistency. The phone is personal, more personal then a PC. The user interface on each mobile device is also personal. An iPhone app interface isn't the same as Android or Windows Phone or BlackBerry. Users want platform consistent experiences.  This is something that you just can't do on the web.
  • Discovery and distribution model:  The web is a collection of "pages" that connect to one-another but conceptually these pages don't always form a product.  The app-store is a model that works because you have a centralized place for complete products, not pages.  These products are rated, ranked and categorized.  In addition to a distribution model native apps have a monetization model that doesn't exist on the web.
  • What about things like PhoneGap? Can't you get the best of both worlds? Develop on the web then package everything as an App? No. Not if you use HTML to do the rendering of your app.  Apps like Bank of America tried this and it's pretty terrible. (Yes we can tell BOA.) Netflix, tried to re-create many aspects of native controls using javascript and while the overal service and app is great this just doesn't work well.

To understand the problems we're facing today with native vs. HTML we need to roll back the clock back to 1994. This was my first memory of HTML.  I had just taken an intro computer class on basic networking and data structures. We learned about the efficiencies in how packets get sent and recomposed between computers and we also learned how to efficiently pack bits into a data-structure for optimal efficiency.  Native C & C++ type stuff.

My next class was an intro to HTML. At the time HTML was pretty simple and you could count the core tags on your fingers <html> <head> <body> <p> <h1> <img> <b> <a> and <center> and <i>. We were able to create basic web-pages. Really basic, no CSS, no JavaScript almost all text.

Even back then I felt there was something wrong. At the core levels of efficiency of both data storage and network traffic it felt like there were problems. Where were the data-structures?  To create something as simple as a link wasted 16 bytes <a href=""></a>.  No big deal? What's 16 bytes anyway? 12 bytes too many.

Yes, it's a little extra data. But it's not just storage of the data but it's encoding the data, sending it over the network and parsing it for display. The inefficiency isn't on the one tag. It's on every single tag.  Same problem for network requests. Instead of opening a connection to a server and getting all images and data in one shot you would open a separate connections for each image.

Fast forward to 2011 and the problem getting clearer. Instead of a handful of tags and a couple images we have hundreds of tags, properties, images, css files, javascript files, web-fonts, DTD documents, etc, etc.

This post is licensed under CC BY 4.0 by the author.