Some advantages of HTML5

I just posted this on the jQuery Mobile forum. My motive to inform people on there that it's not all about performance. (And the sole purpose of this is to concentrate on the advantages. Before you flame me for being one sided, I recognize there are disadvantages and that there are many reasons to NOT go HTML5.)

"One of the primary drivers for adopting JQuery Mobile was flexibility in an uncertain world.
Todd, we realize there are many who are under the delusion that native simulation is achievable with HTML5, and I respect the reality check.


However, there are other major advantages of HTML5 adoption - let's not get hung up on the pure 'performance is king' topic. Please bear the following in mind, and don't lose sight of the fact that users of HTML5 frameworks will EXPECT to host them in native wrappers. I'm glad that you cited that it is a secondary aim of jQM to support the Hybrid model of deployment.


1. Flexibility
1a. Adaptability
2. Consistent looks across platforms
3. True cross-platform "write once run anywhere" potential
4. Future proofing
5. Fast track adoption of new platforms


1. Flexibility
Building in HTML5 gives them the option to deploy as a web app, support HTML5 off-site installation (i.e. install to home screen) or use a native wrapper solution to get into the app stores. There may be many reasons that a solution builder may not already know their deployment strategy, not least because they are unsure that they will be pass compliance with an app store's ever changing policies.
(My personal situation is a case in point - we deploy our HTML5 app on Android as a Hybrid but were unable to reach agreement with the AppStore, and so deploy for iPhone on a web server with the option to install as an HTML5 application.)


1a. Adaptability
Another strong potential has been mentioned above. The potential to reach across formats with one adaptable solution is a very strong one, even if it is not front and center of people's minds at the present time. Frameworks like jQM have the potential to change the face of tradition site design by adopting and supporting a unified, adpatable interface across phones, tablets, netbooks, laptops and desktops. The advent of touch gestures and interfaces has revolutionized even the way people now expect to use their mouse.


2. Consistent look across platforms
Whereas the platform providers recommend certain style guidelines for apps built for their platform, some companies also have their own standards of usage and l&f. HTML5 apps can be styled to the unified standards of the company, not the platform provider.


3. True cross-platform "write once run anywhere" potential
By doing an HTML5 app, I am writing to a cross-platform standard. I have one code base, and have the potential to reach many platforms. My alternative? Invest in teams to develop the same app multiple times, or make a decision that only certain platforms are important to me, and shun the others. 

4. Future proofing
So I have an HTML5 app. It doesn't work well on platform X. The trend towards HTML5 standard compliance means that someday it will work on that platform (and someday after that it may even work well!)


5. Fast-track adoption of new platforms
Getting my existing HTML5 app working on a new or future platform will be far less work than re-writing it in their proprietary native language. And if new providers are not on the HTML5 train, they might as well not be in the game.


I hope that the jQM team will realize that these are valid and achievable goals for HTML5 mobile developers, and decide not to leave anyone behind. We're passionate because we care!"

1st Impressions: Google Chrome Beta on Android ICS

Turns out I was right: Google have been working on Mobile Chrome. (I assume it will eventually replace the deficient default Android browser.)
As a x-platform HTML5 webapp developer, I have been burned BADLY by the default Android Browser. It sucked in four main ways:

- internal scrolling widgets (like iScroll)

- form rendering

- non-GPU accelerated 2D transforms

- inconsistent implementation from different OEMs.

The ICS default browser was a slight improvement in forms, but still full of rendering glitches and obviously not utilizing GPU acceleration for ops like scrolling and map panning.
First impressions on Android Chrome: Logistically we should see almost no fragmentation through Chrome than we do through the mangled browser implementations we are getting from the OEMs. (However, it remains to be seen whether some phones (typically HTC) will still omit to implement multi-touch in the browser from ICS forward, but it's a real problem for advanced web apps today.) Form rendering is better, rendering glitches are reduced, but performance is still on par with the ICS default browser. What gives? Chrome claims to implement hardware accelerated rendering? Compare Google or Bing maps on the web with the native implementation and you'll notice obvious lag. Then browse to the same URL with iOS Safari and you'll see how it should be done.
C'Mon Google - We expect better than this. You're LAGGING behind. (Pun intended.)