5 ms·

OT, but I was and am still pretty steamed that Mozilla spearheaded the effort to deprecate WebSQL back in 2010 [1], while providing a replacement that left many

OT, but I was and am still pretty steamed that Mozilla spearheaded the effort to deprecate WebSQL back in 2010 [1], while providing a replacement that left many disappointed [2] (see comments in both threads universally deriding the decision). The idea was that javascript libraries would be created that would replicate SQLite in the browser (albeit horribly inefficiently with terrible APIs compared to shipped-with-the-browser native C implementation that is SQLite). Anyway, now that Firefox has become less relevant than ever with Microsoft's adoption of Chrome, I wonder if there's any chance that WebSQL will live on despite its deprecation? After all, it's still available in Chrome and Safari, which dominate the browser market. IndexedDB is fine if NoSQL is how you store your data, but an absolute PoS if you want to work efficiently in a relational model with joins, grouping, etc. Such a shame, every server-side language under the sun compiles to javascript now; imagine being able to share SQL statements between client and server; being able to aggregate data, count & sum with reckless abandon. Instead we have to do it all by hand in javascript, such a step backward [3] /rant [3] https://news.ycombinator.com/item?id=9978540 https://news.ycombinator.com/item?id=9978540 [1] 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... [2] https://hacks.mozilla.org/2010/06/comparing-indexeddb-and-webdatabase/ https://hacks.mozilla.org/2010/06/comparing-indexeddb-and-we...

swsieber 8y ago
You couldn't share SQL statements between the backend and the frontend. It's for the same reason it was shot down: SQL implementations are incredibly varied.
- virtualwhys 8y ago
  Limited to a certain subset you most definitely could use the same statements (obviously not CTEs and the like). Ideally you'd have a translation layer, so instead of writing error prone string-y SQL, you'd have a type safe DSL in the vein of LINQ to SQL, Esqueleto, Slick, Quill, etc. that generates approriate SQL based on the target driver. That way you write the same query once, with the same model, and dispense with the inefficient square wheel that is IndexedDB + javascript.
Sylos 8y ago
Are you aware of the recent WebSQL remote code execution vulnerability? That's a pretty good reason for Mozilla's decision.

swsieber 8y ago

You couldn't share SQL statements between the backend and the frontend. It's for the same reason it was shot down: SQL implementations are incredibly varied.

virtualwhys 8y ago
Limited to a certain subset you most definitely could use the same statements (obviously not CTEs and the like). Ideally you'd have a translation layer, so instead of writing error prone string-y SQL, you'd have a type safe DSL in the vein of LINQ to SQL, Esqueleto, Slick, Quill, etc. that generates approriate SQL based on the target driver. That way you write the same query once, with the same model, and dispense with the inefficient square wheel that is IndexedDB + javascript.

Sylos 8y ago

Are you aware of the recent WebSQL remote code execution vulnerability? That's a pretty good reason for Mozilla's decision.