The Power of IndexedDB and the Birth of db64: A Practical Alternative

Understanding IndexedDB

The search for maintainable and efficient persistent storage sees IndexedDB as a robust alternative to localStorage. However, storage in the browser is nuanced and not always a walk in the park. Achieving a balance between functionality and user-friendliness can be an uphill battle.

Why IndexedDB?

1. Better Performance: Unlike localStorage, IndexedDB operates asynchronously, preventing blocking operations.
2. Ample Storage Quota: IndexedDB provides a larger storage quota (dependent on the, browser, OS and available storage) compared to localStorage’s 5MB cap.
3. Reliability and Structured Data: Storing and retrieving data in localStroage can yield unpredictable results if not done properly. IndexedDB reduces common type-coercion and embraces the structuredClone algorithm, ensuring data integrity.

Practical Challenges of Using IndexedDB

While IndexedDB offers significant advantages, it introduces its own set of challenges:

1. Event-Driven Nature: IndexedDB is event-driven without native support for promises, making it less intuitive for developers.
2. Unnecessary Versioning Complexities: It was originally designed to encourage versioning, though many projects do not require this level of complexity.
3. Low-Level API: IndexedDB’s API is considered low-level and is not a seamless replacement for the straightforwardness of localStorage.
4. Database and Store Removal fallacy: Removing a database or store in IndexedDB can be intricate and typically involves versioning. Ironically, it is not entirely possible to remove a database or store due to the nature of IndexedDB’s persistent versioning.

Just Use a Library

The issue here is less technical, and more philosophical. As a developer, you are seeking a straightforward way to store, retrieve, and delete data asynchronously, preferably utilizing promises and or async/await.

There are many IndexedDB libraries that do the above. The drawback is their reliance on versioning and their lack of obviousness that prevents you from wasting time attempting to delete what is out of your control.

Versioning is beneficial for some Progressive Web Applications (PWAs) and apps that need to retain access to old data. However, these apps represent a small fraction, we’re probably talking less than 1% of all web applications at the time of this article.

If you’re still reading, it’s fair to assume you probably don’t need the complexities of versioning. Moreover, you can efficiently clear data from a store without versioning.

In reality, we cannot expect an entire team of front-end developers to understand all the nuances of indexeddb. Therefore a library that just focuses on the meaningful things should be desirable.

I made a small library called db64

The name has no meaning, it was influenced by Super Mario 64. db64 was created to be a practical solution for the majority of local storage needs. Check it out here.

Key Features of db64:

• Promise-Based API: This is standard for most IndexedDB libraries.
• Simplified Operations: Set and get single or multiple entries, delete entries, and clear object stores with ease.
• No Versioning Headache: db64 opts out of the complexity of deleting databases and object stores, offering a hassle-free approach to managing data.
• Clear data: Yes, you can delete data from IndexedDB, not to be confused with deleting containers such as a database or store.
• Tiny: Around 2kB (At the time of this article)

Using db64

import db64 from './db64.js'

try {
  // First create a database with stores
  await db64.create('Games', 'Super Nintendo', 'Gameboy')

  // Assing a variable for modifying a store
  const snes = db64.use('Games', 'Super Nintendo')

  // Set multiple entries into Super Nintendo
  await snes.setEntries({ adventure: 'Mario Wrold', rpg: 'Zelda', fighting: 'Street Fighter II' })

  // Get multiple entries from Super Nintendo
  await snes.getEntries(['adventure', 'fighting']) // { adventure: 'Mario Wrold', fighting: 'Street Fighter II' }
...

In conclusion, IndexedDB is not a fun API, I would strongly recommend using a library unless you have no choice. You don’t have to use db64 though db64 was created with a real-world philosophy in mind.

If you need versioning consider using IDB.

Despite what you decide, I hope that you move away from using localStorage since it's blocking and can have unpredictable results for developers lacking experience in that area.

Thanks for the read :D