localStorage plafonne à 5 Mo, ne gère que des chaînes et bloque le thread avec son API synchrone. Pour une app moderne, tu touches vite le mur de la Web Storage API. C'est la raison d'être des plugins de stockage : te donner une API simple et performante par-dessus IndexedDB.
Heureusement, des plugins de stockage simplifient radicalement IndexedDB. localForage, par exemple, garde une API proche de localStorage mais accepte directement les objets, les blobs, les ArrayBuffers. Concrètement, tu passes de localStorage.setItem('user', JSON.stringify(user)) à localForage.setItem('user', user). Ça change tout. Plus de sérialisation à la main, plus de limite ridicule à gérer.
Mais localForage reste un wrapper clé-valeur. Dès que tu as besoin de requêtes structurées, d'index, de tris, sors Dexie.js. Son API type dexie.where('age').above(18) est infiniment plus saine que de bricoler une boucle sur toutes les entrées. Pour un simple stockage clé-valeur, tu peux aussi considérer idb-keyval : 600 octets, zéro dépendance, parfait pour éviter de charger une lib trop lourde. Mon avis : évalue ce que tu veux vraiment stocker et comment tu veux l'interroger avant de choisir.
localStorage et ses limites : pourquoi passer à IndexedDB ?
Le 5 Mo de localStorage, c'est vite atteint. Et ce n'est pas la pire limite : son API synchrone bloque le thread principal à chaque opération. Sauvegarder un JSON de 2 Mo ? Ton interface freeze.
localStorage ne gère que des chaînes. Pour stocker un objet, tu passes par JSON.stringify, pour le relire, JSON.parse. Pour un Blob ou un ArrayBuffer, oublie. IndexedDB accepte les objets structurés, les blobs, les fichiers, et son API est asynchrone. Tu rends la main au thread, l'écriture passe en arrière-plan. Exemple : une app de gestion de photos en base64 dans localStorage explose au bout de quelques clichés, là où IndexedDB stocke les originaux sans broncher.
Alors, bascule quand ? Dès que tu dépasses 2–3 Mo de données persistantes, dès que tu manipules des binaires, ou dès que la sauvegarde gêne l'interaction. Mais mon avis : si tu écris encore setItem dans une boucle, tu es déjà dans le mur.
Les plugins qui simplifient IndexedDB
IndexedDB est puissant, mais son API native est un cauchemar. Les plugins de stockage transforment cette complexité en une interface simple. Voici ceux que j'utilise au quotidien.
localForage garde l'API de localStorage, mais en asynchrone. Tu passes de localStorage.setItem('user', JSON.stringify(user)) à localForage.setItem('user', user). Plus de sérialisation, plus de limite de 5 Mo. Il choisit automatiquement le meilleur backend : IndexedDB, WebSQL ou localStorage selon le navigateur. Pour une app simple, c'est le choix par défaut.
Dès que tu as besoin de requêtes structurées, Dexie.js est le roi. Son API type db.users.where('age').above(18).toArray() te donne des résultats filtrés et triés sans boucle manuelle. Exemple concret : const adults = await db.friends.where('age').above(18).sortBy('name'). C'est infiniment plus sain que de bricoler des index à la main.
Pour un simple stockage clé-valeur, idb-keyval est une pépite : 600 octets, zéro dépendance, une API get/set/del. Tu peux l'utiliser pour un projet léger sans embarquer une lib lourde. Mon avis : évalue ce que tu veux vraiment stocker et comment tu veux l'interroger avant de choisir.
Mon choix : si tu as besoin d'index, de tris, de requêtes complexes, Dexie. Pour juste remplacer localStorage, localForage. Pour le minimum, idb-keyval. Et si tu veux le contrôle total, apprends IndexedDB brut — mais prépare-toi à souffrir.
localForage vs Dexie.js : comment choisir ?
Franchement, la réponse tient en une phrase : si tu stockes des objets sans avoir besoin de les interroger, prends localForage. Si tu dois filtrer, trier ou compter, passe à Dexie.js. J'ai fait l'erreur de vouloir tout faire avec localForage, et j'ai fini par écrire des boucles for sur toutes les clés pour retrouver un utilisateur. C'est là que tu te dis que tu as raté un truc.
localForage reste un wrapper clé-valeur, point. Il est parfait pour des sessions utilisateur, des préférences, des blobs de fichiers. Son API est simple : localForage.setItem('user', user) et c'est tout. Mais dès que tu as besoin de requêtes structurées, comme « tous les utilisateurs de plus de 18 ans », tu es obligé de tout charger en mémoire et de filtrer. Ça marche pour 100 entrées, mais pour 10 000, ton app rame.
Dexie.js, lui, est construit sur IndexedDB avec une couche qui te donne des index et des requêtes. Tu définis un schéma : db.version(1).stores({ users: 'id, age, name' }). Ensuite, tu interroges : db.users.where('age').above(18).toArray(). C'est propre, asynchrone, et ça utilise les index natifs d'IndexedDB. Pas de boucle, pas de filtrage côté JS. Pour une app de gestion de contacts, de tâches, ou de logs, c'est le choix évident.
Mon avis : commence par te poser la question « est-ce que je vais avoir besoin de requêtes complexes ? ». Si oui, Dexie.js directement. Si non, localForage suffit largement. Et si tu veux une solution ultra-légère pour un simple stockage clé-valeur, regarde idb-keyval : 600 octets, zéro dépendance. Mais ne te trompe pas : pour du structuré, Dexie.js te sauvera la vie.
Solutions légères et approches pratiques
Pour un simple stockage clé-valeur, tu n'as pas besoin d'une usine à gaz. idb-keyval fait le job en 600 octets. Regarde :
C'est tout. Pas de dépendance, pas de schéma, pas de configuration. Si tu veux un fallback vers localStorage pour les vieux navigateurs, localForage le gère automatiquement, mais il pèse 8 Ko. Mon avis : si tu contrôles ton environnement, idb-keyval suffit largement.
La migration de localStorage vers IndexedDB, c'est souvent une question de wrapper. Tu peux écrire une petite fonction qui utilise localStorage en mémoire et IndexedDB en production, ou utiliser localForage qui fait le fallback. Mais ne migre pas les données à la volée. Charge-les en arrière-plan, puis bascule. Un exemple :
Le piège, c'est de bloquer le thread pendant la migration. Fais-la en tâche de fond, avec un indicateur de progression. Et si tu as beaucoup de données, migre par lots. Une fois que tout est écrit dans IndexedDB, tu peux effacer localStorage. Mais ne le fais pas avant — sinon tu perds tout.
Conclusion
Le choix d'un plugin de stockage se résume à une question : quelle est la complexité de tes données ? Si tu stockes un token ou une préférence, localStorage suffit. Mais dès que tu manipules des objets, des blobs, ou que tu veux interroger tes données, tu passes à IndexedDB. Et là, le plugin fait toute la différence.
Pour un simple stockage clé-valeur, localForage est mon choix par défaut. Son API asynchrone et sa gestion automatique des types te font gagner un temps fou. Mais si tu as besoin de requêtes structurées, d'index, de tris, ne te torture pas : Dexie.js est la solution. Son API type db.users.where('age').above(18).toArray() est infiniment plus saine que de bricoler une boucle sur toutes les entrées. Pour un besoin minimaliste, idb-keyval fait le job en 600 octets.
Mon avis : ne te précipite pas sur la lib la plus lourde. Commence avec localForage, et passe à Dexie.js le jour où tu as besoin de requêtes complexes. Le bon plugin, c'est celui qui correspond à ton cas d'usage, pas celui qui est le plus populaire. Prends le temps de tester, et tu verras que le stockage navigateur devient un jeu d'enfant.