Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A future for SQL on the web

jlongster.com

Post reply on HN
Print view View original

111–120 of 227 posts

Re: A future for SQL on the web

#111

Post by jlongster »

mst wrote: post #94
jlongster wrote: post #46

Earlier quoted context omitted.

Yep, this is the biggest problem (although I haven't seen it happen after 7 days, at least on desktop). We will provide a new backend for the Storage Foundation API when it's available.

Clearly the solution to this is to keep a query log in an extra table and periodically stream that to the server as a form of logical replication (plus perhaps being able to load the initial database state from the server side as well, maybe even on-demand using the GH pages trickery until a write forces materialisation into IndexedDB). As a bonus point this effectively adds yet another level of "Yo, Dawg" which I ca…

People are already trying to get me to hook up https://litestream.io/ to it

Re: A future for SQL on the web

#112

Post by nightpool »

infogulch wrote: post #20
devwastaken wrote: post #12

Earlier quoted context omitted.

No, SQLite was not safe to be used with arbitrary queries. There were multiple memory vulnerabilities that allowed escape of the browser sandbox. https://www.sqlite.org/cves.html

This article is about how to defend against potential websql vulns. https://www.sqlite.org/security.html

This article only contains mostly information on adding more limits to avoid DoS—nothing there would harden WebSQL against SQLite vulnerabilities except for SQLITE_DBCONFIG_DEFENSIVE, which was only added in response to the zero-day bugs that were found in Chrome after implementing SQLite.

Re: A future for SQL on the web

#113

Post by monocasa »

tarsinge wrote: post #81
derefr wrote: post #49

Earlier quoted context omitted.

I would point out that the article you linked mentions that webapps "added to the home screen" on iOS Mobile Safari are exempt from this garbage-collection process. In such a case, the "add to the home screen" step is being taken as the user expressing the explicit desire to have that data around indefinitely. Which seems sensible to me; webapps should be treated as ephemeral-by-default, and only be allowed persisten…

PWA are not a standard, they are a Google concept pushed through Chrome (OS). I’m fine with Apple never supporting it.

PWA is a Google term, but the whole web app thing is older than even the native app store on iPhone.

Re: A future for SQL on the web

#114

Post by enumjorge »

tshaddox wrote: post #108
adam12 wrote: post #47

Earlier quoted context omitted.

Tim Cook basically lied to Congress when he stated that developers can create web apps as an alternative to using the app store. Edit: In order for this to be true, Apple (at the very least) needs to enable push notifications and an install prompt for progressive web apps.

But it's totally a valid option to have an app that is a web app and does not have push notifications. For the vast majority of apps regardless of platform, I absolutely do not want push notifications. It seems bizarre to consider that feature as a litmus test for whether the web is a usable platform on iPhones. Would you also require web apps to appear in the App Store in order to consider a web as a usable platform…

That’s a fair point, but I’d argue that for cases where the app really needs notifications (for example an alerting system) or when the users want them, building a web app is not actually an alternative even if Apple considers it one.

Re: A future for SQL on the web

#115

Post by Touche »

tarsinge wrote: post #81
derefr wrote: post #49

Earlier quoted context omitted.

I would point out that the article you linked mentions that webapps "added to the home screen" on iOS Mobile Safari are exempt from this garbage-collection process. In such a case, the "add to the home screen" step is being taken as the user expressing the explicit desire to have that data around indefinitely. Which seems sensible to me; webapps should be treated as ephemeral-by-default, and only be allowed persisten…

PWA are not a standard, they are a Google concept pushed through Chrome (OS). I’m fine with Apple never supporting it.

Which specific feature of PWAs is non-standard?

Re: A future for SQL on the web

#116

Post by TingPing »

mst wrote: post #92
tarsinge wrote: post #81

Earlier quoted context omitted.

PWA are not a standard, they are a Google concept pushed through Chrome (OS). I’m fine with Apple never supporting it.

So long as I can also use them in firefox they're 'unstandardised but not single vendor' and at that point I'm not as troubled about it.

Firefox doesn't support PWAs...

Re: A future for SQL on the web

#118

Post by jlongster »

jeffbee wrote: post #64

So, why is IndexedDB so slow on Chrome? Obviously LevelDB doesn't need 10ms for a point read. If it did, nobody would use it for anything. 10ms is a hell of a long time. Is it spawning a process to perform the read or ??

Reads aren't as bad, but any kind of writes seem terrible. Take "10ms" with a grain of salt and view the numbers yourself here: https://priceless-keller-d097e5.netlify.app/

I was profiling on an older computer. On my newer one, summing 100 items takes ~8ms (use the raw idb mode). When I said "simple operations" I meant simple queries that you'd expect apps to write, not just 1 single read/write. It is a little faster for each read/write, but there seems to be a bottom floor. Even if reading an item itself is fast, opening a transaction is slow. So any query, even if it only reads one item, is going to suffer the perf hit of opening a transaction.

It's only twice as fast as Firefox, so overall IDB is still super slow when compared to running the same queries with native SQLite. We're talking summing 100 items taking ~.01ms or less. I have no idea why it's so slow.

Re: A future for SQL on the web

#119

Post by tshaddox »

enumjorge wrote: post #114
tshaddox wrote: post #108

Earlier quoted context omitted.

But it's totally a valid option to have an app that is a web app and does not have push notifications. For the vast majority of apps regardless of platform, I absolutely do not want push notifications. It seems bizarre to consider that feature as a litmus test for whether the web is a usable platform on iPhones. Would you also require web apps to appear in the App Store in order to consider a web as a usable platform…

That’s a fair point, but I’d argue that for cases where the app really needs notifications (for example an alerting system) or when the users want them, building a web app is not actually an alternative even if Apple considers it one.

I don't think Apple considers the web as an alternative platform for apps that are designed to alert you at any time of day for any reason, including when you are not actively using your devices. I think this is a very, very good thing, and doesn't mean that web apps are not a viable alternative to the App Store.
Post reply on HN