4 ms·

Agree. And while IndexedDB deserves credit, I cringe a bit every time I see a SQL implementation in JS. There's clearly a SQL need for developers, so I still

• virtualwhys 8y ago
  > And as a result, we're having to implement our own relational databases. In JavaScript. 4-5 years later. Now nearly 10 years later. The notion that a WebSQL-like library would be created on top of IndexedDB to replace the deprecated API has proven to be utterly groundless. It's hopeless, how on earth will a bloated JS library compete with the beast that backs WebSQL? Sqlite, a native C application, just blows everything else out the water. Table joins, window functions? Can't even think the thought with anything built on IndexedDB. Worse, in the same way that many languages these days compile to javascript, so too do server-side DSLs generate SQL (see Slick, Quill, Esqueleto, LINQ to SQL, etc.). Wouldn't it be nice to share the same model and sql statements on client and server? You know, offload complex aggregation tasks to a native C application designed specifically for this task, instead of manually doing it all by hand with reams of error prone boilerplate in javascript. Interestingly Chrome and Safari, the browsers that dominate the market, after all these years still ship with WebSQL. Perhaps there's still hope...
  • tracker1 8y ago
    > Interestingly Chrome and Safari, the browsers that dominate the market, after all these years still ship with WebSQL. Perhaps there's still hope... Maybe... I'll have to start experimenting again... when I first looked at it, IE was still too many people to ignore.
  • WorldMaker 8y ago
    > The notion that a WebSQL-like library would be created on top of IndexedDB to replace the deprecated API has proven to be utterly groundless. Uh, we came here to discuss AlaSQL.js which does implement a decent alternative to the WebSQL standard and does store to IndexedDB, when asked. It's probably a better alternative given its additions of JS functions and JSON operators. In the footnotes you can even find a WebSQL shim that recreates the old WebSQL API on top of AlaSQL (though it recommends just using the AlaSQL API if you can). I don't know what the benchmark characteristics of it are, as I haven't yet tried to use this library, but I doubt it is "hopeless". On the other side, SQLite itself directly runs very well with Emscripten (sql.js), and I've heard Web Assembly builds are getting really good, if you do need the "performance" of "real" SQLite. All of which seems to be further proof that SQLite is much better in "user land" than in the Browser's security footprint.
    • virtualwhys 8y ago
      > AlaSQL.js which does implement a decent alternative to the WebSQL standard Well, it isn't at all if SQL is important to you (and corresponding performance gained through delegating to a native C application), or table joins, or efficient aggregation, or window functions etc. AlaSQL.js is a DSL built on IndexedDB with all the limitations that implies; you can't share code between client and server (unless you're all-in on JavaScript and go with Node on the server); all clients have to download it (400KB isn't huge but it's also not a 0KB "download" like browser built-in Sqlite). > SQLite itself directly runs very well with Emscripten (sql.js) Oh, yes, now try writing to disk -- you can't, it's in-memory only, not to mention huge (2MB). I'm sure mobile devices will love parsing that, battery life must be wonderful. > All of which seems to be further proof that SQLite is much better in "user land" No proof has been given, severe limitations have been, however. Security is an issue, I'll conceed that, but otherwise I'll stand by "The notion that a WebSQL-like library would be created on top of IndexedDB to replace the deprecated API has proven to be utterly groundless".