It seems that some HTML5 people have developed a serious case of “Mobile Envy.” Some medieval looking evangelists from endofnative.com have even recently circled Moscone with signs:
Sasha Aickin, the Search Team Lead at redfin.com has pictures of these creative cats in her presentation on the Redfin corporate blog: “HTML 5 vs. Native”.
Web developers want mobile devices to handle HTML5 applications as if they were native apps. Access to mobile markets, in-app payments, the file system, etc. But that can’t happen without native code until magical HTML5 fairies can fly through the air and control the hardware on your phone.
But that aside, this debate is a good opportunity to look at mobile architecture and see how to work with HTML5.
“Speed Kills. Performance is where abstractions go to die.”
That’s a phrase Sara Aickin wrote in her presentation, and it’s very true. The bridge between mobile hardware and HTML5 web-apps can happen, but not without some serious engineering and attention to the limitations of the hardware. If you do a quick survey of what’s already being done in this area, you’ll see some pretty cool options.
How Could HTML5 be Handled?
In the hardware: there’s nothing preventing the design of a microchip that could support HTML5 at the hardware level, but I haven’t seen anyone working on it.
Pros: fast processing; Cons: no upgrade path, and ever more complex hardware.
In the OS: the operating system can be designed to handle HTML5 applications in an optimized way and not just in the browser. WebOS is a good example:
Pros: faster than the web browser and easier access to the entire phone. Cons: the hardware is limited in what it can do – many mobile phones might not handle the functionality well.
In a 3rd party library: libraries are how mobile developers give web developers access to a mobile device’s hardware. THey can be designed around a standardized API specification. PhoneGap is a good example of this approach:
Pros: allows developers the ability to optimize the code that web apps would rely on. Cons: each phone model is different, it’s not possible to write a single API spec to build a library around that would apply equally to all phones.
With a code generator: a good, generalized design tool can generate source code for multiple devices that can be compiled using a mobile devices’ native toolkits. Check out ReadWriteWeb’s blog for a list of some of these applications.
Pros: allows non-developers like graphic designers the ability to generate useful code for a mobile developer. Cons: non-developers have to become comfortable using a developer tool.
With a develpment toolkit/framework: tools exist that generate applications and or code that run on multiple phones. There are a number of ways to do this. Appcelerator Titanium is an example of this approach
Pros: ease of use and lots of hand holding for non-developers; Cons: a lowest common denominator of phone and user interface must be relied upon which is often not as attractive as just a straight web experience, and the resulting applications tend to be way to big.
On the server side: There’s nothing preventing someone from building a server-side pre-processing scheme that compiles all your web code into something secure and save that a mobile device can utilize. Nothing would change for the web developers. I haven’t seen any projects that are taclking this.
Pros: would help improve performance of mobile applications, especially with respect to networking and allows web developers to still write mobile applications. Cons: increases the complexity of web services and adds to the time requiredx to manage a web server.
The difference between these kinds of tools is the audience they are written for and the quality of the application that they produce.
So, what’s best?
Well, that’s up for you to decide. If I had my choice, I would explore integrating HTML5 into the native phone stack in all those areas if I could. Advances in any one of those areas has the potential to make one of the others obsolete, so you have to cover your bets.
One thing is for sure in the meantime, mobile phones handle HTML5 apps in the way they do simply because that’s the best the mobile devices can do. And it won’t change until the hardware and/or application stack on mobile devices itself changes.