[coolbloke1324]

It includes views, triggers / change events, transforms, collection joins and data binding. Also this allows you to spend more time on interacting with data than worrying about what browser supports what storage. It is also useful even for apps that have no use for storage because looping over JS objects for specific matches in a number of areas of an app will get dirty pretty quickly.

[bonn1]

I thought all browsers support IndexedDB?

However, I think it would be helpful to communicate this as a wrapper around IndexedDB instead of positioning it as another new DB.

[coolbloke1324]

It's really not a wrapper around indexeddb at all. It doesn't even communicate with indexeddb except to save and load data for storage and that is optional. The main use here is for allowing web app developers to be able to load a dataset from a server and then query it dynamically on the client-side, as well as display that data automatically via data-binding.

[bonn1]

But at the end you have to store it somehow and thus you employ the underlying browser DBs for that (like IndexedDB or WebSQL) => wrapper

[coolbloke1324]

But that is the point... you don't have to store it in an underlying browser db. It runs as an in-memory store if you don't use an underlying engine. The persistence module is an optional extra and doesn't even need to be included in the library.

[bonn1]

> The persistence module is an optional extra

But a DB offers usually persistency and you called your product ForerunnerDB

I still think that the communication/positioning/branding of ForerunnerDB could be improved since it's misleading.

[nolanl]

Unfortunately, support is still not great: http://caniuse.com/#feat=indexeddb

Those yellows are really more yellow than green, in my experience. :/