I would miss the safety and durability of a (preferably relational) database.
In the end, what I would gain in convenience and development speed I would lose in having to build my own guardrails.
>Yes, you do need queries, but there are not many and they might as well be coded as functions. You can do all the indexing you want, if you need to, but JavaScript in browsers is so incredibly fast these days, that even a linear search works well for most cases.
That's just a bad database. It will work for small amounts of data and simple queries. But add in something complex or lots of data and it will fall over.
Where DBMSes truly shine is working efficiently with data that you can't or don't want to keep in memory all at once, or for which lots of different clients need concurrent access. The first of those (but hopefully not the third) are absolutely considerations for certain kinds of browser apps, but maybe not something the parent was worrying about.
Yes, you do need queries, but there are not many and they might as well be coded as functions. You can do all the indexing you want, if you need to, but JavaScript in browsers is so incredibly fast these days, that even a linear search works well for most cases.
Unless you are handling gigabytes of data client-side, of course. But that wouldn't make much sense.
Data modification needs to go through a server API anyway, because the client environment can't be trusted, so two-way sync would be useless. I want the server to perform data model operations while verifying everything, I do not want data sync.