6 ms·

The excuse was that a standard needs to have multiple implementations otherwise we are standardising implementation details and bugs. Hindsight shows that was

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-vulnerability-exposes-billions-of-apps-including-all-chromium-based-browsers/ https://hub.packtpub.com/an-sqlite-magellan-rce-vulnerabilit...) As a sidenote, I worked a lot with the WebSQL API and it was not a very good API in the slightest, immaturity may excuse some of its flaws, and it isnt like Safari did a much better job with IndexedDB, its just a buggy browser and thats where WebSQL was used most, but a large part of the problem is that it was bolting an API that assumed a single threaded client when that is not the reality with web pages where multiple tabs exist

hitekker 5y ago
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 to no longer occupy positions of prominence in the industry. [1] https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API#see_also https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_A... [2] https://nolanlawson.com/2014/04/26/web-sql-database-in-memoriam/ https://nolanlawson.com/2014/04/26/web-sql-database-in-memor...
- daleharvey 5y ago
  I am familiar with Nolans article, I created PouchDB (the project he is discussing), you seem to have misred the post as it discusses the technical nuance and tradeoffs involved in the decision at many points entirely agreeing with the position against WebSQL. While Nolan came to the a different conclusion than I did (a point he made in the post) he laid out challenges very well and made it very clear there was no obvious technical answer. Regardless of how you view it, the benefit of hindsight shows the exact thing that people warned would happen did in fact happen (a widespread venerability in SQLite exposed across various browsers). Its also a fairly strange point to be personally insulting people involved in the process whose careers are doing perfectly well.
  - hitekker 5y ago
    Edit: Nolan replied before and corrected me. I've removed my misinterpretation and kept my main point below. Back in the day, there were people who strongly suggested MongoDB and IndexedDB were the future, and that PostgreSQL, MySQL, SQLite were trash. I've noticed the folks who rode that hype-train moved into other kinds of occupations that aren't exactly engineering-focused anymore.
    - nolanl 5y ago
      I wrote that article 7 years ago, and FWIW I would side more with Dale these days. It's probably a good thing we didn't just slap a half-baked API on top of SQLite and call it a web standard. The biggest problem is that yeah, WebSQL tends to be faster than IndexedDB. Or at least it was back when I was working on PouchDB. Biggest issue IIRC was that joins were faster in SQLite than implementing the same thing in userland on top of IndexedDB. Browsers eventually shipped getAll/getAllKeys which also helped with cursor slowness. I haven't looked much at the Storage Foundation API [1], but it seems like a more reasonable approach moving forward. Just give developers the low-level tools and let them build SQLite on top of it. Also the Chromium devs have been working on relaxed durability, which apparently improves IDB perf in some scenarios [2] (although still not as fast as Firefox it seems [3]). [1]: https://github.com/WICG/storage-foundation-api-explainer https://github.com/WICG/storage-foundation-api-explainer [2]: https://www.chromestatus.com/feature/5730701489995776 https://www.chromestatus.com/feature/5730701489995776 [3]: https://bugs.chromium.org/p/chromium/issues/detail?id=1025456#c12 https://bugs.chromium.org/p/chromium/issues/detail?id=102545...
      - dmitriid 5y ago
        > Consensus & Standardization > Firefox: Negative [1] > Safari: Negative [2] However, I fully expect Chrome to ship it in stable sometime soon, like they do with dozens of other APIs. There are now four different half-baked storage/file api proposals, at least one of them is already in stable Chrome... it's a mess. [1] https://github.com/mozilla/standards-positions/issues/481 https://github.com/mozilla/standards-positions/issues/481 [2] https://lists.webkit.org/pipermail/webkit-dev/2021-February/031689.html https://lists.webkit.org/pipermail/webkit-dev/2021-February/...
- tehbeard 5y ago
  Having worked with IndexedDB quite a bit at my job, I can level three criticisms at IndexedDB. 1. The API is the dogshit hot mess you'd expect for a pre promise/async API. 2. The lack of partial/computed secondary indexes. 3. Apple/Safari does EVERYTHING in their power to break it. I refuse to believe it's incompetence at this point, it's actively malicious.
  - deleted 5y ago
    [deleted]
- andai 5y ago
  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 Microsoft and Opera, Who don't really seem to matter. THE PLAYERS NIKUNJ MEHTA, of House ORACLE, an instigator JONAS SICKING, of House MOZILLA, an assassin MACIEJ STACHOWIAK, of House APPLE, a pugilist IAN FETTE, of House GOOGLE, a pleader CHARLES MCCATHIENEVILE, of House OPERA, a peacemaker ACT 1 SCENE: A dark and gloomy day in Mountain View, or perhaps a bright and cheery one, depending on your IRC client's color scheme.
  - sdiq 5y ago
    Romeo and Juliet, for those that may not get it.
dmitriid 5y ago
> 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.
- jeswin 5y ago
  > 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.
  - dmitriid 5y ago
    > Very few people are using Chrome-only APIs which are not in the standards yet. So it's not really a concern. 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 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.
    - jeswin 5y ago
      > Ah yes. But SQlite not having competing independent implementations somehow is? Except that's not why it was culled. The reasons are discussed in great detail on this thread and elsewhere. > non-standards that Chrome pushes (many of which will never get a different implementation because both Safari and Mozilla consider them harmful) are good I'm saying nobody uses those Chrome only APIs, until they become standards (which requires acceptance by other vendors). Or are you against experimentation?
BulgarianIdiot 5y ago
> The excuse was that a standard needs to have multiple implementations otherwise we are standardising implementation details and bugs. Looks at Chrome
- da_chicken 5y ago
  At the time, Internet Explorer was still fresh on everyone's mind. It's not like we haven't been exactly where we are now before.
- hitekker 5y ago
  It’s funny that the top comment points out the obvious-- people want SQL in the browser-- and a NoSQL author immediately has to jump in to claim that SQL in the browser was wrong all along. I think the NoSQL and MongoDB folks are worried for their careers.
SilverRed 5y ago
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.
- afavour 5y ago
  Seems like a great way to give every site a multiple MB dependency.
  - SilverRed 5y ago
    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.
    - KronisLV 5y ago
      Disagreed, this is a dangerous line of thinking that leads to using technologies like gwt, Vaadin, Blazor, Flutter or others that try to turn the browser into something that it's not suited to. 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.
dangerface 5y ago
Better to have something thats already considered standard than to invent a new one because you think you can do better than sqlite.

hitekker 5y ago

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 to no longer occupy positions of prominence in the industry. [1] https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API#see_also https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_A... [2] https://nolanlawson.com/2014/04/26/web-sql-database-in-memoriam/ https://nolanlawson.com/2014/04/26/web-sql-database-in-memor...

daleharvey 5y ago
I am familiar with Nolans article, I created PouchDB (the project he is discussing), you seem to have misred the post as it discusses the technical nuance and tradeoffs involved in the decision at many points entirely agreeing with the position against WebSQL. While Nolan came to the a different conclusion than I did (a point he made in the post) he laid out challenges very well and made it very clear there was no obvious technical answer. Regardless of how you view it, the benefit of hindsight shows the exact thing that people warned would happen did in fact happen (a widespread venerability in SQLite exposed across various browsers). Its also a fairly strange point to be personally insulting people involved in the process whose careers are doing perfectly well.
- hitekker 5y ago
  Edit: Nolan replied before and corrected me. I've removed my misinterpretation and kept my main point below. Back in the day, there were people who strongly suggested MongoDB and IndexedDB were the future, and that PostgreSQL, MySQL, SQLite were trash. I've noticed the folks who rode that hype-train moved into other kinds of occupations that aren't exactly engineering-focused anymore.
  - nolanl 5y ago
    I wrote that article 7 years ago, and FWIW I would side more with Dale these days. It's probably a good thing we didn't just slap a half-baked API on top of SQLite and call it a web standard. The biggest problem is that yeah, WebSQL tends to be faster than IndexedDB. Or at least it was back when I was working on PouchDB. Biggest issue IIRC was that joins were faster in SQLite than implementing the same thing in userland on top of IndexedDB. Browsers eventually shipped getAll/getAllKeys which also helped with cursor slowness. I haven't looked much at the Storage Foundation API [1], but it seems like a more reasonable approach moving forward. Just give developers the low-level tools and let them build SQLite on top of it. Also the Chromium devs have been working on relaxed durability, which apparently improves IDB perf in some scenarios [2] (although still not as fast as Firefox it seems [3]). [1]: https://github.com/WICG/storage-foundation-api-explainer https://github.com/WICG/storage-foundation-api-explainer [2]: https://www.chromestatus.com/feature/5730701489995776 https://www.chromestatus.com/feature/5730701489995776 [3]: https://bugs.chromium.org/p/chromium/issues/detail?id=1025456#c12 https://bugs.chromium.org/p/chromium/issues/detail?id=102545...
    - dmitriid 5y ago
      > Consensus & Standardization > Firefox: Negative [1] > Safari: Negative [2] However, I fully expect Chrome to ship it in stable sometime soon, like they do with dozens of other APIs. There are now four different half-baked storage/file api proposals, at least one of them is already in stable Chrome... it's a mess. [1] https://github.com/mozilla/standards-positions/issues/481 https://github.com/mozilla/standards-positions/issues/481 [2] https://lists.webkit.org/pipermail/webkit-dev/2021-February/031689.html https://lists.webkit.org/pipermail/webkit-dev/2021-February/...
tehbeard 5y ago
Having worked with IndexedDB quite a bit at my job, I can level three criticisms at IndexedDB. 1. The API is the dogshit hot mess you'd expect for a pre promise/async API. 2. The lack of partial/computed secondary indexes. 3. Apple/Safari does EVERYTHING in their power to break it. I refuse to believe it's incompetence at this point, it's actively malicious.
- deleted 5y ago
  [deleted]
andai 5y ago
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 Microsoft and Opera, Who don't really seem to matter. THE PLAYERS NIKUNJ MEHTA, of House ORACLE, an instigator JONAS SICKING, of House MOZILLA, an assassin MACIEJ STACHOWIAK, of House APPLE, a pugilist IAN FETTE, of House GOOGLE, a pleader CHARLES MCCATHIENEVILE, of House OPERA, a peacemaker ACT 1 SCENE: A dark and gloomy day in Mountain View, or perhaps a bright and cheery one, depending on your IRC client's color scheme.
- sdiq 5y ago
  Romeo and Juliet, for those that may not get it.

dmitriid 5y ago

> 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.

jeswin 5y ago
> 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.
- dmitriid 5y ago
  > Very few people are using Chrome-only APIs which are not in the standards yet. So it's not really a concern. 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 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.
  - jeswin 5y ago
    > Ah yes. But SQlite not having competing independent implementations somehow is? Except that's not why it was culled. The reasons are discussed in great detail on this thread and elsewhere. > non-standards that Chrome pushes (many of which will never get a different implementation because both Safari and Mozilla consider them harmful) are good I'm saying nobody uses those Chrome only APIs, until they become standards (which requires acceptance by other vendors). Or are you against experimentation?

BulgarianIdiot 5y ago

> The excuse was that a standard needs to have multiple implementations otherwise we are standardising implementation details and bugs. Looks at Chrome

da_chicken 5y ago
At the time, Internet Explorer was still fresh on everyone's mind. It's not like we haven't been exactly where we are now before.
hitekker 5y ago
It’s funny that the top comment points out the obvious-- people want SQL in the browser-- and a NoSQL author immediately has to jump in to claim that SQL in the browser was wrong all along. I think the NoSQL and MongoDB folks are worried for their careers.

SilverRed 5y ago

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.

afavour 5y ago
Seems like a great way to give every site a multiple MB dependency.
- SilverRed 5y ago
  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.
  - KronisLV 5y ago
    Disagreed, this is a dangerous line of thinking that leads to using technologies like gwt, Vaadin, Blazor, Flutter or others that try to turn the browser into something that it's not suited to. 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.

dangerface 5y ago

Better to have something thats already considered standard than to invent a new one because you think you can do better than sqlite.