Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lovefield – A relational database for web apps

google.github.io

Post reply on HN
Print view View original

11–20 of 60 posts

Re: Lovefield – A relational database for web apps

#11

Post by pfraze »

lt wrote: post #8
pfraze wrote: post #7

Earlier quoted context omitted.

Yeah, that was a bummer situation. The problem was that browser APIs require independent implementations to become standard. Chrome used SQLite for their WebSQL, which left Firefox without a good option. (Implementing a SQLite clone isn't feasible with their budget.) So, the standard was dropped. It's a shame, because SQLite is a great tech.

Why couldn't Firefox use SQLite?

There's a W3C rule, that each browser needs their own implementation. If everybody uses the same code, it's considered a Monoculture security risk [1].

1. https://www.schneier.com/blog/archives/2010/12/software_mono...

Re: Lovefield – A relational database for web apps

#12

Post by aikah »

lt wrote: post #8
pfraze wrote: post #7

Earlier quoted context omitted.

Yeah, that was a bummer situation. The problem was that browser APIs require independent implementations to become standard. Chrome used SQLite for their WebSQL, which left Firefox without a good option. (Implementing a SQLite clone isn't feasible with their budget.) So, the standard was dropped. It's a shame, because SQLite is a great tech.

Why couldn't Firefox use SQLite?

I ask myself the same thing regarding the file system API. It's like Mozilla and co are against serious offline apps that would have taken advantage of these 2 features heavily. And no , IndexedDB is not a replacement for these.

Re: Lovefield – A relational database for web apps

#13

Post by rw2 »

This is good for people used to sql but I personally find the way that IndexDB stores data to be superior. You just have to get used to the NoSQL way of persisting objects. Making one technology look like another is never efficient for an app.

Re: Lovefield – A relational database for web apps

#14

Post by zzzmarcus »

rglullis wrote: post #6
jdimov9 wrote: post #3

What is a browser database and what is it good for? Would you use one instead of a back-end DB or in conjunction with one? How? Why? Why is this on 1st page - what is cool about it? I'm clearly missing something, but I can't be bothered to watch the videos - can someone TL;DR it for me, please.

Offline-first web apps. Think of all of the "native mobile apps" that could actually be done as a web app, but instead get built as native applications just because the application needs to store data.

Also Electron apps. It's currently pretty painful getting sqlite working with Electron, this could be a nice alternative.

Re: Lovefield – A relational database for web apps

#17

Post by Touche »

lt wrote: post #8
pfraze wrote: post #7

Earlier quoted context omitted.

Yeah, that was a bummer situation. The problem was that browser APIs require independent implementations to become standard. Chrome used SQLite for their WebSQL, which left Firefox without a good option. (Implementing a SQLite clone isn't feasible with their budget.) So, the standard was dropped. It's a shame, because SQLite is a great tech.

Why couldn't Firefox use SQLite?

They could, but "use SQLite" is not a spec.

Re: Lovefield – A relational database for web apps

#18

Post by DCoder »

jdimov9 wrote: post #3

What is a browser database and what is it good for? Would you use one instead of a back-end DB or in conjunction with one? How? Why? Why is this on 1st page - what is cool about it? I'm clearly missing something, but I can't be bothered to watch the videos - can someone TL;DR it for me, please.

We have a web app that downloads a large list of simple repetitive maintenance tasks ("check amount of spare printer toner", "water the office plants", and such) with documentation, images, etc. that need to be performed regularly, and then shows the user that list so he can perform the tasks and send back the results. Some companies using this app do not allow internet access in the specific areas where tasks have to be performed, so some parts of the app have to work without it. Business requirement was "store enough info on the device to be able to run without internet access for one month".

Without an in-browser persistent database (we used WebSQL, with all the future risks), it would require some interesting workarounds (can you serialize multiple megabytes to local storage? how long will it take? will it rollback from a fault correctly?) or Phonegap type solutions.

Re: Lovefield – A relational database for web apps

#19

Post by ysh7 »

neilellis wrote: post #5
jdimov9 wrote: post #3

What is a browser database and what is it good for? Would you use one instead of a back-end DB or in conjunction with one? How? Why? Why is this on 1st page - what is cool about it? I'm clearly missing something, but I can't be bothered to watch the videos - can someone TL;DR it for me, please.

It's like having PouchDB -> CouchDB but with SQL not NoSQL For me I'd like to: Firebase as backend. Sync user data to browser. Query user data elegantly in browser using select statements.

Better way to describe it was "like SQLite"

Re: Lovefield – A relational database for web apps

#20

Post by pornel »

lt wrote: post #8
pfraze wrote: post #7

Earlier quoted context omitted.

Yeah, that was a bummer situation. The problem was that browser APIs require independent implementations to become standard. Chrome used SQLite for their WebSQL, which left Firefox without a good option. (Implementing a SQLite clone isn't feasible with their budget.) So, the standard was dropped. It's a shame, because SQLite is a great tech.

Why couldn't Firefox use SQLite?

If all implementations use the same code, then they have the same bugs and quirks (and sqlite, being very lite on the SQL standard, has many quirks).

When all implementations have the same bugs/quirks then websites can end up (inadvertently) relying on these bugs, and this makes any future fixes or upgrades to the underlying sqlite very risky (almost guaranteed to break some sites on the net).

It's the situation IE6-only intranet sites ended up with: depending on every dark corner of a particular implementation, and then couldn't even work with IE7/8/9.

So similarly the WebSQL standard would de-facto freeze at some sqlite3 version, and wouldn't be able to upgrade to sqlite4/5/6 until all sites on the web are compatible, which won't happen (and we'd have "quirks modes" for websql versions, etc.)

The whole mess is largely avoided when there are multiple independent implementations. When each implementation has different bugs, then developers will notice that their code works in one browser, but not another, and see what's a bug and what is a feature.

Post reply on HN