- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 4 Apr 2011 09:04:36 -0700
- To: Joran Greef <joran@ronomon.com>
- Cc: Jonas Sicking <jonas@sicking.cc>, public-webapps@w3.org
On Mon, Apr 4, 2011 at 8:07 AM, Joran Greef <joran@ronomon.com> wrote: > On 04 Apr 2011, at 4:39 PM, Jonas Sicking wrote: >> Hence it would still be the case that we would be relying on the >> SQLite developers to maintain a stable SQL interpretation... > > SQLite has a fantastic track record of maintaining backwards compatibility. > > IndexedDB has as yet no track record, no consistent implementations, no widespread deployment, It's new. > only measurably poor performance Ironically, the poor performance is because it's using sqlite as a backing-store in the current implementation. That's being fixed by replacing sqlite. > and a lukewarm indexing and querying API. Kinda the point, in that the power/complexity of SQL confuses a huge number of develoeprs, who end up coding something which doesn't actually use the relational model in any significant way, but still pays the cost of it in syntax. (I found normalization forms and similar things completely trivial when I was learning SQL, but for some reason almost every codebase I've looked at has a horribly-structured db. As far as I can tell, the majority of developers just hack SQL into being a linear object store and do the rest in their application code. We can reduce the friction here by actually giving them a linear object store, which is what IndexedDB is.) ~TJ
Received on Monday, 4 April 2011 16:18:51 UTC