Tuesday, May 3rd, 2005

Ajax Engine: Defining Abstraction Levels

Category: .NET, Ajax, Java, JavaScript, Ruby, XmlHttpRequest

Currently, Ben and I get asked:

Ok, I am sold on this Ajax thing. So, how do I do it?

There is no great answer out there. The problem is that currently Ajax is an architecture, not a technology!.

This means that to help people out we point them too something like:

  • .NET: Check out ASP.NET 2.0 (Whidbey) as it has good Ajaxian components
  • Java #1: Check out DWR for the remoting tie in piece
  • Java #2: Check out dojo.io.bind()
  • Java #3: Look at frameworks such as Tapestry, WebWork and JSF for their Ajaxian components
  • Ruby: Rails
  • General: learn the first principles (JavaScript, XmlHttpRequest, DOM)

I think that the community needs to come together a little more, and define the abstraction levels, and have areas of interop. It would be great to plug and play different pieces in the architecture chain.

Here is one view of an Ajax Engine:

Ajax Engine Levels of Abstraction

Components exposed by Web Frameworks (Rails, Tapestry, WebWork, ASP.NET, …)
UI Toolkit (Dojo, SmartClient, Backbase, …)
Remoting Toolkit (DWR, JSON-RPC, dojo.io.bind())
XHR iframes

It is going to be an interesting year as varied communities come together:

  • Old School JavaScript guys (who have been doing this forever)
  • Web Framework guys (who are looking at building on top of the JS)

Posted by Dion Almaer at 10:36 am
2 Comments

+++--
3.1 rating from 8 votes

2 Comments »

Comments feed

It is a very good idea to define the layers. I know many people will not want to muck around in the Javascript. And many will simply work with JSF or ASP.NET controls which abstract it all away anyway.

With respect to the Javascript level, there should be a basic API to create a remote request and the layer below it should abstract it away to handle the various browser releases and workarounds. I have built some of this for myself in a very basic way but others have done much to make it even more brain dead simple. (ie Dojo)

I also feel there is going to be a bit of re-education required for programmers and designers in terms of interface design. I hope to be putting together some conceptual work soon to illustrate this better. But essentially it comes down to the fact that we can use rich client behavior now and do not need to be bound to the form “submit to server” and wait mentality anymore. In fact, we may simply do away with the submit button in some cases.

Comment by Brennan Stehling — May 3, 2005

I realize your focus is perhaps more architectural or developmental, but I’d like to submit that Ajax is also a *methodology*, or at least increasingly will become an interaction design methodology. There are important implications for both technology architectures as well as interaction architectures once Ajax is identified as a viable engine/architecture/approach for a particular project.

Comment by tim — May 3, 2005

Leave a comment

You must be logged in to post a comment.