I'm diving into an unconventional idea and could use some insights from those well-versed in browser behavior. To give you some context:
- `localStorage` and `sessionStorage` have a small quota (about 5-10MB).
- `IndexedDB` provides persistent, disk-backed storage.
- The Cache API is designed for request/response management.
Now, I'm considering using Blob URLs, created by `URL.createObjectURL`, as a means for non-persistent, RAM-only storage that vanishes upon page reload. Here's why:
- They store data in memory.
- There's no strict quota like in `sessionStorage`.
- They are automatically cleared when you navigate away or close the tab.
- They can handle large binary data.
This approach could be useful for various scenarios such as handling large temporary computation outputs, caching session-specific data, or generating media assets without the complexities of IndexedDB.
I recognize the risks involved:
- Potential memory pressure.
- Risk of tab crashes if misused.
- No built-in persistence or management.
- No guarantees for data retention.
However, if utilized thoughtfully with boundaries, could this method be deemed unsafe or simply unconventional? Has anyone tried using Blob-backed storage effectively, or is it more of a pitfall than a practical solution?
5 Answers
Honestly, you could just use a regular JavaScript variable for this. Anything that you want to store temporarily can be handled by an array, object, or any other type of variable you choose. Why complicate it with Blob URLs? They're really not designed for this.
Blob URLs are not inherently 'storage'; they reference blobs and depend on the underlying object's memory management. While they can be useful as temporary handles for media, managing them effectively can be tricky. Usually, it's more efficient to keep your blobs in a Map or WeakMap and use URLs only when absolutely necessary.
It sounds like you're just reinventing the wheel here. Using a map or plain objects would better suit your needs unless you specifically require a Blob URL for tasks like setting an image source or download links. The primary benefit of Blob URLs is the string handle, which doesn't really apply to your use cases.
You do realize you're just describing a simple variable, right? If all you need is something temporary that disappears on refresh, just store it in memory without over-engineering it.
The storage API for blobs isn't very versatile for anything besides user-selected file handling. If you're trying to create a caching system with blobs, you're likely adding unnecessary complexity and runtime overhead. Better options exist that don't involve serialization or the risk of memory leaks.
Exactly! It feels like an extra layer that's unnecessary. Plus, `sessionStorage` and `localStorage` are synchronous, which could complicate things depending on what you're planning to do.