Beyond HTML5: Database APIs and the Road to IndexedDB

IndexedDB is an evolving web standard for the storage of significant amounts of structured data in the browser and for high performance searches on this data using indexes. Mozilla has submitted substantial technical feedback on the specification, and we plan to implement it in Firefox 4. We spoke to prominent web developers about evolving an elegant structured storage API for the web. While versions of Safari, Chrome, and Opera support a technology called Web SQL Database, which uses SQL statements as string arguments passed to a JavaScript API, we think developer aesthetics are an important consideration, and that this is a particularly inelegant solution for client-side web applications. We brought developer feedback to the editor of the IndexedDB specification, and also spoke with Microsoft, who agree with us that IndexedDB is a good option for the web. With additional implementations from the Chrome team in the offing, we think it is worth explaining our design choices, and why we think IndexedDB is a better solution for the web than Web SQL Database.

Web applications can already take advantage of localStorage and sessionStorage in IE 8+, Safari 4+, Chrome 4+, Opera 10.5+ and Firefox 2+ to store key-value pairs with a simple JavaScript API. The Web Storage standard (encompassing localStorage and sessionStorage), now widely implemented, is useful for storing smaller amounts of data, but less useful for storing larger amounts of structured data. While many server-side databases use SQL to programmatically store structured data and to meaningfully query it, on the client-side, the use of SQL in a JavaScript API has been contentious.

SQL? Which SQL?

Many web developers certainly are familiar with SQL, since many developers touch just as much server-side code (e.g. PHP and database operations) as client-side code (e.g. JavaScript, CSS, and markup). However, despite the ubiquity that SQL enjoys, there isn’t a single normative SQL standard that defines the technology. In particular, SQLite supports most of SQL-92, with some notable omissions, and is what the WebDatabase API is based on. But SQLite itself isn’t a specification — it’s a release-ready technology! And the best definition of what constitutes the supported subset of SQL that SQLite uses is the SQLite manual. In order to really get Web SQL Database right, we’d have to first start with defining a meaningful subset of SQL for web applications. Why define a whole other language, when more elegant solutions exist within JavaScript itself?

The Benefits and Pitfalls of SQLite

We think SQLite is an extremely useful technology for applications, and make it available for Firefox extensions and trusted code. We don’t think it is the right basis for an API exposed to general web content, not least of all because there isn’t a credible, widely accepted standard that subsets SQL in a useful way. Additionally, we don’t want changes to SQLite to affect the web later, and don’t think harnessing major browser releases (and a web standard) to SQLite is prudent. IndexedDB does not have this problem; even though our underlying implementation of IndexedDB may be based on SQLite, we keep developers insulated from changes to SQLite by exposing an API that isn’t based on SQLite’s supported syntax.

Aesthetics and Web Developers

Last year, we held a summit at the Mozilla campus to discuss storage on the web. We invited web developers to speak to us about a desirable structured storage API on the web. Many did express resigned acceptance of a SQLite-based API, since they had already experimented with releases of Web SQL Database in some browsers, and claimed that something in circulation was better than a collection of ideas. Yet, all voiced enthusiasm for better design choices, and how a simpler model would make life easier for them. We watched as developers whiteboarded a simple BTree API that addressed their application storage needs, and this galvanized us to consider other options. We were resolved that using strings representing SQL commands lacked the elegance of a “web native” JavaScript API, and started looking at alternatives. Along with Microsoft, we sent feedback about the IndexedDB proposal and actively became involved in the standardization effort.

In another article, we compare IndexedDB with Web SQL Database, and note that the former provides much syntactic simplicity over the latter. IndexedDB leaves room for a third-party JavaScript library to straddle the underlying primitives with a BTree API, and we look forward to seeing initiatives like BrowserCouch built on top of IndexedDB. Intrepid web developers can even build a SQL API on top of IndexedDB. We’d particularly welcome an implementation of the Web SQL Database API on top of IndexedDB, since we think that this is technically feasible. Starting with a SQL-based API for use with browser primitives wasn’t the right first step, but certainly there’s room for SQL-based APIs on top of IndexedDB.

We want to continue the discussion with web developers about storage on the web, since that helps us structure our thoughts about product features and future web standards. We look forward to seeing the next generation of web applications with support for high performance searches on indexed data, and to seeing web applications work even more robustly in “airplane mode.”

117 comments

[…] Older Article […]

June 1st, 2010 at 11:44
anon

FYI: Your link http://hacks.mozilla.org/2010/05/comparing-indexeddb-and-webdatabase should be http://hacks.mozilla.org/2010/06/comparing-indexeddb-and-webdatabase/

June 1st, 2010 at 12:34
1. Shawn Wilsher
  
  Thanks, I’ve gone and fixed that.
  
  June 1st, 2010 at 13:25
Matthew

Some interesting comments at http://news.ycombinator.com/item?id=1395818

June 1st, 2010 at 15:25
Steve Antal

I can’t seem to understand why does Mozilla shoot itself in the foot all the time.

A framework that encapsulates SQL, sorry , this is just so unimpressive. Why not give me SQL and let me write a framework for myself? Am I(as in web developer) too incompetent?

SQLite has a documentation, if it’s not good enough get together with Microsoft, Google and Opera and write one. Is it so hard?

Having an implementation that everyone would agree to use is superior to writing yet another standard.

I really hate it when organizations tend to know what’s better for developers. Sarcasm aside, I think the best thing to do if you really want this, is to have a JavaScript wrapper that wraps around this IndexedDB(you said that it’s easy to write one) and gives me some SQL that works everywhere.

If you really think you have a superior solution just give it to us, but please give us our crappy solution too just in case it’s the other way around. Let us choose what is best for us!

June 1st, 2010 at 16:05
1. Arun Ranganathan
  
  Steve,
  
  Thanks for your comments. Right now, neither Microsoft nor Mozilla support the Web SQL Database API. In order to have really given you SQL, we’d have had to have *first* standardized a subset of SQL for the web. Simply saying “do what SQLite does” isn’t really a good standard. Also, that makes all existing implementations tied to SQLite, which we really wanted to avoid. All the existing implementations use SQLite. We didn’t want a scenario where version changes between releases of SQLite introduced instability; we’ve definitely seen this with our mozStorage API exposed to extensions, and we didn’t want to expose that to web content.
  
  We actually did talk to developers about this. IndexedDB allows for a wide possibility of use cases, but I completely agree that JavaScript libraries that either introduce a btree-style model *or even* an SQL model would be useful. In fact, we predict that libraries will do for structured storage exactly what they’ve done for the rest of the web — create syntactic simplifications and better abstractions.
  
  Are you currently using Web SQL Database in any of your projects, which is probably Safari, Chrome, and Opera only right now? Do you think the code isn’t portable to IndexedDB? I’d love to learn more if you can give me a pointer.
  
  Thanks again for your comments.
  
  — A*
  
  June 1st, 2010 at 17:44
  1. Marcelo Cantos
    
    I’m sure just about any SQL syntax will be portable to IndexedDB, just as it would also be portable to x86 assembly language. But that’s hardly the point. The last example in the comparison page is a perfect example of why no one with a shred of common sense is going to use IndexedDB.
    
    Please tell me that the solution to this ludicrously verbose and cryptic API (I’ve never seen a more inscrutable looping construct.) isn’t just to await an SQL wrapper that isn’t SQLite.
    
    August 30th, 2010 at 04:46
  2. Fazal Majid
    
    The argument that we can’t document and standardize on SQLite’s dialect of SQL is ludicrous. All modern OSes use a TCP/IP stack based on BSD 4.2, and there are subtle nuances between versions, e.g. TCP SACK. Should we ditch TCP/IP and use SNA just because there is not an independent implementation of the stack?
    
    September 1st, 2010 at 10:47
Steve Antal

Actually I did an application to test drive Google Gears, and it was awesome(the fact that I could write such a web app), with very little effort I could create offline data and sync it with a MySQL database. In a nutshell: it worked, It made me feel that this feature needs to be in ALL browsers as soon as possible.

On the other hand IndexedDB API looks a lot like something I did server side. Yes, I actually did implement an IndexedDB-like API on top of MySQL with PHP, and here are the problems:

– in the end it had no real advantage over using SQL
– other developers did not understand it, and learning new stuff is not something some people desire
– I ended up with writing more code that I would normally write with SQL
– it made some simple operations hard and made complex operations nearly impossible

My code that I did should be portable because it doesn’t use complex hierarchies. The problem however is that on the server side I use SQL, and on the client side I would use IndexedDB….which makes life harder than it already is. I know that there will be some differences anyway between server side and client side db queries but still it helps a lot that they are nearly the same.

I really think that what we need is a minimal subset of SQLite, that should always work, a client side database should not have all the “cool” features of server side databases.

Yes, I agree on that, like nearly everything else: storage will suck, but a JS based library will come and save the day. I am already seeing this happen with YUI Storage.

June 1st, 2010 at 23:12
Tim Lind

I’m looking forward to IndexedDB, but it looks like the IndexedDB API introduces significant inflexibility, regarding the tying of index traversals to the row data.

I’m happy that the indexing is dealt with by the implementation, because that is obviously troublesome to implement, but I always wonder, why do we only have the full effect exposed, when you’ve done the work to get the BTree itself into the browser, why not expose a BTree to us directly, so that we can use that for other purposes that perhaps don’t need a whole row of data and several indexes?

It’s the same as with the localStorage API. We are only given one storage container, with a count and iteration, when you’ve done all the work, and to allow us to create a new container would be trivial and actually quite important. It’s not something we can implement over the API. So you’ve done the work, and then you still don’t provide us with the fundamental building blocks which allows us much more flexibility. It seems bizarre.

June 2nd, 2010 at 00:45
Tim Lind

Actually there isn’t really any inflexibility, that was maybe from a dated draft I looked at, your current implementation looks good, and should make for good building blocks.

But I still think that more focus generally needs to go toward providing the building blocks not just the end product, especially how the localStorage API has failed to do so.

Well done for some great work on this spec.

June 2nd, 2010 at 01:37
fpiat

Why make it simple when you can make complicated.
After 15 years of web developement I’m really tired about all these new kind of stuff. We must knew HTML, CSS, JavaScript, PHP, SQL and now we have another piece of … for managing data. When I look at the spec I can’t imagine why people loose their time for making something so … insignifiant.
Every web developer know SQL. Why another API?
Why don’t face real problems like security?

June 2nd, 2010 at 04:01
Mark Davies

I have to agree with some of the other guys here. I have developed a web app which uses Web SQL for Safari and Chrome browsers. I found this page by a google search to see if or when you would be implementing Web SQL. Web SQL works and is easy to use. There are some good wrapper libraries available. Can we not just standardize and make developers happy? I have no doubt I will be able to *port* my code. But I would prefer to have one set of code that works everywhere.

June 4th, 2010 at 14:17
Brona

I can’t help myself, but I find all this reasoning selfserving
1/ SQL? Which SQL?
Yes, SQLite does not support full SQL92, but which database does and look all webdevelopers writing server code seems to be ok with that, having no problem with that… And sorry, creating and documenting new API which is much less known to developers instead of revriting existing SQLite documentation to more suitable one doesn’t seem to be benefit for anybody.
2/ The Benefits and Pitfalls of SQLite
Again, developers (not only web developers) deal with the same issue every day: new version is not compatible with the old one. SQLite is quite fast and powerful already. There’s no need to upgrade it in case of new version beeing incompatible
3/ Aesthetics and Web Developers
Seems to me like there is not developer in Mozilla who would write webpage with DB access on server side… We are mixing technologies everyday… HTML, CSS, ECMAS, PHP, SQL…. everyday rutine….
The beauty of SQL is the fact, that it’s extremely powerfull, very easy to learn and tweekable (one can play with queries).
It’s not nice of you, that you create somewhat object oriented interface, because that is library’s, programmer’s job to do it. So that the solution fit ones needs… And your solution? As far as I know, multiple keys are not supported, doing compound connections across 3 structures (easily done with simple join in Sql) would mean to spend a day playing with dozens of lines of code filled with callbacks, traversing with cursors, insane comparing and actually inventing SQL all over again

But it’s you choice, Chrome, Safari and Opera have made their own… And webdevelopers will choose, and this will not help you…

June 7th, 2010 at 04:52
Brona

My point is, don’t invent wheel, we already have one…
I wonder what will happen in case WedDatabse will be in standard… Would you ignore it, because you know better?

June 7th, 2010 at 04:56
1. Shawn Wilsher
  
  It is very likely that it won’t become a standard as the editor’s draft of the spec currently states, so there isn’t much point in speculating here.
  
  June 7th, 2010 at 10:34
  1. Sam Orchard
    
    Isn’t what these comments are for? :P
    
    April 29th, 2011 at 14:08
Fazal Majid

Replacing an expressive syntax that separates logical and physical data models like SQL with a half-baked hierarchical model where the app has to handle everything itself is not one step backwards, but ten.

June 7th, 2010 at 22:46
Tim Lind

I think most of the commenters are misunderstanding the crucial aspects of the IndexedDB spec, so Iet’s make a few things clear:

– All SQL databases are built ONTOP of an IndexedDB-like API, which is mimmicked after the old ISAM API (that has long lied under many popular databases you use).

– The IndexedDB spec is now bringing that *lower* layer into the browser, allowing *more* options to be available, instead of less.

– SQL on the browser *will* be available, it will be created by a user loaded framework library, so that you can choose your SQL dialect and the function API to the SQL library.

– Alternative data storage systems, that can be easier to use and more efficient, can *also* be provided on top of the IndexedDB API, so we are not *just* tied to SQL, that is the point of this spec. You will still have SQL functionality.

June 8th, 2010 at 02:13
1. Steve Antal
  
  Why implement a DEAD API?
  Why do a low level API?
  In that case why not just give fread() and fwrite() and let the developers write the whole database engine in JavaScript? Yeah I know it wouldn’t make sense, but it’s basically the same case with IndexedDB, it’s too low level!
  
  This whole thing reminds me of innerHTML, it was not in the standard, the standards group apparently thought you should just write a HTML parser in JavaScript and use the DOM methods which suck.
  Why did it make sense to not being able to use the browser’s HTML parser???? It’s a lot faster than anything you could ever write in JavaScript!
  
  Same is trough in this case, SQLite is a fast C engine, it has an SQL parser which is blazing fast, then why on earth should we duplicate that in JavaScript? Why should we have 2 SQL parsers in a browser(1 in SQLite and 1 in JavaScript).
  
  I can write an IndexedDB API on top of SQL in very few lines of code, then what is the point of crippling SQLite then?
  
  Show me the user loaded framework! I don’t want to wait eons for it to happen I want to use it right now!
  
  Sorry guys, but I really feel that this is a huge step backwards.
  
  June 9th, 2010 at 03:35
2. ged
  
  I agree fully with TIM.
  
  1. SQL is well known but its a syntax on top of a indexer in the first place.
  So its far better to have an indexer at the heart of html5 to allow greater combination of SQL and NOSQL implementations on top.
  
  2. I feel allot of developers are biased towards SQL because its well known to them. I agree that its easy. But your all missing the point.
  The SQL you use on the serevr wil not be the same as what you use on the client !!!
  It is nice to be able to use the same data storage API on the server and the client. Everyone would agree with this OF COURSE.
  So this allow ALL developers access to the ability to be DRY in their architectural stacks.
  DRY = DO NOT REPAT YOURSELF.
  
  With the Index DB there will be wrappers that match MS SQL ; Oracle SQL, etc etc. Do you will get DRY.
  
  Conclusion.
  Its very important that the html5 Data storage API an engine is low level and wrappable.
  Jquery , Dojp and other wrappers have been the saviour of web development because they cover up the gaps between browsers versions.
  SQL wrappers onto of the IndexDB will do the same.
  
  To NOT put this level of flexibility into something as important as the web is architectural suicide…
  Mozilla is trying to avoid the HACK that is the current SQL API from W3C.
  
  October 21st, 2010 at 12:28
  1. blago
    
    Finally, I get it. Oracle, SUN, Microsoft, MySQL, Sybase, SQLite, etc. were all stupid to write all that stuff in C/C++/Assembly when they could’ve written some kickass jQuery plugins.
    
    Makes perfect sense: as far as I know an SQL engine has a query parser and a few for loops. We can have ALL that in 50 lines of JS. Even if it were 10,000 who cares about download times anymore.
    
    Moreover, I recently read somewhere that Nitro is 2 times faster than C++ in the worst case. The 1 order of magnitude penalty per interpretation layer is sooo 90s. And it’s not like data access is frequently used.
    
    I have a special request for all browser vendors. In the spirit of DRY (it means DO NOT REPAT YOURSELF), can we have row file access so that we can have the flexibility to write more highly optimized and custom indexes. When you think about it IndexDB could be implemented on top of files (I think).
    
    Conclusion: Go take a computer science class.
    
    October 22nd, 2010 at 17:18
Brona

2 Tim: it’s much easier to write object oriented interface on top of SQL than write SQL on top of object/callback oriented API. Second of all databases are already optimized for speed and performance, and that is one of the most difficult task to do when creating tools managing a lot of related data. SQL is much easier when dealing with relations that this nonsense and building really fast SQL interface upon IndexedDB would be reinventing the wheel (so the choice is either reinventing the wheel or learning something that seems less efficient with no apparent benefits). And the last paragraph is like a joke: alternative data storage that can be easier to use and more efficient can also be provided on the top of SQL engine, so we are not just tied to IndexDB API. This is the point of current WebDatabase Spec. You can still have IndexedDB funcionality…. seems to me more coherent. Every programmer has written object layer upon SQL with the benefits of easy but powerful query language. I wonder how many programmers will be able to create databases containing related objects that will be similarly efficient upon IndexedDB.
But again, the choice will be upon webdevelopers assuming WebKit and Presto supporting WebDatabase.

June 8th, 2010 at 04:00
jonathan chetwynd

this article does not mention XML, nor native xml databases in particular.

could you comment on how xml data is to be incorporated in these proposals?

June 9th, 2010 at 03:46
InfiniteRand

People in glass houses shouldn’t throw stones. How many browsers implement the complete DOM API? If a browser vendor argues that its the focus of its developers on applications integrated with the desktop environment requires a whole different DOM, well, perhaps web developers can re-implement the current DOM API on top of things

June 10th, 2010 at 18:00
Greg Quinn

I have to agree with Steve Antal about Mozilla continually shooting itself in the foot. I’m currently writing website applications where I need to be able to efficiently store megabytes of data on the client side, and Mozilla, Chome and Safari have all come through like champs. SQLite works. It’s as simple as that; raising straw men about whether they will alter the API at some time in the future – so what? Using Microsoft’s acceptance of IndexDB spec is (to misquote Oscar Wilde), frankly the last bastion of the scoundrel. Honestly, it’s gotten to the stage where my impression is that you guys live in some kind of ivory tower. First Shaver talking on about H264, and now SQLite, which should have been implemented by Firefox a year back. I really don’t appreciate this client side API fragmentation. Carry on like this, and you guys will put yourself out of business.

June 13th, 2010 at 22:17
Brett Zamir

Per jonathan chetwynd’s note, I just left a comment in favor of XML databases at http://hacks.mozilla.org/2010/06/comparing-indexeddb-and-webdatabase/comment-page-1/#comment-95595

June 17th, 2010 at 20:10
1. jonathan chetwynd
  
  havent yet had a chance to try out xquery support in browsers,
  
  but xslt support is excellent:
  http://www.peepo.com/games/Shusai-GoSeigen-19340119.xml
  runs from laptop so….
  
  a simple game player
  
  June 23rd, 2010 at 01:32
Federico

If you won’t provide web sql storage, you’ll make two great damages:

The first:

Firefox will loose a serious part of users: we’re developing a web application using web sql storage (it’s simply super) and we will soon recommend chrome to all of our users. I’m sure we’re not the unique company developing over this really good standard:other companies/developers are doing the same.

Web sql storage solves in a great way the problem of offline usage of complex applications. Do you have a better standard? Ok, you can build it… *too*. The w3c specs about web sql storage are well defined: in the while, it shouldn’t be a bad idea to develop them.

The second: you’re making developers life more difficult. The lacking of this feature in firefox is simply boring: we will have to force our users to another browser, making our apps more difficult to distribute and to be used.

I don’t like google. Please, continue to give us the chance to rely oncemore on the mozilla foundation.

June 20th, 2010 at 17:25
Rastaman

I agree with the previous devs, it’s really not fine to impose ourselves a new tech while SQL do perfectly fine the job. It will be painful to do complex queries ( such as calculates bills, taxes…) in an object oriented way while we can do them in one line of SQL. You loose me as a dev on this, and you really didn’t listen to all the devs which criticize this decision. If it easy to implement a native SQL interpreter in front of IndexDB (which run as fast as Web SQL in Webkit) when do it, support the Web SQL spec with your own implementation on top of indexed-DB and satisfy our needs: you have been supported by the community at one time isn’t it ? Or is it your sponsors (Oracle…) which don’t want to have SQL (not shipped by them) on the client side ?

June 26th, 2010 at 02:59
Nevio

I need to say few things as well.

As I saw in earlier posts, I understand that you all want good and standardized feature prior implementation but unfortunately, for examle:

I am working on social media service full of HTML5 (WebSockets, WebSql, localStorage, etc…). I simply cannot nor I want to write bunch of server side or java code in order to get some kind of scalability. Wait… Server side and Scalability + Real time platform == sucks! (sorry for bad words) So you get my point…

It’s sad that now I will need to force Firefox users to install google gears what will be a terrible solution because I have already ban complete Internet Explorer users from platform. (maybe IE9 later)

As Federico said I will repeat again. Sometimes it’s better to be a follower than to do the right job. Developers who re using Web SQL Database are fully aware of damages it can bring to project but still you know what…

Going to hawai, eating in fine restoran, etc… MasterCard can buy!
Web SQL Database cant! It’s priceless! LoL!

June 28th, 2010 at 16:33
Blago

“Why define a whole other language, when more elegant solutions exist within JavaScript itself”

This sentence makes no sense. JavaScript has no existing solutions for querying structured data. In practice we are going to have to learn a whole new way to design our schemas and query the data. The existing solution is called “SQL” and it would be a huge relief if we could share some code/schema between the client and the server for once. I am not scared of having to change a keyword or two.

If you absolutely have to invent something new, get John Resig to design a jQuery-like selector/filter API – that is elegant and yes… we are familiar with.

Speed is another big concern. I would never elect voluntarily to run a JS callback for every row in the DB just so I can filter out everything but the few object I need. This is insane. We are in the era of mobile devices. Anyone sane will let the C code (with the help of indexes) handle that.

As for the elegancy of code… Just look at the last SELECT example here: http://hacks.mozilla.org/2010/06/comparing-indexeddb-and-webdatabase/

June 29th, 2010 at 11:14
Guido Tapia

Does anyone know of any abstraction js library that will allow indexdb / websql transparency? Perhaps even a localStorage fallback for IE?

July 10th, 2010 at 22:12
1. Sam Dutton
  
  Good question. Did you find anything?
  
  persistence.js does something similar, but different.
  
  March 26th, 2011 at 04:30
  1. JJ
    
    There’s a Javascript library called lawnchair – http://westcoastlogic.com/lawnchair/ – which seems to be an abstraction layer between your data requests and your data. It claims to support WebSQL and IndexedDB.
    
    August 12th, 2011 at 21:02
Komrade Killjoy

user storage is passe

stuff everything in a “free” cloud owned by a megalithic datamining entity

with handy US Federal data storage laws they “get to” store information on subject- err um citizens even longer

win win

July 28th, 2010 at 06:24
pkario

Really, none of the argument for not implementing Web SQL Database makes sense.
* SQLLite is already there,
* most developers don’t want to go back to dbase III+ (event old ones like me)
* of course you know better what is good for us but…

If begging is what you need:
PLEASE…
implement Web SQL Database…

July 31st, 2010 at 04:02
1. Greg Quinn
  
  It’s like Mozilla seems intent in becoming superfluous; after having worked on a client side persistence project with SQLite it feels like a game-changer for web-based applications, it’s lightening fast in action, it’s fast to implement and quick to debug. Fortunately, there are other cross-platform browsers that support SQLite and Mozilla is no longer the only game in town as a multi-platform browser choice. “SQL? Which SQL?” is a heading that still make me both angry and sad.
  
  July 31st, 2010 at 13:56
sri

You can find an indexed db playground at http://tinyurl.com/ff-idxdb. It has examples for the APIs. Wrote it since I could not find documentation elsewhere. Hope it helps.

August 4th, 2010 at 00:57
meh

Will this switch solve the HUGE LAG and memory slurping of having a very very large bookmarks collection?

will these ease a transition to NESTED TAGS?

August 5th, 2010 at 03:41
Marcelo Cantos

I just followed the link to the page by the Chrome team. My favourite bit was this:

Q: Why this over WebSQLDatabase?
A: Microsoft and Mozilla have made it very clear they will not implement SQL in the browser. If you want to argue this is silly, talk to them, not me.

This pretty nicely distils the vibe I’m getting just about everywhere I look. No one outside Firefox or Microsoft seems to agree with this direction. I suspect Microsoft just wants to tie the web to T-SQL, and IndexedDB, lacking even the rudiments of a query language, will give them the perfect excuse.

On a related note, it strikes me as a bit disingenuous to mention Microsoft and the Chromium team one after the other, without giving any indication that their positions are quite different. This leaves the impression that the Chromium team are just as happily on board as Microsoft, which is clearly not the case.

August 31st, 2010 at 06:09
Jason

Add me to the disappointed list. I appreciate all the work the people do on Mozilla for basically nothing but (scarce) credit. That said, I think they’re making the wrong choice. Other browsers are giving us lemonade while Mozilla is offering us lemons, water and sugar cane and telling us about how wonderful it will be to be able to make precisely the kind of lemon flavored beverage we want. What I forsee is that, eventually, someone will hack together a javascript library to get a compatibility layer for SQL out of Indexed DB for Mozilla and IE. It will be slower than the native implementations for Safari, Chrome and Opera. Eventually, the speed lag will become enough of an embarrassment that Mozilla will play catch-up and finally just implement Web SQL. IE probably never will, because they have a pathological need to be useless.

As other posters have already addressed, the reasoning against Web SQL is fairly paper-thin and easily answered. It smacks of reverse-justification of a decision that has already been made. As someone who has stuck with Firefox as their primary browser since day 1, this makes me sad.

September 1st, 2010 at 18:30
1. greg
  
  To be fair about Microsoft’s reluctance to implement a SQLite persistence layer; it seems to me that they would be highly unlikely to support distribution of a SQL engine other than their own, and I’m sure that there are valid commercial reasons that they use internally to justify this. I wish they would instead implement SQL Server Express as part of MSIE as an alternative, but I assume that they consider this too much work to implement and/or that it competes with other product pathways. That’s their right as a company to do what they believe is in the best interests for the company. For this reason, using Microsoft as some kind of crutch for the nonsensical decision of Mozilla not to implement an SQLite persistence layer is simply absurd. I really expected more from you guys.
  
  September 2nd, 2010 at 10:29
  1. Christopher Blizzard
    
    Greg, I already replied to this on another post where you said more or less the same thing with the same tone. I’m sorry that you disagree with our decision on this.
    
    September 9th, 2010 at 10:11
Blago

Greg, I’m sorry for the decision you made because pretty much everybody on this thread disagrees with you.

September 9th, 2010 at 10:39
1. Steve Antal
  
  Blago, actually most people including me, agrees with him. I am highly disappointed in Mozilla, because it seems that Firefox is starting to become the new IE6.
  
  September 9th, 2010 at 10:42
  1. Christopher Blizzard
    
    Hyperbole, indeed!
    
    September 9th, 2010 at 14:25
    1. Brett Zamir
      
      Of course, the Mozilla team is very hard at work adding useful technologies like audio and video, and innovating on many fronts, and its mostly other browsers that have catching up to do as far as developer conveniences (E4X, fixed object iteration order, etc.)–notwithstanding the likes of my long-standing gripe about no external DTD support or withdrawal of enablePrivilege support. I think those of us in favor of SQLite can also chill a little bit in recognition that no doubt some SQLite layer will eventually come, even if it requires adding a script tag whenever we want to use it.
      
      But I agree with the sentiment about speed at any costs (and I’d add to that “dumb down the interface at any cost”). It’s not just about what COULD be done with technologies (esp. with a perception that the likes of Google and Apple are dominating the direction of HTML and who have more resources to take advantage of them) but how easy and robust it is for regular developers to do so, and do so in the immediate future.
      
      Maybe those at Mozilla who are pushing for this can actually implement at least some proof of concept SQL layer (SQLReallyLite) if it can be done for the data-centric crowd accustomed to such a model, or at least make some syntax which can handle joining of data, etc.
      
      In psychology, they say for any behavior you wish to remove, you need to provide a substitution, or otherwise there will be a vacuum. Mozilla should expect to run into some resistance whenever it removes or even plans to remove a feature especially if it is does not provide a better alternative (and not just better in some ways), though we should appreciate timing is not always under your control either.
      
      For my very humble part, I’ve started work on http://code.google.com/p/jsxqueryparser/ to try to eventually bring XQuery support to JavaScript (though a jQuery plugin which allowed querying multiple documents would be fairly trivial to implement today with IndexedDB (though not safe to expose fully to the user) ; I just like the syntax of XQuery and its lack of full exposure to JavaScript which a jQuery plugin would need to allow unless it used a JS parser to subset allowable syntax).
      
      Also, XQuery (a spec which was co-edited by those who created SQL itself), besides allowing relational-style joins (see http://en.wikibooks.org/wiki/XQuery/XQuery_from_SQL#Table_Joins ), has a syntax which is even easier to follow (and more powerful) than SQL, and works with hierarchical (document-centric data) as well as relational data (and can work directly on something as familiar and transparent as XHTML tables).
      
      Personally I think XQuery or a modified jQuery would be great candidates for replacing SQL and allowing the web to start off fresh (map-reduce, to my sense, not so much). So, if the browser will not support XQuery, then I hope we can bring XQuery to the browser. Volunteers welcome (brettz9 – yahoo).
      
      We do appreciate all your hard and innovate work on Mozilla! That’s why we get passionate about it…
      
      September 9th, 2010 at 19:58
      1. Marcelo Cantos
        
        A SQLite layer?? SQLite isn’t an API, or a language, or a standard, for that matter; it’s a rock-solid, proven-in-the-field, high-performance, 600:1-testing-code-to-production-code database engine that comes as one .h file and one .c file (ignoring the auxiliary files: shell.c, sqlite3.def and sqlite3ext.h). It is a piece of pure awesomeness that you couldn’t possibly hope to match with a few weeks (or, frankly, many months) of effort on a little side-project. In fact, I doubt it is even possible to match SQLite’s power via a layer on top of IndexedDB.
        
        What people are really bothered about is not that you won’t be able to do SQL, but that a truly fantastic piece of software that has delivered astounding results till now is being unceremoniously dumped in favour of a rewrite-the-world strategy that won’t deliver anything close to it in terms of reliability, performance and overall maturity for at least another couple of years. And frankly, two years is wildly optimistic, since IndexedDB won’t let Microsoft or Oracle drop their own “light” engines in either. Everyone will have to go back to the drawing board and start building their SQL-on-IndexedDB engines from scratch. And most of what makes the existing engines worthwhile (stability and decades of optimisations) won’t make it across to these new implementations.
        
        September 12th, 2010 at 03:20
      2. Brett Zamir
        
        I understand the concern about implementation possibilities and choices and I’m not taking a position about that; my point is simply that many of the complaints here ARE about the API and not having something in place for that is I think a big cause for frustration by developers who at least want some familiar (or at least similar) way to continue their old approach to getting data.
        
        As a fan of XML databases, I am also concerned about implementation capacity, as I wonder whether IndexedDB could in principle support such a database with high performance as well.
        
        September 12th, 2010 at 04:48
  2. Blago
    
    This was a typo. My comment was directed at Chris. It is more than obvious that few (if anybody) people in this thread are in favor of IndexedDB.
    
    September 9th, 2010 at 18:09
Blago

I too think that Mozilla people are out of touch and in denial. BTW 5 years ago I donated money for the NYT ad so I feel real pain when I say that.

Today it looks like Mozilla couldn’t care less about developers. Think about it. FireBug was awesome back when Joe Hewitt was in charge but turned into a giant BUG since. In the meantime Webkit created WebInspector that is part of and maintained with the browser and works like a champ after a bit of used to.

September 9th, 2010 at 18:24
Meni

I have just read this article, not the comments yet, so excuse me for rushing in to comment, if I make a fool of myself it’s only because i feel strongly about this situation. Isn’t this SVG vs VML all over again? From what I have read, it was egos and pride back then, and we all lost because of that. Had we have a agreed upon vector standard back then the web better today.

What i’m arguing for is get the guys from Google, Apple, MSFT, Mozilla and Opera in a room, NO ONE leaves until we have white smoke. MOVE THE WEB FWD FAST. Ration the pizza while locked there :-)

Sheesh, had JavaScript was to be created by a you guys, we would still be waiting for it today ;-) If there is a lesson to be learned i think it’s: choose something already, who cares if it’s less then perfect, no one is going to jail you for that.

Good day (BTW, thks for FF, can’t live without it)

September 19th, 2010 at 01:13
Jaka Jancar

I love it how you manage to say this like it’s a bad thing:

“But SQLite itself isn’t a specification — it’s a release-ready technology!”

September 27th, 2010 at 13:56
Terry

A huge +1 for web sql db.

Terry

October 12th, 2010 at 07:50
Martijn Otto

I think everything has been said before, so I won’t go into a long diatribe here. I just want to let everybody know that the lack of SQL in Firefox is really a very, very big letdown.

November 5th, 2010 at 15:01
dennis

Ridiculous. This just gives me one more reason to ditch Firefox.

November 22nd, 2010 at 11:15
axmcomp

As the vast majority of posters have already said, the justification is just -post rationalisation of a crappy decision taken for purely political reasons.

The fact remains what developers want is an sql interface, not a a crappy btree interface. I don’t want to have to re-invent sql just to get the work done.

Having said that in my experience this affects mainly mobile developers as we are developing complex javascript based webapps. As the majority of browsers are webkit based, they will continue to use websql so this decision is a niggle at the back of the head but won’t affect anything medium term (assuming they probably take 5 years to agree and implement it).

I think this is going to be another case where Mozilla et al will eventually tuck their tail between their legs and implement what everyone else is using because otherwise firefox will become even less popular than it is today.

When you look at the two technologies dispassionatly one is ten thousand miles ahead than the other.

December 12th, 2010 at 18:02
Ramin

I am a Web Developer, and want to write APPs for smartphones in HTML/CSS/Javascript and SQL.
I have allready some PHP Server Scripts that make use of SQL and communicate with my client side HTML/Javascript (Ajax). Now I would like to write offline Apps that use a local database instead of contacting a web server all the time.
With WebSQL it is simple, to port my online apps to offline apps.

Indexed DB may be nice, but I have to change a lot in my code.
Could Mozilla not provide both WebSQL and IndexedDB, and give the Developers the choice?

December 23rd, 2010 at 07:37
Li Zhou

I can not open the indexedDB database with Firefox 4 beta 8.
var request = window.moz_indexedDB(“candy”, “candy store”);

December 28th, 2010 at 09:46
Juan Antonio

It’s easy. No websql , no firefox

January 10th, 2011 at 00:36
vicm

IndexedDB is Mozilla only product. A developer does not have to think about it much: not supported by all major browsers means I am not using it. PERIOD!!!
It is usually IE that pulls such tricks. Now, Mozilla wants to join in.

If you think that IndexedDB is such a great idea, implement it, and, also, implement WebSQL at the same time. If developers like IndexedDB, all browsers will implement it sooner or later.

February 8th, 2011 at 17:46
wHiTeHaT

It is funny that i find this discussion, as being a kind of noob in this case.
But let me tell you this.
You can say what you want, indexedDB and SQL(ite), will go be the standard in ordinary websites.Of course browser depending.
For the users who use a browser supporting SQL go become in trouble, that is for sure.
The users who runs on a microsoft/mozilla browser can profit from both.
It is a market strategics,and it is a clever one.
Let the work be done for you instead of do all yourself.
The browser and Os war is coming to an end.
The final goal is the end user, and all go depend on the hardware.
Wouldn’t it be nice to have a cpu per browser. ;)
So who decide at the end what soft you run?
The hardware supplier.
And they let you think you buy the best.
LOL it is so funny to read this discussion,who do the dishes?

February 12th, 2011 at 17:25
Remy97

I agree with using a NoSQL approach. For many solutions, a relational model is overkill. I agree with data being structured in the form of JSON, but simply optimized with indexing capabilities. I also like the idea of MapReduce and scaling considerations for the future.

February 17th, 2011 at 10:17
1. Marcelo Cantos
  
  If you think that SQL is overkill, then you obviously haven’t seen the comparative code samples at http://hacks.mozilla.org/2010/06/comparing-indexeddb-and-webdatabase/.
  
  February 17th, 2011 at 20:34
Sam Danielson

Sqlite’s type system is a perfect match for JavaScript, e.g. 1 == ‘1’. The fact that it has a type affinity system, is fast, and was developed for an independent purpose is amazing. Even if IndexDB surpasses all expectations, it will still be a loss to not include some portion of sqlite. It’s a great piece of software. If IndexDB must be included, why can’t we have both? Embrace, extend, …

March 4th, 2011 at 13:26
1. Sam Danielson
  
  Never mind. 1 ‘1’ in sqlite. It’s surprising how long an old assumption can remain unchecked.
  
  March 14th, 2011 at 16:23
Kevin Layman

~~insulting comment deleted~~

March 21st, 2011 at 10:10
1. Paul Rouget
  
  Being insulting is not helping here. I will delete any other comments you’ll post. You’re probably way smarter than Mozilla + Microsoft + Google, but it doesn’t allow you to be insulting.
  
  March 22nd, 2011 at 07:15
  1. Marcelo Cantos
    
    I have reread my copies of the deleted posts. They were certainly forcefully presented, but also hit the nail on the head on several counts. Sure, words like “idiots” and “morons” were better left on the bench, but, given the (IMO) colossally bad decision that has been made, I can understand Kevin’s vehemence. And, based on the comment trail above, it is obvious that he’s not alone in this sentiment; from top to bottom, his posts had me thinking, “Yes, my thoughts exactly!” and were thus an important contribution to this debate.
    
    Unless a post is offensive in nature (i.e., threatening, lewd, etc.), there is no justification for removing it. You could have castigated him for the inappropriate tone and left it at that. And if you thought his arguments were wrong or baseless, then the appropriate response would have been a rebuttal.
    
    The removal of Kevin’s posts strikes me as nothing short of circling the wagons by censorship. Unilaterally vetoing his future posts is a disgrace.
    
    Show the community that you are genuinely interested in hearing our voice. Reinstate Kevin’s original posts.
    
    March 22nd, 2011 at 14:48
Marcos Lima

I know that my comment is coming too late, but I’m interested on indexedDB concerns…

I just would like to load data to the local client storage like JSON arrays, strutured objects, simple arrays of any data and after all query like SQL (using simple relationships), like Object-oriented DB. Also, retrieve all the data like objects again would be pretty nice…

I guess you are making this IndexedDB too much difficult coz’ you’re aiming a cutting-edge implementation…

Make it as easy as possible man! =)

Thanks,

Marcos Lima
System Analyst/Web Developer
Brazil

March 24th, 2011 at 09:51
Marcos Lima

I would like to replace the strategy method that query the data, or set myself the indexed properties, and also crete in-memory views, I think that would be useful, create handlers to the storage modifications, like events to the buttons actually do.

March 24th, 2011 at 10:00
MarkIt

Again, HTML5 standards are not standards. The cake is a lie.
For every new feature we have to wait until a jquery thing abstract all the interactions with the browser, erasing any advantage browsers developers think to gain with their own solution.
At this point I just hope Adobe include their standard sqlite in the flash plugin… oh wait, the Apple thing.

March 26th, 2011 at 08:09
John Z

Kevin Layman’s comments were right on the mark. Delete the parts you found offensive and respond to his technical points.

Censorship sucks!

March 28th, 2011 at 16:38
Lucas

As I don’t want to repeat what others have said like a hundred or thousand times in this discussion I can only say:

* No SQLite implementation in JavaScript on top of IndexedDB will be ever nearly as fast as the WebSQL solution

* Have you been to lazy to re-write the SQLite documentation or is it a little baby thing to do what all the grown-up’s refuse? Like the Internet Explorer in past times …

* I think you have made the wrong decision and I hope for you (really!) that you soon implement the WebSQL standard or it will cost you a lot of active developers and users. Don’t know if it’s that what you want?

April 19th, 2011 at 12:03
Mats

Hi – a swede is calling.

I have been into webdev for some years and recently stumbled over Web SQL Database. And it make it possible for me to write apps that I have been dreaming of for mobile devices. As a fan of FireFox I was really dissapointed that there was no support for this in my Firefox 4.

So, now I am FORCED to use Chrome in my developing.
Please, re-think and start support Web SQL as soon as possible.

Cheers from Mats

May 14th, 2011 at 13:39
Christian R Simms

I don’t have much to contribute, just that I’ve used sqlite for several years in a server-side app, and it’s really solid. Solid enough that if all the browser vendors adopted its use, it would be a good thing. Dr. Hipp did a great job developing it. And no client-side layering on top of IndexedDB will be as fast, plus will take at least a year to get solid.

May 17th, 2011 at 12:35
david karapetyan

None of what you said is holding up in the current implementation. The stuff that is documented in MDC is anything but elegant compared to SQL. All I see is a more imperative and clunky implementation of a small subset of SQL with none of the elegance of the declarative SQL syntax. Plus, who was the genius that thought of separating requests and transactions?

June 25th, 2011 at 00:54
Guido Leenders

I am happy to see that parties are working together to find a standard solution across all browser for midsized storage. That finally allows html apps to work when offline. Not all regions in the world currently have 100% coverage.

I can imagine that the current status of the SQL standard is insufficient and semantics should further be cleared. But as far as I can recall from my university days, SQL is based upon solid semantics from set theory.

The alternative (Indexed DB API) is very low level and I strongly encourage our own developers to work on specifications that map directly into code instead of many low level operations and with of course too many forgotten exception handlers. Sure developers can be trained, but with training needs comes a lower bang for the development buck.

I would hoera it when you Mozilla would reconsider to add Web SQL to Firefox and parties would continue working on the Web SQL standard.

July 10th, 2011 at 04:52
1. Bob H
  
  I have to agree, this seems to be an attempt to make data storage in web applications as difficult as possible. I just read the specification, I am surprised someone didn’t just go a step further and ask web developers to code data functions within ADA+ASM.
  
  Web SQL seems like a far better solution and the arguments presented here by Mozilla really don’t stand up when you think about this from a web development perspective. Perhaps from the perspective of someone who uses C++ every day IndexedDB looks good, but most web developers aren’t doing that and this is overly complex.
  
  I agree with the previous posters, step away from this effort.
  
  August 16th, 2011 at 19:32
[…] 最后我们要介绍的就是IndexedDB了，相比其它两个规范，目前只有Firefox实现了IndexedDB（顺便提一下，Mozilla表示它们永远不会去实现Web SQL Database），不过Google已经表示正在考虑在Chrome中加入IndexDB支持。 […]

August 20th, 2011 at 22:18
[…] 最后我们要介绍的就是IndexedDB了，相比其他两个规范，目前只有Firefox实现了IndexedDB（顺便提一下，Mozilla表示它们永远不会去实现Web SQL Database），不过Google已经表示正在考虑在Chrome中加入IndexDB支持。 […]

August 24th, 2011 at 02:25
klkl

Good decisoin!

I appreciate that you stand for IndexedDB, even though most developers unfamiliar with web standards process are unable to understand depth of the issue.

August 26th, 2011 at 16:14
Alek Paunov

Gentleman,

Complex applications (like evolving IDEs as instance) need a real DB (sqlite or other), not just key-value API without query language.

It is obvious which solution is better:
* it is easy for everyone to emulate IndexedDB using WebSQL (with exactly same performance)
* it is impossible for anyone to emulate WebSQL on top of IndexedDB – (as “Aesthetics” argument absolutely irresponsible suggests)

Current official Moziilla position on this decision (which is very, very influential for the shape of the Web in the next few years) is just a horrible mistake, which need to be corrected.

September 5th, 2011 at 14:19
Leigh Harrison

This really is an unfortunate decision.

Writing complex software for off-line use finally appeared possible with the Web SQL DB. Having carefully considered IndexedDB it doesn’t even start to be an viable alternative, both in terms of its feature set and its interface. Writing a second abstraction layer on top of IndexedDB to emulate the underlying SQLite interface is crazy, and the performance hit would be unacceptable.

It will be sad not to include Firefox among the target browsers for future projects. I sincerely hope Mozilla will rethink this decision.

September 20th, 2011 at 01:23
Greg

I would encourage folks to contact the Mozilla advisory board and/or individuals within Mozilla (even Brendan Eich) to complain about the decision to exclude WebSQL; from looking at these posts at least, they seem to be out-of-sync with the development community.

September 21st, 2011 at 11:25
ed

thanks for not giving developers what they need. You could give us web sql while you think of and develop better solutions. Standards are nice but we have work to do.

October 24th, 2011 at 04:13
Gary Schaecher

Sounds like a last ditch effort by two companies late to the party who want to spoil the hard work and productivity of all who making a goog living with WebSQL and SQLite! Booooooo

October 30th, 2011 at 19:07
Alon Raskin

Definitely a horrible decision. We have apps written for Android, BB and iOS using WebSQL. We are now faced with the decision of support Windows Phone and it turns out that like Mozilla they too have gone down the IndexDB. What do we do now? Do we create another version of our app just to support Windows Phone?

We are even toying with writing a JS layer which will take our WebSQL calls and convert them to IndexDB Calls! The effect of this is to shield our developers from IndexDB!! I dont see what other choice we have…

November 8th, 2011 at 12:44
1. Leigh Harrison
  
  The abstraction layer is a sensible solution.
  
  I’m adopting a slightly different abstraction approach, as my apps do background synchronisation to a MySQL DB on the server anyway. If the user is running a compatible browser we use WebSQL, if the user’s running Firefox or Internet Exploder we use a RESTful service to the MySQL DB on the server. I looked at an IndexDB abstraction, but for the complex databases I’m using it was slower than getting and setting via the web.
  
  To make it clear where the speed issue lies we display a message advising the user that they should switch to Chrome or Safari for superior performance.
  
  I don’t like this solution much, and I’m hoping Firefox will soon see sense and support both IndexDB and WebSQL. If they do, Microsoft will eventually get with the programme too, although on past performance that may not be until IE13 or thereabouts.
  
  November 8th, 2011 at 13:37
Eric Kizaki

This is why M$ does not support SQLite: http://www.microsoft.com/download/en/details.aspx?id=3613

They have SQL Server Mobile.

November 25th, 2011 at 14:08
Eric Kizaki

Here is a more updated version of LINQ to SQL for MS.
http://msdn.microsoft.com/en-us/library/hh202860(v=vs.92).aspx

So saying that MS does not support Web db is a lame argument because MS is doing their own proprietary thing. There was no mention of IndexedDB. If I was developing a MS app I would use this stuff not IndexedDB.

November 25th, 2011 at 14:23
Marcelo Cantos

You are talking about mobile apps. This discussion is about the web.

November 26th, 2011 at 02:40
Ramin

Marcelo, this is the same thing.
every mobile device has a browser, and devs can use HTML, CSS, Javascript and something like phonegap to develop software for not one mobile os but for all of them, just changing the CSS to match the native OS look. Or you can go and use something like JQueryMobile.
So you can use web technology to develop standalone local software for all kinds of mobile OSs that works offline (so they have no access to a web server with a database). Still you want to use a database for your software, and of course it is nice to be able to use the same SQL queries that you would send to a sql serverto send them to your local sqlite DB.
as a dev you do not want to learn a new thing like indexed db that you can use no where else you want to use WebSQL, to use your SQL knowledge, or you want to use LINQ what you use everyday when you develop with C#.

November 26th, 2011 at 12:08
1. Marcelo Cantos
  
  @Ramin: If you and/or Eric are trying to make a case that Microsoft is being hypocritical, I won’t dispute that. Microsoft is a very large company, and to some extent, all large companies struggle to publicly convey a coherent view of the world. You wouldn’t try to argue that Microsoft doesn’t think tablets are the way to go just because the Office org has always had it in for the technology and refused to make Office usable on tablet devices.
  
  November 26th, 2011 at 20:04
  1. Ramin
    
    No, every company can and should do what is best for it. And actually I am very impressed by what MS offers with LINQ. I am just saying that accessing DB on mobiles is really important, and that I think that no dev wants to learn about indexed db.
    WebSQL is a nice thing and should be supported by mozilla and by MS.
    Like most other devs I really cannot understand the argument against WebSQL.
    
    November 27th, 2011 at 10:13
Marcelo Cantos

I guess we’re in violent agreement then. :-)

November 27th, 2011 at 15:27
Waseem

Disappointing to say the least. It would be nice to use a real relational DB engine on the client side, or at least *have the option*. Mozilla completely screwed the pooch on this one, and I am disgusted by this decision. WebSQL was implemented almost completely across the board, and Mozilla’s petulance has set the web 1-3 years back in terms of offline and local development. It is for reasons like this (see also Firefox’s html5 audio/video supported formats) that I no longer recommend Firefox to other users, but Chrome.

March 22nd, 2012 at 07:17
[…] 最后我们要介绍的就是IndexedDB了，相比其他两个规范，目前只有Firefox实现了IndexedDB（顺便提一下，Mozilla表示它们永远不会去实现Web SQL Database），不过Google已经表示正在考虑在Chrome中加入IndexDB支持。 […]

April 1st, 2012 at 05:10
[…] http://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/ […]

May 20th, 2012 at 07:16
Freddy May

I agree with the vast majority of the commenters here. Sure, Mozilla are right to add support for IndexedDB – having NoSQL support is a great thing. But to put the frighteners on the development community by deprecating a hugely practical RDBMS that works beautifully in desktop and especially mobile applications is a bloody disgrace.

July 16th, 2012 at 04:16
Eric

“In another article, we compare IndexedDB with Web SQL Database, and note that the former provides much syntactic simplicity over the latter”

Uh? In what world? The article demonstrates the very opposite of that statement!

August 14th, 2012 at 05:08
John Willis

Yet another asinine screwup by Mozilla… I really hope that Chrome completely destroys FF’s market share so that developers like me won’t have to pander to Firefox, which is to web browsers in this decade what IE was to web browsers in the previous one.

September 21st, 2012 at 12:32
Rene Schickbauer

I’m the developer of the Maplat Webserver (and Framework). I’m currently in the process of designing Client-Side storing/caching of data for a large project.

After evaluating the documentation, IndexedDB has no chance whatsoever of getting used in my projects. It does not fullfill requirement, it’s neither readable, fast nor remotely ACID compliant. IT#s API is just a junk of “when i grow up, someday i’ll be a database”.

WebSQL on the other hand fits the bill nicely for most parts. This is what i’m probably going to use.

So, the plan is as follows: Either completly drop support for browsers that don’t support WebSQL (Firefox is currently at less than 1% of “market share” on my business systems anyway) or don’t cache/store data on the client side for those browsers (which would make them much slower). Either way, i’m probably going to have to present affected users with a link to the latest Chrome build and suggest they “upgrade”.

This isn’t an ideal solution. But in my opinion, IndexedDB is just too broken and convoluted for any serious use…

October 1st, 2012 at 12:59
Nick Vaidyanathan

This is probably a correct and important architectural decision. The mature software engineering community has long acknowledged that it is better to Program to an Interface, Not An Implementation.

Most of the web developers responding to this with disgust are likely to be “coders”, not engineers or programmers. The common “web developer”, sadly, can’t architect their way out of a paper bag and needs 4 Drupal/Wordpress modules to display JSON content on a page. Don’t worry about the harshness of their criticism, it’s simply the crying of children being told “No, don’t stick your fork in the electric socket.” (“But it looks really fun! >:(“)

Passing around hard coded SQL queries as strings is wrong. The last thing we need on the web is a slew of client side SQL injection attacks because dumbo.IcopypastaJqueryPlugin().dev didn’t sanitize his inputs, potentially knocking out tables/harvesting user personally identifiable information.

Additionally, the idea of the web being built around open standards as opposed to “whatever does the job right now” is the reason we’re all using different programs that implement HTTP 1.x and TCP/IP, and not MSIE (or, poignantly for Mozilla, Netscape Navigator). Philosophically, this is an excellent decision.

But the commenters do raise a good point. Come on, guys. It’s 2012. Hibernate has been around for over a decade. GORM, LINQ to SQL..there are a lot of implementations of ORM/Abstract Data Mapper layers out there.

If you want to roll your own NoSQL hash map based data store, you should be providing an entity based model with nice iterators and convenience magic methods like GORM, not some low level cursor transaction thing like we’re programming with ADO.NET 2.0.

November 8th, 2012 at 17:23
1. Waseem S
  
  Please, the argument that there are too many bad developers to allow a standard like WebSQL is not relevant at all. We already have AJAX, client side scripting and IndexedDB – if a developer is out to cause havoc, havoc will be caused. A SQL statement pointing to client side data is just as “dangerous” as a JavaScript command that modifies the local data store.
  
  It’s almost 2013; web apps have come a long way and matured. To treat web developers with kiddie gloves only hinders progress.
  
  December 3rd, 2012 at 21:14
2. ArchE
  
  Nick, it’s so much architectural discussion that for trees you don’t see the forest.
  
  Something like this:
  scholar: “we grow a red sweet apples dear Master. Everyone likes it.”
  master: “dear scholar, that is bad. The apples must be blue”
  scholar: “but blue apples are toxic”
  master: “nevermind dear scholar, no one will eat them then. Finally we will have blue apples.”
  
  December 4th, 2012 at 13:36
ArchE

Generally I strongly disagree. By this decision you limit the freedom of choice.

Philosophically BAD!
Give us FREEDOM OF CHOICE!

1. SQL relational engine is philosophocally on the same level as NoSQL. While NoSQL uses JavaScript to access objects, RDBMS uses SQL.
Difference? No…there’s no real ORM in NoSQL.
2. SQLLite is ANSI SQL and ANSI SQL IS STANDARD
3. Aesthetics – code unification? Okay, not really the argue, but I understand
4. SQLLite changes? common, this is only supplemental argument, you’re always enable to hold stable builds

You should take a care of developer, instead you say how developer would work. Thi is not the good way, as I said, you limit the freedom of choice.

Moreover, just now, you kicked off FF from applications which are using WebSQL and are available for mobile devices also. Because, Chrome, Safari and IE supports WebSQL.

November 13th, 2012 at 23:57
1. Robert Nyman
  
  When it comes to Internet Explorer, it has never supported WebSQL. Current support is listed at caniuse.
  
  Additionally, the WebSQL specification is deprecated.
  
  November 14th, 2012 at 01:30
  1. ArchE
    
    Deprecated, right…according to W3C:
    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.
    
    From this POV I really don not understand. Multiple implementations?
    Many projects already use WebSQL or persistence layers.
    Why not to support such an easy implementation like SQLLite?
    
    It seems to me there is strong dislike of SQLLite :)
    
    November 14th, 2012 at 02:56
ArchE

Other arguments why SQL Lite is not philosophically bad idea can be found here http://www.html5rocks.com/en/tutorials/webdatabase/websql-indexeddb/

November 14th, 2012 at 01:07
Richard Collins

I got really excited about having a decent database available for use in an offline web app I am starting to develop. Then I discovered this crazy decision by Mozilla to not support WebSQL. I am now faced with the decision of increasing development time significantly by using IndexedDB, or creating a Chrome/Safari only app.

Whilst I understand the reasoning, it seems quite narrow. Let’s back a good technology. Sqlite is public domain. In the unlikely event that incompatibilities are introduced in the future the community will fork it.

December 3rd, 2012 at 12:59
1. ArchE
  
  Thumbs up.
  It seems there’s strong disappointment with this descicion in the community.
  
  While I’m in the phase I already have WebSQL application my decision is to not support FF.
  
  I strongly believe guys from FF will change the decision. Hope it will not be too late.
  
  December 3rd, 2012 at 23:48
Waseem S

Firefox (Mozilla) with decisions like these come across as puritanical sticklers who can’t be bothered to listen to other people because they know what’s best for everyone. Aside from sabotaging client side data storage, Firefox is the only mainstream browser that can’t play files encoded in the ubiquitous MP3 format via the HTML5 tag. Any attempts to create a cross platform media solution has to include re-encoding all media to ogg or some other format, which doubles encoding time, media storage requirements and costs. Instead of making the web more accessible to all, they are putting hurdles, especially to smaller organizations.
Their argument that MP3 is a proprietary format that shouldn’t be utilized is laughable when you see their GIF support. .

December 3rd, 2012 at 21:09
Sebastian Baltes

Mozilla is so wrong about this.

We are building a medium sized html5 app based on websql and phonegap, and it’s wonderfull to have sql in javascript! We have it in all mobile plattforms (in win8 via a sqlite plugin). Even in a medium sized app the relational model has a lot of advantages: a powerfull query language, transactions, speed and solidness. And we have some large sql queries – doing that by hand with IndexDB would be a nightmare.

More than ten years ago, Object-Oriented DBs were the hype. What survived? SQL. Then NoSQL was the next thing… it’s nice, and they have their niches, but still the majority uses relational databases. Guess what will be dominant in 10 years?

Your IndexDB may be good for the easiest use cases, but for this we allready have localStorage. The complex use cases are not covered by your immature design-baby.

And why the heck must you guys at mozilla design your own peristent standard at all? Please explain this to me: Why didn’t you took MongoDB for example? Because it’s not a standard??? Smells like some kind of hybris, kind of ‘oh, we are sooo smart, and we have all this money and don’t know how to spend it’ attitude. You guess what? Follow this road, and in ten years firefox will be irrelevant, but we will still use SQL in the browser.

January 17th, 2013 at 10:06
Sergei

I’d agree that structured indexed storage is more useful as a basis for Web platform. And it’s better to have Web SQL Storage atop of primitive structured storage. I’d agree with Mozilla’s arguments about depending on SQLite’s sysntax is a bad thing. But. IndexedDB’s API is terrible. Just look at example 4 in https://hacks.mozilla.org/2010/06/comparing-indexeddb-and-webdatabase/.
It’s simply not a way to go.

February 5th, 2013 at 07:19
Vikash Madhow

Anyone who says that IndexedDB is better than WebSQL does not know what he/she is talking about.

Except for the very simple use-cases, IndexedDB is NEVER going to enable the web-browser to become a platform where we have a useful offline mode for web apps when connectivity is down. I recommend that we move collectively to Chrome and recommend to all to do same. I, for one, need something like WebSQL for the type of apps I’m building and therefore firefox is off the supported-browsers list.

March 8th, 2013 at 23:14

Comments are closed for this article.

Hacks

By Arun Ranganathan

SQL? Which SQL?

The Benefits and Pitfalls of SQLite

Aesthetics and Web Developers

Links

About Arun Ranganathan

117 comments

Beyond HTML5: Database APIs and the Road to IndexedDB

By Arun Ranganathan

SQL? Which SQL?

The Benefits and Pitfalls of SQLite

Aesthetics and Web Developers

Links

About Arun Ranganathan

Discover great resources for web development

Thanks! Please check your inbox to confirm your subscription.