How To Use IndexedDB - Simple Example | Hacker News Reader

How To Use IndexedDB - Simple Example

greenido.wordpress.com

31 pointsronreiter13 comments

Anybody thinking of using IndexedDB should be familiar with the concept of unhosted apps and remote storage, because IndexedDB is one of the technologies that may comprise remoteStorage-compatible websites and webapps.

http://www.w3.org/community/unhosted/wiki/RemoteStorage

http://unhosted.org/

We should use this client-side storage solutions to move in the direction of clients owning and controlling their data - along with better support for offline use.

Very true... I agree, we should have (another) example that show the power of 'offline' with indexedDB.

I wish we had just stuck with WebSQL.

WebSql was just about a single open source project - SQLite. IndexedDB seems to move away from the requirement that a standard is based on a product. Also, the SQL used in WebSql was not standardized.

Yes. But SQLite 3 is Public Domain, and I expect you could reimplement it in the browser if you really wanted to.

But the parent's point stands; IndexedDB is just a set of APIs. A browser vendor can implement it on the backend any way they want. Chrome uses LevelDB and Firefox uses SQLite. When WebSQL they were stuck with improving SQLite.

Unfortunately they chose a set of APIs that is strictly weaker than what we have access to via WebSql.

When I port from WebSql to IndexDb, I will need to implement in Javascript a bunch of things that sqlite3 is already doing for me in C.

I actually started out with a very NoSQL-like architecture on top of WebSql that's closer to the IndexDb model. But when I started taking more advantage of sqlite3 to do the heavy lifting (joins, nested subqueries, etc) I got an order of magnitude better performance. Switching to IndexDb means going back to the slow way.

I agree that those are drawbacks, but they're drawbacks of the standards process used, not the technology itself. They could have standardized around the subset of SQL supported and alleviated those concerns.

IndexDB seems to be deliberately dumbed down in capability just to make it easier to describe in a standards document.

If we were all suffering from interoperability problems with WebSql there might be an argument for something simpler. But that's not the case -- wherever it's implemented, WebSql works the same. It turns out a good open source implementation makes a really good standard. It leaves no room for ambiguity.

And anybody who really wants to do their own implementation has free access to everything they need to know to be compatible. The fact that no one has done so just shows that sqlite3 is already good enough, and it's silly not to just use it.

This polyfill for onupgradeneeded lets you ignore the Chrome deficiency. Come on Chrome team, it's been almost a year since this change happened.

https://raw.github.com/matthewp/multientry-shim/master/upgra...

Chrome 23 supports onupgradeneeded.

Added this IndexedDB polyfill to the example and was able to get it running on all browsers

http://axemclion.github.com/IndexedDBShim/dist/IndexedDBShim...

Thanks! This is great shim... very powerful to have the same source code for mobile (iOS and Android).

Instead of shimming, directly wrapping IndexedDB API and fail back to WebSQL have better performance and more robust https://bitbucket.org/ytkyaw/ydn-db

Reply on news.ycombinator.com