Comment by Groxx | Hacker News Reader

Comment by Groxx | Hacker News Reader

Not quite, methinks:

>This document was on the W3C Recommendation track but specification work has stopped. The specification reached an impasse: all interested implementors have used the same SQL backend (Sqlite), but we need multiple independent implementations to proceed along a standardisation path.

That notice has been up for quite a while now. They're just making it plainer that they've given up, because there's already a spec out there that they don't have control of.

Also, to perform a join in IndexedDB, you've gotta do it by hand, iterating over the results and merging data programmatically[1]. While WebDatabases have a PITA async-only API for reasons which are entirely beyond my comprehension, SQL is an incredibly capable language for interacting with a database, and has very mature and efficient implementations. Losing that would count as a massive loss to me. Why can't we have both? WebKit / Chrome is already going this route, as they have WebDatabase and recently implemented IndexedDB as well.

[1]: http://hacks.mozilla.org/2010/06/comparing-indexeddb-and-web... example 4

While WebDatabases have a PITA async-only API for reasons which are entirely beyond my comprehension

That's because they want to support responsive applications. Javascript doesn't really have native concurrency operations, so the best (only?) way to do it is via async operations.

It's like XMLHttpRequest: Async only, which can be harder to program, but makes it a lot more robust.

> Javascript doesn't really have native concurrency operations

Except for Web Workers, also part of HTML5. The way Google Gears handled this was to allow synchronous database operations only in worker contexts.

Worker<->UI communication is asynchronous, and has additional limitations (only copying, only JSON-able data), so synchronous worker API in many cases would just shift complexity elsewhere.

In part. It makes conditional, nested queries much simpler, however, when you don't need to nest async callbacks 20 layers deep.

I understand that having a synchronous API would mean more people would use it. But honestly, I see that as their problem. A fair number of queries, such as "select * from your_table where id = ?", are useful to have synchronous as an option, and should perform quickly enough to be invisible. And synchronous can easily be made asynchronous, but the other way around is essentially impossible without any Thread.join.

Reply on news.ycombinator.com