What's kind of bonkers here is that IndexedDB uses sqlite as its backend. So, this is sqlite (WASM) -> IndexedDB -> sqlite (native). The Internet is a wild place...
That's even mentioned in the article.
A future for SQL on the web
61–70 of 227 posts
Re: A future for SQL on the web
#62Earlier quoted context omitted.
> The sad irony is that if HN is anything to go by, SQLite is super trendy now. If you look at the recent StackOverflow survey, the majority of the developers only have around 5 years of professional experience in the industry. SQL has been around since the 1970s and is still around in force for reason. There's a good chance a lot of developers, especially the enormous number on the front end, do not have experience…
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. There are people that believe in a flat earth as well after all
Re: A future for SQL on the web
#63This 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…
I think the current state is fine. You ship your WASM-blob of SQLite, which has the exact bug-compatible version of SQLite that you've tested your app against. The browsers are not burdened with maintaining a huge API surface that can "break the web". Otherwise you'd have to deal with different versions of SQLite in different browsers, most likely outdated, with many options turned off. SQLite is full of quirks and g…
[deleted]
Re: A future for SQL on the web
#64So, 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 ??
Re: A future for SQL on the web
#65If only mozilla hadn't screwed up
Re: A future for SQL on the web
#66Earlier quoted context omitted.
Came here just to say this. Each SQL program needs to run on a blockchain so that there's no central authority that can unduly influence the data.
I legitimately can no longer tell if this was being suggested sarcastically, or if you guys are being serious.
To be clear: I was being sarcastic. But if I were to inject our comment chain into it'd fit right in, proving your point that the level of silliness is getting to Monty Python levels. We need The Colonel to barge onto the stage and shut it down I feel.
Re: A future for SQL on the web
#67Just a month ago I was talking with a person that told it is impossible to use SQL in the frontend.
It is a great project and I hope one day we will be able to use it in production.
Re: A future for SQL on the web
#68This 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…
Yeah, it adds to the absurdity of all of this. Although I do empathize with browers vendors. I worked at Mozilla at the time and was aware that this is a lot of things to think about when integrating something onto the web. I get why it happened, but practically speaking maybe it should have won. It's not like Chrome seems to care much about cross-browser standards these days. I'm hopeful for a storage layer like thi…
I think offset based file access could be really powerful just based on what people are achieving in the browser with things like Flat buffers, proto buffers and even http range queries.
Re: A future for SQL on the web
#69Hmm... I was in the middle of rewriting an application of mine from JSON stringify into localStorage to IndexedDB, but was having issues with the API being so clunky. This is a tempting alternative. It does increase size from ~200kb by a whole mb, but the app's usage patterns are such that people open it and then use it for extended periods of time in the background.
Re: A future for SQL on the web
#70Earlier quoted context omitted.
I wish every browser does that! Web site has no business storing data on my computer more than 4093 bytes (that is already too much) per domain in my computer just because I visited a web page. 10 MB - 10GB of data is too much.
I think that's a valid concern. Stuff like this should only be allowed after a prompt where the user explicitly allows it, just like any other permission
I would say it’s even more important in the case of a web app that stores data locally, because it’s imperative that the user understands that data is tied to that particular web browser and device, and that clearing site data (which I’ve known non-technical users to do periodically to reduce tracking footprint), changing devices, etc can/will result in data loss.
Oddly enough the handful of web apps I’ve known to use local storage don’t communicate this at all. Developers seemingly treat data in browser local storage as existing indefinitely and unlikely to be deleted, when in fact it’s probably the most easily accidentally lost form of storage an app can have.