Does HN have a policy about correcting typos in submitted titles? “aguish” is indeed what the gist currently says, but I’d imagine that’ll be fixed at some point.
If anyone has any details about those QuotaExceededError firing when users have plenty of disk space and really not much data on the domain... I am working mostly with Chrome.
I've ran into a similar problem but not a quota error, sometimes large Blobs simply fail to save for no reason in Chrome. It's only certain blobs and not others. Never tracked down why, but it rendered idb unusable for me in that application.
We need a real robust abstraction for the web that works like a file system. Everything else is just too opinionated and compromises in one way or another.
> Multiple tabs of an app using IndexedDB will invariably write to the same IndexedDb database. Without cross-tab locking, database corruption is hard to avoid.
I solved this a few years ago by generating a uuid in SessionStorage and using that as a composite key for tab isolation. Worked very well. That solution is still in production. The IndexedDB wrapper I used was Dexie. Not great for long-lived data, naturally, but we needed IndexedDB for speed, storage size and an async API.
I later used localForage and I found that to be extremely limiting in comparison (because of LocalStorage being the lowest common denominator). I would not recommend localForage for IndexedDB unless you do really, really, really simple stuff.
IndexedDB implementations in various browsers had their quirks, but by far the quirkiest (buggiest) was Safari. I remember working with their implementation for our web app about 3/4 years ago, and their implementation was so utterly unpredictable and unstable, that even their error messages didn't make any sense. It was as if they'd asked a blithering idiot to do their implementation for them, and didn't check any of the work.
Thankfully, I believe things are better now (i.e. they get the basics of storing data right at least), but looking at this gist, they've found alternative ways of irritating developers.
In the past, it was IE that used to bug the heck out of me, but now Safari has well and truly left IE in the dust in terms of its ability to annoy and dumbfound developers.
12 comments
[ 2.9 ms ] story [ 40.5 ms ] threadWe need a real robust abstraction for the web that works like a file system. Everything else is just too opinionated and compromises in one way or another.
I solved this a few years ago by generating a uuid in SessionStorage and using that as a composite key for tab isolation. Worked very well. That solution is still in production. The IndexedDB wrapper I used was Dexie. Not great for long-lived data, naturally, but we needed IndexedDB for speed, storage size and an async API.
I later used localForage and I found that to be extremely limiting in comparison (because of LocalStorage being the lowest common denominator). I would not recommend localForage for IndexedDB unless you do really, really, really simple stuff.
Thankfully, I believe things are better now (i.e. they get the basics of storing data right at least), but looking at this gist, they've found alternative ways of irritating developers.
In the past, it was IE that used to bug the heck out of me, but now Safari has well and truly left IE in the dust in terms of its ability to annoy and dumbfound developers.
But an earlier post said chrome was the slowest.