Perché il database Web SQL è deprecato?

75

Sto creando un'app ibrida per Android.

All'inizio ho deciso di utilizzare localStorage, dopo aver trascorso 2 giorni, mi sono reso conto che è molto strano e quindi lo ho abbandonato.

Poi, ho rilevato IndexedDB, dopo aver trascorso l'intera giornata e ottenuto l'output in Google Chrome, non è in esecuzione all'interno di una WebView dell'app Android.

E non ho mai usato il database Web SQL perché era deprecato. Ad ogni modo, ho notato che PhoneGap utilizza ancora Web SQL e il browser di Android lo supporta.

Perché il Web SQL è stato deprecato in primo luogo? E sarà una buona idea per me andare con Web SQL ora?

    
posta gnat 04.12.2013 - 14:06
fonte

3 risposte

85

Versione breve: Web SQL è stato deprecato perché gli standard sono davvero importanti e trasformare Web SQL in uno standard appropriato sarebbe stato proibitivo.

Poiché le implementazioni esistenti di Web SQL sono fondamentalmente wrapper attorno a SQLite, qualsiasi tentativo di definire uno standard di esso era fondamentalmente "fai ciò che fa SQLite". Questo non è abbastanza buono; un vero standard deve essere autonomo, per definire l'interfaccia e i casi d'angolo e le eccezioni di per sé invece di puntare a un'implementazione esistente (specialmente un'implementazione di terze parti come SQLite). Altrimenti, corri il rischio di prendere le stranezze di una particolare implementazione e consacrarle come standard. Da quello che ho letto, il W3C preferisce implementazioni indipendenti multiple degli standard proposti per aiutare a garantire che ciò accada; dal momento che il Web SQL era così legato a SQLite, non sarebbe successo.

Il blog di Mozilla offre di più dettagli sul loro ragionamento in particolare per non supportare il Web SQL; apparentemente erano una delle voci più importanti nell'ottenere deprecato Web SQL.

Dovresti andare con Web SQL ora? Non mi aspetto che i distributori che attualmente lo supportano (come Google e Apple) lo abbandonino in qualsiasi momento, ma IE e Firefox non lo aggiungeranno, e dal momento che è deprecato, perché investire in esso? (Ad esempio, Ido Green , con Google Developer Relations, non è consigliabile utilizzarlo. )

    
risposta data 04.12.2013 - 14:34
fonte
16

La risposta di Josh Kelley è finora la migliore risposta che abbia mai trovato sulla ragione del lavoro standard da fermare. Detto questo, penso che ci sia una prospettiva aggiuntiva da considerare per quanto riguarda la base di utenti.

Anche se non sono d'accordo sull'approccio di Ido Green all'argomento ("Questa è una raccomandazione per gli sviluppatori web di non utilizzare più la tecnologia con la stessa efficacia") ...

Credo (come vi4m afferma nei commenti dell'articolo di 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 aggiungerei un altro approccio logico: se stai sviluppando per l'ambiente mobile ... ¿quali sono gli ambienti in più mani? Risposta: iOS e Android ... Quindi se ENTRAMBI supportano webSQL e il tuo obiettivo è MASSIVE MOBILE, fallo!

Pensa che le app di grandi dimensioni sono quasi sempre all'inizio, ottieni il MOST prima, poi (una volta raggiunto il successo) ricrea il lavoro per ottenere il restante meno (se vuoi davvero raggiungerli o ti viene chiesto di farlo). Infine, non sempre successo che segna il percorso?

Dopo aver letto l'articolo di Nolan Lawson (in cui è evidente la sua intenzione di dare una possibilità alla sua invenzione) credo che questa faccenda sia diventata una nuova guerra fredda tra giganti della tecnologia che non dovrebbe neppure esistere. Credo che le specifiche siano fatte per rimanere (più - il più lungo e il più intimo possibile - il meglio per le prestazioni orientate al cliente). Ironia della sorte, il lavoro "specs guys" è di generare nuove specifiche (a volte dove non ce n'è bisogno, quindi può avere qualcosa di più da fare), e allo stesso modo i lavori dei programmatori a volte si concentrano sul cambiare e riscrivere ciò che già funziona invece di fare soluzioni per nuovi problemi e nuove tendenze.

Per me, i database lato client consistevano semplicemente nel fare paralleli (tra lato server e lato client) in modo da poter creare, archiviare, caricare e scaricare facilmente i dati. Con questo approccio, avere gli stessi linguaggi e strutture (almeno per noi, gli sviluppatori di LAMP opensource) è semplice e logico.

Credo che l'intenzione di IndexedDB di essere un'alternativa con possibilità sempre più nuove sia un approccio sempre buono, ma in qualche modo mi ricorda la necessità di sviluppare software che DEVE essere installato (anche quando la soluzione core può rimanere sul cloud ). In un mondo che tende a rimanere connesso suona come A) una questione di controllo e possesso o B) concentrandosi sullo sviluppo di mostri per il lato client ... ma per quel tipo di esigenze esistono Apps (nel mondo Mobile) e software (nel mondo PC). Credo che l'obiettivo di Webapps dovrebbe rimanere principalmente sull'estensione del Web indipendentemente dal dispositivo.

Credo che una buona infografica potrebbe uscire da questo approccio.

    
risposta data 14.03.2014 - 17:09
fonte
1

La realtà è che le parti contribuenti hanno raggiunto un'impasse sulla direzione dello standard. In breve, nessuno potrebbe essere d'accordo.

Il sito W3C lo spiega.

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.

sito WSC

    
risposta data 20.06.2014 - 17:16
fonte

Leggi altre domande sui tag