From the first 1 minute and 15 seconds of the video:<p>> "With WebSQL being deprecated, and IndexedDB not providing structured queries, web developers need a tool to satisfy their structured query needs."<p>> "Web app developers need structured queries to work in the mobile world."<p>> "With IndexedDB ... there's a steeeep learning curve to make it useful for your app. Moreover, IndexedDB does not provide structured queries."<p>> "IndexedDB does not offer structured query features, such as sorting by multiple columns, or joining the results of multiple tables."<p>As someone that looked forward to WebSQL, this is painful to hear. Many of us realized the above from the beginning. Yet, some in the standards committee found a way to shoot down WebSQL, w/vague rationale such as "we don't feel it's the best path for the web".<p>Well, thank you. Instead of giving us one of the most well tested SQL implementations (SQL Lite) that addresses all of the above, and much more, we were shoved a harder to use, more verbose, and less powerful alternative (IndexedDB). And as a result, we're having to implement our own relational databases. In JavaScript. 4-5 years later.<p>No offense to Lovefield, but it represents everything wrong w/the decision to deprecate WebSQL and implement IndexedDB instead. It was also the single-most decision that made me lose faith in the standards committee.
Another database which has similar characteristics (although not quite sql-like api's) that I've had a lot of luck with is <a href="https://github.com/tonsky/datascript" rel="nofollow">https://github.com/tonsky/datascript</a>. Bit of a tangent, but anyone looking for this kind of functionality might be interested.
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?<p>I'm clearly missing something, but I can't be bothered to watch the videos - can someone TL;DR it for me, please.
Interesting. At first I was thinking this might be part of their cross-platform (iOS/Android/web) architecture that they use for Inbox, Sheets, and a few other things.<p>E.g. they assert that, despite having pure-native views (e.g. no Swing-style "one UI for all platforms"), they share ~70% of the client-side code across iOS/Android/web.<p>Which to me insinuates the reused code is probably things like the domain models, validation rules, and also online/offline data storage/sync logic.<p>E.g. maybe Lovefield was part of that cross-platform client-side storage architecture. But probably not since it's Javascript. (Which is fine, Google is a big place/lots of different apps/needs.)
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.
Would be interesting to compare it to AlaSQL (<a href="https://github.com/agershun/alasql" rel="nofollow">https://github.com/agershun/alasql</a>).
The api style looks very similar to JOOQ's one.<p>1: <a href="http://www.jooq.org/doc/3.6/manual/sql-building/sql-statements/dsl-and-non-dsl/" rel="nofollow">http://www.jooq.org/doc/3.6/manual/sql-building/sql-statemen...</a>
The whole saga is very sad. WebSQL was the right move all along. NoSQL turned out to be a fad and people really just want to use SQL to build real apps.
Especially newbies, learning SQL is a lot easier than learning how to reimplement it's features on top of a document store.
Lovefield is still relatively new and immature. When I tried to use it I ran into some strange errors. The situation might have improved now but I personally would still recommend PouchDB instead.
Niiice... last time I tried to get something done with IndexedDB it was total pita. If this manages to take away even 20% of IndexedDB's pain, it's sure worth taking a look at!
I'm not a web developer, but this looks great, I want to learn how SQL things work, maybe this is a good start for beginner ?
BTW, speaker's face is too serious.
This just goes to prove that what developers really want out of browsers is not a document viewer but a deployment platform. To go to these lengths, someone has to be very concerned about getting one set of code to run on practically any device. You don't otherwise end up with something like this.<p>This wouldn't have been possible without the work the Chromium team has done to achieve such complete compatibility between desktop and mobile versions. But unfortunately the browser is still stuck in the mentality that it's just a document viewer. I think we really need to wake up and make the browser into a proper deployment platform. I applaud efforts like this, even if I don't immediately have a need for such a thing, because they are doing the necessary work to push on browser developers to release the right features towards that goal.