Coach Wei, CTO of Nexaweb, has written a status update on the OpenAjax Alliance and the challenges he see that exist for Ajax Adoption. The Open Ajax Alliance has grown to include 50 industry leaders and elected its first steering committee: elected its inaugural 7-member Steering Committee: Alex Ruseel (Dojo/SitePen), Mike Milinkovich, David Boloker(IBM), Coach Wei (Nexaweb), Kevin Hakman (Tibco), Mike Pinette (Zend) and Scott Dietzen (Zimbra). Wei sees the biggest hurdle to Ajax as having nothing to do with technology:
The biggest adoption hurdle is the massive confusion going on right now. Ajax is not the solution to all problems. There are different levels of adoption of Ajax (borrowing terms from Ray Valdes from Gartner: snippet, widget, toolkit/client-side framework and client/server integrated framework). Different Ajax solutions are for different levels of adoption, etc. – I personally strongly recommend a web 2.0 reference architecture to customers because they need something like this to understand the landscape and pick the right solutions.
Wei also lists several technical issues he thinks that the OpenAjax Alliance should collectively strive to address in the near term:
- Toolkit “loading and unloading”(the capability to load and unload more than one Ajax toolkits into one page): For example, right now a lot of toolkits overload the “onload” function, which will certainly cause collision with another toolkit;
- Name collision (the capability to deal with variable and function name collision). For example, quite a few Ajax toolkits today use “$” as a function name. When they are all loaded onto the same page, what happens?
- Event Hub (The capability to have interaction between different Ajax toolkits). The key requirement here is to enable some kind of “event” propagation so that an event generated from toolkit A can be processed by toolkit B. An example is that the user drags an item from Toolkit A and drops it on Toolkit B – how should this two toolkits communicate the information related to this event? The proper solution is to provide a common event hub that each Ajax toolkit can publish and subscribe events. Initially, we do not have to define the details of different event objects, which can be defined in the future.
- Markup scanning (the capability for an Ajax toolkit to scan an HTML document to pick up the interested markup segments for processing): many Ajax toolkits allow the usage of markup to define components within an HTML page but they all have their own mechanism of scanning the document. If more than one toolkit is loaded, the HTML document maybe scanned multiple times with the danger of causing significant inefficiency and collision. Providing a common mechanism to scan an HTML document would solve this problem.
- Network Hub (server connectivity management): most browsers allow only limited number of connections to the server (for example, Internet Explorer allows only two). If each Ajax toolkit uses its own mechanism to handle server connectivity, it is highly likely collision will happen if more than one Ajax toolkits are loaded on the same page. A proper solution is to provide a common mechanism that centrally manages server connectivity and serves all registered toolkits.;
Wei also sees a number of other technical issues that he categorizes out of the reach of change by the OpenAjax Alliance in the near term. Among these include the performance of Internet Explorer in processing Ajax code, the download footprint of using multiple Ajax toolkits in an application, and the development of offline and mobile Ajax paradigms.