4 ms·

We are stuck with NoSQL in HTML5, because Mozilla and Microsoft refuse to implement WebSQL (http://en.wikipedia.org/wiki/WebSQL http://en.wikipedia.org/wiki/Web

by frik 13y ago

We are stuck with NoSQL in HTML5, because Mozilla and Microsoft refuse to implement WebSQL (http://en.wikipedia.org/wiki/WebSQL http://en.wikipedia.org/wiki/WebSQL ) IndexedDB is fine for storing JSON objects, etc. but a relational database with SQL query syntax, indexes, etc. more powerful and means less code to write. With IndexedDB one has to reinvent the wheel to just get basic query features. WebSQL is not deprecation, the W3C Working Group Note actually says: 'This specification is no longer in active maintenance and the Web Applications Working Group does not intend to maintain it further'. WebSQL is only available in Webkit based Browsers (Safari, Chrome) which means most mobile browsers. As SQLite is in public domain, no company would "loose their face" if they choose to use it. They could fork off SQLite and change the SQL query syntax (parser) to whatever the W3C finds suitable. https://www.sqlite.org https://www.sqlite.org Mozilla Firefox and FirefoxOS both already ship SQLite for years and can be accessed by its internal JavaScript API. And several Microsoft products already use it anyway (e.g. Forza Xbox games). Microsoft has of course also various other SQL database libraries like MS Access JetRed, MS Outlook JetBlue and SQL Express. We had a discussion about it recently: https://news.ycombinator.com/item?id=7574754 https://news.ycombinator.com/item?id=7574754 The new hip things is "NewSQL" (http://en.wikipedia.org/wiki/NewSQL http://en.wikipedia.org/wiki/NewSQL ). For example Facebook, Google Ads, etc. are powered by MySQL's InnoDB database engine. I would go as far as count SQLite to this group. We would need a movement to convince Mozilla to finally add WebSQL to Firefox and FirefoxOS.

davidjohnstone 13y ago
There are good reasons why work has stopped on the WebSQL specification — everybody was using SQLite, and the specification can't be tied so closely to a single implementation of SQL. The specification even has the line "User agents must implement the SQL dialect supported by Sqlite 3.6.19"[1]. 1. http://www.w3.org/TR/webdatabase/#web-sql http://www.w3.org/TR/webdatabase/#web-sql Edit: here is Mozilla's rationale for not supporting WebSQL: 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...
- mmahemoff 13y ago
  While that looks ridiculous at first glance, one of the important things about the HTML5 spec was reverse-engineering to describe what the browsers are actually doing. I'd be more worried if it says "the latest stable SQLite", but referring to a frozen version is only being honest about expectations. I believe SQLite caused issues with MS, but Mozilla was more philosophically opposed to SQL as being legacy tech. Which is understandable but unfortunate when the standard had momentum and SQL is so well-understood.
  - jgraham 13y ago
    One of the things that's well understood about SQL is that interop is terrible. No one expects to write anything substantial using Postgres and be able to port it over to MySQL or MSSQL without a serious amount of effort. On the backend, that's more or less OK, although one of the value propositions of ORMs is that they make it somewhat easier to change databases later by reducing the amount of product-specific SQL that has to be rewritten. On the web, however, it's totally unacceptable. Sites are expected to keep working between multiple browsers and across multiple browser versions. To achieve that level of interop would have required someone to sit down and write a detailed specification of the dialect of SQL that should be supported on the web, and for browser vendors to take the time to implement it. In practice people weren't willing to spend the time doing either of those things; the level of buy-in was enough to fork sqlite but no higher. Eventually the web might get something like WebSQL. But the way it will happen will be for people to implement SQL in js on top of IndexedDB. If that proves popular but has issues (e.g. with performance) then there will be renewed impetus to do a proper job of a WebSQL specification.
    - kbenson 13y ago
      I fail to see how that's any different than the current case with JS and how we use shims to normalize the usage to a sane, concise API until it stabilizes (if it ever does). Do we really expect there won't be umpteen shims for WebSQL to normalize any syntax and feature inconsistencies?
    - brixon 13y ago
daleharvey 13y ago
Safari are finally adding IndexedDB, which means for the first time we have a unified storage interface across all the browsers. IndexedDB is kinda nasty to work with directly, but there are fairly good libraries on top of it. http://www.taffydb.com/ http://www.taffydb.com/ looks great for complex queries. One I work on http://pouchdb.com http://pouchdb.com provides syncing (also works with WebSQL) WebSQL is also pretty nasty to work with, hand crafting SQL string in the browser for one just feelds weird, even yesterday I had a bug filed which related to the internal SQLLite implementation (the entire reason WebSQL is a no go is it has one implementation, Richard Hipp would now own web storage) I havent seen much support from webSQL, even between those of us who actually use it most are just waiting for it to die, indexeddb in safari is that final nail
- taf2 13y ago
  "Safari are finally adding IndexedDB, which means for the first time we have a unified storage interface across all the browsers." localStorage has been well supported over all browers since IE8... It's interface IMO is a perfect fit in JavaScript... with the one exception of not being callback driven...
  - daleharvey 13y ago
    Yeh sorry, not technically correct, while localstorage is great for quickly storing small items, due to having a sync api and having to encode / decode complex data its a non starter more data driver applications, so I always automatically exclude it
- deleted 13y ago
  [deleted]

by frik 13y ago

davidjohnstone 13y ago

There are good reasons why work has stopped on the WebSQL specification — everybody was using SQLite, and the specification can't be tied so closely to a single implementation of SQL. The specification even has the line "User agents must implement the SQL dialect supported by Sqlite 3.6.19"[1]. 1. http://www.w3.org/TR/webdatabase/#web-sql http://www.w3.org/TR/webdatabase/#web-sql Edit: here is Mozilla's rationale for not supporting WebSQL: 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...

mmahemoff 13y ago
While that looks ridiculous at first glance, one of the important things about the HTML5 spec was reverse-engineering to describe what the browsers are actually doing. I'd be more worried if it says "the latest stable SQLite", but referring to a frozen version is only being honest about expectations. I believe SQLite caused issues with MS, but Mozilla was more philosophically opposed to SQL as being legacy tech. Which is understandable but unfortunate when the standard had momentum and SQL is so well-understood.
- jgraham 13y ago
  One of the things that's well understood about SQL is that interop is terrible. No one expects to write anything substantial using Postgres and be able to port it over to MySQL or MSSQL without a serious amount of effort. On the backend, that's more or less OK, although one of the value propositions of ORMs is that they make it somewhat easier to change databases later by reducing the amount of product-specific SQL that has to be rewritten. On the web, however, it's totally unacceptable. Sites are expected to keep working between multiple browsers and across multiple browser versions. To achieve that level of interop would have required someone to sit down and write a detailed specification of the dialect of SQL that should be supported on the web, and for browser vendors to take the time to implement it. In practice people weren't willing to spend the time doing either of those things; the level of buy-in was enough to fork sqlite but no higher. Eventually the web might get something like WebSQL. But the way it will happen will be for people to implement SQL in js on top of IndexedDB. If that proves popular but has issues (e.g. with performance) then there will be renewed impetus to do a proper job of a WebSQL specification.
  - kbenson 13y ago
    I fail to see how that's any different than the current case with JS and how we use shims to normalize the usage to a sane, concise API until it stabilizes (if it ever does). Do we really expect there won't be umpteen shims for WebSQL to normalize any syntax and feature inconsistencies?
  - brixon 13y ago

daleharvey 13y ago

Safari are finally adding IndexedDB, which means for the first time we have a unified storage interface across all the browsers. IndexedDB is kinda nasty to work with directly, but there are fairly good libraries on top of it. http://www.taffydb.com/ http://www.taffydb.com/ looks great for complex queries. One I work on http://pouchdb.com http://pouchdb.com provides syncing (also works with WebSQL) WebSQL is also pretty nasty to work with, hand crafting SQL string in the browser for one just feelds weird, even yesterday I had a bug filed which related to the internal SQLLite implementation (the entire reason WebSQL is a no go is it has one implementation, Richard Hipp would now own web storage) I havent seen much support from webSQL, even between those of us who actually use it most are just waiting for it to die, indexeddb in safari is that final nail

taf2 13y ago
"Safari are finally adding IndexedDB, which means for the first time we have a unified storage interface across all the browsers." localStorage has been well supported over all browers since IE8... It's interface IMO is a perfect fit in JavaScript... with the one exception of not being callback driven...
- daleharvey 13y ago
  Yeh sorry, not technically correct, while localstorage is great for quickly storing small items, due to having a sync api and having to encode / decode complex data its a non starter more data driver applications, so I always automatically exclude it
deleted 13y ago
[deleted]