Comment by frik | Hacker News Reader

Comment by frik | Hacker News Reader

We are stuck with NoSQL in HTML5, because Mozilla and Microsoft refuse to implement 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

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

The new hip things is "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.

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

Edit: here is Mozilla's rationale for not supporting WebSQL: https://hacks.mozilla.org/2010/06/beyond-html5-database-apis...

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.

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.

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?

No one expects to write something in Python and port it over to C# with a serious amount of effort either. I don't think changing databases is more common than changing programming languages.

Which is why web standards often specify javascript APIs, and don't generally say "this should be available in a language that's...well, mostly imperative or object oriented, and maybe there can be some functional features, I guess..."

There are well respected standards such as SQL 92. They could also just take SQLite specification and use it.

Many SQL databases support multiple SQL dialects.

SQLite implements the SQL-92 standard (http://en.wikipedia.org/wiki/SQL-92 , http://en.wikipedia.org/wiki/SQLite#Features ).

Firefox certainly ships with SQLite and even their IndexedDB implementation is based on top of it internally (the irony): https://plus.google.com/+KevinDangoor/posts/PHqKjkcNbLU

Microsoft has MS Access JetRed, MS Outlook JetBlue and SQL Express SQL Databases that ship already with Windows and/or Office and are SQL-92 compatible. It should be trivial for them to figure out which SQL DB engine would fit best and integrate it in IE 12.

First sentence of http://en.wikipedia.org/wiki/SQLite#Features : "SQLite implements most of the SQL-92 standard for SQL but it lacks some features."

I assume that for an embedded DB, MS would be using a variant of Microsft Sql CE, which is their counterpart to SqlLite. And it's terrible.

SQL CE is no longer under active development.

Most Microsoft tools that need an embedded engine use ESE(Jet Blue), which is bundled with Windows.

For third-party desktop developers, the replacement is SQL Express LocalDB. For WinRT developers, Microsoft has paid the SQLite developers to port it over, so that it passes Store validation.

Windows Phone still uses SQL CE, but the only interface to it is LINQ-to-SQL. So Microsoft could conceivably swap out the backend at any time.

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/ looks great for complex queries. One I work on 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

"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...

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

Reply on news.ycombinator.com