[daleharvey]

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

[BulgarianIdiot]

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

Looks at Chrome

[da_chicken]

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]

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.

[dmitriid]

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

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

> 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

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

[scns]

From the first comment below the article:

> The Safari team did quite a lot of work re-styling their alerts and dialogs to be within the context of the webpage, yet phishing and scams that utilize this still run rampant on iOS. Repeated alerts are used to lock up the browser and make it unusable, forcing non-technical users to call a scam telephone number because they think their device was hacked.

A few bad actors ruining it even for totally different usecases.

[dmitriid]

> A few bad actors ruining it even for totally different usecases.

Same thing happened to Do Not Track... that was used for fingerprinting

[jeswin]

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

[dmitriid]

> I'm saying nobody uses those Chrome only APIs, until they become standards

Ah yes. Once Chrome releases something in stable, literally no one ever uses those APIs, no one. And even Google's propaganda machine doesn't tell you to use them (example: https://web.dev/usb/)

> Or are you against experimentation?

I'm not. What Google does isn't experimentation.

[jeswin]

My assumption is that a very small percentage of developers participate in it. Feel free to prove me wrong if you have any numbers.

> I'm not. What Google does isn't experimentation.

So the way this is done now (with origin trials to collect feedback from developers) is not good enough? What exactly is your definition of experimentation?

[SilverRed]

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.

[TeMPOraL]

I'd agree with some of the existing web APIs. But I think some web SQL API should be built-in.

Why? Because it's a very common pattern. Almost fundamental. Take any project more complex than a toy calculator, and you'll quickly find places where the authors are hand-rolling relational operations.

Does your app have an array of records in memory, which it then searches for values, filters by conditions, and/or sorts? I'd give it a 50/50 chance that if you replaced that array with an in-memory SQLite table, and all operations on it with SQL queries on it, the result would be less code, more readable code and better performance[0].

It's not just the web - I'd argue that programming languages in general should all embed first-class in-memory relational database engines. It should be a part of the language standard - if it's easy to write this:

  struct Foo {
    int bar;
    date baz;
    string quux;
  };

  //somewhere in something
  Array<Foo> foos;

it should be easy to write this:

  table<Foo, index=[bar, quux]> foos;

(or some other, better way of describing intended data access patterns)

and get a thing that can be efficiently queried, filtered and transformed along dimensions specified, with the compiler turning your request into efficient bytecode/nativecode. Doesn't mean you have to write queries in vanilla SQL - there are more composable syntaxes out there. But arbitrary loops and map-reduces aren't that good either.

When you start looking at your data processing code as database operations, you'll see it everywhere. That map/reduce/zip blob? That's a JOIN query. That struct you're keeping in your event loop, that looks like:

  struct Schedule {
    Array<Task> tasks;
    PQueue<TaskId> toRun;
  };

that priority queue is an index on the tasks array, and looking at its front is just SELECT id FROM tasks ORDER BY priority LIMIT 1;. That Entity-Component-System pattern you're using in your videogame? That's literally a relational database. It was conceived of as such (and for massively multiplayer games, is often implemented as such). Wouldn't it be nice if the ability to express this came built into the language? With a column-oriented option for improved performance, too?

--

[0] - It's trivial to add indexes to SQL table. The engine will maintain them for you. Nobody habitually adds indexes to their own regular variables. They, along with the code to maintain them, would manifest as extreme code bloat. Meanwhile, in-memory SQLite is freakishly fast. If you're measuring performance in Python/Ruby units, you won't even notice the FFI overhead.

[afavour]

Seems like a great way to give every site a multiple MB dependency.

[SilverRed]

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]

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.

[pimterry]

> why not have it be a native app instead of a bundled browser app, for excellent file size

There are other valid arguments, but "use a native app for smaller file size" specifically doesn't make sense at all - the opposite is true.

While webapps may be larger than simple web pages, they're still far far far smaller than native apps, and using service workers etc, you do only pay the download size for a web app once, just like a native app.

For example: the Twitter Android app is a 21MB download. I just tested loading the Twitter PWA (https://mobile.twitter.com) logged in but with an cleared cache: it's a <3MB, including all the content visible in my feed on the first load.

The native app is _7+ times larger_.

I suspect the same or worse is true for the vast majority of other apps, e.g. Uber on Android is a 50MB download, while m.uber.com (reloaded after login with a cleared cache) gives you the same features with <1MB.

[KronisLV]

That might be an apples to oranges comparison in some regards, to be honest.

Using native UI frameworks will almost always yield smaller file sizes than the equivalent implementation in any of the web technologies, regardless of whether served as a webpage, or bundled in a WebView or something similar (with few exceptions, one of which is listed below). Just consider a WinForms/GTK/Qt or a similar application in contrast to using React/Angular/Vue and including those within Electron, or even loading them in a web browser.

Many of the mobile applications out there actually include hybrid technologies (like Ionic, React Native, Xamarin or anything else of the sort), since nowadays telling a company that you'll have separate codebases with OS native widgets for iOS, Android and others would not be met positively. Therefore, concessions are made to speed up development, at the expense of having more abstraction layers and larger bundles.

One aspect in which you're probably correct, however, is that technically the web indeed affords you the possibility of having pretty good download space savings, if you choose which forms to make user download, as opposed to including all of them in the application. For example, if you have a billing form that actually needs 50 different variations based on countries and regions, and include them bundled into a native app, then on the web you'll instead be able to just download the one that you need dynamically. That said, none of this is alway easy, hence Twitter and Uber both employ a large number of engineers that work on screens like that, even if many people won't even see them.

My point here is that there are many different approaches and technologies that can be used, "native" in the context of my message meaning an application that uses the OS UI and widgets directly, without reinventing the wheel or attempting to encapsulate cross platform or web technologies within it. Of course, it's perfectly understandable and valid why companies that are highly focused on their own brands and shipping quickly don't necessarily adopt that approach.

[talolard]

I subscribe to an alternative premise - "The browser is effectively an OS and thus a standardized distribution target". There are cases where the people I want to distribute to don't suffer from the constraints you mentioned. e.g. will tolerate a 20 second page load in exchange for the experience my product will provide.

Being able to reach all devices and have a super fast experience without consuming bandwidth is always good, but not always a high priority .

[KronisLV]

That is a valid premise indeed, but one that i cannot agree with for a plethora of reasons. There are articles that go into more detail about what this approach leads to: https://idlewords.com/talks/website_obesity.htm

There are also aspects which are probably entirely overlooked because of that approach, for example, consider:

  - https://whatdoesmysitecost.com/test/210813_AiDcEB_e62852d10cb795009ccd61f1dd2d8623#gniCost
  - https://whatdoesmysitecost.com/test/210813_AiDcPZ_dd4b52c10c37e4c7483ab391015a00cb#gniCost

Sometimes, there are also accessibility concerns (especially in the case of Flutter), all of which will work against letting your software be used by as many people as possible, in as many hardware and software configurations as possible.

If the target audience of your products and sites are wealthy and able bodied individuals in 1st world countries, then by all means go ahead. However, in certain other pursuits inclusivity is definitely an important goal as well and one that i personally value a bit higher than fancy looking sites with rich functionality.

That said, isn't 20 seconds a bit much? Sure, i get that it's just an example, but i think even heavier pages like GMail load in approximately half of that. I think that bundle splitting and some optimization are probably a good idea even in heavier pieces of software!

[TeMPOraL]

Funny, how this is the static/shared library problem again :). And where the hivemind seems to prefer static libraries for regular software, it's reverse on the web.

I suppose the problem is, on the web, you're redownloading the whole bundle each time you run. There are layers of caching in the browser that are supposed to help, but they're almost always defeated by a combination of app misconfiguration and developers' reluctance to use the cache given the ridiculous rate of redeployment of web software.

I'd still argue that SQL API is a prime candidate for a shared system-level library - AKA browser built-in. The concepts behind it have been worked out in the 1970s and honed through decades since. It's not experimental tech. The API won't be changing every month.

[hitekker]

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

[2] https://nolanlawson.com/2014/04/26/web-sql-database-in-memor...

[daleharvey]

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]

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]

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

[2]: https://www.chromestatus.com/feature/5730701489995776

[3]: https://bugs.chromium.org/p/chromium/issues/detail?id=102545...

[dmitriid]

> 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

[2] https://lists.webkit.org/pipermail/webkit-dev/2021-February/...

[tehbeard]

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.

[andai]

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]

Romeo and Juliet, for those that may not get it.

[dangerface]

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