Live data from Hacker News

W3C Working Group Just Killed Web SQL Database

w3.org

61–70 of 87 posts

Re: W3C Working Group Just Killed Web SQL Database

#61
post #26

Earlier quoted context omitted.

For someone unfamiliar with the term, what does "web-like" mean?

I'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 D…

isNaN() 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".

Re: W3C Working Group Just Killed Web SQL Database

#62
post #13
post #7

Probably 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…

The 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…

For any web standard to be valid there need to be two different implementations. There is no second implementation for Web SQL.

Re: W3C Working Group Just Killed Web SQL Database

#63
post #51
post #13

Earlier quoted context omitted.

The 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…

Because there is only one implementation, no matter how good it is, websites would end up relying on every bug and quirk in SQLite. SQLite isn't quite SQL. It has weakly dynamically typed columns (will happily store strings in INT column), and ROWID/auto increment is icky (magic behavior with special-casing for backwards compatibility).

Exactly. All proposed web standards require at least two implementations to become actual web standards. That was never going to happen with Web SQL.

Re: W3C Working Group Just Killed Web SQL Database

#64
post #49
post #15

Am I the only one that's sad about this?

Yeah, 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 easil…

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.

For a proposed web standard to become an actual web standard there need to be at least two implementations. This is a good, healthy thing. There was going to be no second implementation of Web SQL, so it was never going to become a standard.

Re: W3C Working Group Just Killed Web SQL Database

#65
post #24

Earlier quoted context omitted.

The truth is the reason they pointed to SQLite is because the proposed API was so obscenely complicated that it was easier to point to a reference implementation than to accurately specify a standard, which points to a rather fundamental problem with the proposed standard: SQL is too damn complicated, and embedding it in browsers is a bad idea. For a web standard to succeed, you need either Mozilla or Microsoft suppo…

Why not just use SQLite? Write a small wrapper around it to isolate each website off on it's own database or set of databases. Each site corresponds to a SQLite user with a password that ONLY the browser knows.

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.

Re: W3C Working Group Just Killed Web SQL Database

#66
post #24

Earlier quoted context omitted.

The truth is the reason they pointed to SQLite is because the proposed API was so obscenely complicated that it was easier to point to a reference implementation than to accurately specify a standard, which points to a rather fundamental problem with the proposed standard: SQL is too damn complicated, and embedding it in browsers is a bad idea. For a web standard to succeed, you need either Mozilla or Microsoft suppo…

> For a web standard to succeed, you need either Mozilla or Microsoft support, preferably both. They have 75% of the browser market between them, so without either any standard is dead on arrival I don't get it. If IE6 can be kept afloat by enterprise web apps that weren't designed for anything else, why can't there be web apps with offline features that only work with Chrome and Safari?

IE6's hanging around isn't looked at as a good thing.

Re: W3C Working Group Just Killed Web SQL Database

#67
post #55
post #30

Earlier quoted context omitted.

> 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.

Worker 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.

In part. It makes conditional, nested queries much simpler, however, when you don't need to nest async callbacks 20 layers deep.

I understand that having a synchronous API would mean more people would use it. But honestly, I see that as their problem. A fair number of queries, such as "select * from your_table where id = ?", are useful to have synchronous as an option, and should perform quickly enough to be invisible. And synchronous can easily be made asynchronous, but the other way around is essentially impossible without any Thread.join.

Re: W3C Working Group Just Killed Web SQL Database

#68
post #65

Earlier quoted context omitted.

Why not just use SQLite? Write a small wrapper around it to isolate each website off on it's own database or set of databases. Each site corresponds to a SQLite user with a password that ONLY the browser knows.

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.

I believe you, especially as it makes a number of lines I've heard around this make more sense... but why? Especially in this case, where there is a standard and it's already been implemented by several? Is it just pedantry because they don't get to call the shots?

Re: W3C Working Group Just Killed Web SQL Database

#69
post #65

Earlier quoted context omitted.

Why not just use SQLite? Write a small wrapper around it to isolate each website off on it's own database or set of databases. Each site corresponds to a SQLite user with a password that ONLY the browser knows.

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.

That's a pre-open-source view of standards. We don't have multiple implementations of Python or Linux, yet they can be widely relied on.

Re: W3C Working Group Just Killed Web SQL Database

#70
post #7

Probably 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…

I'm disappointed by the vendor war attitude in this thread. Why don't Mozilla or MS support WebSQL? Do they have some objection to it or have they just not gotten around to implementing it yet?
Post reply on HN