| I don't think Jonas was dishonest in any way. I think Mozilla talked to front-end Javascript devs who came from a "NoSQL" background (after all, Javascript devs are what begat "web scale" MongoDB) and who had disdain for SQL. I think that disdain sealed the fate of any SQL-based API in HTML5, irrespective of the involvement of SQLlite. The "no independent implementations" was certainly a convenient way to dismiss away the already-implemented SQLlite-based solution. It's a valid argument for rejecting SQLlite as the spec, for sure. Implementations notwithstanding it seems like Mozilla was unwilling to even consider anything SQL-based. The same tone comes out in the "Beyond HTML5: Database APIs and the Road to IndexedDB" Mozilla blog post[0]: > In order to really get Web SQL Database right, we’d have to first start with defining a meaningful subset of SQL for web applications. Why define a whole other language, when more elegant solutions exist within JavaScript itself? ... > We were resolved that using strings representing SQL commands lacked the elegance of a "web native" JavaScript API ... That sounds like the same rhetoric used in the early MongoDB / NoSQL craze days to dismiss RDMS, ACID, JOINs, etc. Never mind that SQL is a battle-hardened DSL that has proven itself to be suitable to the task-- it wasn't "elegant" enough for the front-end devs Mozilla surveyed. As an aside, I also find the quote from that post very amusing: > In another article, we compare IndexedDB with Web SQL Database, and note that the former provides much syntactic simplicity over the latter. The example for a JOIN using IndexedDB in the referenced article[1] looks strained. It really doesn't look like it has "syntactic simplicity" compared to the WebSQL version above it. [0] https://hacks.mozilla.org/2010/06/beyond-html5-database-apis... [1] https://hacks.mozilla.org/2010/06/comparing-indexeddb-and-we... |