I’ve just read a post by Alex Maccaw, 5 APIs that will transform the Web in 2013, and think that while the APIs described are all pretty cool, my personal favourite has not been mentioned: web intents. The specification is currently in the ‘working draft’ stage and so chances are it still won’t be finalised next year, which probably means browser coverage will be lacking (particularly in the IE camp), but Firefox and Chrome are already picking it up and so at least that’s something!

Web intents is inspired by Android’s Intents framework, and is a framework that allows for web-based inter-app communication and service discovery. The example that is typically bounded about when talking about web intents is photo editing. Say, for example, I build a web application that allows users to upload photos, and I want to enable them to manipulate the photo on my site. I could spend a lot of time trying to develop my own editing system, but the likelihood is that it will be buggy, or lacking in features, because this is simply not my area of expertise. Using the web intents framework, however, I could simply integrate with a third-party photo editing application which is hopefully less buggy and more feature packed than anything I could code myself. Furthermore, since all my application is doing is declaring that it needs a certain type of service, rather than specifying one service specifically, the user is able to select whichever photo editing application suits him best.

This example works well, given the difficulties that can arise for the average developer dealing with advanced image manipulation techniques, but the web intents system specification is open enough that anyone can register a service for any intent that they wish. Take a look at the demos on the webintents.org for some different sample applications, as well as to get an idea of how this system will work. I think it’s really exciting, and will make it easier for us all to develop richer web applications going forward.

I’m a big fan of Twitter’s Bootstrap html/css/javascript framework, and use it on practically all new web projects that I work on. It makes it super easy to quickly knock up a slick-looking web application, and since it’s built on less it’s really easy to customize the look of each site.

That said, the markup is complex enough that when developing sites I typically have the docs open in another tab at all times as a reference point, which lead me to start building little HtmlHelper extensions to create the more complicated elements, such as navbars, forms, etc. These extensions have been bounced around from project to project, and have ended up a little scrappy as they’ve been built as-and-when with no real planning, but they have been hugely useful, so I decided it was finally time to look at rewriting them. Check out the Bootstrap Extensions repo over on GitHub, or have a browse through the documentation (design somewhat inspired by the original bootstrap docs!).

The library is by no means complete, as of writing this I’ve only implemented lists, buttons, button groups + toolbars, navbars and progress bars; but it’s a start, and I intend to cover the majority of the more involved elements. I’ll also look at fine tuning the API to make development as pleasurable as possible.

Update: This project has been included on The Big Badass List of Twitter Bootstrap Resources. Check it out, there’s some brilliant useful stuff on there

I’ve been reading recently about the new HTML5 specs, and one thing that really interested me was the Web SQL Database spec that would allow javascript developers to access a client-side database from within the browser, in order to save and manipulate data locally on the users machine. This would enable interactive javascript web applications to run offline, in a similar manner to how Google Gears works (think storing emails for access at a time when no internet connection is available). The WebDB API defined a relational database that could be queried using SQL. Unfortunately, as of 18th November 2010, this spec was canned, because it suffered from one fatal flaw: it used SQL. The problem was that in order to define a cross-browser compatible API, all vendors would need to implement the same database (or more specifically, the same form of SQL). The spec pushed SQLLite as the database implementation, which both Chrome and Safari agreed with, but since Microsoft wanted to use a version of SQL Server in IE, work on the specification was ceased.

The replacement for the WebDB API was the Indexed Database API. Unlike webDB, this was a NoSQL database implementation, which used object stores rather than the typical relational database implementation. The main problem with the IndexedDB API, it seemed to me, however, was 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 advantages of IndexedDB over WebDB!). This example, taken from that post, shows the different code samples required to load and display all the kids in a database that have bought candy:

WebDB

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();
    }
  }
}

Pretty monstrous right? Which is a real shame, since IndexedDB has the potential to be a really, really useful in a client side developers toolkit.