Perception is the way in which people interpret their environment.
Perception starts off as a very basic processing of the information we receive via our available senses. It's then combined with our own personal knowledge and beliefs and at that very moment, it becomes truth. It may not be the actual truth, but it's truth to us based on how we perceive it.
HTML5 and mobile have suffered from a perception of inadequacy ever since some very influential people stood on some big stages and made some very broad sweeping statements.
We created the HTML5 Mobile Challenge to put perceptions about HTML5 and mobile to the test. Not just a blanket generalization, but a hands on experiment so we could start with the raw senses and move up to the truth. We gave savvy developers two seemingly identical applications, and asked them to advise us on which one was native, and which one was a hybrid application running in a browser.
The proof is in the video. Once you tell someone that an app is native or hybrid, they make immediate assumptions about it based on their perceptions. Even when there is no native application at all.
In order to be able to challenge perceptions, we first had to find out if the rumors about HTML5 were true. Could we build a mobile app with HTML5 that was indistinguishable from native? We've heard a lot about how it couldn't be done, so we decided to find out for ourselves.
Over the last few months, we put our money where our mouth was - on HTML5. We sat down, designed an app, and began to build it using our own tools and the HTML5 platform. The result was a demo app called “Cuteness”.
Cuteness is a Reddit reader (so named because it only allows you to read the 'aww’' subreddit) which aims to take a hard look at some of the most tenuous areas of the mobile web.
What we learned won't shock you, but it's not going to support some assumptions that you may have about HTML5.
First and foremost, HTML5 is not a framework. The browser is simply a runtime executing our code. Due to reduced power and processor size, it's imperative for mobile applications to be highly optimized, and optimization is hard.
The browser does not magically optimize any components, either visual or logical. Both iOS and Android have native frameworks that offer a completely pre-optimized toolkit, further skewing direct comparisons to browser-based apps.
All mobile platforms offer a scrolling list of items. This is not something that the developer has to worry about when writing native code. iOS offers the UITableView, which is subclass of UIScrollView. iOS is known for its smooth scrolling on lists of items--and for good reason. When a list of items is created, this UITableView component actually reserves a set number of cells both on and off the screen. As the user scrolls, iOS swaps out the cells that are out of view with the cells that are now visible. Instead of trying to handle an unknown amount of items, iOS simply reuses the same reserved set of table cells over and over.
Listing items on a page using HTML is far too trivial. However, it's in no way optimized. The same way that a native iOS app would choke on too many UITableView cells, the browser chokes on too many unordered list items. The more markup you add to these list items, the harder the browser chokes. This is the point at which frame rates hit the floor, hands get thrown up and the inadequacies of HTML5 are proclaimed. Clearly, this is a highly unfair comparison to native lists that automatically optimize for performance.
It is possible to improve and optimize HTML performance, though. You do not have to settle for the default, unoptimized implementation.
We learned that we could replicate the same on-screen / off-screen cell reservation strategy with lists of items. The browser is actually quite good at manipulating a set list of items. We baked this strategy back into the Kendo UI Mobile ListView and immediately saw a 30% performance gain.
Cuteness has a second view that just displays the pictures from each of the posts. It's called the canvas view and it renders six items in a canvas that the user can then swipe forward and backward.
Implementing this functionality taught us that images come at a high cost. A guaranteed way to slow down your application is to try and animate any element with an image of any significant size. Animations get jerky and the whole of the UI appears unresponsive while the browser is busy painting or simply trying to re-size an image. The key to mobile performance is to reduce images to their smallest and most efficient size without experiencing a loss of fidelity.
Since we had no control over the size of the images coming from Reddit, we opted to use an image optimization service to make Reddit’s images mobile performance friendly.
Image optimization services (such as Yahoo!'s SmushIt) use techniques specific to the image type (jpeg, gif, png) to remove unnecessary bytes from the image while preserving the quality, otherwise known as "lossless". We were amazed at how much better images performed in conjunction with animations after passed through a simple optimization service.
We also regret to inform you that while GIF's are a lot of fun, they are a flat out death sentence for performance. There is a reason that iOS does not support the animated GIF format. It fares no better in native code than it does in a browser.
In the history books, scholars will likely write about the Flat Revolution. iOS and OS X have long had a fascination with blurring the line between the physical and the digital. Many of the components on Apple’s flagship operating systems have historically been very textured and full of gradients and shadows. This gives the UI depth and a 3-dimensional facade.
The operating system works with bitmaps and drawing libraries like CoreGraphics, but the browser has a very specific tool for creating these kind of visual effects. We call it CSS.
CSS is always preferred over images when it comes to styling elements. The drawback is that while CoreGraphics is powered by the Graphical Processing Unit (GPU), the browser has to paint the CSS which uses the CPU. When CSS effects like patterns, gradients or shadows are combined with animations, the CPU often has to shoulder GPU-like tasks, while also managing core processing for the app and the rest of the OS.
Fortunately, the Flat Revolution has brought with it a quite unexpected benefit for mobile devices. Browsers love flat. It's easy to paint single colors with CSS and it makes a remarkable difference in speed. One of the single biggest performance increases we saw happened by simply moving from standard iOS 6 type gradients to a completely flat UI, which shaved nearly 300ms off view transitions. That being the case, we created a completely flat skin for Kendo UI Mobile.
We also bottled-up all of these improvements and now ship them as part of Kendo UI Mobile. That’s right! Our pain is your immediate gain, as you can now get all of the optimized behaviors and performance in your HTML5 mobile apps simply by using Kendo UI Mobile widgets.
The perception about HTML5 is mostly affected by the assumptions that the browser should be able to handle anything we throw at it without much work on the developer's part. This simply isn't the case, and frankly is a highly unfair expectation to put on any runtime.
Additionally, we expect HTML5 to perform the same across devices, no matter the form factor or specs. Even the operating system on older versions of Android is sluggish. Why would we expect an application that performs well on an iPhone 5S to perform exactly the same on an Android 2.3 device?
It's time to change perceptions about HTML5. No more unfair comparisons and assumptions. Load up Cuteness on a current device (the iPhone 5S is simply amazing) and try it out for yourself. As little as six months ago there was speculation that the rather large chasm between the performance of the operating system and that the browser would never be closed, and yet the devices rolling off the line today have already reduced that limitless void to a hardly distinguishable and rather blurry line.
HTML5 is not a framework. The browser is simply a runtime. Kendo UI Mobile provides the optimized components that iOS and Android have shipped since day one. Modern devices have closed the performance gap and HTML5 is ready for prime time.
Burke Holland is a web developer living in Nashville, TN and the Director of Developer Relations at Telerik. He enjoys working with and meeting developers who are building mobile apps with jQuery / HTML5 and loves to hack on social API's. Burke works for Telerik as a Developer Advocate focusing on Kendo UI.
Copyright © 2016, Progress Software Corporation and/or its subsidiaries or affiliates. All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.