121–130 of 227 posts
> Every [IndexedDB] library I looked at was messy and made performance even worse Seconded – I was pretty dismayed when I saw the IndexedDB helper library landscape. I ended up making https://github.com/TehShrike/small-indexeddb which is ~50 lines to make it less onerous to work directly with the IDBObjectStore.
https://github.com/jakearchibald/idb
It's basically a promise-based version of the standard API.
So it sounds like IndexedDB was the right abstraction all along.
Earlier quoted context omitted.
Well, I woudln't call using IndexedDB "exactly that". As IndexedDB is rather fleeting. You don't use a server, that is correct. But IndexedDB goes away under many circumstances. Saving a file via the File System Access API would give the user peace of mind that it is safe. I did not see any mention of the File System Access API in your post.
Read harder. https://jlongster.com/future-sql-web#more-than-just-another-...
"Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that.""
This is funny and sad to me. We had SQLite in the browser[0]. I only did a little bit of work with it but it seemed actually pretty nice. It was torpedoed because it was SQL-based (and not trendy "key value" and "web scale"). There was the whole excuse that the specification was "whatever SQLite does" and, therefore, not suitable for being a standard. There would be worse things than SQLite upon which to base a stand…
The excuse was that a standard needs to have multiple implementations otherwise we are standardising implementation details and bugs. Hindsight shows that was entirely correct, as SQLite bugs were then found that could be exploited directly via WebSQL, Firefox of course was not vunerable. ( https://hub.packtpub.com/an-sqlite-magellan-rce-vulnerabilit... ) As a sidenote, I worked a lot with the WebSQL API and it was n…
And yet we're are now at a point where Chrome rams its own APIs through standards bodies, and there are no (and often won't be) any independent competing implementations.
this may be the most performant/secure/cheapest b2b saas stack ever
every customer gets own sqlite database, downloads it to their browser on first load, each db gets synced to s3
everything is served statically from s3 as well
> that allows SQLite to read/write from IndexedDB in small blocks, just like it would a disk So it sounds like IndexedDB was the right abstraction all along.
Another spec that failed from a practical perspective because of Mozilla's reluctance to implement key aspects of it is web components.
On a similar note, have this nagging feeling that we used to have this ability to use SQL in client-side applications. I just can't recall how?
/s
This is funny and sad to me. We had SQLite in the browser[0]. I only did a little bit of work with it but it seemed actually pretty nice. It was torpedoed because it was SQL-based (and not trendy "key value" and "web scale"). There was the whole excuse that the specification was "whatever SQLite does" and, therefore, not suitable for being a standard. There would be worse things than SQLite upon which to base a stand…
The excuse was that a standard needs to have multiple implementations otherwise we are standardising implementation details and bugs. Hindsight shows that was entirely correct, as SQLite bugs were then found that could be exploited directly via WebSQL, Firefox of course was not vunerable. ( https://hub.packtpub.com/an-sqlite-magellan-rce-vulnerabilit... ) As a sidenote, I worked a lot with the WebSQL API and it was n…
Looks at Chrome
Earlier quoted context omitted.
Read harder. https://jlongster.com/future-sql-web#more-than-just-another-...
Hey, can you please not do this ("Did you read the post?", "Read harder", etc.), even when someone else hasn't read an article? I understand how frustrating it can be when people don't read what you write very closely (believe me, I understand), but it's one of the tropes that degrade discussion and we're trying to avoid sinking to that level here. " Please don't comment on whether someone read an article. "Did you e…
> Every [IndexedDB] library I looked at was messy and made performance even worse Seconded – I was pretty dismayed when I saw the IndexedDB helper library landscape. I ended up making https://github.com/TehShrike/small-indexeddb which is ~50 lines to make it less onerous to work directly with the IDBObjectStore.
I've had good experiences with https://github.com/jakearchibald/idb It's basically a promise-based version of the standard API.