The only function it provides is count, and the rest of the APIs just return a range of items. You’re on your own if you want to query data in IndexedDB.
This makes a massive difference for what kinds of apps you can write against it. Simple operations against the database take ~10ms (and I’m being charitable!), while it’s common for me to be profiling SQLite at ~.01ms. What’s even worse, in my testing Chrome, which is by the far the major browser, has the slowest implementation. But if we really want webapps to be impressive (I do), we need a more powerful way to work with data. Sure, it might be fine for small bits of functionality. It’s the only option for something database-like that works across all browsers.Īs you attempt to build a local app, you will quickly find that it’s a poor database to build an entire app around. If you are writing a web app today, you’ll probably choose IndexedDB to store data. In this post I will explain the absurdities of the web’s storage APIs (mainly IndexedDB), show how SQLite provides a 10x perf improvement, explain all the cool tricks that make it work, and explain the locking/transactional semantics that make it robust. That means it doesn’t have to load the whole db into memory, and writes persist.
The end result is absurd-sql, and it’s a persistent backend for SQLite on the web. I discovered something absurd recently and I’m very excited to tell you about it.
0 kommentar(er)
