¿Por qué la base de datos Web SQL está en desuso?

Estoy haciendo una aplicación de Android híbrida.

Al principio decidí usar localStorage, después de pasar 2 días, me di cuenta de que es muy extraño y lo dejé.

Luego, recogí indexedDB, después de pasar todo el día de hoy y obtener el resultado en Google Chrome, no se ejecuta dentro de un WebView de la aplicación de Android.

Y nunca usé la base de datos Web SQL porque estaba en desuso. De todos modos, me di cuenta de que PhoneGap todavía usa Web SQL y los navegadores de Android lo admiten.

¿Por qué se desactivó Web SQL en primer lugar? ¿Y será una buena idea para mí ir con Web SQL ahora?

Versión corta: Web SQL quedó en desuso porque los estándares son realmente importantes y convertir Web SQL en un estándar adecuado habría sido prohibitivamente difícil.

Dado que las implementaciones existentes de Web SQL son básicamente envolturas alrededor de SQLite, cualquier intento de definir un estándar del mismo era básicamente "hacer lo que hace SQLite". Esto no es lo suficientemente bueno; un verdadero estándar debe ser autónomo, para definir la interfaz y los casos de esquina y las excepciones en sí, en lugar de apuntar a una implementación existente (especialmente una implementación de terceros como SQLite). De lo contrario, corre el riesgo de tomar las peculiaridades de una implementación en particular y consagrarlas como estándar. Por lo que he leído, el W3C prefiere múltiples implementaciones independientes de los estándares propuestos para ayudar a asegurar que esto suceda; como Web SQL estaba tan vinculado a SQLite, eso simplemente no iba a suceder.

El blog de Mozilla da más detalles sobre su razonamiento en particular para no admitir Web SQL; aparentemente fueron una de las principales voces en desaprobar Web SQL.

¿Deberías ir con Web SQL ahora? No espero que los proveedores que actualmente lo admiten (como Google y Apple) lo eliminen pronto, pero IE y Firefox no lo agregarán, y dado que está en desuso, ¿por qué invertir en él? (Por ejemplo, Ido Green , con Google Developer Relations, no recomienda usarlo).

La respuesta de Josh Kelley es hasta ahora la MEJOR respuesta que he encontrado sobre la razón del trabajo estándar que se debe detener. Dicho esto, creo que hay una perspectiva adicional a considerar con respecto a la base de usuarios.

Sin embargo, no estoy de acuerdo con el enfoque de Ido Green sobre el tema ("Esta es una recomendación para que los desarrolladores web ya no usen la tecnología de manera tan efectiva") ...

Creo (como afirma vi4m en los comentarios del artículo de Ido Green):

Nosotros (los desarrolladores) aún podemos usar esta tecnología. Ningún proveedor de navegadores solicitó la eliminación de esta tecnología, ni planea eliminarla. Los desarrolladores son la voz de la web. Podemos seguir usándolo, tal vez Mozilla cambie de opinión ;-)

Y agregaría otro enfoque lógico: si está desarrollando para entornos móviles ... ¿qué ambientes están en más manos? Respuesta: iOS y Android ... Entonces, si AMBOS son compatibles con webSQL, y su objetivo es MÓVIL MASIVO, ¡adelante!

Piense como las grandes aplicaciones lo han hecho casi siempre al principio, obtenga la MAYORÍA primero, luego (una vez que haya logrado el éxito) vuelva a crear el trabajo para obtener la menor cantidad restante (si realmente desea lograrlas o se le pide que lo haga). Finalmente, ¿no es siempre el éxito quien marca el camino?

Después de leer el artículo de Nolan Lawson (en el que está claro su intención de darle una oportunidad a su invención) creo que este asunto se convirtió en una nueva guerra fría entre gigantes tecnológicos que ni siquiera debería existir. Creo que las especificaciones están hechas para permanecer (lo más largo y lo más intacto posible) para el mejor rendimiento orientado al cliente. Irónicamente, el trabajo de "especificaciones técnicas" es generar NUEVAS especificaciones (a veces donde no se necesita ninguna, para que pueda tener algo más que hacer), y de la misma manera, los trabajos de los programadores a veces se centran en cambiar y reescribir lo que ya funciona en lugar de hacer soluciones para nuevos problemas. y nuevas tendencias.

Para mí, las bases de datos del lado del cliente consistían simplemente en hacer paralelos (entre el lado del servidor y el del cliente) para que pudiéramos crear, almacenar, cargar y descargar datos fácilmente. Según este enfoque, tener los mismos lenguajes y estructuras (al menos para nosotros, los desarrolladores de código abierto de LAMP) es sencillo y lógico.

Creo que la intención de IndexedDB de ser una alternativa con posibilidades más amplias y nuevas es siempre un buen enfoque, pero de alguna manera se parece a la necesidad de desarrollar software que NECESITA instalarse (incluso cuando la solución central puede permanecer en la nube). En un mundo que tiende a mantenerse conectado, suena como A) una cuestión de control y posesión o B) enfocándose en desarrollar monstruos para el lado del cliente ... pero para ese tipo de necesidades existen aplicaciones (en el mundo móvil) y software (en el mundo de la PC). Creo que el objetivo de Webapps debería ser principalmente extender la web sin importar el dispositivo.

Creo que una buena infografía podría salir de este enfoque.

La realidad es que las partes contribuyentes llegaron a un punto muerto en la dirección de la norma. En resumen, nadie podría estar de acuerdo.

El sitio W3C explica esto.

La especificación llegó a un punto muerto: todos los implementadores interesados ​​han utilizado el mismo backend SQL (Sqlite), pero necesitamos múltiples implementaciones independientes para avanzar a lo largo de una ruta de estandarización.

Sitio de la CSM