Por que o banco de dados da Web SQL está obsoleto?

75

Estou fazendo um aplicativo Android híbrido.

No começo eu decidi usar o localStorage, depois de passar 2 dias, percebi que é muito estranho e por isso desisti.

Então, eu peguei indexedDB, depois de passar o dia inteiro de hoje e realmente obter o resultado no Google Chrome, ele não está sendo executado dentro de um WebView do aplicativo android.

E eu nunca usei o banco de dados Web SQL porque ele estava obsoleto. De qualquer forma, chegou ao meu conhecimento que o PhoneGap ainda usa o Web SQL e os navegadores do Android o suportam.

Por que o Web SQL foi suspenso em primeiro lugar? E será uma boa ideia ir com o Web SQL agora?

    
por gnat 04.12.2013 / 14:06
fonte

3 respostas

85

Versão resumida: o Web SQL foi preterido porque os padrões são realmente importantes e tornar o Web SQL um padrão adequado teria sido proibitivamente difícil.

Como as implementações existentes do Web SQL são basicamente wrappers em torno do SQLite, qualquer tentativa de definir um padrão dele era basicamente "fazer o que o SQLite faz". Isso não é bom o suficiente; um verdadeiro padrão precisa ser autônomo, para definir a interface e os casos de canto e as próprias exceções, em vez de apontar para uma implementação existente (especialmente uma implementação de terceiros, como o SQLite). Caso contrário, você corre o risco de tomar as peculiaridades de uma implementação e consagrá-las como padrão. Pelo que li, o W3C prefere múltiplas implementações independentes de padrões propostos para ajudar a garantir que isso aconteça; como o Web SQL estava tão ligado ao SQLite, isso simplesmente não aconteceria.

O blog da Mozilla dá mais detalhes sobre seu raciocínio, em particular, por não suportar o Web SQL; aparentemente, eles foram uma das principais vozes em deixar o Web SQL obsoleto.

Você deveria ir com o Web SQL agora? Eu não espero que os fornecedores que atualmente o suportam (como o Google e a Apple) o descartem em breve, mas o IE e o Firefox não o estarão adicionando, e como ele está obsoleto, por que investir nele? (Por exemplo, Ido Green , com o Google Developer Relations, não recomenda usá-lo. )

    
por 04.12.2013 / 14:34
fonte
16

A resposta de Josh Kelley é até agora a MELHOR resposta que já encontrei sobre o motivo do trabalho padrão a ser interrompido. Dito isso, acho que há uma perspectiva adicional a considerar em relação à base de usuários.

Eventhough, eu discordo sobre a abordagem de Ido Green para o assunto ("Esta é uma recomendação para desenvolvedores da web para não usar mais a tecnologia de forma tão eficaz") ...

Eu acredito (como afirma o vi4m nos comentários do artigo de Ido Green):

We (developers) can still use this technology. No browser vendor requested removal of this technology, nor plan to remove it. Developers are the voice of the web. We can just still using it, maybe Mozilla will change mind ;-)

E eu adicionaria outra abordagem lógica: Se você está desenvolvendo para ambiente móvel ... ¿quais ambientes estão em mais mãos? Resposta: iOS e Android ... Então, se BOTH suportam webSQL, e seu alvo é MASSIVE MOBILE, vá em frente!

Pense como grandes aplicativos têm feito quase sempre no início, obtenha o MAIS PRIMEIRO, então (uma vez alcançado o sucesso) recriar o trabalho para obter o restante menos (se você realmente quiser alcançá-los ou se for solicitado a fazê-lo). Por fim, nem sempre é sucesso quem marca o caminho?

Depois de ler o artigo de Nolan Lawson (no qual está clara sua intenção de dar uma chance à sua invenção), acredito que este assunto se tornou uma nova guerra fria entre gigantes tecnológicos que nem deveria existir. Acredito que as especificações são feitas para ficar (o quanto mais longo e intocado possível, melhor para o desempenho orientado ao cliente). Ironicamente, o trabalho de "specs guys" é gerar NOVAS especificações (às vezes onde não há nenhuma necessidade, então ele pode ter algo mais a fazer), e da mesma forma os trabalhos de programadores às vezes se concentram em mudar e reescrever o que já funciona ao invés de fazer soluções para novos problemas e novas tendências.

Para mim, os bancos de dados do lado do cliente eram uma questão de simplesmente estabelecer paralelos (entre os lados do servidor e do cliente) para que pudéssemos criar, armazenar, fazer upload e fazer download de dados com facilidade. Sob essa abordagem, ter as mesmas linguagens e estruturas (pelo menos para nós, desenvolvedores de software livre LAMP) é direto e lógico.

Acredito que a intenção do IndexedDB por ser uma alternativa com possibilidades mais amplas e novas é sempre uma boa abordagem, mas de alguma forma me parece a necessidade de desenvolver software que precisa ser instalado (mesmo quando a solução principal pode permanecer na nuvem ). Em um mundo que tende a permanecer conectado soa como A) uma questão de controle e posse ou B) focando no desenvolvimento de monstros para o lado do cliente ... mas para esse tipo de necessidade existem Apps (no mundo Mobile) e software (no mundo do PC). Acredito que o objetivo dos Webapps deve permanecer principalmente na extensão da Web, independentemente do dispositivo.

Eu acredito que um bom infográfico poderia sair dessa abordagem.

    
por 14.03.2014 / 17:09
fonte
1

A realidade é que as partes contribuintes chegaram a um impasse sobre a direção do padrão. Em resumo, ninguém poderia concordar.

O site do W3C explica isso.

The specification reached an impasse: all interested implementors have used the same SQL backend (Sqlite), but we need multiple independent implementations to proceed along a standardisation path.

site da WSC

    
por 20.06.2014 / 17:16
fonte