A bit off topic, but would be great to use SQLite in the browser instead of IndexedDB.
I love relational databases, but you're almost forced into a NoSQL approach when developing a SPA since the client (browser) only supports simple key -> value storage. It would be a dream to use LINQ-to-SQL, or similar type safe query DSLs like Slick or Quill (Scala), or Esqueleto (Haskell) in the browser.
Combine that with a single language driving the backend and frontend and voila, no duplication of model, validation, etc. layers on server and client.
One can dream I guess, but the reality is NoSQL fits the modern web app like a glove, for better or worse.
> A bit off topic, but would be great to use SQLite in the browser instead of IndexedDB
That almost happened. There was a thing called WebSQL [1] that was W3C was working on to add SQL to the browser. Everyone who implemented it used SQLite.
Apparently, that disqualified it from standardization. To move ahead, they wanted to see independent implementations of the standard.
No browser makers stepped up to reduce the quality of their implementation by replacing some of the best designed, best written, best tested code on the planet with some other SQL back end to satisfy the committee, and so Mozilla was able to push IndexedDB as the standard browser DB interface.
They had to, since what was standardized was specifically the SQL dialect of SQLite v3.6.19.
> No browser makers stepped up to reduce the quality of their implementation by replacing some of the best designed, best written, best tested code on the planet with some other SQL back end to satisfy the committee
There were only two implementations at all: WebKit and Opera. Mozilla and Microsoft weren't going to implement it without a spec decoupled from particular backend.
This almost happened. Ten years ago "WebSQL" was being considered as a standard - it would have introduced SQLite-backed databases as a built-in browser feature: https://en.wikipedia.org/wiki/Web_SQL_Database
The W3C dropped it in November 2010 because they were uncomfortable supporting a web standard which was entirely tied to a single implementation of SQL (SQLite). I adore SQLite but I think the W3C made the right call there - web standards need more than one compatible implementation.
> I adore SQLite but I think the W3C made the right call there - web standards need more than one compatible implementation.
could you elaborate on that? I get the impression that now, eight years later, we're much worse off. I don't really see the upside of not going for what is, AFAIK, a relatively vanilla implementation of SQL.
A web standard needs to have more than one implementation. If you allow one single implementation to define the standard, you get something like Flash.
I don't have a particularly strong practical argument here: for me this is more of a fundamental principle for how the web should work.
Flash was a closed source plugin that was added to the browser as a binary blob. It could be updated by the user, and because it frequently had security bugs users were frequently urged to update. Those updates also often introduced new features, which content providers started taking advantage of once a significant number of people updated, putting pressure on the rest to update too.
SQLite is open source that would have been compiled into the browser by the browser vendor. A typical user would not have the means to update it separately from the rest of the browser.
So why couldn't W3C pick a particular release of SQLite, list a specific subset of its features, and declare that this, as described in the documentation for that specific version, is the standard?
I love relational databases, but you're almost forced into a NoSQL approach when developing a SPA since the client (browser) only supports simple key -> value storage. It would be a dream to use LINQ-to-SQL, or similar type safe query DSLs like Slick or Quill (Scala), or Esqueleto (Haskell) in the browser.
Combine that with a single language driving the backend and frontend and voila, no duplication of model, validation, etc. layers on server and client.
One can dream I guess, but the reality is NoSQL fits the modern web app like a glove, for better or worse.