Introdução:

Estou traduzindo um artigo que achei interessante sobre localStorage. Você pode consular aqui o artigo original (inglês)

Nem tudo eu concordo 100%, porém sempre que eu tiver uma opinião própria eu poderia citar em algum momento (ou não dependendo do meu tempo)

Pare de usar o localStorage!

O título não é clickbait, a mensagem é abrupta: "Stop Using localStorage!" (Pare de usar o localStorage!). Não há ambiguidade aqui, e não estamos dando as mãos e cantando parabéns para amenizar o golpe.

Problemas com o localStorage?

O localStorage surgiu por volta de 2009 como um armazenamento baseado em strings de 5 MB. Vamos direto ao ponto com alguns tópicos, já que nossa capacidade de atenção está em desordem atualmente:

• Uma coleção de strings: Ele só pode armazenar strings. Se você quiser armazenar ou recuperar, precisará serializar e desserializar. Se você se esquecer disso, poderá ficar exposto a peculiaridades que têm sido responsáveis por todos os tipos de sites quebrados. Por exemplo, quando você armazena "true" ou "false", há também um potencial null, undefined ou "" a ser observado, dependendo de sua configuração.

• Sem dados estruturados: O JavaScript tem um recurso chamado algoritmo de clone estruturado. Você realmente precisa saber que isso existe. As APIs modernas e as APIs atualizadas, como postMessage, WebWorkers, IndexedDB, Caches API, BroadcastChannel, Channel Messaging API, MessagePort e History API, usam dados estruturados. Isso resolve o problema de serializar e desserializar JSON em um aplicativo. O localStorage não foi atualizado com esse recurso e não há discussões sobre isso no futuro.

• Compromissos comuns de segurança: Para esclarecer, você nunca deve armazenar dados confidenciais em qualquer armazenamento persistente que não tenha sido projetado especificamente para eles. Os desenvolvedores ainda costumam armazenar IDs de sessão, JWTs, detalhes de cartão de crédito e chaves de API no localStorage. É um hack de segurança muito comum porque é tão fácil quanto window.localStorage_

• Desempenho: Historicamente, o localStorage tinha seus momentos de lentidão, embora tenha havido algumas otimizações ao longo do tempo que o levaram a um desempenho razoável. Apesar disso, ainda não é desejável para aplicativos simultâneos com necessidade de transações frequentes. Se você fizer um benchmark, por exemplo, com o MacBook mais recente sem limitar o desempenho, talvez não entenda as implicações de custo em dispositivos de baixa potência.

• Limitação de tamanho: o localStorage tem um limite de 5 MB que está sujeito a despejo. Essa é uma quantidade muito pequena para aplicativos modernos. É difícil armazenar mídia codificada com uma quantidade tão pequena. E isso não é definitivo, assim como todo armazenamento persistente na Web, o localStorage pode e será removido pelo navegador em algum momento. Espera-se que você gerencie essa parte do ciclo de vida dos dados, apesar de não haver nenhum lembrete para isso.

• Sem acesso ao Web Worker: Espero que você entenda que o localStorage não é uma API para o futuro ou para aproveitar a concorrência, que se esforça em dispositivos de baixa potência.

• Sem atomicidade ou isolamento: o localStorage não garante atomicidade em várias operações. Não há mecanismo de bloqueio para garantir o que é gravado ou para evitar que as informações sejam gravadas por cima.

• Sem separação de dados ou escopo de origem granular: o localStorage é apenas um objeto de cadeias de caracteres, não há separação de dados, os dados do usuário são misturados com os dados do aplicativo. Embora ele use a política de mesma origem, não há como restringir os dados por um domínio ou subdomínio específico que tenha acesso. Isso pode criar trabalho duplicado ao atender aos padrões do GDPR em vários domínios.

• Sem transações agrupadas: o localStorage não tem transações de acordo com a definição do banco de dados, mas também não tem como agrupar operações. Cada operação é síncrona, não isolada, sem bloqueio.

• Problemas de serialização: Muitos sites estão operando com o estado quebrado devido ao mau gerenciamento do localStorage. Desde a época deste artigo, apenas no ano passado, como cliente, três serviços da Web diferentes me disseram para "limpar o cache", o que descobri que era devido ao gerenciamento inadequado do localStorage. Se você não estiver familiarizado com as pegadinhas ao armazenar dados no localStorage, poderá estar criando erros em seu aplicativo que talvez nunca encontre pessoalmente. Esses erros de tipo nem sempre são óbvios, especialmente para novos desenvolvedores.

• Bloqueio de operações síncronas: o localStorage não é assíncrono e bloqueará o thread principal. Ele pode até mesmo tornar suas animações instáveis, dependendo de quanto você lê/grava e com que frequência. A assincronia é fundamental para a criação de aplicativos fluidos, especialmente para dispositivos móveis

Para onde foi o WebSQL?

O objetivo do WebSQL era ser uma interface de banco de dados SQL simples para a Web. Ele tinha um suporte decente, mas acabou enfrentando desafios que o levaram a ser descontinuado.

Por que eles abandonaram o bebê?

• Implementação de um único fornecedor: O WebSQL era basicamente uma coisa do webkit (inicialmente Chrome e Safari). A falta de suporte de outros grandes fornecedores de navegadores (Mozilla e Microsoft) tornou a adoção por parte dos desenvolvedores quase inexistente no mundo comercial.

• Sem padronização do W3C: isso é fundamental para a adoção. A W3 parece ter abandonado a proposta em 2010.

• Concorrência com o IndexedDB: o IndexedDB estava ganhando mais força e suporte durante o surgimento do WebSQL. Ao contrário do WebSQL, o IndexedDB foi projetado para ser uma solução padrão e entre navegadores.

• Preocupações com a segurança: Vários desenvolvedores e especialistas em segurança demonstraram preocupação com a segurança do WebSQL. Eles estavam céticos em relação a vários aspectos, incluindo a falta de controles de permissão e as vulnerabilidades do estilo SOL.

Por fim, o IndexedDB tornou-se o padrão "recomendado" para o armazenamento no lado do cliente, sendo considerado mais robusto e compatível com vários navegadores. Mas de que adianta ser "recomendado" quando a maioria dos desenvolvedores front-end experientes, na época deste artigo, o evitava como uma praga?

Apesar de suas deficiências, na época o WebSQL foi muito elogiado pela comunidade da Web e era um concorrente à altura.

O que são cookies?

Os cookies foram criados em 1994 por Lou Montulli, um programador de navegadores da Web da Netscape Communications.

Alguns de vocês ainda não eram nascidos quando os cookies estavam estragando tudo. O título deste artigo deveria ser "Pare de usar cookies e localStorage", mas essa é uma luta muito difícil (sim, devemos usar cookies seguros).

• Limitações de tamanho: Normalmente, os cookies são limitados a cerca de 4 KB por domínio.

• Dados enviados com cada solicitação: Os cookies são enviados com cada solicitação HTTP para o domínio associado. Se os seus dados não precisarem ser transmitidos com cada solicitação, isso pode resultar em sobrecarga desnecessária e aumento do uso da largura de banda.

• Preocupações com a segurança: Os cookies são mais suscetíveis a XSS. Como os cookies são incluídos automaticamente em cada solicitação ao domínio, eles podem ser alvo de scripts mal-intencionados.

• Expiração e vida útil: Os cookies foram projetados para expirar em uma determinada data.

• Aumento da latência: Como os cookies são incluídos automaticamente em todas as solicitações HTTP para o domínio, eles geralmente aumentam a latência, tornando o carregamento do site mais lento.

Por quê IndexedDB?

• Melhor desempenho: Ao contrário do localStorage, o IndexedDB opera de forma assíncrona, evitando operações de bloqueio. (A API é orientada por eventos, não baseada em promessas)

• Cota de armazenamento ampla: O IndexedDB oferece uma cota de armazenamento maior (dependendo do navegador, do sistema operacional e do armazenamento disponível) em comparação com o limite de 5 MB do localStorage.

• Confiabilidade e dados estruturados: O armazenamento e a recuperação de dados no localStorage podem gerar resultados imprevisíveis se não forem feitos corretamente. O IndexedDB reduz a coerção de tipos comum e adota o algoritmo structuredClone, garantindo a integridade dos dados.
  Mas...

Você provavelmente não quer usar o IndexedDB diretamente

O IndexedDB é a exceção à regra de evitar dependências. Pense no IndexedDB como um banco de dados de back-end, você provavelmente quer um ORM ou uma biblioteca de banco de dados para processar as consultas. Isso é semelhante a querer uma biblioteca do IndexedDB, exceto pelo fato de a API do IndexedDB ser atroz.

O motivo pelo qual você deseja usar uma biblioteca é que, em geral, elas

• São baseadas em Promises
• São mais fáceis de usar
• Reduzem o código padrão
• Concentram-se em coisas mais significativas.

Pessoalmente, não recomendo o uso de bibliotecas grandes para o IndexedDB porque o que você está tentando realizar não exige mais do que um punhado de kBs de um dígito. Bibliotecas IndexedDB excessivas não farão nada de significativo em seus cenários do mundo real.

O único problema que encontrei na maioria das bibliotecas do IndexedDB é que elas são orientadas principalmente para o controle de versão, o que provavelmente não é necessário, especialmente se você estiver apenas procurando uma alternativa razoável de armazenamento local.

Se você precisar de controle de versão ou cursores, recomendo a idb, que é uma biblioteca abrangente que cobre bem todos os casos de nicho.

Conclusão

Embora nem sempre seja possível, nos dias de hoje, devemos tentar evitar o uso do localStorage.

Os novos desenvolvedores terão mais conhecimento significativo e reutilizável para adquirir brincando com Promise(), async/ await e dados estruturados do que tentando descobrir por que o número "0" está tornando suas condições verdadeiras ou por que seu usuário irritado recebeu nulldeliveries.

Recapitulando, há uma vantagem de velocidade, você pode armazenar tipos de forma confiável e pode até usar cursores para iterar sobre as entradas. Com essa tecnologia, você pode criar um mecanismo de pesquisa no lado do cliente com buscas de dados acumulados que não fazem suas animações se mexerem como o localStorage bloqueia e interfere nelas 👀.

indexedDB é comumente descrito como de "baixo nível". Não há absolutamente nada de baixo nível no IndexedDB, ele é apenas uma API com uma sintaxe antiga e pouco amigável. Mas isso não nega seus recursos subjacentes, daí o uso comum da biblioteca.

Você não precisa necessariamente usar a API diretamente, a não ser que queira, mas faz sentido usar uma pequena biblioteca de wrapper ou, por que não, criar a sua própria.