Na superfície, as duas tecnologias podem parecer diretamente comparáveis; no entanto, se você passar algum tempo com elas, logo perceberá que não. Eles foram projetados para atingir um objetivo semelhante, o armazenamento do lado do cliente, mas abordam a tarefa em questão de perspectivas significativamente diferentes e funcionam melhor com diferentes quantidades de dados.
localStorage, ou mais precisamente Web Storage , foi projetado para quantidades menores de dados. É essencialmente uma cadeia de caracteres - apenas armazenamento de valor-chave , com uma API síncrona simplista . Essa última parte é a chave. 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 se importe em usar um armazenamento de valor-chave ingênuo para grandes quantidades de dados, seus clientes se importarão em esperar para sempre o carregamento do aplicativo.
O indexedDB , 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 impedem o carregamento da interface do usuário. Além disso, o indexedDB, como o nome revela, fornece índices . Você pode executar consultas rudimentares no banco de dados e buscar registros pesquisando as respectivas chaves em intervalos de chaves específicos . O indexedDB também suporta transações e fornece tipos simples (por exemplo, Data).
Nesse ponto, o indexedDB pode parecer a solução superior para todas as situações de todos os tempos. No entanto, há uma penalidade por todos os seus recursos: comparada ao armazenamento DOM, sua API é bastante complicada. O indexedDB assume uma familiaridade geral com os conceitos de banco de dados, enquanto que com o Web Storage você pode entrar. Se você já trabalhou com cookies, não terá problemas ao trabalhar com o Web Storage. Além disso, em geral, você precisará escrever mais código no indexedDB para obter exatamente o mesmo resultado que no Web Storage (e mais código = mais bugs). Além disso, a emulação de armazenamento na Web para navegadores que não o suportam é relativamente simples. Com o indexedDB, a tarefa não valeria a pena. Por fim, antes de mergulhar no indexedDB, você deve primeiro dar uma olhada na API de cotas .
No final do dia, você decide se você usa o Armazenamento na Web ou o indexedDB, ou ambos, em seu aplicativo. Um bom caso de uso para o Armazenamento na Web seria armazenar dados de sessão simples, por exemplo, o nome de um usuário e salvar algumas solicitações no banco de dados real. Os recursos adicionais do indexedDB, por outro lado, podem ajudá-lo a armazenar todos os dados necessários para que seu aplicativo funcione offline.