AJAX & Java: Feature Interview with "AJAX in Action" Coauthor Dave Crane

http://java.sys-con.com/read/167031.htm

Republished with kind permission from IndicThreads.com:
"Ajax technologies aren't particularly new or sexy"

Harshad Oak: 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 (pictured): 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.

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!

Join Dave Crane at the "Real-World AJAX" One-Day Seminar, March 13, 2006
Click Here to Register Today and Save $300!
On-Site Registration Limited To 200 Delegates!

HO: 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”?

DC: 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.

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.

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 realization 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.

HO: 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?

DC: 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, IDEs and DOM Inspectors up their sleeves too – I certainly do.

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.)

HO: 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.

DC: 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 favor of pushing the envelope of what a web app can do, and I think AJAX is going in the right direction, on the whole.

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.

HO: 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?

DC: 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 :-).

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 favor as the fact that it is ubiquitous.

HO: 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?

DC: 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.

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.

HO: Interest in AJAX has been especially high in the Java world. How does AJAX fit into Java's scheme of things?

DC: 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 architecture, but I'd hesitate to say that that's universally the right way to go.

Java is keeping up on both these fronts. On the one hand, there are the aforementioned 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.

HO: 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?

DC: Every project is different, but speaking from my experience in a large AJAX Jave EE 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. 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.

HO: 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?

DC: 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.

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.

HO: Where do you see Ajax going from here?

 

DC: 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.