Na superfície, as duas tecnologias podem parecer diretamente comparáveis, no entanto, se você passar algum tempo com elas, logo perceberá que elas não são. Eles foram projetados para atingir um objetivo semelhante, o armazenamento no lado do cliente, mas eles abordam a tarefa em questão de perspectivas significativamente diferentes e funcionam melhor com diferentes quantidades de dados.
localStorage, ou mais precisamente Armazenamento na Web , foi projetado para pequenas quantidades de dados. É essencialmente um armazenamento de valor-chave apenas de strings , com uma API simplista síncrona . Essa última parte é fundamental. Embora não haja nada na especificação que proíba um armazenamento DOM assíncrono, atualmente todas as implementações são síncronas (ou seja, solicitações de bloqueio). Mesmo que você não tenha se importado em usar um armazenamento ingênuo de valores-chave para grandes quantidades de dados, seus clientes se importarão em esperar que seu aplicativo seja carregado.
OindexedDB , por outro lado, foi projetado para trabalhar com quantidades significativamente maiores de dados. Primeiro, em teoria, ele fornece uma API síncrona e assíncrona. Na prática, no entanto, todas as implementações atuais são assíncronas e as solicitações não bloquearão o carregamento da interface do usuário. Além disso, indexedDB, como o nome revela, fornece índices . Você pode executar consultas rudimentares em seu banco de dados e buscar registros pesquisando as chaves deles em intervalos de chaves específicos . O indexedDB também suporta transações e fornece tipos simples (por exemplo, Data).
Neste ponto, indexedDB pode parecer a solução superior para qualquer situação. No entanto, há uma penalidade em todos os seus recursos: em comparação com o DOM Storage, sua API é bastante complicada. indexedDB pressupõe uma familiaridade geral com conceitos de banco de dados, enquanto que com DOM Storage você pode ir direto ao ponto. Se você já trabalhou com cookies, não terá um problema ao trabalhar com DOM Storage. Além disso, em geral, você precisará escrever mais código no indexedDB para obter exatamente o mesmo resultado que no DOM Storage (e mais código = mais bugs). Além disso, emular o DOM Storage para navegadores que não suportam é relativamente simples. Com indexedDB, a tarefa não valeria a pena. Por fim, antes de mergulhar no indexedDB, primeiro você deve dar uma olhada na API de cota .
No final do dia, depende totalmente de você usar o DOM Storage ou indexedDB, ou ambos, em seu aplicativo. Um bom caso de uso para o Armazenamento DOM seria armazenar dados de sessão simples, por exemplo, o nome de um usuário, e salvar algumas solicitações para o banco de dados real. Por outro lado, os recursos adicionais do indexedDB podem ajudá-lo a armazenar todos os dados necessários para que seu aplicativo funcione offline.