It’s time to kill the web app

This is a convincing argument that's a stupid rule, not a convincing argument against WebSQL. Standardization processes are and ought to be a means, not an end in themselves.

If standards body rules are blocking progress on new features which are eagerly anticipated by developers and significantly improve the experience for users, that means the rules are broken. Standards bodies work for the community, not the other way around.

Also, this particular bit of standards-lawyering was a blatantly-hypocritical dodge. Virtually every web technology was first implemented in one browser before it was in others.

This is an all-purpose, substance-free objection that could've been, and can be in the future, made against any significant web technology, including those promoted by Mozilla.

Also, every browser, including Firefox, implements IndexedDB with ... sqlite.

One of Mozilla's actual arguments was "we surveyed front-end webdevs, and they said 'ZOMG, SQL isn't webscale!! XD'" Apparently browser development is to proceed on the Idiocracy principle.

But leaving that aside, Apple and Google did their own surveys and found that developers (who had actually used or knew of WebSQL) were overwhelmingly positive. Whereas impressions of IndexedDB are overwhelmingly negative, especially vis-a-vis WebSQL.

To this day, 7 years after its deprecation, and still never having been implemented in a Microsoft or Mozilla browser, developers have voted with their feet for WebSQL; it remains far more frequently used than IndexedDB.

Even as a cross-browser solution, the default remains LocalStorage while IndexedDB languishes in much-deserved obscurity.

>>>the only implementation that the spec allowed, if you were going to achieve interoperability, was a particular version of sqlite.

Good thing then that sqlite is one of the most mature and stablest programs in existence. sqlite's query API has broken backwards compatibility less in 17 years than most any web API does in 5. It wouldn't even be particularly burdensome to track sqlite in near-real-time.

Implausible worst-case scenario, you have to fork sqlite at a specific version. sqlite currently has 3 part-time maintainers.[1] The costs associated with maintaining a fork would be a pittance for an organization Mozilla's size.

Also, sqlite is free software, unencumbered by patents — there's absolutely nothing preventing anyone from making their own independent reimplementation of sqlite, it's just that there's no reason to because the original implementation is comprehensively battle-tested and of excellent quality by any metric.

sqlite is so good that, forget about sqlite's dialect, nobody feels the need to develop a competitor in its niche of embedded RDBMS, period. This is an excellent reason for using sqlite, not against.

>>>There were various ways to solve this problem, including abstracting away the database more (i.e. developing an actual Web SQL with well-defined semantics that were not tied to a particular implementation), but none of the WebSQL proponents were willing to go ahead and put in the time to do that, as far as I can tell.

I'd have preferred an ActiveRecord-style API, which in addition to being more ergonomic also would've been independent of a specific backend, but you can't let the perfect be the enemy of the good. Or abandon both perfect and good in favor of unusable garbage.

>>>The second issue was the fact that WebSQL had synchronous database queries going on. The storage API really should be async, if it's going to be accessed from the "main thread" (the one the Window object lives in).

This is incorrect, WebSQL's API is entirely async. But even if it weren't it wouldn't matter because it's blazing fast, around 50x faster than IndexedDB and as often as not it's the Javascript engine that struggles to keep up rather than the reverse.

>>>I do think we could have done better than IndexedDB, though. It, like many other recent web specs, feels way over-engineered to me.

That's one of the less colorful ways of putting it, yes.

This one's getting quite long so I'll address your other points in a separate reply.

[1] https://www.sqlite.org/crew.html

iOS apps Just Work™, and incidentally the "transactional cost" of just tapping a button once to install any particular app hardly seems onerous to me.

And the fact remains, as is always the case with these debates, that the uncountably vast majority of users could not care less about the underlying technology that lets them play Candy Crush. Nobody is ever going to build a mass-market consumer product targeted specifically at people like you or me regardless of what preferences we have. All users want to know is that their device works the way they expect it to work and is as easy as possible to manipulate.

Having said that, I'd be interested to hear you expand further on what price you think you're actually paying and why you consider it to be too high. What is it about the iOS model that's holding you back so much, and how do those drawbacks outweigh the benefits? In concrete, real-world terms, what is your use case?