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.

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

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.

Check out “SQLite as an application file format”, https://www.sqlite.org/appfileformat.html

And how does it help in case of frontend development? A half of those points don't apply to web dev. Do you really need joins? Do you really need atomic transactions? Do you really need SQL? Most of API's that used by web apps operate with objects or arrays of objects. Why should we add complexity of SQL if we already can store those objects in a plain array?

It helps because apps are often used to view or edit files. By “files” I mean things like word doc files, photoshop files, Apple Keynote files. Many people like working with files and saving them locally, rather than on a server. With SQLite running in the browser, a file that is an SQLite database can be very easily read into memory, worked with, then saved back to disk. The page I linked explains this in detail. There are some examples of companies taking this approach at https://www.sqlite.org/appfileformat.html. Hope this extra detail is helpful.

Edit: Additionally, I encourage you to experiment with this. If you haven’t already, you may be surprised at how efficient/compact SQLite files are. They’re significantly more compact that JSON or XML documents and can include binary files like images. It’s much simpler to use SQLite as a file format than to create a custom binary file format.

This logic is flawed. X is not in Y, so we shouldn’t add it, because currently in Y no one is using neither X nor some crippled parody of it.

You haven't answered the questions. I don't see a reason to use RDBMS in a browser, if it's not, for example, an SQL tutorial site. You gave an example of a t-shirt store. A plain array of JS objects is enough to store items in a browser. Why do you need a fully backed RDBMS for it?

Because it’s a better programming model.

> better

Sorry, but it's just you opinion. Do you have proofs of how t-shirt store will benefit of putting RDBMS on a client side (how much space does it take BTW) instead of using simple list of objects?

And you still haven't answered the questions.