It delivers on the promises in the comic. Tabs are first-class entities; a window is more a convenient way to organize a bunch of tabs than a necessity. I didn’t notice any difference in the speed of Javascript, but I’m willing to postulate that it’s improved. The interface is nicely minimalist; there is very little present except the bare minimum necessary for browsing.

However, there are a few things that Chrome lacks that I consider essential for a daily use browser:

• Open All in Tabs. This ability shapes my daily browsing; to have to revert now to opening collections of pages manually or serially seems absurd. I had hoped that Chrome’s Omnibox would recognize the name of a folder of links and offer that feature automatically, but it does not.
• Bookmark menu support. Chrome’s natural way to access your bookmarks is by typing into the Omnibox, which is nice enough as far as it goes. However, some people have large, organized collections of bookmarks. When I want one of them, my natural way of getting to it is by opening the bookmarks menu, then drilling down through the subfolders until I have what I want. I may remember no part of the page title or URL, but I can still find what I want this way. Unfortunately, the only direct access to your bookmarks through Chrome is by opening a row of bookmark buttons, which takes up valuable UI space. Lonely on one end of that row is the bookmark menu access button. It would be nice if that button sat next to the other buttons in the primary row.
• Caching. I want to see a three part strategy for loading commonly accessed pages:
  1. Load and render immediately from the cache
  2. Download simultaneously from site
  3. As the current version of the page comes in, diff against the cached version. As necessary, either completely restart rendering or insert changed elements via DOM manipulation.

  Instead of that, Chrome currently appears to cache nothing at all. I accidentally loaded a page in the current frame instead of a new tab, so I hit the back button. I then had to wait for the site to be completely reloaded before I could relaunch my link. Hitting the back button should be essentially instantaneous.

• Mature Plugins. The Chrome developers don’t need to worry too much about this one; it’ll fix itself as time passes. However, I won’t be willing to use this as a primary browser until, at a minimum, the equivalent of Adblock Plus is developed.

This is a promising start; given time, Chrome has the potential to develop into a serious competitor against Firefox. However, it’s not quite ready for the prime time yet.

XML and Java have the same sort of flavor to them: they’re reasonably good and very widely used; they’re the sort of product that design committees everywhere aspire to create. Their flaws only really become visible after something better comes along. In Java’s case, Python demonstrated that a whole lot of the structure and required text that gives Java code its rigidity can be stripped away, leaving a language that’s a joy to develop in. However, there hasn’t been an analogous improvement on XML.

Until yesterday.

Protocol Buffers have a non-descriptive name; I had no idea what to expect when I clicked the link to the announcement that Google put out. As it turns out, they’re a generic data serialization format (much like XML), except without all the human-readability business that so bloats actual XML. From the announcement:

Protocol Buffers allow you to define simple data structures in a special definition language, then compile them to produce classes to represent those structures in the language of your choice. These classes come complete with heavily-optimized code to parse and serialize your message in an extremely compact format. Best of all, the classes are easy to use: each field has simple “get” and “set” methods, and once you’re ready, serializing the whole thing to – or parsing it from – a byte array or an I/O stream just takes a single method call.

In case you missed that, all you have to write is the schema. All the encoding and decoding crap that you have to wade through in XML has already been abstracted away; they generate classes to do that for you. This is, in fact, cooler than sliced bread.

Of course, there do exist times when XML might better serve your needs:

However, protocol buffers are not always a better solution than XML – for instance, protocol buffers would not be a good way to model a text-based document with markup (e.g. HTML), since you cannot easily interleave structure with text. In addition, XML is human-readable and human-editable; protocol buffers, at least in their native format, are not. XML is also – to some extent – self-describing. A protocol buffer is only meaningful if you have the message definition (the .proto file).

In my experience, the human-readability and self-documentation inherent in XML have always been bonus features not essential to the core mission, which was getting data from Point A to Point B. However, I’ve had to spend countless hours wrangling with DOM and SAX, dealing with the problem of getting the data into and out of that intermediate form.

There is one wart that I noticed: you still have to create and read the Messages entirely distinctly from your own native class structure. The natural thing to do, if you want to use this to serialize and deserialize a class, would be just to put all the members into the Message definition and put the methods into a subclass of the generated class. However, that is expressly forbidden. All is not lost, though: all you really need, at simplest, is a pair of methods like this:

class AClass(object):
     ...
     def toPBuff(self):
          out = AClassPBuff()
          for member in dir(self):
               if not (callable(member) or '__' in member or member in self.__excludeFromSerialize):
                    setattr(out, member, getattr(self, member))
          return out

     @classmethod
     def fromPBuff(cls, pBuff):
          out = AClass()
          for member in dir(out):
               if not (callable(member) or '__' in member or member in self.__excludeFromSerialize):
                    setattr(out, member, getattr(pBuff, member))
          return out

In short, even if only in terms of making efficient use of developer time, this is already an awesome project. Once you count in that it is also faster and slimmer than the alternatives, this becomes astonishingly cool. Expect it to be making appearances in my code from now on.