Hacker News Reader

Comment by systems | Hacker News Reader

what is exactly the use case for this?

It's an alternative to using IndexedDB which is a browser provided API.

On use cases, you can give your web app offline support by locally caching data in an SQL database and have it be fully queryable.

Say you are building an app like Notion, they already have "offline mode" for the mobile and desktop apps, this would enable you to build that for the web app.

This is very much one of the final jigsaw pieces needed to make PWAs (progressive web apps) competitive for the majority of use cases. We just need Apple to catch up and fill in a few other blanks too.

A design pattern that is beginning to emerge is "offline/local first". You design your app to fundamentally work offline, using things such as this, and the server component only works to synchronise clients. It's a bit like the design move to "mobile first" that happed 10 years ago, but going to another level.

I haven't used IndexedDB in a while.. but my recollection is that it is basically SQLite. Not sure I see the advantage of this above and beyond what IndexedDB is already providing. What are the pros and cons of each approach?

https://nolanlawson.com/2021/08/22/speeding-up-indexeddb-rea...

IndexedDB seems like a whole bag of gotchas. SQLite + simpler browser provided file backing seems interesting to me.

> but my recollection is that it is basically SQLite.

SQLite, which has a SQL database engine, is, by definition, a relational database. IndexedDB is a non-relational, or noSQL, database. One can't be basically the same as the other :-)

IndexDb is not a relational data store. It's much closer to Mongo than it it to Sqlite.

If you want relational tables, joins, aggregations etc, you want something like this (or the original Web SQL that was deprecated).

There is definitely a use case for it.

> It's much closer to Mongo than it it to Sqlite.

If only. It’s much closer to DBM than it is to Mongo.

One is a key value store, the other is a full relational database.

Think Redis vs PostgreSQL.

So thick client applications get the last laugh in the end?

It reminds me of an old concept, that has a catchy name I can't recall, positing an endless cycle in systems evolution where local peripherals grow processing capability until someone notices and (re)centralizes it, only for the local processing capability to quietly begin growing again, and so on.

Fantastic, would love to know the name if you end up remembering. I see this pattern so often.

"Offline/local first" sounds easy but it's the distributed problem. How is data be consistent?

You can have transactional causal consistency with an AP system. Combined with CRDTs it’s very powerful.

You also have mixed (“just right”) consistency systems and techniques to introduce and optimise the use of runtime coordination where necessary.

For example see https://electric-sql.com/docs/reference/consistency

It feels like you're assuming that Apple is a student here that forgot to do his homework, as opposed to a miscreant who is trying to block progress on purpose.

Apple wants to handicap web apps to encourage people to build for iOS.

That may or may not be to some extent true, however I find negativity isn't generally the best way to encourage people to do something you would like.

I think Safari has also made progress over the last couple of years, and there is indication of them being more receptive to PWAs. I'm going to cheerlead for that.

It's also worth noting that the EU and UK competition authorities are looking at forcing Apple to make changes to some of their rules around web browsers on iOS. They have a big stick, I don't, hence my nicer words.

Based on this note:

> In our blog post Deprecating and removing Web SQL, we promised a replacement for Web SQL based on SQLite. The SQLite Wasm library with the Origin Private File System persistence backend is our fulfillment of this promise.

I'd venture to guess the best answer is "whatever the hell people used Web SQL for." Doesn't really answer the question, but alas.

Plenty. Suppose you're working on a cross-platform application, building for web will get even easier, as up until a few months ago there weren't even official WASM builds from SQLite (but some amazing community run ones such as sql.js!). As for why somebody would want that, an example: your browser and everyone's is probably always open when you're at a PC, attrition is next to none compared to having to download an application, it's great for even just trying something out. SQLite really makes user data storage trivial in most circumstances, key:value doesn't.

Perhaps this could be used to create more privacy focused apps where your data stays local and works offline. I'm not sure about the persistence though, like if you clear the cache does it wipe out the local database?

Or if you switch devices?

Or need to collaborate on the data (i.e. a company with empoyees)

Or have regulations/controls on where data lives 'at rest'

It lets you build static web applications that can manage relational data for your users that is stored on their own machines.

This is a really powerful capability. You could build the equivalent of full desktop applications - things like Word, Excel, Access, Evernote, task trackers, Blender... all without any server side storage mechanism at all.

So basically a desktop app that runs in a desktop app on a desktop?

Yup - but crucially one that people can start using by clicking a link, without having to download and install anything first.

And it's an app that runs in a very robust sandbox, so much less risky than installing software.

True, but you have it backwards. Web app needs user to download and install a web browser first; desktop app does not need anything downloaded first. Both can be started by clicking a link.

I guess you mean downloading a browser version that supports the new origin filesystem feature? Every user has a web browser installed.

Quite simple. I do not need to download a web browser at all to run the desktop app. Deployment of the desktop app is simpler and provides the same or even more functionality without adding a complex desktop browser and sandbox container to run the app. Why is this so hard to get across?

What operating system are you using where you don't have a web browser?

> desktop app does not need anything downloaded first.

Well, you need to have a computer, and download and install an operating system first.

SQL but in the web browser. Mobile apps have long been using sqlite for their needs. Now web apps can too.

You want to run some code in the browser that wants to use a persistent SQL database.

Reply on news.ycombinator.com