Just a few months ago, we could have summed up the browser wars in single word: BORING! That's not to say we haven't appreciated the new features that accompany each new release of Mozilla's Firefox and Microsoft's Internet Explorer, but the results and the competitors always remained the same. It's become far too easy to predict how each new round will go - Firefox will add new features, get a little faster, and inch ever so closer in market share, while each new IE release will suck a little less than the last and continue to be the most widely used browser on the planet. At least in the chip wars, AMD and Intel have taken turns putting the smackdown on one another accompanied by the occasional trash talk.
It took a surprise release by an unlikely newcomer to finally get us excited about the future of browsers again. Google's Chrome seemingly came out of nowhere and has the potential to turn what has been a stale two-man scuffle into a three-way battle royal. Along with greater stability, Chrome's claim to fame is that it can render web pages faster than the competition, and indeed a recent benchmark comparison has pegged Chrome as the new speed king. But in order for anyone to truly take Chrome seriously, Google has to put extension support at the forefront of development, and it appears they're doing exactly that.
As much as it would be nice to simply port all of Firefox's vast library of extensions over to Chrome, Google knows that direct support just isn't technically possible. Instead, Google's getting busy developing its own system , one it believes will prove as equally powerful and easier to use. Wouldn't it be groovy if you could install an extension and have it work right away without a reboot? That's one of the goals. So too is being able to tell what amount of resources each extension is taking up.
These aren't just empty promises, either. Google has put together a design document for Chromium, the open-source implementation of Chrome, listing out specific goals, what types of specific extensions it would like to support (think AdBlock, Stumbleupon, FoxyTunes, and other popular extensions), package and distribution goals, how installation should take place, and much more.
Google understands that it would be an impossible undertaking to make Chrome appeal to every single user, noting that "the feature needs of one person often conflicts directly with those of another." This is something Firefox has long understood as well and is in somewhat of a contrast to Opera's approach, which comes with a wider feature-set from the get-go but isn't nearly as customizable.
User created extensions, in Google's mind, tackles three key problems: Being able to add niche features which apply to a limited fan base, ensuring that users coming from other browsers will have the same core extensions they've grown comfortable with on their previous browser, and allowing third-parties to add features specific to their bundle.
The design document lists out several specific goals for how Google envisions implementing user-created extensions, with a particularly interesting view on stability. One of the strong points of Chrome is that each tab runs in a separate process so if an error occurs, only a single tab is affected and now the whole browser. That's a major selling point given the prominence of tabbed browsing, and likewise, extensions need to maintain that behavior. Specifically, Google's goal is that extensions wouldn't even be able to crash or hang the browser process. Moreover, extensions that are gorging on resources would be clearly identified, much in the same way Task Manager works for system processors.
A handful of the many other goals include making developing and using extensions as easy as developing and using web pages (in essence, extensions should really just be web technologies), a low potential for forward compatibility issues as new browser versions are released, a lightweight feel when installing and using extensions, and extensions should work exactly the same in Chromium as they would in Chrome.
Google's lofty goals will succeed or fail based on the foundation, and at the heart of development document is the necessity to build an infrastructure for an extension system capable of supporting various types of extensibility. The infrastructure being worked on should eventually support an open-ended list of APIs, including toolbars, content scripts, and content filtering (parental filters, malware filters, and so forth), according to the document.
Perhaps best of all, future Chrome extensions should be easy to install with a minimal interface, requiring as little as two mouse clicks. Click the embedded link, accept (or deny) the confirmation, and you're done. And again, most of those extensions won't require a browser restart, and might not even necessitate a page reload. Sweet!
For anyone with the technical know-how or for those that are just plain curious, the Chromium projects contains several resources to help you dive in or just look around. Taken from the Chromium Developer Documentation homepage: