A future for SQL on the web • Hacker News Board

Re: A future for SQL on the web

#71

Post by coliveira » Thu, Aug 12, 2021, 5:54 PM UTC

SahAssar wrote: post #27

EvanAnderson wrote: post #4

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 justification was more that the standardization process requires at least 2 independent implementations, and nobody was working on rewriting SQLite from scratch. I would have loved WebSQL, but it is reasonable to require multiple implementations for full standardization.

I don't buy this reasoning because they could have standardized only the interface, letting it open for developers to choose SQLite or some other future implementation. There is no need to standardize SQLite behavior, including bugs.

Re: A future for SQL on the web

#72

Post by justsomeuser » Thu, Aug 12, 2021, 5:56 PM UTC

bob1029 wrote: post #58

> SQLite, even though it’s implemented on top of IndexedDB, easily beats out IndexedDB in every single performance metric. The absurdity! This really is quite incredible. Same idea extends to your filesystem too. Tracking millions of 1KB objects on disk? You could load the whole set into memory substantially faster from SQLite using the same disk. If WAL is enabled with reasonable sync flags, the same applies going b…

Nice. What kind of business logic are you using SQL queries for?

Re: A future for SQL on the web

#73

Post by coliveira » Thu, Aug 12, 2021, 5:57 PM UTC

411111111111111 wrote: post #62

kall wrote: post #22

Earlier quoted context omitted.

Yeah I think so too. It‘s a cliche by now to say these things go in cycles but they do. If we like this part of the cycle, let‘s ride it and let SQL get hyped, even though its been around forever and never went away.

What gives you the confidence that it's going on circles? I cannot see our industry repeating the mantra that NoSQL solves all our persistence problems ever again. There are use cases for them, but not everything is a good fit and I'm pretty sure we found that out as an industry. I'm sure there are always going to be individuals that will claim that they're better at everything, but that doesn't really mean anything.…

The cycles don't happen exactly. But I'm pretty sure they will come up with something new that in the end is the same as NoSQL and give it a trendy name, so young developers will believe they found gold and run with it... It is just the way these things keep happening.

Re: A future for SQL on the web

#74

Post by z3t4 » Thu, Aug 12, 2021, 5:58 PM UTC

adam12 wrote: post #47

lioeters wrote: post #32

> browsers may delete your IndexedDB database under certain conditions Safari will happily delete your IndexedDB database after 7 days of inactivity. It deletes "all of a website’s script-writable storage after seven days of Safari use without user interaction on the site". That includes: - Indexed DB - LocalStorage - Media keys - SessionStorage - Service Worker registrations and cache Source: https://webkit.org/blog…

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.

Apple did plan to make web apps first class on iPhones. But changed their minds when developers complained about not getting hard metal access. Maybe they thought that supporting web apps would get them more apps, but developers gave them apps for free and it allowed Apple to have a monopoly. Microsoft tried the same with their phones but somehow failed... Google went the web app route on ChromeOS with decent success. Mozilla tried with FirefoxOS but was too early - FirefoxOS is now very popular but under another name on low end hardware phones.

Re: A future for SQL on the web

#75

Post by collaborative » Thu, Aug 12, 2021, 6:01 PM UTC

So good to see persistent dbs coming to the web. I also started using https://github.com/WebReflection/sqlite-worker which is pretty similar

Re: A future for SQL on the web

#76

Post by sosodev » Thu, Aug 12, 2021, 6:07 PM UTC

Thank you for this. I've been hoping for something like this for ages.

Re: A future for SQL on the web

#77

Post by danielovichdk » Thu, Aug 12, 2021, 6:13 PM UTC

I stopped reading after this

"If you are writing a web app today, you’ll probably choose IndexedDB to store data. It’s the only option for something database-like that works across all browsers."

RDBMS all the way baby

Re: A future for SQL on the web

#78

Post by mschuster91 » Thu, Aug 12, 2021, 6:13 PM UTC

lioeters wrote: post #32

> browsers may delete your IndexedDB database under certain conditions Safari will happily delete your IndexedDB database after 7 days of inactivity. It deletes "all of a website’s script-writable storage after seven days of Safari use without user interaction on the site". That includes: - Indexed DB - LocalStorage - Media keys - SessionStorage - Service Worker registrations and cache Source: https://webkit.org/blog…

So that is why a website I work on has complaints of Apple users who keep getting nagged by cookie banners - they store their settings in LocalStorage since cookies tend to have issues when the content is too long. Thank you so very much.

Re: A future for SQL on the web

#79

Post by mschuster91 » Thu, Aug 12, 2021, 6:16 PM UTC

SahAssar wrote: post #27

EvanAnderson wrote: post #4

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 justification was more that the standardization process requires at least 2 independent implementations, and nobody was working on rewriting SQLite from scratch. I would have loved WebSQL, but it is reasonable to require multiple implementations for full standardization.

> and nobody was working on rewriting SQLite from scratch.

One could also have embedded a trimmed-down PostgreSQL or MariaDB into browsers.

Re: A future for SQL on the web

#80

Post by SahAssar » Thu, Aug 12, 2021, 6:17 PM UTC

coliveira wrote: post #71

SahAssar wrote: post #27

Earlier quoted context omitted.

The justification was more that the standardization process requires at least 2 independent implementations, and nobody was working on rewriting SQLite from scratch. I would have loved WebSQL, but it is reasonable to require multiple implementations for full standardization.

I don't buy this reasoning because they could have standardized only the interface, letting it open for developers to choose SQLite or some other future implementation. There is no need to standardize SQLite behavior, including bugs.

That's not how the process works though. You could argue that they should change the process, but the reasoning behind it seems solid to me:

> Implementation experience is required to show that a specification is sufficiently clear, complete, and relevant to market needs, to ensure that independent interoperable implementations of each feature of the specification will be realized.

From https://www.w3.org/2015/Process-20150901/#implementation-exp...