[fauigerzigerk]

If your app lets users sort, search, group, join or transform non-trivial data then SQL requires far fewer lines of code than procedural JavaScript, especially if you don't know ahead of time all the different ways in which users might want to query the data. It's definitely not useful for every kind of app though.

Think of something like personal finance, accounting, payroll, project management, CRM, zettelkasten style note taking, health and fitness tracking, etc, where users may want flexible analysis and reporting tools.

Much of this is now done on the backend, which makes sense if the data is accessed by many users in a transactional manner. But if it's a single user app or something used by tiny teams then cutting latency down to zero could greatly improve usability while still benefitting from everything a real query engine has to offer.

[ris58h]

I agree that it could work for a single user web app that works locally, but it's a pretty rare case.

[fauigerzigerk]

It has indeed been a pretty rare case for web apps, but it's a not completely insignificant niche for desktop and mobile apps. Some of those (e.g many Electron apps) could become pure web apps if more of their enabling technologies were available as WASM modules. I think this SQLite initiative as well as the underlying file system access API is part of that trend.