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.