Earlier quoted context omitted.
My feeling is that the web apis try to do too much. Why do we need a webSQL api. Why do we not just let websites create a file and then they can provide whatever kind of library they want. They could package a WASM version of sqlite and just work like they would as a desktop app. That way you never have to deal with browser incompatibility or unchangeable specifications.
Seems like a great way to give every site a multiple MB dependency.
A future for SQL on the web
181–190 of 227 posts
Re: A future for SQL on the web
#182Earlier 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.
> 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
#183Earlier quoted context omitted.
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…
> The excuse was that a standard needs to have multiple implementations otherwise we are standardising implementation details and bugs. 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.
Very few people are using Chrome-only APIs which are not in the standards yet. So it's not really a concern.
But otherwise, Chrome really has pushed the web forward more than any other browser. If it hadn't, native (and walled garden style) app stores would have totally taken over.
The web is in business (and thriving) as an application platform because it's being pushed forward relentlessly. The Storage Foundation API discussed in TFA is a good example.
Re: A future for SQL on the web
#184This 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 used it back in the day and was quite sad when it disappeared. Nolan Lawson does a good job telling the sordid tale at https://nolanlawson.com/2014/04/26/web-sql-database-in-memor...
Re: A future for SQL on the web
#185This 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…
SQLite as a library is amazing, SQLite as a spec for a standard web API is not. The issue is not just that there wasn't a competing implementation at the time, it is that you could not feasibly create a competing implementation. The set of features supported by SQLite is _massive_. And even you stick with SQLite, which version? And which extensions? Which features do you remove because they're not safe or not applica…
>The issue is not just that there wasn't a competing implementation at the time, it is that you could not feasibly create a competing implementation. The set of features supported by SQLite is _massive_. And even you stick with SQLite, which version? And which extensions? Which features do you remove because they're not safe or not applicable for web?
This seems like a case of perfect being the enemy of good.
Re: A future for SQL on the web
#1861. People often reset the cache on their browser, after all it is just a cache. SO a big benefit of databases which is persistent data is kind of not there. Juts rest your cache.
2. The second great benefit of databases is that they are multi-user. There can be in fact millions of users. But this benefit would not be there if the database lives and executes in the browser.
Re: A future for SQL on the web
#187Earlier quoted context omitted.
> It was torpedoed because it was SQL-based (and not trendy "key value" and "web scale"). This is almost certainly not even close to correct. There are substantial reasons why it wouldn't be a good idea, but this might be the biggest one: it's very hard to adequately sandbox an external C library. (... and, also, Apple probably would prefer that the web didn't exist at all, but that's a different pandora's box...)
My "web scale" bit is snark. The "because it was SQL based" comes from the feeling I got at the time that Mozilla absolutely wouldn't accept anything was SQL-based. I strongly believe anti-SQL attitudes at Mozilla, and little else, are what killed WebSQL. This is also how I justify my opinion that the "no independent implementations" was more of an afterthought excuse, and less of a primary motivation on Mozilla's pa…
WebDatabase, with or without a spec, boiled down to shipping SQLite. We didn't want the Web to depend on that. It might even have required shipping a specific version of SQLite to make sure that query planning matches other browsers.
It seems that IndexedDB has turned out poorly for various reasons but one of those reasons is that Chrome has botched their implementation and that's not Mozilla's fault.
Re: A future for SQL on the web
#188Earlier quoted context omitted.
Seems like a great way to give every site a multiple MB dependency.
I think its fine for a web app to be multiple MB. Websites like HN/wikipedia/blogs have no need for an SQL database but if you are loading something like a full IM client, it makes sense to download a few MB to make it stable over all browsers.
Sure, there could be cases where you have absolutely no alternatives to do something really specific, but in those cases I'd first invite you to reconsider whether what you're attempting to do actually needs to be a web app. Of course, people's thoughts will probably be split there.
However, the bottom line is still this - large sites load slower and cost more to load, they consume more battery and CPU, which on lower end devices could lead to system instability. If users don't outright leave your bloated solution (i.e. if they're forced to use it because of network effect) then in the case of any non-optional conditions (slow or unstable networks, low end devices, expensive data) their experience will be miserable.
Maybe have your IM client be a downloadable app instead? Better yet, why not have it be a native app instead of a bundled browser app, for excellent file size, small attack surface and great performance, while conforming to the OS look and feel?
Alternatively, why not make your IM client have a lightweight browser version that doesn't try to do everything under the sun? Personally, i feel like the answer is not to make browsers do more, but to try to do less yourself.
To that end, utilize server side rendering and pre-rendering with hydration when needed. Split some bundles and shake some trees. Compress as much as possible and use boring, common fonts while preferring local versions if available. Avoid videos in most cases and use smaller images, or vector graphics. The web can be a simple, beautiful and fast place if we make it one.
Re: A future for SQL on the web
#189Earlier quoted context omitted.
> The excuse was that a standard needs to have multiple implementations otherwise we are standardising implementation details and bugs. 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.
> 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. Very few people are using Chrome-only APIs which are not in the standards yet. So it's not really a concern. But otherwise, Chrome really has pushed the web forward more than any other browser. If it hadn't, native (and walled garden style) app st…
Ah yes. But SQlite not having competing independent implementations somehow is?
Also, "not many people using something" is not as great an argument as you think it is. See, for example, the latest problem with browsers deciding to remove alert/prompt/confirm: https://dev.to/richharris/stay-alert-d
> The web is in business (and thriving) as an application platform because it's being pushed forward relentlessly.
A quote from the same article: "An ad company shouldn't have this much influence over something that belongs to all of us".
So somehow non-standards that Chrome pushes (many of which will never get a different implementation because both Safari and Mozilla consider them harmful) are good, and push the web forward. But SQlite is bad because there are no independent competing implementations.
Got it.
Re: A future for SQL on the web
#190Earlier quoted context omitted.
I view the "standards" argument as a red herring for building a NoSQL db in the browser. Which, to this day, is slow, buggy and requires third party libraries to be usable [1] For those who are able to stomach an uncomfortable political history instead of an easy, technical answer, you can take a look at [2]. It's interesting that 7 years later, many the folks who pushed hard to get rid of SQL in favor of NoSQL seem…
PROLOGUE Six houses, all alike in dignity, In fair IRC, where we lay our scene, From ancient grudge to new mutiny, Where civil blood makes civil hands unclean. From Oracle, that SQL seer of IndexedDB, To Google, the stronghold of search, We add Mozilla, the Web SQL killa, And Apple, peering from its mobile perch. Here, a storage war would set keys to clack, Tongues to wag, and specs to shatter, There was also Microso…