8 ms·

Sadly, in the browser SQLite has been kicked to the curb, replaced by IndexedDB. It's deeply disappointing to not be able to use SQL on both client and server.

Sadly, in the browser SQLite has been kicked to the curb, replaced by IndexedDB. It's deeply disappointing to not be able to use SQL on both client and server. Yes, there's Lovefield, which employs its own DSL that has nothing to do with SQL, so you can scrap everything on the server and redo it on the client. Or just give up and go with NoSQL on client and server, that seems to be what the browser vendors are implicitly pushing developers toward.

dahart 9y ago
> Sadly, in the browser SQLite has been kicked to the curb, replaced by IndexedDB Are you thinking of WebSQL? I don't remember a SQLite interface client-side in any browser. I might be wrong, but I thought IndexedDB was originally implemented on top of SQLite in both Chrome and Firefox. I think Chrome moved to a different backing store, but that has no bearing on the API.
- virtualwhys 9y ago
  > Are you thinking of WebSQL? Yes, exactly, but Web SQL uses SQLite as the backing store. IndexedDB is its own thing, a standalone key/value store, nothing to do with SQLite.
  - gcp 9y ago
    IndexedDB may be backed by SQLite. I think it likely is in Firefox?
- tejasmanohar 9y ago
  SQLite has been ported to the browser via Emscripten. I’ve seen it used in a couple niche projects (generally those that revolve around the SQL language), but I don’t remember it being a standard or even a primary use of SQLite. [0]: https://github.com/kripken/sql.js/ https://github.com/kripken/sql.js/
  - virtualwhys 9y ago
    I'm aware of it, nice project, but 2.6MB + in memory only storage, no thanks.
    - hajile 9y ago
      It shouldn't be super difficult to backup/restore your db from localstorage using a dataURL. https://hacks.mozilla.org/2012/02/saving-images-and-files-in-localstorage/ https://hacks.mozilla.org/2012/02/saving-images-and-files-in...
      - kbenson 9y ago
        At that point, why wouldn't you just look for some SQL to LocalStorage API/shim, since it's bound to be faster than (and likely more stable with regard to page resets than) putting a full SQL engine in place that just serializes to a LocalStorage object anyway?
  - coleifer 9y ago
    Sure, but that's got to be a massive download. Probably not really an option for most sites.
- gcp 9y ago
  Are you thinking of WebSQL? I don't remember a SQLite interface client-side in any browser. Well, yes and no. The whole problem with WebSQL was that it effectively meant using SQLite and never anything else that wasn't completely bug compatible. So the whole problem with WebSQL was that it was, de facto, a web standard built around giving an SQLite interface client-side.
icebraining 9y ago
There's SQL.js: https://github.com/kripken/sql.js/ https://github.com/kripken/sql.js/
hajile 9y ago
Not the greatest solution, but you should be able to compile to asm.js or WebAssembly.
coleifer 9y ago
Yeah, Mozilla killed it out of concerns that there was only one implementation (which admittedly has some quirks)...so the question was, do we standardize SQLite and all its quirks? That didn't seem like a good option to them. Plus this is the heyday of nosql fanboi-ism, so you have all the sheep at mozilla clamoring for NoSQL in the browser. "Devs don't want SQL" Mozilla said. It's hard to say which reason was more compelling for Mozilla, but my gut feeling is that they were betting hard on NoSQL and came up with convenient technical justifications afterwards.
dragonwriter 9y ago
> Sadly, in the browser SQLite has been kicked to the curb, replaced by IndexedDB. SQLite hadn't been kicked to the curb, the WebSQL API whose “standard” was essentially “act like version x of SQLite” was kicked to the curb. The concept of WebSQL was good, but the standard itself wasn't great, and the absence of any intent to implement from other vendors or intent to improve the standard from those who had embraced it made it a dead-end standard.
- hungerstrike 9y ago
  > WebSQL API whose “standard” was essentially “act like version x of SQLite” was kicked to the curb. Nobody said what was so wrong about that.
  - merb 9y ago
    they said. it is not a standard.
  - rakoo 9y ago
    A standard needs to have multiple open source implementations to be accepted. What you're asking is basically to reimplement sqlite, feature for feature, bug for bug, and keep up with it as soon as it changes. No wonder no one wanted to try that.
    - hungerstrike 9y ago
      What about JSON? That became a standard without multiple implementations or even any discussion about what people would’ve wanted, like comments. I just don’t think there’s any rule that says that we need multiple implementations of thing to make it a standard. Also, we already have a standard for SQL and they could’ve just used the parts of SQLite that were compliant with that.
      - virtualwhys 9y ago
        > Also, we already have a standard for SQL I know right, there are in fact several (which may have been part of the problem). Most SQL database vendors tend to stray slightly (or not so slightly) from the SQL standard that they target; SQLite is no exception. Just unfortunate that the browser vendors couldn't come together and build a client-side SQL based API rather than punting and implementing a very basic key/value store on top of which someone will eventually reimplement SQLite. It's like 5 or 10 years from now we'll have what we had 10+ years ago, such progress!
adrianmonk 9y ago
> so you can scrap everything on the server and redo it on the client. Were you writing the same queries on the client and the server? Generally client and server are different moving parts of the same machine, so they don't really share a lot of code anyway. (Perhaps in some cases computations could optionally run on client or server depending on the circumstances, but security concerns limit the opportunities to do that.) Yes, it's a pain to have to know two different technologies, but it doesn't seem like this often leads to literally needing to scrap code and rewrite it.
- virtualwhys 9y ago
  > Were you writing the same queries on the client and the server? Well, yeah, that's the idea, isn't it? These days every language under the sun compiles to javascript, why wouldn't you want shared model, validation, queries, etc.? > Yes, it's a pain to have to know two different technologies, but it doesn't seem like this often leads to literally needing to scrap code and rewrite it. Currently working in an Angular 5 + TypeScript frontend with Scala on the backend, a shared nothing architecture, really blows compared to a single typed shared everything stack. All the stats based queries run on the server? Throw 'em out and manually recalculate on the client, probably literally 100X the amount of code; less efficient and error prone to boot. Same for form validation, model layer (hey, why does this new property exist client-side and not on the server?), etc. -- it's a house of cards.

dahart 9y ago

> Sadly, in the browser SQLite has been kicked to the curb, replaced by IndexedDB Are you thinking of WebSQL? I don't remember a SQLite interface client-side in any browser. I might be wrong, but I thought IndexedDB was originally implemented on top of SQLite in both Chrome and Firefox. I think Chrome moved to a different backing store, but that has no bearing on the API.

virtualwhys 9y ago
> Are you thinking of WebSQL? Yes, exactly, but Web SQL uses SQLite as the backing store. IndexedDB is its own thing, a standalone key/value store, nothing to do with SQLite.
- gcp 9y ago
  IndexedDB may be backed by SQLite. I think it likely is in Firefox?
tejasmanohar 9y ago
SQLite has been ported to the browser via Emscripten. I’ve seen it used in a couple niche projects (generally those that revolve around the SQL language), but I don’t remember it being a standard or even a primary use of SQLite. [0]: https://github.com/kripken/sql.js/ https://github.com/kripken/sql.js/
- virtualwhys 9y ago
  I'm aware of it, nice project, but 2.6MB + in memory only storage, no thanks.
  - hajile 9y ago
    It shouldn't be super difficult to backup/restore your db from localstorage using a dataURL. https://hacks.mozilla.org/2012/02/saving-images-and-files-in-localstorage/ https://hacks.mozilla.org/2012/02/saving-images-and-files-in...
    - kbenson 9y ago
      At that point, why wouldn't you just look for some SQL to LocalStorage API/shim, since it's bound to be faster than (and likely more stable with regard to page resets than) putting a full SQL engine in place that just serializes to a LocalStorage object anyway?
- coleifer 9y ago
  Sure, but that's got to be a massive download. Probably not really an option for most sites.
gcp 9y ago
Are you thinking of WebSQL? I don't remember a SQLite interface client-side in any browser. Well, yes and no. The whole problem with WebSQL was that it effectively meant using SQLite and never anything else that wasn't completely bug compatible. So the whole problem with WebSQL was that it was, de facto, a web standard built around giving an SQLite interface client-side.

icebraining 9y ago

There's SQL.js: https://github.com/kripken/sql.js/ https://github.com/kripken/sql.js/

hajile 9y ago

Not the greatest solution, but you should be able to compile to asm.js or WebAssembly.

coleifer 9y ago

Yeah, Mozilla killed it out of concerns that there was only one implementation (which admittedly has some quirks)...so the question was, do we standardize SQLite and all its quirks? That didn't seem like a good option to them. Plus this is the heyday of nosql fanboi-ism, so you have all the sheep at mozilla clamoring for NoSQL in the browser. "Devs don't want SQL" Mozilla said. It's hard to say which reason was more compelling for Mozilla, but my gut feeling is that they were betting hard on NoSQL and came up with convenient technical justifications afterwards.

dragonwriter 9y ago

> Sadly, in the browser SQLite has been kicked to the curb, replaced by IndexedDB. SQLite hadn't been kicked to the curb, the WebSQL API whose “standard” was essentially “act like version x of SQLite” was kicked to the curb. The concept of WebSQL was good, but the standard itself wasn't great, and the absence of any intent to implement from other vendors or intent to improve the standard from those who had embraced it made it a dead-end standard.

hungerstrike 9y ago
> WebSQL API whose “standard” was essentially “act like version x of SQLite” was kicked to the curb. Nobody said what was so wrong about that.
- merb 9y ago
  they said. it is not a standard.
- rakoo 9y ago
  A standard needs to have multiple open source implementations to be accepted. What you're asking is basically to reimplement sqlite, feature for feature, bug for bug, and keep up with it as soon as it changes. No wonder no one wanted to try that.
  - hungerstrike 9y ago
    What about JSON? That became a standard without multiple implementations or even any discussion about what people would’ve wanted, like comments. I just don’t think there’s any rule that says that we need multiple implementations of thing to make it a standard. Also, we already have a standard for SQL and they could’ve just used the parts of SQLite that were compliant with that.
    - virtualwhys 9y ago
      > Also, we already have a standard for SQL I know right, there are in fact several (which may have been part of the problem). Most SQL database vendors tend to stray slightly (or not so slightly) from the SQL standard that they target; SQLite is no exception. Just unfortunate that the browser vendors couldn't come together and build a client-side SQL based API rather than punting and implementing a very basic key/value store on top of which someone will eventually reimplement SQLite. It's like 5 or 10 years from now we'll have what we had 10+ years ago, such progress!

adrianmonk 9y ago

> so you can scrap everything on the server and redo it on the client. Were you writing the same queries on the client and the server? Generally client and server are different moving parts of the same machine, so they don't really share a lot of code anyway. (Perhaps in some cases computations could optionally run on client or server depending on the circumstances, but security concerns limit the opportunities to do that.) Yes, it's a pain to have to know two different technologies, but it doesn't seem like this often leads to literally needing to scrap code and rewrite it.

virtualwhys 9y ago
> Were you writing the same queries on the client and the server? Well, yeah, that's the idea, isn't it? These days every language under the sun compiles to javascript, why wouldn't you want shared model, validation, queries, etc.? > Yes, it's a pain to have to know two different technologies, but it doesn't seem like this often leads to literally needing to scrap code and rewrite it. Currently working in an Angular 5 + TypeScript frontend with Scala on the backend, a shared nothing architecture, really blows compared to a single typed shared everything stack. All the stats based queries run on the server? Throw 'em out and manually recalculate on the client, probably literally 100X the amount of code; less efficient and error prone to boot. Same for form validation, model layer (hey, why does this new property exist client-side and not on the server?), etc. -- it's a house of cards.