Mozilla

Firefox 4: An early walk-through of IndexedDB

Web developers already have localStorage, which is used for client side storage of simple key-value pairs. This alone doesn’t address the needs of many web applications for structured storage and indexed data. Mozilla is working on a structured storage API with indexing support called IndexedDB, and we will have some test builds in the next few weeks. This can be compared to the WebDatabase API implemented by several browsers that uses a subset of the allowable language of SQLite. Mozilla has chosen to not implement WebDatabase for various reasons discussed in this post.

In order to compare IndexedDB and WebDatabase, we are going to show four examples that use most parts of the asynchronous APIs of each specification. The differences between SQL storage with tables (WebDatabase) and JavaScript object storage with indexes (IndexedDB) becomes pretty clear after reading the examples. The synchronous versions of these APIs are only available on worker threads. Since not all browsers currently implement worker threads, the synchronous APIs will not be discussed at this time. The IndexedDB code is based off a proposal that Mozilla has submitted to the W3C WebApps working group that has gotten positive feedback so far. The code for both APIs does not include any error handling (for brevity), but production code should always have it!

These examples are for the storage of a candy store’s sale of candy to customers, which we’ll refer to as kids. Each entry in candySales represents a sale of a specified amount of candy to a kid, specified by an entry in candy and kids respectively.

Example 1 – Opening and Setting Up a Database

This first example demonstrates how to open a database connection and create the tables or object stores if the version number is not correct. Upon opening the database, both examples check the version and create the necessary tables or object stores and then set the correct version number. WebDatabase is a bit stricter in how it handles versions by giving an error if the database version is not what the caller expects (this is specified by the second argument to openDatabase). IndexedDB simply lets the caller handle versioning as they see fit. Note that there is active discussion about how IndexedDB should handle version changes in the working group.

WebDatabase

var db = window.openDatabase("CandyDB", "",
                             "My candy store database",
                             1024);
if (db.version != "1") {
  db.changeVersion(db.version, "1", function(tx) {
    // User's first visit.  Initialize database.
    var tables = [
      { name: "kids", columns: ["id INTEGER PRIMARY KEY",
                                "name TEXT"]},
      { name: "candy", columns: ["id INTEGER PRIMARY KEY",
                                 "name TEXT"]},
      { name: "candySales", columns: ["kidId INTEGER",
                                      "candyId INTEGER",
                                      "date TEXT"]}
    ];
 
    for (var index = 0; index < tables.length; index++) {
      var table = tables[index];
      tx.executeSql("CREATE TABLE " + table.name + "(" +
                    table.columns.join(", ") + ");");
    }
  }, null, function() { loadData(db); });
}
else {
  // User has been here before, no initialization required.
  loadData(db);
}

IndexedDB

var request = window.indexedDB.open("CandyDB",
                                    "My candy store database");
request.onsuccess = function(event) {
  var db = event.result;
  if (db.version != "1") {
    // User's first visit, initialize database.
    var createdObjectStoreCount = 0;
    var objectStores = [
      { name: "kids", keyPath: "id", autoIncrement: true },
      { name: "candy", keyPath: "id", autoIncrement: true },
      { name: "candySales", keyPath: "", autoIncrement: true }
    ];
 
    function objectStoreCreated(event) {
      if (++createdObjectStoreCount == objectStores.length) {
        db.setVersion("1").onsuccess = function(event) {
          loadData(db);
        };
      }
    }
 
    for (var index = 0; index < objectStores.length; index++) {
      var params = objectStores[index];
      request = db.createObjectStore(params.name, params.keyPath,
                                     params.autoIncrement);
      request.onsuccess = objectStoreCreated;
    }
  }
  else {
    // User has been here before, no initialization required.
    loadData(db);
  }
};

Example 2 – Storing Kids in the Database

This example stores several kids into the appropriate table or object store. This example demonstrates one of the risks that have to be dealt with when using WebDatabase: SQL injection attacks. In WebDatabase explicit transactions must be used, but in IndexedDB a transaction is provided automatically if only one object store is accessed. Transaction locking is per-object store in IndexedDB. Additionally, IndexedDB takes a JavaScript object to insert, whereas with WebDatabase callers must bind specific columns. In both cases you get the insertion id in the callback.

WebDatabase

var kids = [
  { name: "Anna" },
  { name: "Betty" },
  { name: "Christine" }
];
 
var db = window.openDatabase("CandyDB", "1",
                             "My candy store database",
                             1024);
db.transaction(function(tx) {
  for (var index = 0; index < kids.length; index++) {
    var kid = kids[index];
    tx.executeSql("INSERT INTO kids (name) VALUES (:name);", [kid],
                  function(tx, results) {
      document.getElementById("display").textContent =
          "Saved record for " + kid.name +
          " with id " + results.insertId;
    });
  }
});

IndexedDB

var kids = [
  { name: "Anna" },
  { name: "Betty" },
  { name: "Christine" }
];
 
var request = window.indexedDB.open("CandyDB",
                                    "My candy store database");
request.onsuccess = function(event) {
  var objectStore = event.result.objectStore("kids");
  for (var index = 0; index < kids.length; index++) {
    var kid = kids[index];
    objectStore.add(kid).onsuccess = function(event) {
      document.getElementById("display").textContent =
        "Saved record for " + kid.name + " with id " + event.result;
    };
  }
};

Example 3 – List All Kids

This example lists all of the kids stored in the kids table or the kids object store. WebDatabase uses a result set object which will be passed to the callback method provided after all rows have been retrieved. IndexedDB, on the other hand, passes a cursor to the event handler as results are retrieved. Results should come back faster, as a result. While not shown in this example, you can also stop iterating data with IndexedDB by simply not calling cursor.continue().

WebDatabase

var db = window.openDatabase("CandyDB", "1",
                             "My candy store database",
                             1024);
db.readTransaction(function(tx) {
  // Enumerate the entire table.
  tx.executeSql("SELECT * FROM kids", function(tx, results) {
    var rows = results.rows;
    for (var index = 0; index < rows.length; index++) {
      var item = rows.item(index);
      var element = document.createElement("div");
      element.textContent = item.name;
      document.getElementById("kidList").appendChild(element);
    }
  });
});

IndexedDB

var request = window.indexedDB.open("CandyDB",
                                    "My candy store database");
request.onsuccess = function(event) {
  // Enumerate the entire object store.
  request = event.result.objectStore("kids").openCursor();
  request.onsuccess = function(event) {
    var cursor = event.result;
    // If cursor is null then we've completed the enumeration.
    if (!cursor) {
      return;
    }
    var element = document.createElement("div");
    element.textContent = cursor.value.name;
    document.getElementById("kidList").appendChild(element);
    cursor.continue();
  };
};

Example 4 – List Kids Who Bought Candy

This example lists all the kids, and how much candy each kid purchased. WebDatabase simply uses a LEFT JOIN query which makes this example very simple. IndexedDB does not currently have an API specified for doing a join between different object stores. As a result, the example opens a cursor to the kids object store and an object cursor on the kidId index on the candySales object store and performs the join manually.

WebDatabase

var db = window.openDatabase("CandyDB", "1",
                             "My candy store database",
                             1024);
db.readTransaction(function(tx) {
  tx.executeSql("SELECT name, COUNT(candySales.kidId) " +
                "FROM kids " +
                "LEFT JOIN candySales " +
                "ON kids.id = candySales.kidId " +
                "GROUP BY kids.id;",
                function(tx, results) {
    var display = document.getElementById("purchaseList");
    var rows = results.rows;
    for (var index = 0; index < rows.length; index++) {
      var item = rows.item(index);
      display.textContent += ", " + item.name + "bought " +
                             item.count + "pieces";
    }
  });
});

IndexedDB

candyEaters = [];
function displayCandyEaters(event) {
  var display = document.getElementById("purchaseList");
  for (var i in candyEaters) {
    display.textContent += ", " + candyEaters[i].name + "bought " +
                           candyEaters[i].count + "pieces";
  }
};
 
var request = window.indexedDB.open("CandyDB",
                                    "My candy store database");
request.onsuccess = function(event) {
  var db = event.result;
  var transaction = db.transaction(["kids", "candySales"]);
  transaction.oncomplete = displayCandyEaters;
 
  var kidCursor;
  var saleCursor;
  var salesLoaded = false;
  var count;
 
  var kidsStore = transaction.objectStore("kids");
  kidsStore.openCursor().onsuccess = function(event) {
    kidCursor = event.result;
    count = 0;
    attemptWalk();
  }
  var salesStore = transaction.objectStore("candySales");
  var kidIndex = salesStore.index("kidId");
  kidIndex.openObjectCursor().onsuccess = function(event) {
    saleCursor = event.result;
    salesLoaded = true;
    attemptWalk();
  }
  function attemptWalk() {
    if (!kidCursor || !salesLoaded)
      return;
 
    if (saleCursor && kidCursor.value.id == saleCursor.kidId) {
      count++;
      saleCursor.continue();
    }
    else {
      candyEaters.push({ name: kidCursor.value.name, count: count });
      kidCursor.continue();
    }
  }
}

IndexedDB generally simplifies the programming model for interacting with databases, and allows for a wide number of use cases. The working group is designing this API so it could be wrapped by JavaScript libraries; for instance, there’s plenty of room for a CouchDB-style API on top of our IndexedDB implementation. It would also be very possible to build a SQL-based API on top of IndexedDB (such as WebDatabase). Mozilla is eager to get developer feedback about IndexedDB, particularly since the specification has not been finalized yet. Feel free to leave a comment here expressing your thoughts or leave anonymous feedback through Rypple.

182 comments

Comments are now closed.

  1. Morn wrote on December 6th, 2010 at 01:48:

    I don’t know why that firefox 4.0b7 changed the indexedDB API,I made a demo before,and it works all nice in beta 2,but now it totally can’t work in beta 7.do you know anything about the method of indexedDB.open() ?

  2. Chad wrote on December 11th, 2010 at 17:04:

    Anyone know of vacuum sql cleaner alternative for Firefox 4 B7?

  3. Jesse Morgan wrote on December 12th, 2010 at 04:02:

    Hey guys, some interesting discussion going on in here.

    I think the way Mozilla are heading is correct. If we don’t get this right now, before web-application’s begin to supplant client-side apps, we’re just going to be in one whole kludge of a mess that can’t be undone easily.

    Look at the trouble a single short-sighted product design has inflicted on the technological growth of the internet by not thinking of the long term implications. I’m talking about internet explorer.

    While the guy several posts up with broken English was a little hard to understand, I agree that the well established model of thinking of data in terms of tables and columns is an overly restrictive and case-specific thing to force on the web as a lowest common denominator. More loosely defined object stores just make more sense here and as has been stated, more rigid table-like semantics can be implemented on top of this if required.

    I do think that we definitely need a clear and concise syntax for querying these object stores. Again this, as stated, makes sense as a higher level implementation..

    In terms of a simple, flexible, but structured and finitely defined querying approach, I can’t help but think of Microsoft’s LINQ – Or more specifically, The whole IEnumerable interface and accompanying LINQ methods.

    To be clear for those who know LINQ, the object methods required to support LINQ querying are distinct from it’s SQL-like query syntax, which just compiles down to methods on return objects. You can still use LINQ without writing a string based query.

    A quick google turns up a couple of Javascript implementations of this!, which excites me a little if only to have a play.

    http://linqjs.codeplex.com/
    http://jsinq.codeplex.com/

    Examples:
    var result =
    customers.groupBy(function(customer) {
    return customer.lastname;
    }).
    select(function(g) {
    return {lastname: g.key, count: g.count()};
    }).
    orderByDescending(function(r) {
    return r.count;
    });

    var query = new jsinq.Query(‘\
    from customer in $0 \
    group customer by customer.lastname into g \
    select {lastname: g.key, count: g.count()} \
    into r \
    orderby r.count descending \
    select r \
    ‘);

    query.setValue(0, customers);
    var result = query.execute();

    Also an obligatory ‘JOIN’ example.
    from order in $2
    join product in $1 on order.product equals product.id
    select {customer: order.customer, price: product.price}
    into p
    group p by p.customer
    into g
    select {customer: g.getKey(), sum: g.sum(function(q) { return q.price; })}
    into c
    join customer in $0 on c.customer equals customer.id
    orderby c.sum descending
    select {name: customer.firstname + ‘ ‘ + customer.lastname, ‘sum of all purchases’: ‘$’ + c.sum}

    Because JS is a prototype based language, supporting the querying methods on enumerable objects (just arrays??) should be fairly easy to complete in full. This looks like the case with the links I posted.

    Where the real guts would come in is the more lower level interaction between it and DBIndex, so that data iteration can happen lazily. But I’m sure it could be done!

  4. Paul wrote on December 27th, 2010 at 22:29:

    As a web developer, the solution is simple from my perspective. Drop firefox support in my apps as so many did in the prior browser war, and handle IE users with Chrome Frame. This is really fairly simple since firefox is still a minority browser.

    No offense to mozilla but I really have no intention of holding off on using key technologies that work in favor of someone else’s political games.

    To me it would be better to declare support for SQL92 or draft a new SQL-like spec. If current implementations don’t comply, then it should be considered a bug.

    1. Chris wrote on June 2nd, 2011 at 14:52:

      “This is really fairly simple since firefox is still a minority browser.”

      Hogwash. As of April 2011, FF had a 42.9% market share. The next largest share was Chrome at 26.5%.

      1. Chris wrote on August 29th, 2011 at 02:28:

        Dude,
        Do not use w3schools.com for web stats, although it doesn’t explicitly state it on their site I am convinced that the stats come from users of their site, so their stats have some considerable sample bias – quite simply web developers, and aspiring web developers are more likely to use FF or Chrome.
        If you found some better, more representative, stats you’d probably find IE is still leading (it is the default option on Windows, and not that many will change), followed by FF, and then Chrome. Opera, Safari and Rockmelt might have a percent or two each.

  5. Clay Lenhart wrote on January 4th, 2011 at 15:32:

    C# has benefited from LINQ, and there’s no reason Javascript can’t enjoy this as well. In short the answer is to modify the Javascript language to support querying.

    Take a look at the Pig script here (http://www.readwriteweb.com/cloud/2011/01/how-twitter-uses-nosql.php). The Pig script is completely understandable. You could easily see a Pig language embedded in Javascript like LINQ is embedded in C#.

  6. John wrote on January 14th, 2011 at 08:20:

    @Paul, I can’t believe you consider yourself a web developer yet you would drop one of the fastest advancing and most popular web browsers to date.

    The majority of mobile users are using webkit now (iOS and Android), which Firefox complies with almost entirely. I find very few things that don’t work among the most popular browsers: Chrome, Safari, and Firefox.

    Firefox 4 is offering some amazing new technology that will push online applications and gaming into the next generation. Other browsers will follow suit, so if you expect to have a job as a web dev I highly recommend not dropping support for Firefox in your apps.

    1. Paul wrote on January 15th, 2011 at 09:32:

      To be clear I’m not talking about dropping support for firefox alltogether, but for apps that would use offline storage.

      I really have trouble seeing how stuffing a whole new query language into javascript will be anything but painful for someone who needs to deal with more than 3 or 4 “tables”. Especially considering that this solution has us going back to walking through btrees.

      WebDB is an existing standard in production-level browsers. Offline apps can be developed against it without having to support / keep up with an experimental standard used exclusively in experimental versions of browsers.

      There’s no way I’d be able to keep my job as a web developer if I had to try and justify developing anything against this.

      1. Shawn Wilsher wrote on January 18th, 2011 at 15:10:

        The problem with WebDB is that it never reached CR status, and is in fact considered a deprecated standard now.

    2. satish wrote on January 29th, 2013 at 07:06:

      could you please expain to me about database connection in visual studio professional……..

  7. codeguru413 wrote on February 1st, 2011 at 10:06:

    I for one am not a fan of this IndexedDB thing….yet. For one, I am comfortable with tables and database terms. However, that is not a good enough reason to say we should use that style of storage access and development. There is something to be said about using the notion of “objects”, as that’s what we deal with in our everyday physical lives, and so is a good analogy in terms of computing and storage. What I didn’t see from the examples above, is more complicated relational logic…which is important for, well, relating objects to one another. Now, perhaps the examples above are overly simplistic in an attempt to only demonstrate IndexedDB and contrast it with the proposed WebDatabase proposal (which admittedly, is severly flawed in that as of right now, it primarily deals with SQLite).

    But, before we go jumping on the Indexed DB bandwagon, let’s consider one alternative that could make WebDatabase work (or, even enhance IndexedDB in terms of using a object-relational model instead of a tabular-relational model–which if you think about it, isn’t really all that different when you consider that at the core, it’s all relational algebra). Anyway, the main problem is that the databases (e.g. MS SQL Server (or CompactSQL), SQLLite, etc.) al use a different “dialect” of SQL–to put it mildly. Since most of these “compact” and lite databases are offered for free, there really isn’t any reason why they each need to speak a different dialect of SQL. Perhaps there should be a single standard of SQL used for the Web only that all these different compact databases will use (or database engines created specifically for WebDatabase or IndexedDB) in order to facilitate cross-browser, cross-DB support? I know, seems novel…. I don’t understand why we can’t all get over ourselves and make this happen.

    Anyway, just my $0.02… You don’t have to get mad at me. If you don’t like what I say, just move on and read something else or continue to do whatever you do currently.

    Mostly, I just encourage everyone who’s making an effort to bring this to fruition to make the interface as simple as possible to query. Data is king, and many people without formal knowledge of database technology need to query and analyze that data–even creating “queries” on the fly.

  8. Rafal wrote on February 14th, 2011 at 00:57:

    Are you able to run example codes from this post in Firefox 4 beta 10 or 11?
    My problem is that the success event triggered after calling mozIndexedDB.open() doesn’t have result property and I cannot get to the instance of the database? Is this a firefox bug or am I doing something wrong?

  9. Rafal wrote on February 14th, 2011 at 14:18:

    OK, I found the answer myself. In Firefox you have to read the result from the request object not the event object. Don’t understand why it is done that way, cause the Indexed DB draft says something else.

  10. Ben Dilts wrote on March 2nd, 2011 at 00:09:

    Those code samples read like advertisements for Web SQL. In every case, I would pay money to be allowed to use the Web SQL code rather than the Indexed DB code.

    I just tried implementing a simple one-table, one-index setup in Firefox 4 using IndexedDB, and the code is so painful to write, and the performance so dismal (4 *seconds* to simply loop through 200 objects of about 1KB each with a cursor) that I’m ready to support *anything* other than this.

  11. ray wrote on March 7th, 2011 at 21:46:

    I believe the code examples speak for themselves. Every example with the exception of “Storing Kids…” is longer as IndexDB. How is this helpful?

    1. Paul wrote on March 7th, 2011 at 22:46:

      For that matter – what exactly about looping through objects for child relationships is indexed?

  12. Mike Wilson wrote on March 21st, 2011 at 21:56:

    Just my 2 cents here but why didn’t Mozilla simply support WebDB as originally specified by WC3? Seriously? You have to write your own join strategies? It’s 2011, but Mozilla has implemented a storage strategy that basically throws away about 40 years of grounded relational theory (Codd, et al)? Even if you don’t like the proprietary(-ish) nature of Sqlite couldn’t they have come up with something that at least had SQL join syntax?

    Grrrr. I’m currently doing a HTML5 audit of features for a new product I’m writing and because of this I’m seriously thinking about excluding Firefox as a supported browser. Go Chrome!

    1. Christopher Blizzard wrote on March 22nd, 2011 at 09:58:

      Chrome is also likely to support IndexedDB.

      1. Greg wrote on March 22nd, 2011 at 10:13:

        Hopefully Mozilla will follow Chrome’s lead and support both storage technologies :)

        1. Shawn Wilsher wrote on March 22nd, 2011 at 10:19:

          Why would Mozilla implement a specification that has been marked as deprecated?

          1. Marcelo Cantos wrote on March 23rd, 2011 at 04:15:

            You guys have a major influence on these standards. Complaining that it’s deprecated is just a cop-out. Why can’t you just pick up the standard in whatever state it’s in, and fix whatever issues it has? You moan about the fact that the standard references a specific implementation and the consequent difficulties of defining the language independently of one, but most of the work has already been done for you. SQLite supports most of the SQL-92 syntax. So, as a starting point, Web SQL Database could define a subset of SQL-92 that happens to also be a subset of SQLite syntax.

            Now, I’m not totally naïve. I’m sure it’s more complicated than that, but do you seriously expect us to believe that it would be more work than what you’re trying to do now?

  13. John Smith wrote on April 4th, 2011 at 22:03:

    Yes, the decision is pretty bad.
    Yes, the excuses are laughable.
    OK, let’s think for a minute.
    Please correct me if I am wrong, but there should be some rationale behind this.
    People at Mozilla are not idiots and morons (as per Kevin Layman).
    So, who benefits most from hindering acceptance of common browser SQL DB standard?
    Obviously, the company who owns the desktop.
    Who loses most?
    Obviously, the company who wants to move all apps to the net.
    Is it counter intuitive that Mozilla took the side of the former, rather than the later?
    Yes, it is, but we do not know everything behind the scenes.
    Is it possible that some money changed hands or someone was offered high position at Microshaft?
    Who knows?

    Anyway, what would be the consequences?
    Shall businesses start to move to webkit based browsers their intranet apps?
    Shall Mozilla move be side steped with another Chrome frame?
    Shall some new, killer app, based on WebDatabase, pop up and swipe Mozilla market share?

    Thoughts?

    1. Dan wrote on June 13th, 2011 at 08:16:

      “Yes, it is, but we do not know everything behind the scenes.
      Is it possible that some money changed hands or someone was offered high position at Microshaft?”

      @John Smith – You’re kidding me right buddy? Mozilla is a 501.3C NPO, so the idea that the new IndexedDB standard came about through some clandestine database hush-money conspiracy is laughable.

      “Can I get a price check on tin-foil for checkstand 8, we have a gentleman here who needs a large quantity, apparently he’s making hats.”

  14. Jesse Morgan wrote on April 7th, 2011 at 17:41:

    The people screaming for SQL to be supported – SQL is horribly prehistoric. It’s 2011! We can do better, and why should be support older syntax at the expense of progress.

    I commented previously on a LINQ-like syntax for indexdb – something that I think would work excellently for object store or noSQL style storage.

    Seems Microsoft Research agrees with me (not that I place faith in MS research – but the article is sound)
    http://queue.acm.org/detail.cfm?id=1961297

    1. Paul wrote on April 8th, 2011 at 17:31:

      It’s not a step forward until new capabilities are introduced.

      As I understand it, LINQ is an abstraction layer for SQL (there are even built-in utilities for viewing the SQL queries that are generated by LINQ). And while the syntax for LINQ is somewhat different, there are very few features that exist in SQL that cannot be found in LINQ.

      This is clearly not the case with indexedDB, there is no concept of relationship between data entities, you must maintain that yourself. Regardless of what year it is, looping through lists of objects to filter them on your own is not only more work syntactically, but it more work computationally.

      Any developer who’s been in the industry for more than a year or two should know by now that syntax is largely irrelevant as long as functionality is still there. I’m not married to the SQL language, i’m sure there are other methods for querying that are easier to read/maintain. But if we’re going to have an object relational model for persistent storage, then relational integrity must be guaranteed. This isn’t in indexedDB and until it is, it is an inferior standard when compared to webDB.

      So while it may be a good start, I have trouble justifying the time and effort to build against it when I can use Chrome and Chrome Frame and end up with a stable, maintainable application.

      1. Jesse Morgan wrote on April 11th, 2011 at 18:36:

        I don’t believe your understanding of LINQ is correct.

        LINQ is based on the IEnumerable interface. The concept is that any object that can be enumerated conforms to a single interface standard which can be operated on, queried and related using a unified model and syntax – with results being generated as implicit runtime types (js takes care of this by being prototype).
        There are no pre-existing relations. LINQ is definitely not a SQL generator. LINQ to SQL is a LINQ implementation for querying SQL. Likewise LINQ to Object or LINQ to XML perform the same for other data store types.

        The .NET Entity framework does exist to provide preset relations between objects, and it does integrate with LINQ but is not required. I believe this is where you are getting confused.

      2. Jesse Morgan wrote on April 11th, 2011 at 18:42:

        Also, iterating result sets is not implicitly more computationally expensive. I’m and not sure what would give you this idea?

        Regardless of whether the API you are using does the iteration for you, or you do it yourself; it’s still being done somewhere.

        With the case of indexedDB you are given the lower level control to perform this yourself. As has been indicated – another API can be built utilising indexedDB providing this relational ‘integrity’ in a packaged way.

        This has development method has worked great for libraries like jquery

        1. Paul wrote on April 23rd, 2011 at 09:09:

          This isn’t a government project.

          Point taken with LINQ, I had confused it with LINQ to SQL. But I have to say that if SQL databases loop through entire datasets, that’s considered a “full table scan” and is a sign that you at least need some indexes defined.

          I think that you’ve hit the nail on the head about why there’s so much opposition to indexedDB. It’s a lower-level data storage solution, which means we have to go back to the drawing board on query tools, reporting tools, analysis tools, etc.

          This isn’t a government project. I don’t think that it’s unreasonable to think that concurrent efforts are possible, in fact the web is made of a multitude of standards that serve the same purpose with different strengths and weaknesses, giving designers and architects choices on what’s best for each application.

          The software industry has seen countless iterations of fundamental changes like this, as new technologies mature, they take replace the older technologies as they offer advantages in real-world applications. Beyond a more javascript-like syntax there is no advantage to indexedDB in terms of new features.

          In fact it has fewer features than WebDB. The examples demonstrate that the programmers are on their own when it comes to joins. There are no demonstrations of aggregates, or protections from things like orphans.

          I personally have no problem with working with new technologies, I find it strange when people in this industry do. But I also don’t understand the obsession so many in this industry have with syntax. I’ve worked with a lot of technologies and frankly I find that syntax rarely makes a difference. I especially don’t see the attraction to a new syntax when demonstrations like these show that the new syntax will result in MORE WORK.

          I’m sure that indexedDB will eventually mature into something that provides advantages, or will be replaced with something that does. Until then I can’t justify supporting firefox in mobile applications when I have support for WebDB built into every other browser (including IE through Chrome Frame).

          1. Jesse Morgan wrote on April 23rd, 2011 at 17:03:

            Hi again,
            Thanks for the thought out reply.

            I just think that an object store model suits much more to a modern environment and what I hope is a coming age of ubiquity with web technologies. The fact that you can reference a store of like objects indexed by common properties is fairly powerful.

            It fits the bill for javascript because it preserves the type-fluidity of prototype.

            I think that if you’re trying to use an object store as a SQL store, then you are correct; its a long way around.

            The power comes when you realise that you are not constrained in your storage to a table schema. All you must do is ensure that you set a meaningful key or key-property on the store value; the rest is free form.

            Take for instance an object store named ‘Entity’
            Now, ‘Entity’ stores records for both people, and companies.

            Therefore when we store objects in this store, we ensure we assign a unique ‘EntityID’ as a key – but the VALUE has little similarity beyond the fact that it has a property named ‘Entity Type’ which is a hint for which other related properties to expect exist.

            We may index ‘Entity Type’ to speed up querying, but essentially you have a SQL ‘table’ which has differing columns based on need.

            In this context, a ‘Person’ record may have First Name, Last Name, Username, Password, History[], Friends[]

            The latter two being arrays of more objects or EntityIDs

            Personally I’m not a big believer of database level relational management. It just seems like a copout for bad coding of whatever is calling the SQL queries.

            Don’t get me wrong, that’s obviously a broad sweeping statement to make – But I think you are right in that a DB systems primary function is indexed, timely access of information. Relation management comes second IMO and in this case I’d be more than happy to manage that in a higher layer.

            There’s also the fact that SQL is essentially a glorified text store. Obviously we have numeric datatypes too, inclusive of date. You can store ‘blobs’, but they are dumb – the db engine cannot understand them.

            What I’m not totally clear on here is that IndexedDB will take a ‘Value’ in it’s key/value pair as a standard javascript style object with properties – and allow QUERYING on the objects properties.

            This is a major benefit given the time I spend serialising and deserialising data to text if I have to use a SQL DB

  15. Jesse Morgan wrote on April 11th, 2011 at 18:59:

    Perhaps I should wait a minute before posting so I can combine replies;

    What we have here is a critical path in technology. There was an article recently positing that we only have the industry and reliance on expensive liquid rocket technology we have now due to a specific sequence of events including world war 2 and Hitlers fascination with the V2 rocket, and ensuing cold war and ICBM leap-frog development.

    The end result is industry and ‘standardised’ technology relating to liquid rocket propulsion which may not necessarily be the best solution – but which we are stuck with because of the expense of ‘starting again’ and the investment and resistance of change of experience in the field.

    This is equally true in this scenario. We are talking about the platform of the future here, so it makes sense to take stock of what technologies form the base.

  16. Shiby wrote on May 24th, 2011 at 02:08:

    IndexedDb is not working for me .. the code was simple, but its throwing an error while trying to open the database. Error: uncaught exception: [Exception... \The operation failed for reasons unrelated to the database itself and not covered by any other error code.\ code: \1\ nsresult: x80660001 (NS_ERROR_DOM_INDEXEDDB_UNKNOWN_ERR)\ location: \file:///D:/shiby/html5/IndexedDB/IndexedDbSampleFF.htm Line: 14\]

    Anyone got any idea?

    1. louisremi wrote on May 24th, 2011 at 05:45:

      More details on the code you are using would be helpful.
      Louis-Rémi

      1. Shiby wrote on May 24th, 2011 at 22:30:

        Its the similar code as above. Still will paste mine here :

        var request = window.mozIndexedDB.open(“todos”);
        request.onsuccess = function(event) {
        var v = “1.0″;
        var db = request.result;
        };

        At the line where the open method is called, the exception occurs

  17. Pingback from Dive Into HTML5:本地存储(续二) | DevBean's World on June 13th, 2011 at 22:05:

    [...] 如果你曾经做过 SQL 数据库编程,就会发现这些概念都十分雷同。二者主要区别在于,对象存储没有结构化查询语言的概念。你不需要类似”SELECT * from USERS where ACTIVE = ‘Y’”这种语句。你需要做的是使用对象存储机制提供的函数,在名为 USERS 的数据库上打开一个游标,遍历所有记录,过滤掉不活动的用户,使用访问函数读取剩下记录的所有字段。An early walk-through of IndexedDB 是一篇关于 IndexedDB 如何工作的不错的教程,给出了关于 IndexedDB 和 Web SQL Database 的对比。 [...]

  18. Bill Harten wrote on June 27th, 2011 at 13:15:

    50X Faster? “I never said the data in [table] cells had to be atomic” — Ed Codd, father of the relational database, 1999 Very Large Database Conference in San Francisco. I went to the conference just to hear him say it.

    He was defending his invention and explaining why object stores are often 50X to 100X faster than comparable relational implementations. He explained how the industry went astray in the hands of the first relational DB implementors by recognizing nothing more complex than atomic values (strings, ints, floats, blobs, etc.) in the cells of a table.

    Codd’s relational algebra showed how a complex real-world information structure can be normalized (decomposed) into a set of 2-dimensional tables and later reconstituted via the relational operators project, select, and join. The problem is that reconstituting from many smaller atomic parts takes more work than storing the same information in fewer compound pieces. This is why modern object stores, XML databases, object-oriented and the old hierarchical databases like MUMPS and IMS (ancient but they got it right) handle complex data orders of magnitude faster than relational. The only thing that allowed the relational database to survive and thrive these past 40 years was accelerating hardware following Moore’s Law.

    Really? In 1984 I created both a relational and an XML-based (GEDCOM) object database for the LDS Church FamilySearch database, the largest genealogical database in the world at the time. (I know, XML didn’t exist yet). Both were implemented and deployed in production serving the same requirements. We did both at the same time out of group uncertainty. The relational version was carefully indexed and semi-normalized to optimize for performance. Notwithstanding, the XML/GEDCOM-based system was over 50X faster, not 50% but 50X! A whole family, its members, and details were stored in a single compressed physical chunk. Deployed on a lowly 1984 PC, it ran circles around our relational system on multi-million dollar mainframe. This was due to the real-world complexity of the data and the effects of breaking data up versus keeping them together. The mainframe ended up preparing data for deployment on CDs.

    Learnings? IndexedDB’s ability to store a complex object can potentially yield much greater performance, if implemented to advantage. Lack of join and traversal semantics, bulky syntax, and other problems have been solved before in other settings; we just need to put our heads, best ideas, and data together.

  19. Paul wrote on June 30th, 2011 at 04:09:

    This seems a big backwards step to me.

    There is a reason SQL doesn’t just have a ‘SELECT * FROM mytable’ command (which is essentially what IndexedDB seems to have, as far as I can see).

    Anything that you can do in IndexedDB you can do with a similar level of difficulty in SQL, but things you can do easily in SQL look to be really complicated and/or inefficient in IndexedDB. Maybe there are some things which are easier in IndexedDB, but they’re not clear from these examples…

    Saying that disk I/O will be slow compared to Javascript reading and filtering data, for instance, is very disingenous. This ignores the fact of caching. Consider doing a sequential scan of a 50MB database. If the database has to be read from disk, the disk speed will make the difference between JS and a compiled language have very small effect on the overall time. However, if the database has been loaded into memory (either in the DB engine, or just in the OS cache), then the difference between JS and the compiled language will be MUCH more significant.

    1. Bill Harten wrote on September 8th, 2011 at 08:31:

      Your comments ignore performance and suggest that code simplicity is paramount. When you have thousands of simultaneous transactions and terabytes of complex interrelated data, performance often determines what is possible.

      I didn’t say the speedup is because of compiled code, it is because of the number of discrete physical blocks that have to be accessed in a relational implementation vs a hierarchical one. The speedup I reported was not theoretical, it was actual. It was measured on real optimized databases on real optimized hardware with real user loads. The speedup was 50X to 100X (not 50% but 50 to 100 times faster). Orders of magnitude performance gains are significant in big systems, don’t you think?

      My measurements above included caching and were not disingenuous. The numbers are actual performance comparisons, not projected. They were measured on large memory supercomputers with huge caches. But there are limits to the problems caching can solve. Performance depends most on how many physical blocks have to be retrieved from disk to satisfy the query, and big databases don’t fit in cache, by definition. Relational implementations scatter the data you need across many blocks whereas a hierarchical implementation can deliver a complex bundle of data in a single physical read, depending on how it is organized and how it needs to be traversed.

      This is why indexedDB should be able to run circles around a traditional relational implementation when complex related data can be grouped hierarchically corresponding to traversal requirements. And this is why IndexedDB is a big step in the right direction. If you don’t like the language syntax then suggest an alternative, but avoid confusing syntax with the amount of work the hardware has to do under the hood.

      1. Robert Brown wrote on September 15th, 2011 at 14:07:

        Hi Bill,

        Your example would be 50 – 100 times faster because the data you are storing is highly hierarchical and therefore I’m guessing has only one relation defined, parent has children, that traverses the entire tree. If your system had more relations in it, I.E. parent has children and works for employer, you would see a very different result unless you store data multiple times in your XML db and that seems like you are asking for integrity issues and or circular reference problems.

        How do you resolve circular references in your XML? I’m curious because you say that the entire family is stored as a single data block. I.E. if the unthinkable happened, (and unfortunately it does) and someone has a child with one of their descendants, how can you store the entirety of the family when you hit that descendant, the entire tree above them can’t be repeated infinitely right?

        Specialized data can be sped up with a specialized storage mechanism, we are talking about (with a web standard) a generalized storage mechanism that should well for the widest variety of data with the lowest cost to maintenance (ease of use, difficulty in doing the “wrong” thing) while providing the highest performance possible. SQL and relational dbs have so far been the best compromise. There’s a reason that Google came up with BigTable for their proprietary DB, the data worked best with that structure, and performance outweighed the other items. Building a mechanical parts ordering system with BigTable is probably not a good use.

        IndexedDB doesn’t seem to be a good general data storage mechanism. It sounds like it’s a little too low level for use. I.E. data integrity is the user’s responsibility entirely, the ability to store completely different data types in one store with ease frankly scares me based on the developers that I’ve seen out there in the last 30 yrs. Why do people think it’s a good thing to be able to store People and Companies in the same logical data store?

  20. devlim wrote on July 20th, 2011 at 10:18:

    Does the database still remain, after user clear the cache/cookies?

    1. Michael wrote on September 1st, 2011 at 06:43:

      Yes, it does.
      The IndexedDB data is stored in a different location (in Chrome and FF there’s a dedicated folder for each domain), so a cache-cookies cleanup won’t affect the stored date.

      1. Robert Brown wrote on September 15th, 2011 at 14:08:

        You can however, clear the DB as well and if you aren’t savvy enough you can do it by accident when clearing cookies.

  21. Ken Corey wrote on September 6th, 2011 at 13:23:

    What a bunch of pretentious nonsense. The IndexedDB code is more complex, roughly the same size or bigger, and is rather like the argument about which end of an egg to open.

    Example 4 (websql) is readable by anyone who knows SQL. It’s obvious.
    Example 4 (IndexedDB) is a train wreck of Javascript.

    What are they thinking? Is it *really* this necessary to protect someone’s job?

  22. Leigh Harrison wrote on September 20th, 2011 at 01:49:

    I have an existing desktop application I want to redevelop as a web app with off-line storage. It currently uses SQLite, has fourteen tables and builds its own dynamic queries based on user choices. Many of these queries contain multiple sub-queries and deeply nested WHERE clauses.

    I can port this to the Web SQL DB without substantial difficulty. Even contemplating the task with Indexed DB at a theoretical level is impossible.

    For some cases, Indexed DB may be a perfectly acceptable solution. But it’s not an appropriate tool for some of the work I hope to do. And I’m convinced that the web is the future of applications.

    Wny can’t we have both?

    1. Paul wrote on September 21st, 2011 at 12:45:

      If you read the comments by supporters I think that the reason is obvious. It’s politics.

      Supporters of KVP databases like Couch and Indexed DB (both mozilla pet projects) insist that we need a database that’s equally as scalable when it comes to read access when working with terabytes worth of information — inside a browser environment.

      They are also convinced that this performance increase is worth shirking the responsibilities that relational/SQL databases have taken head-on such as data integrity and native support for aggregate functions. These solutions shift the responsibility for those things to the application developer to handle through disciplined use of good design patterns. In exchange they get to claim better I/O times for the database without ever having to show any actual metrics on the impact to practical overall application performance.

      Supporters also insist that there is an additional advantage in keeping the SQL language from infecting web development…because when you’re working with the web, you should never have to work with multiple syntax structures and languages simultaneously.

      These supporters may be right, however I’ve seen no recommendations for any frameworks, reporting tools, or other development tools available for these databases…because they don’t exist. It would be an understatement to say that Indexed DB is in its infancy. Compare this to WebDB which is based on SQLite, with a host of development, reporting and testing tools and for anyone who actually wants to do practical application development the advantage is obvious…there is no justified reason for Mozilla not to support WebDB (at least until Indexed DB is mature) except for politics…multiple standards can and should be supported with offline storage just as multiple standards for document layouts (XML, HTML, XHTML, etc) are supported.

      1. Daniel wrote on September 21st, 2011 at 13:10:

        I wasn’t going to comment, but you mentioned there was no tooling and frameworks dealing with IndexedDB…and it just so happens I wrote one for an advanced MooTools repo that is, IMHO, absolutely phenomenal: https://github.com/csuwldcat/mootools-htmlx/blob/master/Source/IndexedDB/Database.js

        With this MooTools-based Database.js script, you don’t need to worry about async if you don’t want to (it has built-in queuing of async DB requests), you don’t have to keep regenerating connections to the DB (does if for you), and you get a ton of chainable helper methods that allow you to rock socks. Oh and did I mention you can bootstrap a schema with a JSON object if you like?

        How bout’ them apples ;)

        1. Marcelo Cantos wrote on October 22nd, 2011 at 08:11:

          What about an equivalent to the sqlite3 CLI? I located and opened the add-ons database for my Firefox with sqlite3, issued a “.schema”, followed by a “SELECT name FROM addon;” and, lo and behold, I saw a list of Firefox add-ons I currently have installed. Now, this isn’t WebSQL, so I did a further test…

          I loaded http://project.mahemoff.com/sql.html in Chrome and added a couple of cities. I then loaded the corresponding database with sqlite3, confirmed that cities were stored with .schema then SELECT, added another city with INSERT and reloaded the web page. And there it was. The whole exercise took less than a minute, most of which was spent figuring out where Chrome stores its WebSQL databases.

          Consider how this degree of flexibility can impact the development process, especially if you choose from the plethora of extant GUI clients instead of the crufty old sqlite3 CLI, or even build your own tools using one of the many languages with SQLite bindings. For instance, the following Python script strains a list of city populations out of another web page and adds them to the WebSQL demo at http://project.mahemoff.com/sql.html. After a reload, the demo displays the populations of 100 cities.

          $ python -c ‘
          import sqlite3, urllib2, re
          conn = sqlite3.connect(“http_project.mahemoff.com_0/11″)
          conn.executemany(
          “INSERT INTO cities (name, population) VALUES (?, ?)”,
          sorted((city, int(pop.replace(“,”,””)))
          for line in urllib2.urlopen(“http://www.worldatlas.com/citypops.htm”)
          for m in [re.match(r"^\s*\d+\.\s+(.+?),.*?([\d,]+)”, unicode(line, “utf-8″))]
          if m
          for (city, pop) in [m.groups()]))
          conn.commit()

          I am sure plenty of effort is going into IndexedDB to make it easier to work with. But when Paul indicated that there was no tooling, I don’t think that 235 lines of API wrapper — lovely as those lines may be — are what he had in mind.

          1. Daniel wrote on October 24th, 2011 at 09:15:

            I’m not sure you really understand the “API wrapper” you are seemingly dismissive of. First off, it isn’t just a wrapper. It offers convenient methods that people are use to working with when using JS natives like Array that don’t exist on the native IndexedDB object. Additionally it *eliminates entirely* the async handling for you and makes it so you *never* have to worry about whether your transaction objects are stale.

            You tipped your hand when you called it a *wrapper* and offhandedly dismissed it. At that point I knew you didn’t really give it a decent look, much less try it out ;)

          2. Marcelo Cantos wrote on October 24th, 2011 at 14:46:

            @Daniel: Firstly, I did have a good look at it before commenting, and no, I wasn’t trying to be dismissive by calling it a wrapper. Even the raw SQLite API is much more difficult to code against than the C++/Python/Javascript/etc. wrappers, which also do more than just “wrap” the SQLite API. If I came across as dismissive, you have my unreserved apology; that wasn’t my intent.

            My point was, and still is, that a library that makes it easier to access the raw API — even one that improves async handling and adds support for storing additional data types — is a far cry from the wide range of tools, libraries and services that are available for SQLite. Do you dispute the claim that IndexedDB is in its infancy? That’s basically the claim Paul and I were making.

  23. Mike wrote on October 22nd, 2011 at 12:23:

    this is why firefox is heading downhill, speed and functionality is lacking behind webkit:

    http://en.wikipedia.org/wiki/File:Usage_share_of_web_browsers_(Source_StatCounter).svg

    We choose to take the stance that if the user wants offline functionality in their app then they will have to use a webkit browser or IE w/ chrome frame. The server DB and iOS/Android apps are already using sql, writing the html5 app using a very simular database schema had many advantages. Sql works on almost all mobile devices and 80% of desktop browsers (using google frame)

    My users have no problem using a more advanced web browser to get offline functionality, most of them move to Chrome and never look back.

  24. Shiby wrote on October 25th, 2011 at 04:51:

    I had made a post earlier : An exception coming in my Firefox when I run my sample code. But running the Trail Tool (http://nparashuram.com/trialtool/index.html#example=/ttd/IndexedDB/ie.html&selected=#prereq&amp;) it works fine in the same firefox window. Can anyone suggest what might me the issue?

  25. Pingback from HTML5 WebDB vs IndexedDB » Jordan Wallwork on January 29th, 2012 at 07:13:

    [...] that the syntax was just awful compared to it’s SQL alternative. The code samples found at Mozilla Hacks show this pretty well (although it seems that the point of the post is supposed to sing the [...]

  26. Pingback from webStorage: Persistent client side data storage | Web Directions on April 1st, 2012 at 18:21:

    [...] couple of articles from the Mozilla Hacks blog on web databases, the Road to IndexedDB and an introduction to IndexedDBMSDN’s introduction to IndexedDB (supported in IE10)An introduction to webStorage, also from MSDN4 [...]

  27. Fikre wrote on April 14th, 2012 at 20:53:

    I always say “USE COMMON SENSE!”. Firefox is getting complicated, slow and outdated by the day. And when I see this attitude which say “we don’t want to support webdb for NO CONVINCING reason” then it is clear to me why Firefox will be history soon. Many people I know are moving to chrome nowadays because of its ease of use. Users and developers doesn’t give a damn about politics and some theoretical blah blah. What they always prefer is something that WORK with EASE. This is just common sense. And if you lose sight to the simple things that are absolutely obvious to any normal person then your done!

  28. Stan wrote on October 16th, 2012 at 06:07:

    IndexedDB is terrible to implement when you’re dealing with complex data relationships. It is the biggest pain to try and join multiple related data stores when all it would have needed in sql was a few joins to get the job done.. and for data optimization I don’t see how you could even come close to leveraging the power of something like a CTE either.. As web developers we should be making tools easier to use.. not the other way around.

  29. Kurt wrote on December 11th, 2012 at 10:28:

    I created HTML5 pages that use IndexedDB. They are working fine with Google Chrome. But when running on Mozilla Firefox, IndexedDB just does NOT work. I am using Firefox 18.0. Does anyone have any idea why ? Does anyone have IndexedDB running successfully of any version of Firefox ?

    1. Robert Nyman wrote on December 11th, 2012 at 12:33:

      Does this help? Storing images and files in IndexedDB.

  30. Kurt wrote on December 12th, 2012 at 12:56:

    Robert,
    Thank you for pointing me to this article. I am reading it and compare my code and the code in your article.

  31. JimP wrote on March 6th, 2013 at 19:32:

    Bear with me… There is a point to this post…

    A long time ago, a large company I was working for was looking at two competing database technologies. One was basically a hierarchical database manager – with a query language similar to VSAM. The other was a SQL RDBMS. We asked both companies to implement a series of CRUD-type operations using data that were typical for our company. Both were given the flexibility to structure the data however they chose, as long as the operations we required could be implemented.

    SQL-guy created a set of tables, and wrote the seven queries, all in about 3 hours. Hierarchical-guy hand-generated highly optimized code to do the same things, and it took him (full time) seven weeks to do it.

    SQL-guy’s queries averaged appx 1.5 seconds per query.
    Hierarchical -guy’s queries averaged appx 0.5 seconds.

    Advantage Hierarchical-guy, right? But wait… SQL-guy took one look at the results, and said “Well, I guess I need to create an index or two.” An hour or so later, he had the average query time down to 0.8 seconds. The performance still lagged behind Hierarchical-guy’s, but users didn’t really notice the difference in performance.

    Then we asked both companies to make a fairly significant change to one of the queries. (What? You’ve never had requirements change mid-stream?) SQL-guy shrugged, spent 30 minutes making the changes, and had the new version running with comparable performance to the old. Hierarchical guy pitched a hissy-fit, spent nearly a week working on it, and came back with a query that produced the results required, but performed very poorly… He said he would have to re-design the entire suite to resolve that performance issue.

    Our company’s decision? We went with SQL. It was unquestionably true that a master programmer, spending an inordinately long time writing highly optimized code could make the hierarchical solution outperform the SQL database. But the cost in development time was 35X higher to code the hierarchical solution. And a (very common) requirements change mid-stream was roughly 70X the cost in development time.

    So why bring up this ‘ancient history’ in this context? I’m hearing the same refrain here: A great programmer should be able to write faster, more elegant code using IndexedDB. (Quite possibly — maybe even probably — true.) But at what cost? And how about the vast majority of “real world” programmers, who fit into the “roughly average” skill category? (And let’s face it folks, fully HALF of ALL programmers are “below average” skill level! Think about it… Look to your left, look to your right, if you don’t see the “below average” programmer sitting there, you’re probably the one… ;-) For those folks, and even for those who truly are “above average”, WebSQL may be a better commercial solution. It probably won’t be as elegant, but it will likely cost less to write, maintain, and change those solutions over time.

    My vote: provide both interfaces, and let the programmers decide when to “pay the piper” for the ultimate in flexibility and performance, and when to use a “good enough” solution.

  32. Anthony Caudill wrote on March 9th, 2013 at 15:08:

    It looks like it’ll be worth the effort to master Chrome’s technologies for my webapp. Moz has been going downhill these past couple years…. My theory is when Blake Ross took over he elevated some people with him who held on for a while and intimidated the crazy wrapper gurus who don’t know anything about design into being quiet, but now the Seamonkey people have taken back over and Moz is headed back to the nut house. This was a tough decision (maybe tougher than it should have been), but I’m dropping Firefox for Google pretty soon.

  33. Daniel Buchner wrote on March 9th, 2013 at 15:52:

    Wow, people sure are forgetting we’ve entered a consumer landscape dominated by client-driven apps not beholden to massive DBs and interactions with a back-end server. Obviously there are many apps that still rely on such models, but the IndexedDB API serves today’s common mobile app use-cases.

    For each person on this thread up in arms over the inability transfer the SQL paradigm to the client, there will be ten more client-side developers, who when equipped with a slick client-side IndexedDB module/lib, will be happy everyday not to have to deal with SQL.

    Perception is reality folks – you must realize that many of the apps commonly developed for phones, tablets, and…errr…glasses, are not cut from the same cloth as old school server-bound apps. Additionally, the developer pool is changing – it now includes pure-JS folks who will be making apps where almost all the code resides on an installed, on-device package. These developers don’t care hardly as much about some far-off relational database server or the millions of rows it houses. This point is underscored by the emergence of a whole class of auth, content/media, payment, and no-SQL storage services now available to web app developers who have grown tired of all the annoyances the traditional app-stack interaction/maintenance forces them to wade through.

    Maybe it’s frustrating to those who are closely tied to older models of web development, but this is the evolving reality of where app development is clearly headed.

    1. Anthony Caudill wrote on March 9th, 2013 at 20:50:

      Daniel why not give people the choice? Let the consumers decide. And please, please make the file handle api something independent of indexedDB. We don’t want that. Our users don’t want it. They want data they can share with other users and between PCs. They need a conversion point between the browser and the file system. It just seems to me like this is a big bunch of baloney holding back people who like to code in Javascript. I love Javascript… it’s so easy to turn prototype ideas into working ideas with it… you can start with a goal but maybe not a plan, and just keep going until you’re there. Maybe your code won’t be interoperable with other scripts… but if you’re creating something that’s never been seen before, maybe it doesn’t need to be. I don’t make much use of libraries, but my code is lightweight and very easy to understand. That’s all I need from it… I can do by myself what it takes ten people to do in Java or C++, with Javascript. That and the ability to make use of all that browsers have to offer nowadays with HTML 5… you can’t hardly do that with either Java or C++ with the same simplicity (VB is the only thing that comes close). Cloud services are impractical for small developers because they are impossible to manage without spending thousands of dollars.

      Personally tired of it. Just going to Chrome. At least they think of user convenience there. You might win me back, but you’ll have to work for it. And, you’ll have to win back the 8% of the market you’ve lost over the last two years… it’s because of them that I think it’s OK to leave. I think you’re doomed to become the Linux desktop of web browsers: 2% market share competing for a small hermit-like niche… surprise me. …You’ve made me so angry.

      1. Anthony Caudill wrote on March 9th, 2013 at 21:36:

        BTW… what’s wrong with IndexedDB? Why do so many people hate it? Because it was forced on them by a third party that has the leverage. That’s not something the creators of commercial databases had. You are presuming that users will force developers to go your way out of a sense of brand loyalty. You have assumed wrong.

  34. DG wrote on March 10th, 2013 at 17:06:

    In an age of ‘cloud’ this feature is irrelevant. Firefox suffers from too many chefs and bad design. For example, some screens are URL’s like ‘about:config’, yet others are old fashioned popup dialog wizards, and so on and so on….the lack of webkit compatibility leaves firefox’s engine in the stone age….I hate chrome, but its the best crap out there….

  35. Greg wrote on March 11th, 2013 at 06:20:

    I’ve left this thread alone for ages because it’s so inflammatory, but sorry, have to comment:

    “For each person on this thread up in arms over the inability transfer the SQL paradigm to the client, there will be ten more client-side developers, who when equipped with a slick client-side IndexedDB module/lib, will be happy everyday not to have to deal with SQL.”

    Not sure whether this is a serious comment, but no one I’ve ever met, ever, in client side or serverside development has a problem dealing with SQL. Also, as a mobile developer, one of the reasons that I’ve dropped Mozilla is because it’s pretty much useless for mobile apps, especially given its lack of support for SQLite. Saw a report today that mentions that Firefox is avoiding iOS – good.

    As Anthony mentioned, FireFox is (thank heavens) fast becoming irrelevant.

1 2

Comments are closed for this article.