How should we now approach the debate circling the use of native mobile application software development versus the benefits offered by concentrating on apps developed for the mobile web using HTML5?
Although Mark Zuckerberg thinks that "betting completely" on HTML5 is a bad choice to make despite the fact that his company had done so in the past, not everything the Facebook founder touches turns to gold.
The goal here is the creation of the so-called "consistent user experience" across all devices in any usage scenario.
HTML5 also benefits from its easier (than old HTML) methods for updating web applications that do not require users to download or install physical updates to their machines; as we might consider normal with a "native" app that is installed directly onto a user's smartphone, tablet or indeed any other device.
While native apps will typically run in more offline scenarios with no Internet connection, the porting of this software across multiple devices and platforms is the painstaking part of the equation which, in general terms, can be circumvented by use of an HTML5 app via a browser.
But HTML5 has also been called out for its limitations.
Interdependencies, nuances and fragmentation issues
Is it a consistent user experience in all use cases via a browser? No not quite, HTML5 apps can render and perform differently depending on the browser and the device platform being used; there are just too many application interdependencies, nuances and fragmentation issues for the seamless "same app anywhere" Holy Grail to be there - not quite yet anyway.
HTML5 has also been criticised for having weaker and less intuitive User Interfaces (UIs) for some application deployments than native apps.
There has also been developer consternation over missing HTML5 APIs and the suggestion that it is sometimes more difficult to route monetising advertisement streams onto HTML5 sites than it is to target older HTML ones.
In fact, HTML5 has even been criticised for not having the required level of DRM (Digital Rights Management) that it really needs to be able to serve all the multimedia services that it needs to.
Support for background processing functionality and the overall security of its data storage capabilities have also been questioned.
If you consider the basic laws of physics, HTML5 application execution is (at this stage) also logically going to lag behind native app execution functions that plug into core components of the device by virtue of proximity such as the camera, accelerometer, gyroscope, GPS system, microphone and calendar etc.
The thing to remember here at the still comparatively early and still formative stage is that it's not a complete "native or HTML5 only trade off" situation i.e. it is possible to developer native apps with a portion of HTML5 web-centric connectivity such they benefit from some a layer of extra connectivity.
Think of it as a hybrid app approach where elements of native code are presented in an HTML5 wrapper.
This debate has only just begun.