En surface, les deux technologies peuvent sembler directement comparables, mais si vous passez du temps avec elles, vous vous rendrez vite compte qu'elles ne le sont pas. Ils ont été conçus pour atteindre un objectif similaire, le stockage côté client, mais ils abordent la tâche du point de vue de points de vue très différents et fonctionnent mieux avec différentes quantités de données.
localStorage, ou plus précisément Web Storage , a été conçu pour de plus petites quantités de données. Il s’agit essentiellement d’un stockage de valeur-clé composé uniquement de chaînes , avec une API synchrone simpliste . Cette dernière partie est la clé. Bien que rien dans la spécification n'interdit un stockage DOM asynchrone, toutes les implémentations sont actuellement synchrones (c'est-à-dire, les demandes de blocage). Même si cela ne vous dérange pas d'utiliser une clé naïve - une valeur de stockage pour de plus grandes quantités de données, vos clients voudront bien attendre le chargement de votre application.
indexedDB , d’autre part, a été conçu pour fonctionner avec des quantités de données beaucoup plus grandes. Premièrement, en théorie, il fournit une API synchrone et asynchrone. En pratique, toutefois, toutes les implémentations actuelles sont asynchrones et les requêtes ne bloqueront pas le chargement de l'interface utilisateur. De plus, indexedDB, comme son nom l'indique, fournit des index . Vous pouvez exécuter des requêtes rudimentaires sur votre base de données et récupérer des enregistrements en recherchant leurs clés dans des plages de clés spécifiques . indexedDB prend également en charge les transactions et fournit des types simples (par exemple, Date).
À ce stade, indexedDB peut sembler être la solution supérieure pour toutes les situations. Cependant, toutes ses fonctionnalités sont pénalisées: comparée au stockage DOM, son API est assez compliquée. indexedDB suppose une connaissance générale des concepts de base de données, alors qu'avec le stockage Web, vous pouvez y accéder directement. Si vous avez déjà travaillé avec des cookies, vous n'aurez aucun problème à utiliser le stockage Web. En outre, en général, vous aurez besoin d'écrire plus de code dans indexedDB pour obtenir exactement le même résultat que dans le stockage Web (et plus de code = plus de bogues). De plus, l’émulation de Web Storage pour les navigateurs qui ne le prennent pas en charge est relativement simple. Avec indexedDB, la tâche ne vaudrait pas la peine. Enfin, avant de vous plonger dans indexedDB, vous devez d'abord jeter un coup d'œil à l' API Quota .
En fin de compte, c'est à vous de choisir si vous utilisez Web Storage ou indexedDB, ou les deux, dans votre application. Un bon cas d'utilisation de Web Storage serait de stocker des données de session simples, par exemple le nom d'un utilisateur, et de vous enregistrer certaines requêtes dans votre base de données réelle. Les fonctionnalités supplémentaires d’indexedDB, en revanche, pourraient vous aider à stocker toutes les données dont vous avez besoin pour que votre application fonctionne en mode hors connexion.