So the OpenAjax Alliance had its first face-to-face summit this week in San Francisco. Up until now, IBM’s tireless shuttle diplomacy has been the primary mover, but no doubt it’s going to get tougher to herd the cats with them all in one room :-). As someone who had the good fortune to be there when the initial OpenAjax seeds were planted, it is exciting to see the uptake of these efforts by so many talented companies. While I think it inappropriate for me to provide any color commentary on the meeting discussions (watch Dion and the crew at www.ajaxian.com for that), I do feel comfortable sharing the somewhat controversial (?) charge that Zimbra gave to the OpenAjax group:
(1) We need to clearly define Ajax. A strict interpretation might really only cover asynchronous JavaScript XHR (XMLHTTPRequest) programming in the browser to send XML requests to a server application and receive XML (or JSON) responses. In practice, however, most of us use the term to also embody the range of DHTML/JavaScript techniques for richly-interactive browser applications (X/HTML, CSS, JavaScript, XML/JSON, DOM/XHR programming), and synchronous communications as well as asynchronous. We much prefer the broader definition intended to cover most of what you can get away with in a standard web browser sans plug-ins (which, by the way, has also been embraced by the ultimate authority—Wikipedia).
(2) Clarify the mission of Open Ajax. Our take is that OpenAjax exists to best leverage the investment protection and community innovation inherent in the open source model to accelerate Ajax adoption while ensuring that Ajax remains
– Multi-client — Windows, Apple, Linux, etc., as well as working from PCs to (hopefully) mobile devices;
– Multi-browser — Firefox, IE, Safari, Opera, etc.;
– Multi-server — Linux, Other Unix, Windows, and legacy; and
– Multi-language/container on the server — Java, C#, PHP, Ruby/Rails, etc.
I believe this mission can be achieved (in fact, is most likely to be achieved) without we vendors starting a full-on standards body. Rather my belief is that OpenAjax’s best bet is to continue to work through existing Web standardization efforts (W3C, ECMA, etc.) and, more importantly, existing open source collaborations (Mozilla, Eclipse, Apache, Dojo, etc.).
(3) Endorse and improve Ajax platform technologies. Most of all, Ajax developers are looking to make safe, solid technology bets. Microsoft is actually off to a strong start with Atlas (the MS Ajax Toolkit) and Visual Studio (after all, Microsoft is the inventor of DHTML, XML, and XHR) . At the same time, the greater open source community has Mozilla Firefox (far and away the best browser for Ajax), Eclipse (the tooling framework with the broadest reach in the market), and Apache (the defacto web runtime provider) going for it. The key gaps the OpenAjax camp has to close is consolidation of investment around a handful of innovative Ajax Toolkits (in my humble opinion, closest to critical mass are Apache Kabuki/Zimbra AjaxTK, Dojo, and Scriptaculous), and work on more declarative (less programming intensive) open source authoring alternatives to MS XAML. (Extra credit for simplifying the coexistence of multiple Ajax Toolkits in the same web pages/applications.) This competition for the hearts and minds of developers between Visual Studio and Eclipse; between IE and Firefox; and between Atlas and Kabuki, Dojo, et al. is good for all. At the same time, I think it is generally going to be increasingly hard for other proprietary vendors to find a sweet spot between Microsoft and open source.
(4) Endorse and improve Ajax design patterns. One of the most compelling things about Ajax technologies is that (a) multiple user-interfaces and web-accessible services can be mashed up in new and exciting ways; and (b) WYSIWYG authoring within the browser, which will allow users to far more easily collaborate on the creation of rich content via design patterns like Ajax Linking & Embedding (ALE). Over time, OpenAjax will hopefully take a role enhancing such Ajax design patterns to make them more broadly applicable.
(5) Last, but not least improve the browser. Yes, hearty kudo’s to Mozilla for building the best browser yet for Ajax in Firefox, but there is clearly more that can be done. Having crafted one of the high-water marks to date in terms of rich (and large) Ajax applications, I think we are in a particularly good position to make the ask:
– Higher-performance access to the DOM — The “crossing costs” from JavaScript code to the DOM is simply too expensive for the kind of script-intensive Ajax applications we want to see more of.
– Image collation for download — We need simpler techniques for aggregating the download of multiple images (such as icons) that are used in Ajax applications.
– JIT (“Just In Time” Compilation) for JavaScript — While this is far from low-hanging fruit, faster execution of JavaScript in the browser via native code (5-10X improvement?) could prove the best single thing to increasing the richness of Ajax applications.
– Persistence & other native OS features “sandbox” — While security must be addressed (browser applications cannot be given uncontrolled access to disk or to other OS features), appropriate sandbox techniques in which users retain control could enable a new range of Ajax applications (cut/paste, drag & drop). Of particular interest would be easier support for off-line Ajax applications.
Just our $.02. Good fun, with hopefully much more to come.
Comments are closed.