Poor IE. Like the late comedian Rodney Dangerfield, it seems to have a hard time getting much respect these days. Within Microsoft it has long been the unwanted stepchild - ignored when Microsoft shifted gears towards server-side technologies in the late 1990s, Internet Explorer was intended to fade away into the woodwork with the coming of Longhorn (now known as Vista), but the rebirth of Netscape Navigator as Mozilla Firefox caught the company off guard and the sudden shift to concerns about security after 9/11 put into the bind of having to improve its browser just to be seen as staying competitive.
The year 2008 saw the next major salvo in the "Second Browser Wars" with the emergence of Google Chrome. This locks Microsoft into a frustrating position - while it is possible to view Mozilla as an annoyance, Google entering the fray forces Microsoft to either radically improve their browser or to fade out altogether, at a time when the stand-alone application market, even with web services capabilities, is being replaced whenever possible with web-based alternatives.
Between them, Mozilla and Google have the potential to force Microsoft below the 50% threshold of adoption by the end of 2009, though I think a likelier target would be mid-2010. This is actually even worse for Microsoft than it sounds, because a significant percentage of Microsoft's deployments are on legacy systems or on OEM machines that may be present, but used comparatively rarely. As of Q4, 2008, IE has 68.15% usage, Mozilla 21.34%, Safari 7.93% and Chrome 1.04%, according to Net Applications.
I think that the Safari numbers may improve a little bit as Apple laptops continue to eat into Microsoft market-share, but Safari's penetration is very much dependent upon the relative size of the Apple vs. Microsoft markets. I think that Mozilla's also probably near the top end of its penetration range, perhaps improving another 4-5% points overall to become a consistent quarter of the market.
Google Chrome, on the other hand, has the potential to do some damage. Overall, Chrome's performance is somewhat better than a Mozilla Firefox and considerably better than IE7, assuming no encumbering extensions. However, those extensions are where Firefox has the edge on both IE and Chrome right now - the add-on mechanism for Firefox makes it possible for Firefox to be configured to do just about anything, and while IE also has an extension mechanism, it requires considerably more programming expertise in order to build these extensions ... which will be even more true once Ubiquity, Mozilla's browser "command-line" reaches a stage where it can be deployed as an integral part of the browser.
Extensibility is becoming a key factor in the browser wars because it draws in the community as a participant in the development of the browser itself. Without the thousands of extensions, Firefox would likely have stalled fairly quickly in 2006.
In December 2008, Aaron Boodman, the founder of Greasemonkey and de facto speaker on all matters Chrome at Google, revealed that while the initial release of Chrome does not have an extension mechanism, this was not an oversight - pointing to a design document that showcases Google's extension strategy. I expect to see extensions surface by late Spring, 2009, designed to work within Chrome's architecture, designed to be simple to build and to share, and designed to be sufficiently contained so as not to impair the security of the browser.
Once this happens, I think that you're going to see a major explosion in the usage of Chrome, partially by developers who aren't happy with either Microsoft or Mozilla, but more-so by a cadre of new developers who see this as a potential platform (or market) on which to build. On the other hand, I don't necessarily think that this will be a unique group - up to a certain point, developing extension components is likely going to be similar enough between the platforms that you'll see extensions designed to work for both Firefox and Chrome.
Moreover, I can see a move on the part of both organizations at some point to develop an API for component extensions that can be standardized as well, which in turn will likely also be supported by both the KDE foundation and possibly by Apple (Chrome, Safari and KDE Konquerer are all built on WebKit, so such standarization between these organizations would make a lot of sense). I don't necessarily see this playing out much before 2010, but I'm reasonably confident that it will happen.
The second major factor will be the release of HTML 5, which may happen in 2009, but more likely will be released in 2010, though the browser vendors will no doubt be integrating prospective features in point releases prior to that. HTML 5 is the first major revision to the HTML specification since the 4.01 specification in 1999. It incorporates a number of new tags as well as recognizes XHTML as being a legitimate "variant" of HTML ... and that all browsers will need to be able to support both forms of syntax.
One of the more intriguing aspects of HTML5 has been the fact that the XForms working group has formed a joint committee with the HTML working group for the purpose of creating an XForms for HTML 5. This will make it possible to set up XML model instances, to bind content to HTML elements and to otherwise provide a lot of the same functionality that has been intrinsic to XHTML+XForms into HTML+XForms, at a considerably lower barrier to entry for developers. This should provide even more fuel for the growth of XForms within the 2009-2010 period.
I will be doing an analysis of HTML 5's features in an upcoming article for O'Reilly later in the winter, so won't cover specific features here. However, given the broad consensus of companies working on HTML 5, its looking increasingly likely that the move to HTML 5, especially if it is done in concert with the release of ECMAScript 3.5, should provide a much higher degree of interoperability between browsers by late 2010.
Overall, I think that the ones best positioned in this space moving forward are those with significant backers - jQuery (with strong support from Microsoft), ext JS (which has an extensive customer base), Dojo, Nexaweb and Tibco likely all have enough legs to survive through the shakeout. To me, AJAX libraries and frameworks are beginning to approach "mature" technology, and as such, is really just beginning to come onto the radar of enterprise buyers.
I did have an interesting conversation recently in which the topic of AJAX support in the Enterprise came up, and one of the things that I'm definitely sensing is that the primary reason that you're not seeing the uptake at the Enterprise level has much more to do with AJAX's ability to work with minimal change with the XML messaging architecture (while consumer-level "mashups" are messaged in the main over JSON, the enterprise is unequivocably XML, and I see no real shift away from that stance any time soon). This is one of the reasons why I suspect that one of the key directions of AJAX library development will be in that area of broad data model integration, and until that happens, enterprise adoption will remain tepid and largely confined to read-oriented "dashboards" rather than full read/write capabilities.