Ajax seminar in NYC notes

On Monday March 13th two colleagues of mine, Glenn and Christian attended an Ajax Seminar in NYC. They wrote up some notes with their impressions:

Some background: Ajax is not really a new technology. Instead, it's a collection of older technologies (late 90s-early 00s - JavaScript, CSS, DHTML, XML, etc) that are being combined together in a new way -- to produce an "asynchronous" browsing experience.

Put simply, the end result of using these technologies in the Ajax-fashion is that users can interact with a web page, and that web page can update small sections of itself without doing a full "browser refresh".

This was the first conference focused on Ajax, and there was an air of skepticism mixed with excitement. The range of presenters was diverse, discussing high-level UI design, detailed UI design, and a number of different technical approaches (some contradicting each-other).

___


The vibe from a User Experience perspective was that this technology allows technical capabilities on par with Flash/Flex, in terms of immediate responses, page activity occurring in the background, slick use of visual effects, transitions, etc.

One constant was the caution of not using Ajax just for the sake of it -- focus it primarily on high-interactivity areas.

The following presentations focused on the User Experience:


* Jesse James Garrett (Adaptive Path) coined the acronym AJAX ("Asynchronous Java and XML") to come up with a vocabulary word to encapsulate this combination and usage of technologies.

Jesse spoke on how Ajax changes the classic request-response web paradigm into one of constant, multi-threaded, asynchronous interaction, which opens new doors in terms of how users can interact with the web.

His original essay on Ajax is along the same lines.


* Bill Scott (Yahoo) spoke at length about UI patterns, which "describe an optimal solution to a common problem within a specific context".

He showed us Yahoo's new UE design pattern library, which attempts to concisely describe UI patterns such as:

- Auto-Complete
- Breadcrumbs
- Drag and Drop Modules
- Navigation Tabs
- Pagination
- Ratings

These are very detailed, and I'd think would be of interest to both UEs and Engineers in terms of functional requirements -- look here for an example.

Bill's blog can be found at http://looksgoodworkswell.blogspot.com/ .

___

Most of the other presentations were more technically-focused.

In the technical Ajax community, there an interesting divergence in opinion regarding what exactly should come across the XMLHTTPRequest pipe -- Model data, or View data.


* Kevin Hakman (TIBCO/General Interface/Perficient) gave us a sales pitch that described TIBCO's "General Interface" offering. This software allows users to visually construct a user interface which is ultimately rendered as a very fat JavaScript client.

They advocate using the request pipe purely to transact XML model data, and to build the entire MVC framework in JavaScript in the Web Browser.


* David Heinemeier Hansson (37signals), the creator of Ruby on Rails (!!!), begged to differ -- his approach of using Ruby on Rails with Prototype (a browser abstractor) and Scriptaculous (a DHTML scripting library) results in the web browser acting more or less like a frame-set and tile-set, with the server passing exclusively HTML snippets over the pipe.

David's approach has a number of advantages (lightweight client, memory leak avoidance, lower latency, generally improved performance, security, architectural elegance, etc.), but particularly interesting was that his demo would automatically function in a basic (fallback) mode if JavaScript is disabled. This would be tremendously important for sites that must adhere to accessibility standards.


* Rob Gonda, Editor-in-Chief of AJAX Developer's Journal and CTO of iChameleon, gave a rather dry presentation that essentially agreed with David's approach (transmit the View, not the Model) for other reasons -- specifically, security. Rob discussed a number of ways to address security concerns with Ajax technologies.


Our takeaway from this Model vs. View topic was that the Hansson/Gonda approach of sending only HTML View data over the XMLHTTPRequest should be used unless your client has specific needs necessitating an extremely heavyweight client.


Most of the rest of the presentations were sales-oriented, including:

* Christophe Coenraets (Adobe) showing how Flex can extend Ajax. The highlights were:

1.) Flex server is now free
2.) Using Flash/Flex events/sockets to send binary data around is useful (i.e. browser-to-browser streaming webcam video, for example for a CSR app)
3.) Using Flash/Flex events/sockets to PUSH data to the client is powerful

A particularly cool demo showed how one user's browser action could instantaneously affect the screen of another user. (David Hansson followed up on this and showed it working in conjunction with Rails). PUSH technology is coming back!


A number of presenters discussed Ajax toolkits / frameworks - there's a ton of competition for this space, and no real leaders as of yet (except Atlas for .NET)

* Sahil Malik showed telerik's R.A.D. Controls module, which essentially allows you to easily change .NET Postbacks into AJAX Callbacks, preserving the ViewState and all that. Interesting for .NET AJAX developers (not sure how it plays with Atlas)


* Scott Dietzen (Zimbra, formerly an exec at BEA) tried to sell us on Zimbra's "open source server and client technology for next-generation enterprise messaging and collaboration" (which uses Ajax heavily).


* Ross Dargahi (IBM) talked a bit about IBM Alphaworks (Apache)'s Ajax toolkit options, including Eclipse ATF (Ajax Toolkit Framework) proposal and Apache Kabuki (http://wiki.apache.org/incubator/KabukiProposal).

Seems like neither of these are officially out yet, but they were showing demos so I bet the alphas/betas are available.


* Jouk Pleiter (Backbase) talked about his company's toolkit / framework - http://www.backbase.com/ .

___

Some other quick tech takeaways:

* JavaScript is bad - use other technologies to abstract yourself from it

* You can never fully abstract yourself from JavaScript -- you will have to write some.

* Browsers were not meant to be Ajax platforms. Memory leaks are a real problem, especially in IE.

* Everyone grudgingly respected Microsoft's Atlas Ajax toolkit.

* Testing Ajax (unit or performance) is hard. No software framework has emerged as a leader yet.



Overall, the seminar was very exciting. It seem inevitable that Ajax will work its way into the web and our work at Molecular, once our clients start losing ground to their more innovative competitors.

It definitely opens up new doors for what can be done on the web -- it will be interesting to see what people can dream up.

I don't necessarily agree with the

JavaScript is bad

quote but it's just another way of saying: use frameworks as much as possible!

Technorati tags: Ajax Seminar, ajax, JavaScript