SQLite expects synchronous reads and writes because it’s just simple C.
There are other storage standards on the horizon for web browsers, but locking becomes an issue. Native SQLite runs 2-3 times faster than absurd-sql, which demonstrates how slow IndexedDB really is. Of course, it’s not all roses when it comes to web development. So what’s the downside? Other than a somewhat large WebAssembly file that needs to get downloaded (409KB) and cached, there really isn’t. A query like SELECT SUM(*) FROM kv led to stunning results. On chrome (as well as Firefox), absurd-sql beats IndexedDB on almost every benchmark. That brings us to the other reason why it’s absurd. This means that only sections of the database need to be read in, bringing in huge performance gains. Instead of being memory backed, he added a layer to read and write blocks from IndexedDB. tweaked SQLite’s method of reading and writing blocks. However, sql.js uses an in-memory storage backing and all data is lost when refreshing the page. Luckily for there already was a project known as sql.js that uses emscripten to compile the C-based SQLite into WebAssembly. So for many browsers, it is just SQLite on top of IndexedDB on top of SQLite. Why absurd? Partially because most browsers (not chrome) implement IndexedDB on top of SQLite. He set out to bring a tool he was familiar with, SQLite, and bring it to the web browser as absurd-sql. However, as found, IndexedDB is painfully slow on chrome and limited in querying ability.
#Sqlite browser. Offline
The ability for web apps to work offline requires a persistent local storage solution and for many, IndexedDB is the only choice as it works across most browsers and provides a database-like interface. Love it or hate it, the capabilities of your modern web browser continuously grow in strange and wild ways.
0 kommentar(er)
