Ajax is a way of doing new things with old technologies.

Can Ajax fit into the Python applications and frameworks ? In this interview, Dave Crane not only talks about Ajax but also about how Ajax can fit into the kind of applications and frameworks we are used to working with today. He also tells us why he feels Ajax has become so popular in such a short time. Dave is the author of "Ajax in Action" and has been working with Ajax technologies for several years. He likes to code in Python, Java, Ruby. According to him Ajax technologies aren’t particularly new or sexy.

Content Team >> Hi Dave. Congratulations on the publication of your book “Ajax In Action”. Could you tell us a little more about yourself and your involvement in Ajax?

Dave Crane >> Hi! Thanks, it’s a real buzz to see the book out there, and getting such a good reception.

I’ve been working with the web for roughly ten years now, and watched JavaScript growing up. My main line of work has always been something else – Perl, Java, etc. – but JavaScript kept creeping into everything that I did. Five years ago, I found myself on a project developing set-top box systems using JavaScript, which gave me my first experience of maintaining a very large JS codebase. Since then, I tended to apply what-we-now-know-as-Ajax style approaches to my web app coding, using a variety of the old hidden iframe tricks and so on.

My second big experience with JavaScript was at SmartStream Technologies, working with a very smart team of J2EE developers on financial applications that were deployed to call centre-like setups in some of the tier-1 banks. Using the web browser to deliver the main application that a user would be pounding away on for eight hours a day was a pretty big challenge, and I have to say that we met it pretty well. Of course, there was a lot of Ajax going on in there.

"The Ajax technologies themselves aren’t particularly new or sexy…"

Other than that, I’m just another computer fanatic who likes tinkering around with these pesky machines. I started writing code on a BBC Micro when I was fourteen, and currently use Linux, Windows and Mac OS X. I’ve contributed bits and pieces to various open source projects over the years, and like to code in Java, Python, Ruby and, of course, JavaScript!

Content Team >> As Ajax is such a new thing and only a handful are sure of what Ajax is all about, could you give us your thoughts on “What is Ajax”?

Dave Crane >> Well, it isn’t a technology. At the risk of sounding a bit fluffy, I’d say it’s a way of doing new things with old technologies. From the programmer’s perspective, everything that we needed to do Ajax has been available for several years, but it’s taken most of us this long to get it. A few brave souls like Brent Ashley, Eric Costello, and the people that I’m now working with at Historic Futures, have been pioneering this approach for some time, but it was never mainstream until recently.

"Ajax is a way of doing new things with old technologies…"

To the coder, Ajax is just a new way of using all the DHTML technologies, such as JavaScript, CSS and the DOM. Because you can get by longer without full-page refreshes, those technologies suddenly become more useful. To the architect and the business-person, it’s more of a challenge, because it ousts some of the user flow control from the presentation tier, and requires a rethink of how the server-side works too.

"Adding asynchronous requests into the mix increases the reach of these technologies…"

To me, that’s the most interesting thing about Ajax. As techies, we tend to get hung up on the Next Big Thing technology-wise (OK, i should speak for myself, I get hung up on these things), and yet with Ajax, the technologies themselves aren’t particularly new or sexy. Rather, it’s the realisation that new things can be done with the old technologies. Simply adding asynchronous requests into the mix increases the reach of these technologies to the ‘sovereign’ applications that users use as their main workhorse for several hours a day. We’re seeing people like 37signals suddenly make sense of the ASP model that’s been talked about for several years and never quite taken off until now. And once you get into the whole Web 2.0 thing of ‘mash-ups’ and published APIs, then the entire business model is changing further still.

Content Team >> In a very short time, Ajax has perhaps become the most popular acronym in software development. What do you think are the reasons? Did you see this coming?

Dave Crane >> No, I didn’t see it coming, much as I’d like to nod my head sagely :-). I think the popularity of Ajax lies in the low barrier to entry. Writing an Ajax app needs nothing more than a text editor and a web browser, although a serious Ajax professional will probably want a whole array of debuggers, IDE’s and DOM Inspectors up their sleeves too – I certainly do.

"The popularity of Ajax lies in the low barrier to entry…"

Web sites can adopt it incrementally, again, making the barrier to entry pretty low.

If you compare Ajax to, say, Java Web Start, then web start wins on sheer power and what you can do with it. But Ajax is good enough for most situations, and it’s ready to run on most people’s computers without installing any client software. Maybe the fact that it uses a scripting language has something to do with it too (I’m a big fan of scripting as much as possible, I got a great productivity boost personally out of jython, for example, when i first picked it up a few years ago.)

"I’m a big fan of scripting as much as possible…"

 Content Team >> Some experts feel that Ajax is stretching HTML and JavaScript too far and that these languages were never meant for developing rich Internet applications and so it’s just not a good match.

Dave Crane >> There’s a line that the mark of a really good invention is that it will end up getting used for purposes that the inventor never could have dreamed of. I forget who it’s attributed to now. I’m all in favour of pushing the envelope of what a web app can do, and I think Ajax is going in the right direction, on the whole.

"It’s possible to make the user experience worse by inappropriate use of Ajax,…"

Sure, it’s possible to make the user experience worse by inappropriate use of Ajax, singing, dancing boxes popping up everywhere. But I’m pleased to see sites like Backpack and Flickr that work not just because they’re using cool new technologies (or is it cool old technologies?), but because they’re marrying that with improved useability, and offering something that people really do find easy to use.

Content Team >> Flash has been delivering powerful and interactive Internet applications for many years. So when is using the tried and tested Flash a better choice than trying to create magic with HTML and JavaScript?

Dave Crane >> For a very graphical application, Flash can do things that the current round of browsers just plain can’t. With Ajax, one is very much tied to the rectangular nature of the DOM elements – look at the hoops that Google Maps jump through to render round-edged speech bubbles with semi-transparent drop shadows, for example. I presume that drawing that sort of thing in Flash would be much easier. ( I’m not that familiar with Flash from a developer standpoint, so please take my reply with a pinch of salt 🙂 ).

"Ajax is there, it works, and it’s good enough. Ajax is ubiquitous…"

Dave Crane at Haddon Hall, England

Again, in most cases, Ajax is there, it works, and it’s good enough. Nobody designing an interactive web-based application platform from scratch would come up with Ajax, it’s evolved organically out of the web browser. Like Microsoft Windows, Ajax has nothing so much in its favour as the fact that it is ubiquitous.

IndicThreads >> Technologies generally don’t sustain if there aren’t good tools and frameworks around them. So what’s the status with Ajax? Does one develop Ajax applications using any text editor or are there any specialized tools we must look at?

Dave Crane >> There is no single Ajax IDE at the moment. Heavyweight development jobs can benefit from some sort of IDE, and I’ve seen people using everything from Eclipse to Dreamweaver to code their Ajax apps. The full toolkit is broader than that, however. There are code debuggers, such as Venkman for Mozilla, the free Microsoft Script Debugger and the Script Editor that ships with Office and/or Visual Studio for IE. There are HTTP debuggers – I’m currently using Fiddler and the Apache TCPMon. There are DOM Inspectors, XSLT tools, and so on. Firefox and Mozilla provide an excellent starting set of dev tools, with the big downside that they can’t help you with IE-specific bugs.

"Ruby on Rails is clearly enjoying much synergy with Ajax…"

As far as frameworks go, there are two types – client-tier frameworks written in JavaScript, and server-tier frameworks written in Java, Ruby, .NET, PHP and whatever else. The situation here has been pretty volatile in the last eight months or so, but I’d put my money on prototype.js (and it’s child Scriptaculous), and maybe Dojo and MochiKit on the client tier. Ruby on Rails is clearly enjoying much synergy with Ajax, and it feels like the Java and .Net worlds are playing catch-up here, but several projects are starting to catch up, both existing frameworks such as Tapestry, MyFaces and Wicket, and new frameworks such as DWR. 2006 is going to be an interesting year.

"In serverside frameworks, I’d put my money on prototype.js (and it’s child Scriptaculous)…"
"Maybe Dojo and MochiKit on the client tier…"

 Content Team >> Interest in Ajax has been especially high in the Java world. How does Ajax fit into Java’s scheme of things?

Dave Crane >> Nobody likes a web framework or twenty more than the java community, of which I’d count myself a member, I hasten to add! On the one hand, Ajax steals some of the thunder from the server-side frameworks. It’s possible to write fairly autonomous clients in JavaScript that just hit the server when they need data, in which case, much of the presentation tier disappears. On the other hand, it’s possible to modify the presentation tier to generate smart-client Ajax code instead of static HTML, in which case the presentation tier framework very definitely still has a job to do. I tend to lean towards the smart-client-and-data architeture, but I’d hesitate to say that that’s universally the right way to go.

"Ajax steals some of the thunder from the server-side frameworks…"

Java is keeping up on both these fronts. On the one hand, there are the afore-mentioned Tapestry, Wicket and JSF efforts underway to Ajaxify the heavyweight presentation tiers, and arguably maintain the lock-in to one’s server technology of choice. On the other hand, Java has been pretty active with web services and the whole SOA space, which plays very nicely with the independent JavaScript client approach. So Ajax and Java look to have a long and happy future together, although Ajax is definitely shifting the balance of power to some extent.

"Ajax and Java look to have a long and happy future together…"

Content Team >> Is Ajax more of a concern for the web designer or for the server side developer? How do you think would the division of work in Ajax project teams work out?

Dave Crane >> Every project is different, but speaking from my experience in a large Ajax J2EE project, everyone is affected to some extent. The designer needs to understand how the interface is generated automatically, and its easy to do this badly, and have the designer and JavaScript coder treading all over each other. There are strategies for separating the client-tier logic from the content, which we cover in the book (I think this is the chapter that was previewed on The Server Side, for those wanting a sneak preview). As far as the server-side teams are concerned, the balance of power between client and server is shifting again, as I mentioned in my previous remarks.

"Balance of power between client and server is shifting…"

Content Team >> Can Ajax applications that have powerful JavaScript running on the client still achieve a clean separation of presentation and logic or does a lot of logic move to the JavaScript on the client side?

Dave Crane >> Yes, it can, but it has to do it differently. In a classic web app, everything important happens on the server, it’s like a mainframe talking to a dumb terminal. To get the benefits from Ajax, it’s necessary to move some of the logic to the client, but in order to be secure, it has to be a partial duplication of the logic that the server tiers do. I wouldn’t trust a site that validated my credit card only using JavaScript, for example. It’d be way too easy to craft HTTP requests in a malicious client program and dupe the server into thinking it was talking to the bona fide Ajax app.

"To get the benefits from Ajax, it’s necessary to move some of the logic from the server to the client…"

Ajax client apps will often contain a lot of JavaScript. I think that, going forward, it’ll be necessary to pay a lot of attention to the design of that code, to provide clean layers within the JavaScript. That’s something that we talk about quite a lot in the book.

Content Team >> Where do you see Ajax going from here?

Dave Crane >> All over the place 🙂 The big server frameworks are picking it up. The new types of smart internet clients are doing clever things with it. It seems to be breathing new life into the ASP business model. I’m intrigued by the various gadget/widget frameworks – Konfabulator, Mac OSX Dashboard, and Vista Gadgets – that seem to be combining elements of Ajax and desktop apps, blurring the boundaries a little bit further. I only wish that I had more time to explore all these avenues, I’ll look forward to seeing what happens in the next year or two in this space.

"Ajax is breathing new life into the ASP business model…"

Content Team >> Thanks Dave for sharing your views on Ajax. Any blog URL / email you would like to share?

Dave Crane >> Thanks for the opportunity to talk. I hope your readers have enjoyed my thoughts, and feel inspired to roll their sleeves up and get coding some interesting Ajax stuff!

My own blog can be found at http://dave.sunwheeltech.com/wordpress/, and my co-author Eric Pascarello keeps his at the JavaRanch (http://radio.javaranch.com/pascarello/ ). Eric puts a tremendous amount of energy into the various Ajax forums and groups on the web, and we’d both be very happy to welcome the readers of IndicThreads to our sites. (Our third co-author, Darren James, doesn’t have a blog as far as I know. Hi, Darren!)

 Republished with kind permission from IndicThreads.com

Related :
>> ZOPE users would love to have a product like ZOAX (ZOPE + AJAX) ! 
>> Is AJAX worth adopting?
>> Will AJAX bring up a different kind of software developer?
>> AJAX is more hype than substance