Exactly

>>You referenced the right docs. Thomas got the story right: Oracle, in particular, wanted to get a sql db out of HTML5. I had the name wrong: SQLite was the one. With it in place, disconnected data is a snap, as much as disconnected data can be a snap. Without it, you are back in the dark ages. But, with native, having sqlite is easy, if it's not in fact already there, waiting to be used.
>
>Hmm, per Thomas, just digging a little more into this. Looks like Oracle was/is promoting BerkeleyDB, which its Wikipedia page claims is "the most widely used database toolkit in the world, with hundreds of millions of deployed copies". If SQLite is widespread on mobile I'd have to doubt that claim.
>
>You'd think something named "BerkeleyDB" would use a BSD-style license. Its so-called "Sleepycat" license is actually kind of obnoxious, and IMO not suitable for inclusion in something that is meant to become a widespread standard (i.e. HTML5).
>
>>You nailed the speed issue also: it's all relative. And the standard is native apps. If your app is noticeably (by the user) slower displaying or (and this is a frequently noted issue) when changing aspect (turning vertical to horizontal and v-v), the user notices, and doesn't like it. It's all under 1.1 seconds either way, mind you. On native it snaps, and in HTML5, unless there is the right combination of everything, it paints. Users notice, and wonder, and complain.
>>
>>Hank
>>
>>>Hmm, I missed the bit about the HTML5 persistent storage PR blitz, is there an executive summary somewhere?
>>>
>>>UPDATE: there seem to be a couple of APIs, "Web SQL Database" and "Indexed Database API". The former seems to be moribund, don't know about the latter. The first articles I've seen about them discuss SQLite rather than MySQL.
>>>
>>>Side issue, since you mentioned web-based being "noticeably slower than native apps": I wonder what is considered "fast enough", these days. Years ago I remember hearing that a response time of 2 seconds was considered "fast enough". It's probably faster today. After all, we have a civic duty to reduce car crashes etc. due to inappropriate apping/texting etc. :-/
>>>
>>>>I've got two mobile app (families) planned for the first year. They will both be browser based at first; but one will move to native as it is available. The one that will stay browser based will be for users who will use it only occasionally: it's not an everyday app, just has a very wide potential user base. The second is just the opposite: small, targeted user base, and used many times a day.
>>>>
>>>>HTML5 may make it some day, but for the next few years, at least, displaying the DOM, even with tricks like pre-architecting segments on the back end, will be noticeably slower than native apps (because the direct access to video feature of HTML5 is a long way from becoming fact). Plus there's the persistent storage issue in HTML: as Thomas has noted, the best solution was ousted by the powers that be, with a PR blitz (about MySQL not being a standard) worthy of the presidential campaigns.
>>>>
>>>>Depending on how a browser app is deployed, it can have an Icon.
>>>>
>>>>Hank
>>>>
>>>>>>As per previous posts there are numerous vendors who earned their billions from served web interfaces (e.g. ebay, priceline, godaddy, amazon) who nevertheless promote locally installed apps for mobile devices. Why? Perhaps it's temporary pending 100% reliable mobile networks- though the niche experts assert that there never can be such a thing.
>>>>>
>>>>>Does an installed app put an icon on your device? If so, that's eyeball share you don't get with a generic browser. Also starting an app has to be faster than starting the same functionality delivered via a browser. Eliminate any impedance between users and your goods and services.