* There is a common misconception about SQLite3 dynamic type system. It can be done using SQL statements: http://stackoverflow.com/a/2762020, http://www.sqlite.org/datatype3.html . The browser vendors could enable static typing by default by adding a few lines of code or just a flag afaik. Beside that there are other SQL db engines. SQL-92 was the third revision of the SQL database query language. It's the common dialect that every SQL engine supports: http://en.wikipedia.org/wiki/SQL-92
* Beside that even if Microsoft would use JetRed (http://en.wikipedia.org/wiki/Microsoft_Jet_Database_Engine) or JetBlue (http://en.wikipedia.org/wiki/Microsoft_JET_Blue) database engine and use a slightly different SQL dialect, everyone else would use SQLite anyway (and even Microsoft products like several Xbox games and Tools use SQLite). It's the same like supporting different XHR/AJAX API versions (like the ActiveX API calls of < IE9) or many other glitches. One could use a shim.
Without WebSQL support one has to compile SQLite via emscripten to asm.js -> 3 MB big JS file.
Or you know, one could use IndexedDB, because you don't need a freaking relational model, unless you're planning to execute ad-hoc queries and aggregation on a significant amount of data, data that would do well to fit the relational model, which would be a stupid idea to do in the browser.
> everyone else would use SQLite anyway
That does not make it a web standard and after 25 years of web evolution, I can't believe we are still having the same problems. The web has been extremely successful for some obvious reasons, yet we keep forgetting those reasons. One of the web's primary traits is that it's based on documented standards and has multiple implementations. SQLite fails that test.
> One could use a shim
Or you could not have this problem in the first place. And technically you could implement WebSQL on top of IndexedDB.
> unless you're planning to execute ad-hoc queries and aggregation on a significant amount of data, data that would do well to fit the relational model, which would be a stupid idea to do in the browser.
You mean like every iOS app that uses Core Data? And web apps will kill native apps with an approach like this?
> SQL-92 was the third revision of the SQL database query language.
And is completely irrelevant to WebSQLDB, which specifies "the SQL dialect supported by SQLite 3.6.19" -- not SQL-92 -- as what implementations must support. The SQL dialect supported by SQLite 3.6.19 does not include all of SQL-92, and includes extensions to SQL-92, so supporting SQL-92 would be neither necessary nor sufficient, from a supported SQL standpoint, to conform to the WebSQLDB spec.
* Beside that even if Microsoft would use JetRed (http://en.wikipedia.org/wiki/Microsoft_Jet_Database_Engine) or JetBlue (http://en.wikipedia.org/wiki/Microsoft_JET_Blue) database engine and use a slightly different SQL dialect, everyone else would use SQLite anyway (and even Microsoft products like several Xbox games and Tools use SQLite). It's the same like supporting different XHR/AJAX API versions (like the ActiveX API calls of < IE9) or many other glitches. One could use a shim.
Without WebSQL support one has to compile SQLite via emscripten to asm.js -> 3 MB big JS file.