Comment by me551ah
5 years ago
The only thing stopping SQLite from becoming the primary application file format is browsers. Every single other client supports SQLite. Embedded, Mobile, Lightroom, Desktop Apps and Cross platform mobile frameworks have really good support for SQLite.
On the one hand, browsers dislike access to files (regardless of format) for security reasons. On the other hand, browsers use SQLite a lot. For example Firefox uses SQLite at least for IndexedDB (various files) and for history and bookmarks (places.sqlite): https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_Ope...
Wasn't there an effort a few years back to try to create a W3C standard for accessing data that stalled because all of the browsers used SQLite and no one wanted to create a different implementation? IIRC, the standard required two different implementations and SQLite was used by everyone?
You're think of WebSQL. My take on it dying was a combination of "key-value stores can replace relational semantics and key-value stores are cool", "only oldsters use SQL", and "wheel-reinventing is fun". The whole "we need multiple independent implementations" was a convenient excuse to kill it in my view.
https://en.wikipedia.org/wiki/Web_SQL_Database
Primary application file format for... what kind of files? Because it's certainly not going to (nor should it ever) replace hypertext documents.
Being able to load a read-only .sqlite database might seem cool, but I can't think of a single instance in which that's smaller and/or more efficient than calling data endpoints that use gzip/brotli for transport.
Or are you thinking "as replacement for IndexedDB"? In which case, hard agree but then it's an actual database, not used as file data container.