techno.blog("Dion")

I just wrote about the “don’t deploy HTML5″ comment that sparked a lot of conversation around HTML5 and its readiness (again).

I wasn’t sure if Philippe’s words were taken out of context from the reporter. There are some valid points that can be made around the comment, and thus I was curious to see if Philippe would take the opportunity to put his thoughts into his own words, and he has done in his post on HTML5: The jewel in the Open Web Platform.

It felt like a bit of a bizarre “response” since it doesn’t really acknowledge the discussion and instead reads to me, as a piece on how we are in the early stages, need to test, fun for browsers to be playing, but again….. early stages.

There are some points I very much agree with here. I like the notion of the “Open Web Platform” as the stack that brings together HTML5, CSS, JavaScript, etc…. although the server side and protocol side of the Open Web community may not agree and would prefer “Open Web Client Platform” or something. We have been using the term “HTML5″ as the big umbrella of the client side revolution, post-Ajax.

Ben and I have recently given a talk on HTML5 and the role the Web plays with respect to the application ecosystem explosion we are seeing right now. To put it in perspective, the iOS market by itself is growing faster than the Web 1.0 revolution. The Web is a massive ecosystem, and so is the app ecosystem, so it is obvious that there will be some impact from these two worlds colliding.

As Web fans, we are at war. We are passed the browser wars…. that is now in fighting. We need the Web to be a competitive platform, and this is where I do agree with Philippe. What does it mean to be an “HTML5″ platform right now? Just when I feel like we are getting aligned (e.g. using CSS3 transforms/transitions/animations for high performance graphics) one of the important browser runtimes leaves them out. Developers need a solid platform that they know they can build on. With HTML5 we have our first opportunity to deliver an app platform rather than a documentation hypertext system that happens to have enough hack-ability that we could add in Ajax. We can’t sit and complain to the W3C or browsers about the lack of platform features though. We as a community need to get together and show everyone what we as web app developers require from a platform. We want capability. We want ergonomics. We want uniformity. Great things are happening in browser runtime land right now…. so it is time to push.

So, I think Philippe has some of the right idea after all, but I do hope he realizes that we can’t wait for the full HTML5 to bear out. We need to weaponize *today* against the app ecosystems in the fight for the Web.

And, the Web is so very much worth fighting for. When in history has a major platform NOT been owned by a single vendor? Mainframes. personal computing. consoles. All the world of the proprietary. We are in absolute danger of losing the true gem of the Web…. its true open-ness. Being open itself isn’t a weapon though, and in fact it can be a drag and a hinderance which means we need to be even smarter to make sure that the open system that we have is able to deliver better experiences for developers and users.

Aaron Boodman wrote a fantastic post on Gears and Standards which I am very passionate about myself.

In it he talks about the HTML5 Storage API and how we are all working together to unify the database access semantics.

You can see the Database 2 API which aims too:

• Enable Javascript developers to easily write code that works with both Gears and browser database APIs
• Reduce developer “mind-print” by implementing the same API that is available in browsers
• Support the proposed HTML5 database standard with an implementation available for all browsers that Gears supports
• Implement an asynchronous API that can be called from the UI thread without freezing the UI
• Implement a synchronous API to simplify usage inside workers
• Implement a thread pool abstraction that can be used in other modules for asynchronous operations (bonus)
• build a new module from scratch using the new Dispatcher model (bonus).

It would allow you to write code such as:

var dbman = goolge.gears.factory.create('beta.databasemanager');
var db = dbman.open('pages', '0.0.1.0',
  'Collection of crawled pages', 3000000);
 
function renderPageRow(row) {
  // insert page row into a table
}
 
function reportError(source, message) {
  // report an error
}
 
function renderPages() {
  db.transaction(function(tx) {
    tx.executeSql('CREATE TABLE IF NOT EXISTS Pages(title TEXT, lastUpdated INTEGER)', 
      []);
    tx.executeSql('SELECT * FROM Pages', [], function(rs) {
      for(var i = 0; i < rs.rows.length; i++) {
        renderPageRow(rs.rows.item(i));
      }
    })
  })  
}
 
function insertPage(text, lastUpdated) {
  db.transaction(function(tx) {
    tx.executeSql('INSERT INTO Pages VALUES(?, ?)', [ text, lastUpdated ],
      function() {
        // no result returned, stub success callback
      },
      function(tx, error) {
        reportError('sql', error.message);
      });
  });
}

There is a full technical design, so you can get involved and take part in the open source / open community process that we have going on in Gears land.

I will again end with my visualization of the zipper :)

Above is a slide from one of my Gears decks. I get a lot of questions around Gears and HTML 5, and I wanted to be explicit about the role that each play, and how excited we are about HTML 5 (and other standards in fact).

I do not see HTML 5 as competition for Gears at all. I am sitting a few feet away from Hixie’s desk as I write this, and he and the Gears team have a good communication loop.

There is a lot in common between Gears and HTML 5. Both are moving the Web forward, something that we really need to accelerate. Both have APIs to make the Web do new tricks. However HTML 5 is a specification, and Gears is an implementation. Right now you can see differences between the two. I overheard a good analogy for this in a meeting this morning. You can see how similar parts and pieces are, and it will be natural to bring these together just like the image above shows the sides of a zipper.

It is my belief that HTML 5 and Gears will converge in the not too distant path. This has already happened a little, as the WorkerPool API has been proposed to be added as a standard. We are also working on converging the database APIs, with great work from Dimitri Glazkov. To be clear, we have actually been working with the HTML 5 group (starting with WHATWG) from the beginning, but life isn’t perfect and it can take some time to converge.

Standards bodies are not a place to innovate, else you end up with EJB and the like. Instead, they are a place to take work that is already being done and spreading it out. Hixie is doing just that. He studies the Web, how it works, and then works with everyone to come up with nice general standards. HTML 5 is also a large spec that has some additions that do not make sense for a Gears plugin, items that are low level browser features that we couldn’t touch. All implementations of specs are not perfect, and thus we know that Gears will not have exactly the same implementation of HTML 5 as others. On the other hand, Gears is always going to be a superset of HTML 5 as we are pushing the Web hard and innovation is key.

Gears came out of the real-world need within Google to create more and more compelling Web applications. We took Google Reader offline and learnt along the way. We saw the pitfalls, wrestled with synchronization issues, and along with other applications came out with the first release of Gears last May. Now we work with ever expanding groups at Google and learn from their needs, and since we went public in May, we have gotten to learn from you folks.

Gears is a battle hardened Web update mechanism, that is open source and ready for anyone to join and take in interesting directions. Web developers get to go guerilla and fit issues that they see. The good ones? We can bring them back to the HTML 5 standards party.

I guess the zip will always be opening and closing. For some APIs (Database and such) we will join at the hip, and then as we come up with new ones we will break away again and the innovation will start.

My hope is that we will constantly be coming back together.

When you view Gears through the lense of “A bleeding edge implementation of HTML 5″ that is also battle hardened since it has to be deployed for Google (so it isn’t an experimental toy!) you can also see how different it is to AIR and Silverlight. They can play together just fine, as the future of Gears gets into HTML 5. This means that WebKit will support it, and Gears and AIR will be together in that world. Hopefully the IE team will continue on their standards march and you will see the same there. It is nice to see a world where you can work together instead of make stark choices.

The first post I read this morning was Alex Russell giving some more thought to the future of the Open Web where he concludes:

Gears has an open product development process, an auto-upgrade plan, and a plan for N+1.

At this point in the webs evolution, I’m glad to see browser vendors competing and I still feel like that’s our best long-term hope. But we’ve been left at the altar before, and the IE team isn’t giving us lots of reasons to trust them as platform vendors (not as product vendors). For once, we have an open, viable Plan B.

Gears is real, bankable progress.

Oh, and @simonw, I am with you. I want to see that too.

These are my personal opinion and may or may not be that of my employer