Write once run everywhere, version 2.0

In 1996, according to the Wikipedia, Sun Microsystems promised, 

Java’s write-once-run-everywhere capability along with its easy accessibility have propelled the software and Internet communities to embrace it as the de facto standard for writing applications for complex networks

That was version 1.0. Version 2.0 of the write-once-run-everywhere promise goes to HTML5. There are four real challenges with pure HTML5 apps, though, especially on mobile devices:

• The specification isn’t finished, and devices and browsers don’t always support the full draft spec.
• Run-time performance can be slow, especially on older mobile devices – and HTML5 apps developers can’t always manage or predict client performance.
• Network latency can adversely affect the user experience, especially compared to native apps.
• HTML5 apps can’t always access native device features – and what they can access may depend on the client operating system, browser design and sandbox constraints.

What should you do about it? According to Ethan Evans, Director of App Developer Services at Amazon.com, the answer is to build hybrid apps that combine HTML5 with native code.

In his keynote address at AnDevCon earlier this month, Evans said that there are three essential elements to building hybrid apps. First, architecting the correct division between native code and HTML5 code. Second, make sure the native code is blinding fast. Third, make sure the HTML5/JavaScript is blinding fast.

Performance is the key to giving a good user experience, he said, with the goal that a native app and a hybrid apps should be indistinguishable. That’s not easy, especially on older devices with underpowered CPUs and GPUs, small amounts of memory, and of course, poor support for HTML5 in the stack.

“Old versions of Android live forever,” Evans said, along with old versions of Webkit. Hardware acceleration varies wildly, as does the browser’s use of hardware acceleration. A real problem is flinging – that is, rapidly trying to scroll data that’s being fed from the Internet. Native code can handle that well; HTML5 can fall flat.

Thus, Evans said, you need to go native. His heuristic is:

• HTML5 is good for parts of the user experience that involve relatively low interactivity. For example, text and static display, video playback, showing basic online content, handling basic actions like payment portals.
• HTML5 is less good when there is more user interactivity. For example, scrolling, complex physics that use native APIs, multiple concurrent sounds, sustained high frame rates, multi-touch or gesture recognition.
• HTML5 is also a challenge when you need access to hardware features or other applications on the device, such as the camera, calendar or contacts.
• Cross-platform HTML5 is difficult to optimize to different CPUs, GPUs, operating systems versions, or even to accommodate single-core vs. multi-core devices.
• Native code, by contrast, is good at handling the performance issues, assuming that you can build and test on all the key platforms. That means that you’ll have to port.
• With HTML5, code updates are handled on the server. When building native apps, code updates will require apps upgrades. That’s fast and easy on Android, but slow and hard on iOS due to Apple’s review process.
• Building a good user interface is relatively easy using HTML5 and CSS, but is harder using native code. Testing that user interface is much harder with native code due to the variations you will encounter.

Bottom line, says Amazon’s Ethan Evans: HTML5 + CSS + JavaScript + Native = Good.