Firefox 4: An early walk-through of IndexedDB | Hacker News Reader

Firefox 4: An early walk-through of IndexedDB

hacks.mozilla.org

22 pointsmbrubeck15 comments

Can someone tell me the difference between what Mozilla are doing here by ignoring WebDatabase, and Microsoft used to do with their "embrace and extend" style of thinking?

I realise it's slightly inflammatory to write a comment, but I'm genuinely a bit put out that Mozilla have decided to go like this.

Mozilla is not "ignoring" the Web Database API. Quite the opposite: we are very vocal about the reasons we are not implementing it. The alternative API we are promoting is equally open and is being considered by the same standards body.

This is how the process is supposed to work. Neither API is a standard yet. They are both at the "Editor's Draft" stage. Now is the right time to try to influence the eventual standard(s).

I can appreciate why Mozilla doesn't want to standardize, I'm just slightly weary of seeing yet another vendor-specific browser extension come out. Let's face it: it's going to be years before there's a standard for these things, and in the meantime the average web developer is faced with a stark choice of implementing nothing or two-and-a-half versions of a site.

If the HTML5 working draft just specified SQL92, would you jump on board?

It seems like your main complain isn't relational databases, but rather the fact that the HTML spec, as stands, essentially specifies "whatever SQLite implemented" as its database specification.

Even if the standard said SQL92, the only practical, shippable embedded SQL database today is SQLite. I don't think browser vendors are itching to implement their own SQL databases (or if they did, that they would be any more interoperable than the various relational databases today).

So realistically, if we go the SQL route, what will get is SQLite. SQL is a great language and SQLite is a great implementation. But Mozilla knows what happens in the long term when we end up with a web standard that is actually defined by a single implementation: It becomes very hard for anyone else to implement the standard interoperably, or for the standard to evolve by design rather than by accident.

Programming languages are the most complicated standards of all. SQL is good, but Mozilla thinks it's better to give up the advantages of embedded SQL for a lower-level API that is more standardizable, and doesn't add another language to the web stack. (The language we have now - JavaScript - is just starting to be truly interoperable itself.) IndexedDB can and will be backed by SQLite, and the SQL language can be built back on at the JavaScript layer where it will be portable to both SQLite- and non-SQLite backends.

ActiveJS already includes a SQL parser/compiler in pure JavaScript for its in-memory datastore: http://activerecordjs.org/

Everyone using SQLite instead of trying to implement their own independent interoperable stuff would be fucking awesome. There is very little software that's anywhere I would say that about, but SQLite belongs in valhalla. Reimplementing it is too much wank even for the FSF to muster.

Anyone telling me that they were going to implement their own SQLite (especially a browser vendor) and ship it to millions of users to run untrusted unsanitized input would get my door smashed into the face, their nose broken and bleeding. They would deserve it.

> Reimplementing it is too much wank even for the FSF to muster

This must be a typo, becaus nothing is too much wank for the FSF. :)

Well, the object proof is that there isn't even a vaporware "GNU Embedded SQL" project.

Unfortunately, there is probably a Rule 34 for these things. Apologies in advance.

The other common complaint is that using plain strings for data access is inelegant, and not very javascript-y. It will face the same problem as other platforms, where developers end up writing ORM frameworks to map relational database tables (somewhat awkwardly) to objects.

IndexedDB feels closer to real javascript - it does all access through javascript methods. Writing storage wrapper libraries will be cleaner against this kind of API than concatenating strings of SQL.

And it does not preclude someone from writing an SQL implementation on top of it, if they desire. (Or something simpler. eg. http://thomasfrank.se/sqlike.html)

The reason we didn't like Embrace and Extend was because we didn't have the source code. IE6 was exasperating because we couldn't easily study how it rendered pages. Webkit embraced web standards and extended them, but they show the source, so that's not problematic. It's mildly peeving, but not much more so than -webkit-border-radius.

Maybe that's the reason you didn't like it. For me at the time, it was about the pain of having to write for two systems.

Given two systems, do you prefer the closed or open one?

I prefer the one that lets me get the job done in the most efficient manner.

Not related to the FF4 but am I the only one to see that FF 3.6.x loses address bar history?

http://support.mozilla.com/en-US/kb/Ask+a+question

Reply on news.ycombinator.com