
What’s new in IndexedDB 2.0? - dwaxe
https://hacks.mozilla.org/2016/10/whats-new-in-indexeddb-2-0/
======
Achshar
I still feel that the api is a lot more complicated than it has any right to
be. WebSQL for example was nifty little thing that worked just fine as far as
me as a dev is concerned. I realize there must have been considerable issues
with it from implementation POV but IDB seems so much worse (to me at least).

~~~
pilif
It wasn't so much of an implementation issue as it was politics around the
spec that killed it: As WebSQL basically happened by just exposing a SQLite
runtime to JS, there was never a clear spec of what WebSQL should support (no
- "it just supports all that SQLite supports" is not good enough).

And even if somebody went in and specified all of SQLite's features, then
there would still be the issue that any accepted web standard needs two
independent implementations, meaning that one of the browsers would have had
to clean-room reimplement SQLite.

And finally, there would be the question of what to do as SQLite involved.
What would browsers do as SQLite gains features or changes behaviour? Keep the
old version of SQLite around for JS? Freeze the whole browser on the old
version of SQLite?

I agree though that WebSQL was much more convenient and useful than IndexedDB.

~~~
egeozcan
IIRC, the idea was making IndexedDB low-level, giving way to the library
authors to create something easier to use.

I'm not sure if that ever happened.

~~~
robin_reala
PouchDB[1] sits on top of IndexDB (or WebSQL and other methods) and exposes a
CouchDB-like interface.

[1] [https://pouchdb.com/](https://pouchdb.com/)

~~~
aikah
But that's yet another dependency to load that is not written in C++/C, not
good enough.

~~~
untog
It's client side JS, why would it be written in C++/C?

~~~
aikah
Neither WebSQL or IndexedDB are written in Javascript themselves.

------
jakub_g
The announcement made me check caniuse for IndexedDB support, and it turns out
that Safari 10 finally has non-broken IndexedDB:

[http://caniuse.com/#feat=indexeddb](http://caniuse.com/#feat=indexeddb)

[https://developer.apple.com/library/content/releasenotes/Gen...](https://developer.apple.com/library/content/releasenotes/General/WhatsNewInSafari/Articles/Safari_10_0.html)

[https://github.com/localForage/localForage/issues/604#issuec...](https://github.com/localForage/localForage/issues/604#issuecomment-247335607)

[https://gist.github.com/nolanlawson/08eb857c6b17a30c1b26](https://gist.github.com/nolanlawson/08eb857c6b17a30c1b26)

~~~
dumbmatter
Despite what some claim, Safari 10's IndexedDB is still quite broken, except
possibly for some trivial cases (like if you only use one object store, or you
don't use indexes):
[https://www.reddit.com/r/javascript/comments/545ylm/psa_inde...](https://www.reddit.com/r/javascript/comments/545ylm/psa_indexeddb_on_safari_10_is_still_shitty/)

~~~
jakub_g
Good to know, thanks for sharing!

------
ralusek
If any of you are serious about using IndexedDB, please consider:

[https://github.com/google/lovefield](https://github.com/google/lovefield)

Explanation here:
[https://www.youtube.com/watch?v=S1AUIq8GA1k](https://www.youtube.com/watch?v=S1AUIq8GA1k)

------
tuckerjt07
I'm currently working on a Angular2 cache management, similar to Redis,
wrapper for IDB and these features will help quite a bit with a few of the
lower performance operations in my API.

------
amelius
What happens if you access the database simultaneously from different browser
tabs? Also, is there some eventing mechanism to push messages through the
database between tabs?

~~~
dumbmatter
_What happens if you access the database simultaneously from different browser
tabs?_

It works fine. Transactions prevent conflicts. And you can even do schema
upgrades because there is built-in versioning, and it provides events to let
you handle when a version change occurs in another tab.

 _Also, is there some eventing mechanism to push messages through the database
between tabs?_

No, you have to do that yourself.

------
jstclair
No mentions of promises? Any reason to rev the spec _without_ promises?

~~~
bwindels
IIRC the main reason indexeddb does not use promises is because promises are
required to reject/resolve asynchronously [1]. Indexeddb requires that you
manipulate the object stores in a synchronous way from it's event handlers, so
it can terminate the transaction after running the event handlers
synchronously. It can't do this with promises that will run their resolve
handler at best in the next microtask.

It's been a while since I looked into this, but I remember this being my
conclusion.

1: [https://promisesaplus.com/#point-34](https://promisesaplus.com/#point-34)

~~~
dumbmatter
That's actually not true in Chrome
[https://bugs.chromium.org/p/chromium/issues/detail?id=457409](https://bugs.chromium.org/p/chromium/issues/detail?id=457409)
although it's not clear if that is a bug in Chrome or in other browsers. It
would be nice to have more clarity on that, or an explicit promise API like
[https://github.com/inexorabletash/indexeddb-
promises](https://github.com/inexorabletash/indexeddb-promises) because until
then it's really shitty to use - you have to constantly worry about cross-
browser compatibility.

