4 ms·

I'm not sure WebSQL was but maybe it just died off as nobody was using it?

mschuster91 10y ago
WebSQL was basically SQLite accessible from JS - which also, unfortunately, was the reason for it being dropped... apparently the standards committees only want standards with multiple competing implementations. Which is total bananas, given the fact that there's only one (free, ultra portable, tiny) embeddable SQL database - SQLite. Which every browser except IE/Edge ships, anyways, for internal data storage.
- tannhaeuser 10y ago
  I'm a big fan of sqlite and would have loved to see WebSQL succeed, but I think HTML adopting the de-facto behaviour of sqlite is "bananas" - it would be the equivalent of "formatLikeWord95" of the OOXML spec. They should have defined a proper ISO SQL subset/profile instead. What remains of WebSQL is the commonly implemented SQL client driver API for Node.js which isn't so good a fit IMHO.
  - mschuster91 10y ago
    > They should have defined a proper ISO SQL subset/profile instead. That wouldn't have helped. Google Chrome (and, by extension, Safari and Opera) and Firefox would just use the already present SQLite library in the engine... and I think MS would also have chosen SQLite instead of risking to develop a full SQL database (and opening a rich source of bugs and security issues, in contrast with using battle-tested SQLite). Again, just one implementation of the standard.
    - tannhaeuser 10y ago
      Or, MS would have blessed us with their Access/JET DB.
      - mschuster91 10y ago
        Well if MS could build a safe interface to Access (also managing translation from ISO SQL to Access SQL!), I'd be perfectly fine with it! I've seen people building really nice stuff based on it, a pity it's only available on "higher end" Office variants and even there only on Windows :(
    - dragonwriter 10y ago
      Microsoft has several embedded DB engines of their own (not Free, but they already own them), so I don't know that they would have used SQLite.
- detaro 10y ago
  regarding apparently the standards committees only want standards with multiple competing implementations., yes, that is a quite basic principle, but it is not directly what killed WebSQL. (Non-)passing of a standard depends a lot on what is going inside the specific Working Group: If everybody had agreed that SQL was the right answer/important to have, WebSQL probably could have gotten through pretty close to what it was, but they didn't. Mozilla published some blog posts about why they didn't like WebSQL and backed IndexedDB instead: https://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/ https://hacks.mozilla.org/2010/06/beyond-html5-database-apis... If someone else had put in the work to write a "proper specification" of an SQL dialect, shown that it works with (modified) SQLite and was reasonable to implement in a different implementation, WebSQL might have passed nevertheless. It happens that W3C Working Groups release standards without 2 implementations, so this isn't some strict rule that can't be broken, but then everybody involved agrees. In the other direction, I think it would have been good to demonstrate by implementation that you can build good SQL-like APIs on top of IndexedDB during the standards process, to make sure it fulfills that need.
- paulddraper 10y ago
  ...and somehow the browser adopted WebGL which is even more blatantly OpenGL.
  - detaro 10y ago
    OpenGL has multiple, independent implementations (including backends) though. Being based on another API standard is not the problem.
dragonwriter 10y ago
WebSQL was a browser-embedded SQL database engine. It was killed by the standards committee because a key part of the standard was essentially "do exactly what SQLite version x.yy does", because the only implementation was by embedding that version of SQLite in the browser and putting a thin API on top of it.
- paulddraper 10y ago
  And Mozilla said they would never ever support such a thing

WebSQL was basically SQLite accessible from JS - which also, unfortunately, was the reason for it being dropped... apparently the standards committees only want standards with multiple competing implementations. Which is total bananas, given the fact that there's only one (free, ultra portable, tiny) embeddable SQL database - SQLite. Which every browser except IE/Edge ships, anyways, for internal data storage.

tannhaeuser 10y ago
I'm a big fan of sqlite and would have loved to see WebSQL succeed, but I think HTML adopting the de-facto behaviour of sqlite is "bananas" - it would be the equivalent of "formatLikeWord95" of the OOXML spec. They should have defined a proper ISO SQL subset/profile instead. What remains of WebSQL is the commonly implemented SQL client driver API for Node.js which isn't so good a fit IMHO.
- mschuster91 10y ago
  > They should have defined a proper ISO SQL subset/profile instead. That wouldn't have helped. Google Chrome (and, by extension, Safari and Opera) and Firefox would just use the already present SQLite library in the engine... and I think MS would also have chosen SQLite instead of risking to develop a full SQL database (and opening a rich source of bugs and security issues, in contrast with using battle-tested SQLite). Again, just one implementation of the standard.
  - tannhaeuser 10y ago
    Or, MS would have blessed us with their Access/JET DB.
    - mschuster91 10y ago
      Well if MS could build a safe interface to Access (also managing translation from ISO SQL to Access SQL!), I'd be perfectly fine with it! I've seen people building really nice stuff based on it, a pity it's only available on "higher end" Office variants and even there only on Windows :(
  - dragonwriter 10y ago
    Microsoft has several embedded DB engines of their own (not Free, but they already own them), so I don't know that they would have used SQLite.
detaro 10y ago
regarding apparently the standards committees only want standards with multiple competing implementations., yes, that is a quite basic principle, but it is not directly what killed WebSQL. (Non-)passing of a standard depends a lot on what is going inside the specific Working Group: If everybody had agreed that SQL was the right answer/important to have, WebSQL probably could have gotten through pretty close to what it was, but they didn't. Mozilla published some blog posts about why they didn't like WebSQL and backed IndexedDB instead: https://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/ https://hacks.mozilla.org/2010/06/beyond-html5-database-apis... If someone else had put in the work to write a "proper specification" of an SQL dialect, shown that it works with (modified) SQLite and was reasonable to implement in a different implementation, WebSQL might have passed nevertheless. It happens that W3C Working Groups release standards without 2 implementations, so this isn't some strict rule that can't be broken, but then everybody involved agrees. In the other direction, I think it would have been good to demonstrate by implementation that you can build good SQL-like APIs on top of IndexedDB during the standards process, to make sure it fulfills that need.
paulddraper 10y ago
...and somehow the browser adopted WebGL which is even more blatantly OpenGL.
- detaro 10y ago
  OpenGL has multiple, independent implementations (including backends) though. Being based on another API standard is not the problem.

dragonwriter 10y ago

WebSQL was a browser-embedded SQL database engine. It was killed by the standards committee because a key part of the standard was essentially "do exactly what SQLite version x.yy does", because the only implementation was by embedding that version of SQLite in the browser and putting a thin API on top of it.

paulddraper 10y ago
And Mozilla said they would never ever support such a thing