3 ms·

> Depending on every browser vendor to play along in sync is, quite frankly, a lost cause. Very true, but that is not mutually exclusive with not understanding

> Depending on every browser vendor to play along in sync is, quite frankly, a lost cause. Very true, but that is not mutually exclusive with not understanding why it's a lost cause. There's literally three browser vendors, and of those, really only one of them needs to go "fuck it, sqlite now has an API" and the other two kind of don't have a lot of choice but to follow suit. It's a Chrome world right now. We could have easily done this, we chose not to. Why? (and you probably don't have the answer to that. I don't know if anyone does)

sgbeal 4y ago
> There's literally three browser vendors, and of those, really only one of them needs to go "fuck it, sqlite now has an API" and the other two kind of don't have a lot of choice but to follow suit. It's a Chrome world right now. In the general case, admittedly true. Note, however, that the Chrome folks have no say-so in the shape of this particular sqlite API, with the tiny exception that they are not willing to create a 100% synchronous API for OPFS, which complicates the sqlite-side development of that one small part of the API considerably[^1]. The shape/flavor/whatever we'd like to call it of the sqlite JS/WASM APIs is left 100% to the project members' discretion. If Chrome dies tomorrow, this API is still a thing, it will just have severely reduced client-side persistence options until the next hypothetical vendor creates one, at which point we'd latch onto that one. [1] = When we consider that async APIs exist largely to account for network latency, and OPFS _has no latency_ beyond the local storage device, OPFS's interface being async is, IMHO, a design flaw stemming from the misled assumption of "it's on the web ergo it must be async" (and i've told them that in emails and meetings). Based on our testing metrics, the performance of the OPFS sqlite layer would increased by at least 30% if it had a 100% synchronous API to work with, as it tends to waste anywhere from the low-30s to mid-40s percentage points of its time waiting at cross-thread communication boundaries.

sgbeal 4y ago

> There's literally three browser vendors, and of those, really only one of them needs to go "fuck it, sqlite now has an API" and the other two kind of don't have a lot of choice but to follow suit. It's a Chrome world right now. In the general case, admittedly true. Note, however, that the Chrome folks have no say-so in the shape of this particular sqlite API, with the tiny exception that they are not willing to create a 100% synchronous API for OPFS, which complicates the sqlite-side development of that one small part of the API considerably[^1]. The shape/flavor/whatever we'd like to call it of the sqlite JS/WASM APIs is left 100% to the project members' discretion. If Chrome dies tomorrow, this API is still a thing, it will just have severely reduced client-side persistence options until the next hypothetical vendor creates one, at which point we'd latch onto that one. [1] = When we consider that async APIs exist largely to account for network latency, and OPFS _has no latency_ beyond the local storage device, OPFS's interface being async is, IMHO, a design flaw stemming from the misled assumption of "it's on the web ergo it must be async" (and i've told them that in emails and meetings). Based on our testing metrics, the performance of the OPFS sqlite layer would increased by at least 30% if it had a 100% synchronous API to work with, as it tends to waste anywhere from the low-30s to mid-40s percentage points of its time waiting at cross-thread communication boundaries.