News Stay informed about the latest enterprise technology news and product updates.

Ajax mature enough for the enterprise

Edwin Aoki, technology fellow at AOL LLC., delivered a keynote address titled "Ajax in the Real World" at The Ajax Experience conference in San Francisco on Wednesday. A veteran of user interface technology development, having worked at Apple Computer Inc. and Netscape, prior to its acquisition by AOL, he talked about how Ajax and rich Internet technology has grown and matured to the point that it is ready for the real world. Following his keynote, SearchWebServices talked to Aoki about the latest work at AOL, which includes implementing one of the hot topics at the conference, "progressive enhancement," which starts with the simplest HTML for limited browsers and slowly builds up to high end Ajax. It is a way to serve various browser capabilities including screen readers and cell phones. He also talked about what Ajax and JavaScript need to do to reach full maturity including identity management and data storage support. These next steps for the technology are issues that he and other members of the Ajax community are hashing out face-to-face at the Ajax Experience, he said.

What are you doing with  Ajax at AOL?
We have a whole group that has been working on dynamic Web-based applications for some time. Once you've got your great idea and you've selected whatever toolkit you want and put the concept down, that's when the real fun begins in terms of being able to take those ideas and deploy them in the real world. So the talk was "Ajax in the Real World." In the real world are there particular problems you've encountered?
A lot of times when we talk about Ajax the headlines are around performance and accessibility, where accessibility is defined not just as the issue around screen readers and support for the visually impaired, but beyond that in terms of being able to have the content and services accessible to the broadest audience, the broadest number of browsers, the broadest number of devices. This is especially true when that audience may not even be people. A big audience for a lot of these applications is search engines. Ajax poses some particular challenges for that. Are you doing a lot of Ajax?
We have extensive support for Ajax. We've done a lot of work with  Dojo [the open source JavaScript toolkit]. We have a lot of products that use Ajax. We've been involved in the Dojo effort for some time. A number of our premier products including the MyAOL product that we just launched, use Ajax to stream content in or improve the loading experience. We've also used Ajax for progressive enhancement. What is progressive enhancement?
It's this notion of being able to take raw semantic content in the form of  XHTML [eXtensible HyperText Markup Language] and microformats and expose that through a layer for Simple CSS [Cascading Style Sheets] or less capable browsers, and then build on top of that a much more interactive experience using  JavaScript and  DOM [Document Object Model] to selectively add and remove elements. What do you gain through progressive enhancement?
The advantage of using that model over the traditional graceful degradation model is that you are able to create sites that are more accessible using that broad sense of accessibility. They work even when JavaScript is turned off. They work in mobile browsers. If you have rich media the user doesn't notice the difference. They get the best possible experience for their output model. And the search engines know how to see this stuff. The whiz-bang Ajax stuff doesn't distract them from that. So it helps the search engines find your content?
Yeah, in fact in my presentation today I showed an old version of our video hub that was largely Ajax based. We have tens of thousands of full-length television programs, but if you went to Google, you'd never find them because the Ajax interface was getting in the way of the search engine finding all that content. How did you fix that?
We went through and redesigned it using some of the principles of progressive enhancement and also some of the design techniques. We went back and took a lot of the Ajax work and made it less central using PE to drive interactivity without having it get in the way of the main content. What does the progressive enhancement model do so that the search engine can find the content?
What happened previously is we had a large amount of content showcased through a scrolling DIV. We'd used XHR [XMLHttpRequest] to pull the content into that DIV from the backend. Because we wrote that on the fly, when the search engine came through it didn't parse the JavaScript and so the only thing it saw was the fact that there was this empty DIV and never went in. So the search engines were blind to the content?
That's right because we were pulling that content in dynamically across our Ajax pipe. Now, how does it work?
Now, what we do is all the content exists in the form of raw HTML and if you're a search engine or you're a text browser or you've turned off CSS and JavaScript in your browser that's all you get. But it's a perfectly readable, perfectly viewable page in its own right. Then we apply a set of styles on top of that and you get a prettier view. If you're a mobile phone with an underpowered Web browser that's probably the view that you see. If you've turned off JavaScript that's the view that you'd see. If you've turned off ActiveX in a pre-IE 7 browser so you don't get XML HTTP requests that's the view that you'd see. Then if you have all those things enabled, we use JavaScript to manipulate the DOM so that you get the flash, you get the images, you get the all these things, but they are in addition to the experience and there are not subtractions from a degraded experience. So is progressive enhancement a better way to reach browsers with a variety of capabilities?
It always causes a bit of a stir when we talk about it because it's counter-intuitive to the way people think of graceful degradation where you build out the full experience first and then figure out what fails if you don't have full browser capabilities. But it turns out progressive enhancement is very good for search engines. It's really good for screen readers that have a lot of trouble with JavaScript, obviously. And it turns out that it's also good for performance because it results in cleaner markup, more cacheable JavaScript because your JavaScript and your content are more separable. It gives you a nice programming model. Are the AOL developers mostly using JavaScript or do you also work with  PHP and Ruby?
We have a little bit of everything. Some of our products are built on  Ruby on Rails. We have some PHP content. Our teams tend to select the tools they feel are the most appropriate to their particular task. In the past year, there's been some talk that JavaScript is the weak link in Ajax, what has been your experience?
It's certainly gotten better. The work that's been done in IE 7 and Firefox 2 and the Safari 3 beta have made the overall support for JavaScript a lot better, but in my presentation today we talked about the work the browser manufacturers have done, the work that the community has done in terms of things like Dojo and  Prototype [JavaScript Framework] and [JavaScript library] have come a long way in the last year, but it's not there yet. There are still some fundamental areas that we feel are missing from a robust Web development environment. They are ones that we'd like to collaborate with the industry and the other people here at the conference to flesh out.

For more information
Mobile Ajax for workers on the edge

Check out our Ajax Learning Guide

 What areas of JavaScript would you like to see improved?
Things like identity management. We have an API for identity management called Open Authentication. We think it's pretty robust. It integrates with OpenID [single sign-on technology], but it's not built into any of the frameworks. It doesn't work with a profile model that's accepted in Ajax. We don't have a framework for doing that. The same for communications. We have a great Web-based instant messaging platform, which we're extending into a Web-based data caching platform, but at the same time you still have to pick it up and put it together. The building blocks are still fairly rough and raw. We'd like to build out an environment in conjunction with people at Dojo and Prototype and where you can just rely on these service being that and you can just work on what your application is really supposed to do without worrying about storage or identity or how to pass data back and forth. That's really what Dojo and these other frameworks have done on the client side, but making them work with a range of backend services from ourselves and others, we think that's the next stage. Is that what you see as the next step in Ajax maturity?
One of the reasons why that's so important is that it's not just about building new Web apps anymore. That same model is being used for widgets for the desktop and in aggregation environments like Google. It's the open environment for the Nintendo Wii. It's the only open environment for mobile whether that's a pocket IE or the or the Nokia S60 Series or the Apple iPhone. Once you get to the point where Ajax is a first class development environment for these platforms, all of a sudden you have a community that's going to start wanting these backend tools combined with security, combined with metrics, combined with a measurement system that is built in so that people can get analytics on their apps. That was my theme. It's really everywhere. We've come a long way. We at AOL struggled through a lot of the same problems that every developer struggles through in this space, but at the end of the day there's still a lot of work that we have to do, and a lot of opportunity in the space.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.