9 ms·
W3C Working Group Just Killed Web SQL Database
- deleted 16y ago[deleted]
- jchrisa 16y agoThis spec isn't the only game for offline storage. IndexedDB is the favored replacement: http://www.w3.org/TR/IndexedDB/ http://www.w3.org/TR/IndexedDB/ I like it because the API is much more web-like than SQL. Others have other reasons to prefer it.
- Udo 16y agoIt is a replacement, but I'm not really sure whether it's a good one. SQL was a nice choice because it made writing hybrid applications (with online and offline DB storage) very easy, and it was using an API that was already well known and understood. At this point it's unclear if IndexedDB is actually going anywhere, it's a prime example of a lifeless spec being prescribed from "high above". It might get adopted, maybe browser makers will force web devs to do it in the end, but SQL already has been proven more than workable in the field whereas IndexedDB has not.
- henryprecheur 16y agoSQL is certainly a well-known _language_, but I don't think it's very well understood by most. Also if IndexedDB has a "lifeless" spec, it might be because there's not much to discuss. Something simple and straightforward tends to requires much less discussion and debate, than something complex.
- jamesaguilar 16y agoFor someone unfamiliar with the term, what does "web-like" mean?
- Groxx 16y agoI'll be obtuse, and claim it means "JavaScript-like". You know, multiple "truthy" values, the inability to detect the difference between arrays and objects, a weird mashup of OO and functional abilities, `=== undefined` but `isNaN()`, and no real difference between integers and floats, and all the math weirdness that goes with them. Browsers implementing the same thing different ways, interacting with a system (the DOM) that's the same but different everywhere, and patched together by multiple, usually-mutually-exclusive libraries that everyone uses instead of the actual language. (disclaimer: I've come to quite like JS, it's made some of my experiments phenomenally simple. but it's weird.)
- deleted 16y ago[deleted]
- fforw 16y agoisNaN() only exists because the real way to detect NaN is so counter intuitive. Lots of people will see "if (x !== x)" and will try to "optimize".
- jchrisa 16y agoAn API that maps to the underlying data-structure (btree, ranges, cursors), is bar-none simpler than an API that abtracts the underlying data structure away (like any SQL does). The web was built by taking existing systems, and cutting away at them until they were so simple they barely worked. But because they were simple they could spread. IndexedDB isn't the simplest spec it could be (I think they could do-away with transactions if they were willing to require MVCC semantics) but it is admirably simple for a database.
- jamesaguilar 16y ago> An API that maps to the underlying data-structure (btree, ranges, cursors), is bar-none simpler than an API that abtracts the underlying data structure away (like any SQL does). That may be true in this specific case (I'm not saying either way), but it does not hold generally. For example, APIs involving directories and files are simpler than APIs involving inodes and blocks.
- henryprecheur 16y agoI think that's a great news. HTML5 adds lots of complexity in the browser, and yet don't address most of the fundamental problems of HTML: security, complexity. Web SQL was another step in the wrong direction. Local storage wont go away. I hope Web SQL will be replaced by something "better" and more straightforward, A simple key-value database would be great.
- patrickaljord 16y ago> A simple key-value database would be great. That's exactly it: http://www.w3.org/TR/IndexedDB/ http://www.w3.org/TR/IndexedDB/
- halo 16y agoProbably a good thing. The most complex part of Web SQL amounted to "Whatever SQLite implements", neither Mozilla nor Microsoft supported it making the standard effectively irrelevent, and I remain thoroughly unconvinced that providing an extremely thin JavaScript API to an SQL-driven database is an elegant solution to this particular problem. Presumably the W3C have decided to favour IndexedDB instead, which solves many of the same problems in a much more elegant, simple and well-specified fashion.
- ergo98 16y agoThe most complex part of Web SQL effectively amounted to "Whatever SQLite implemented" Which is one of the most tested, most utilized, most known pieces of code used among modern software. Saying "reference it" is entirely rational. And really the ludicrous notion that documenting its behaviors is unfathomably difficult is so asinine that it demolishes that line of argument. neither Mozilla nor Microsoft supported it Microsoft doesn't REALLY support either: Does IE9 have IndexedDB? Not that I'm aware of. Microsoft's angle regarding Web Databases was nothing more than "I don't know...that looks mighty uppity for a web app..." Mozilla is taking a very myopic, "high-road" approach that is similar to, and less justifiable, the whole h.264 debacle: Everyone loses, but someone gets to hold their head up high. Further, Chrome, Safari, Opera, other...none of them support IndexedDB, so as a standard it is effectively irrelevant. Presumably the W3C have decided to favour IndexedDB instead, which solves many of the same problems in a much more elegant, simple and well-specified fashion. Ha ha ha! The IndexedDB spec right now has incredible gaps that make it close to useless. The braintrust at Mozilla that are responsible for it can't stop themselves from saying "CouchDB" long enough to actually work on it, it seems. I think they got caught up in the whole NoSQL thing. So much so that they now seriously advocate that libraries should pop up inefficiently implementing SQL on top of IndexedDB, which is just saddening. But aside from that, rah!
- henryprecheur 16y agoWhich is one of the most tested, most utilized, most known pieces of code used among modern software. Sounds like Microsoft Windows to me :) I think that SQLite is a really nice database. But just because SQLite would work in the browser, doesn't mean W3C shouldn't try to do something better.
- jfb 16y agoWhy, again, was this needed? HTML5 is already looking like a security and management shitstorm; anything that makes it simpler is fine by me.
- Groxx 16y agoHow is a domain-locked local SQL database a security shitstorm?
- jfb 16y agoI suppose I'm just jumpy because of the lack of granularity in user control over local storage, and wary of the eptitude of the browser vendors, and in favor of fewer, smaller features. After reading the inept IndexedDB thing, however, it seems like the wrong local storage mechanism is going to get it in the neck.
- Groxx 16y agoYou've got just as much control. Grab the console and 'drop table' - all that data, gone. You can even trash all the databases in most browsers pretty simply. And restrict their size. The difference is that client-side JavaScript becomes useful with a large-ish local storage. Arguably, it's significantly safer than cookies, which are sent with every request (ie: Firesheep).
- ihsw 16y agoThe issue would largely be storing sensitive data (I presume), namely personally identifiable information. Imagine all the user data being stored in a simple and quick API that advertisers (et al) can grab at, rather than having to scrape through HTML bits on a page. Now imagine malware spreading across the internet and frictionlessly gathering this data. Although some might argue we're already there and that there's nothing stopping the deluge of user information.
- Locke1689 16y agoXSS and SOP disasters. Basically, everything that was broken about the web before, but more broken-y now. This of course applies to HTML5 local storage, too.
- Groxx 16y agoNot quite, methinks: >This document was on the W3C Recommendation track but specification work has stopped. The specification reached an impasse: all interested implementors have used the same SQL backend (Sqlite), but we need multiple independent implementations to proceed along a standardisation path. That notice has been up for quite a while now. They're just making it plainer that they've given up, because there's already a spec out there that they don't have control of. Also, to perform a join in IndexedDB, you've gotta do it by hand, iterating over the results and merging data programmatically[1]. While WebDatabases have a PITA async-only API for reasons which are entirely beyond my comprehension, SQL is an incredibly capable language for interacting with a database, and has very mature and efficient implementations. Losing that would count as a massive loss to me. Why can't we have both? WebKit / Chrome is already going this route, as they have WebDatabase and recently implemented IndexedDB as well. [1]: http://hacks.mozilla.org/2010/06/comparing-indexeddb-and-webdatabase/ http://hacks.mozilla.org/2010/06/comparing-indexeddb-and-web... example 4
- nl 16y agoWhile WebDatabases have a PITA async-only API for reasons which are entirely beyond my comprehension That's because they want to support responsive applications. Javascript doesn't really have native concurrency operations, so the best (only?) way to do it is via async operations. It's like XMLHttpRequest: Async only, which can be harder to program, but makes it a lot more robust.
- nex3 16y ago> Javascript doesn't really have native concurrency operations Except for Web Workers, also part of HTML5. The way Google Gears handled this was to allow synchronous database operations only in worker contexts.
- pornel 16y agoWorker<->UI communication is asynchronous, and has additional limitations (only copying, only JSON-able data), so synchronous worker API in many cases would just shift complexity elsewhere.
- bluedevil2k 16y agoThere's enough security/privacy issues with cookies, and those are simple text strings. Imagine the issues a nefarious mind could cause with a DB.
- drivebyacct2 16y agoJust imagine how scary it wouldn't be if you understood the security implications and risks of cookies compared to the lack there of for a local browser db storage....
- ronaldj 16y agoAm I the only one that's sad about this?
- jhrobert 16y agoI am sad only to extend that there is some juice in SQL that the SQL people where unable to inject into JavaScript, either because of lazyness or more probably because they will never compromise at the syntax level when times come to reduce the impedance mismatch between two different language syntaxes.
- bphogan 16y agoNo, in fact I'm mighty upset about this and have been for some time, mainly cos the damn thing isn't vaporware. It exists in Safari and Chrome, whereas IndexedDB works nowhere yet but "sounds neat." I want to see what WebKit browsers are going to do. I use this in a couple of small HTML5 offline apps.
- k7d 16y agoYeah, me too. I think it's just politics, in the best traditions of big corporations, that doesn't do any good to actual web developers. From practical perspective we would be better off with Web SQL DB. Functionally it addresses everything a developer needs to create offline HTML apps. API is not perfect but you can always improve that with small wrapper libraries (like JQuery improves DOM API). You can always easily implement IndexDB-like API on top off SQL if you really want that. The opposite is probably possible but much more difficult. Also I think IndexDB might turn out to be yet another compatibility headache because everybody will be creating their own implementation (I'm pretty sure there will be at least 3 - Microsoft, Mozilla & Webkit). It's a speculation but most likely this wouldn't be an issue with Web SQL DB because everybody would just use the same SQLLite backend. And worst of all, this is delaying progress of web applications. Lack of solid cross-browser client-side storage solution is the last big gap for next generation of web applications. If everybody had just agreed on SQLLite we could be there today... now it's still unknown when we will get there.
- sid0 16y ago
- jhrobert 16y agoIf the SQL guys were serious about their shit they should have patch some JavaScript at the syntax level. Instead they pushed/lobbied for the usual broken binding that is the very reason SQL is so contreversed: impedance mismatch. Of course, hacking a javascript parser to introduce some SQL semantic in it is not exactly "easy" Basically, the initiative was doomed from day one, what a waste of time...
- rsanders 16y agoI'm not sure what you're trying to say. SQL works quite well in just about every language there is without introducing new syntax. Are you talking about something like LINQ? Nice, but unnecessary.
- Eil 16y agoSo is IndexedDB a beefier version of localStorage or does it serve a different purpose altogether?
- jchrisa 16y agoLocal storage is just key/value queries, IndexedDB allows you to make range queries against indexes you define, so you can get eg: recent blog posts, etc.
- mindeh 16y agoyeah. to give an example: if I want to store persist objects using localStorage, I'd convert them to JSON and store key-value. However I cannot store whole object hierarchy as it'll soon become an overkill. so I store separate objects, and recreate relations upon retrieval manually. But I also need to maintain my own index - to know which objects I have stored under what keys.
- jasongullickson 16y agoSo what does this mean for browsers that support web SQL and apps that are built on it? Is it likely that Safari, Chrome, etc. will drop support for it before a viable alternative is avaliable?
- pornel 16y agoIt will be maintained until IndexedDB becomes viable. Perhaps someone will write JS library that implements IndexedDB on top of WebSQL (or vice-versa).
- amattie 16y agoNo one has mentioned yet that both Android and iPhone implemented SQLite as described in the draft spec. There's a tremendous number of developers -- including myself -- who have built apps against it. The described spec may not become commonplace in desktop browsers, but it's an entirely different story on advanced mobile devices where Mozilla / Microsoft have nearly zero influence. I definitely don't see this just suddenly evaporating or going unmaintained in those platforms.
- briandon 16y agoSQLite is already baked into Firefox and available to Firefox itself and to extensions/addons, although not available to web page authors: https://developer.mozilla.org/en/Storage https://developer.mozilla.org/en/Storage
- Hixie 16y agoThe W3C didn't kill it, it was Mozilla and Microsoft who decided they didn't want to implement it (for a variety of reasonable reasons) and me who decided to not continue working on a spec that didn't have all the browser vendors on board.
- mindeh 16y agoThe heading is misleading imho. As you see written in the spec, it was on the track to W3 Recommendation, but as every vendor who implemented it chose SQLite, there was little to do about it. In other words, it isn't a "kill", just end of active maintainence. But spec as it is, is pretty solid. And WebSQL is here to stay in WebKit - there are just too many apps dependent on it to kill it. And no good reason to kill as there's no viable alternative on the horizon. Summing up - WebKit (so iOS, Android and others) has it and will have it for quite a while, IE won't, FF won't too.
- DjDarkman 16y agoJust great, it just seemed like we will have something this decade, but sadly that will not be the case. I have read the comments in Mozilla's thread http://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/ http://hacks.mozilla.org/2010/06/beyond-html5-database-apis-... they clearly don't give a damn about what the users want. They should have just agreed on a simple subset of SQL instead of going NoSQL, but apparently that wasn't good enough for them, waiting a decade more for something to store data in is probably better. I personally love the concept of NoSQL, it's just that IndexedDB needs a few more years, which means it will probably even miss IE10.
- uriel 16y agoLets hope it stays dead, seems that we just dodged a pretty nasty bullet. IndexDB seems to also be ridiculously complex, but as wicked as most standards are anything is better than SQL.
- alkavan 16y agowhy would you write SQL with JavaScript? don't think that JavaScript yet at a point it can run heavy GUI element, handle AJAX, maybe Video or 3D and Query a database. JavaScript likes JSON very much, so all you need is just export your data with a language like PHP in JSON format, and handle it with JavaScript.
- ficeto 16y agoSo reading all the comments I see that most "against" are because "Because if everyone used SQLite there would be no second implementation, which is something that is necessary for a proposed standard to become an actual standard." WTF? Do we need to implement MySQL, PGSQL or MSSQL to get a chance of having SQL in our browsers? Does that sound stupid only to me? Is Mozilla trying to follow the "success" of IE? Who pays W3C? Why do they play like the God of Web? And why can't we have both? I certainly don't want to ever use IndexedDB if I have and SQL option.