On Tue, Sep 29, 2015 at 10:51 AM, Domenic Denicola <d...@domenic.me> wrote:
> I guess part of the question is, does this add enough value, or will authors 
> still prefer wrapper libraries, which can afford to throw away backward 
> compatibility in order to avoid these ergonomic problems? From that 
> perspective, the addition of waitUntil or a similar primitive to allow better 
> control over transaction lifecycle is crucial, since it will enable better 
> wrapper libraries. But the .promise and .complete properties end up feeling 
> like halfway measures, compared to the usability gains a wrapper can achieve. 
> Maybe they are still worthwhile though, despite their flaws. You probably 
> have a better sense of what authors have been asking for here than I do.

Remember that the *entire point* of IDB was to provide a "low-level"
set of functionality, and then to add a sugar layer on top once
authors had explored the space a bit and shown what would be most

I'd prefer we kept with that approach, and defined a consistent,
easy-to-use sugar layer that's just built with IDB primitives
underneath, rather than trying to upgrade the IDB primitives into more
usable forms that end up being inconsistent or difficult to use.


Reply via email to