John Reynolds's Blog

AJaX: Two steps forward... Two steps back?

Like Ed, I've been intrigued by the promise of AJaX, but when I consider it in a wider context I'm a bit concerned.

The basic message of AJaX is that modern browsers, through a combination of JavaScript and XmlHttpRequest, provide an advanced client that allows you to write rich client interfaces without the need to deploy a plugin.

So far so good, but when you look at the mechanisms that are currently available to take advantage of AJaX, a boatload of JavaScript embedded in an HTML file, you will probably experience a sickening feeling of deja vu all over again.

AJaX totally blows the idea of seperating presentation markup and code snippets. The result brings back memories of pre-custom tag JSP pages... a little puddle of HTML markup embedded in an ocean of Java code (only this time it's JavaScript).

The promise of AJaX is exciting, but until tools and frameworks automate the generating of "AJaX" we're back to some pretty ugly and potentially buggy UI code.

I'm still excited, but It's going to be awhile before we really develop "best practices" for using XmlHTTPRequest properly.

Comments

• "AJaX totally blows the idea of seperating (sic) presentation markup and code snippets."
  
  Which is a Bad Thing only if you slavishly adhere to an overly-strict interpretation of MVC -- i.e., one that utterly forbids any code of any kind on the page. But reasonable people can agree that some code on the page serves as a kind of "syntactic sugar", a convenience which, if not abused, makes things easier in a natural way (think iterating over a collection to build a table, or simple conditional display). Yes, we now tend to wrap that code in custom tags and congratulate ourselves at having been able to disguise code as markup, but it still quacks pretty much like a duck.
  
  MVC is not about separating code and markup; it's about separating view logic from controller and model logic. If the code on the page serves the view without mucking with the controller or the model, then it should be allowed.
  
  "The result brings back memories of pre-custom tag JSP pages... a little puddle of HTML markup embedded in an ocean of Java code (only this time it's JavaScript)."
  
  The (crucial) difference being that JavaScript executes on the client side, and does not have access to the full set of Java APIs. This keeps it from being subjected to the same kinds of abuses that early JSP pages exhibited.
  
  I agree with you that the jury is still out, but I think this could end up being a more natural way of expressing a user interface than, say, JSF, which I consider effective but clunky.

  Posted by: davidrupp on March 04, 2005 at 08:38 AM

• In a perfect world you could do all those Ajax JavaScript thingies in Groovy or Jython ...

  Posted by: euroderf on March 04, 2005 at 09:10 AM

• "I agree with you that the jury is still out, but I think this could end up being a more natural way of expressing a user interface than, say, JSF, which I consider effective but clunky. "

  I have a different perspective. I think that AJaX is going to accellerate JSF adoption because the "cleanest" way that I can think of to package AJaX JavaScript is inside a JSF (or Tapestry) component.

  JavaScript bundled in a component alond with the Server-Side event handling makes sense to me.

  Posted by: johnreynolds on March 05, 2005 at 07:59 AM

• IMHO if you get HTML,CSS JS (possibly with DOM and other fancities), and all the client side Java APIs together to build a GUI what you get is a very thick pudding. And I've eaten pudding for so long I won't have one more taste at it. I think the only succesful evolution of web apps into rich clients would be one that meant a complete rupture with the past. But adding a new taste to the pudding won't make a revolution at all.

  Posted by: jordihs on March 07, 2005 at 01:00 AM

• Mmmm....pudding

  Posted by: oravecz on March 25, 2005 at 11:51 AM

• I'm working on a toolkit to build Ajax type applications called XAB. you can find it on my web page "http://www.kessin.com/wiki" its still in an early phase right now, but It can generate working AJAX code right now. I'm working on making it more robust.

  Posted by: zkessin on March 30, 2005 at 11:07 AM

• I could not disagree more. AJaX returns us to the glorious days where the Controller code handled user input LOCALLY, and the View handled rendering graphics LOCALLY. But now the Model is mostly REMOTE. In fact, since the model is mostly remote I think it will help even more to keep your model code properly separate. (Heck it's on a different machine!) Now the developer only has to focus on keeping the Controller separate from View. MVC was originally invented before the internet was popular. It was invented for GUI applications on standalone workstations, way before the three amigos took credit for calling it a "pattern". Controller - the code "handled" user input from the keyboard, mouse, and other (typically serial) input devices View - the code responsible for rendering the graphics Model - the code for handling the data abstraction AJaX is much more aligned with this view of MVC. Just because the current implementations are disappointing, does not mean "AJaX totally blows" anything.

  Posted by: revans on April 08, 2005 at 09:30 PM

• Like alot of other people I'm very excited about using AJAX. I have even put together an AJAX web site with information and sites using AJAX. I look forward to feedback and any suggestions like a best practices section?

  Posted by: digitalsanctum on April 16, 2005 at 01:48 PM

• Put the JavaScript in a .js file and refer to in the HTML.

  <script type="text/javascript" src="../../scripts/calc.js"></script>

  Then you don't have the problem of having all your javascript mingled in the html.

  Posted by: abarrach on April 21, 2005 at 09:36 PM

• What seems to be called for is a more flexible, generic type of application-rendering client and/or a matching protocol update to enable these sorts of things, instead of piles of hacks (albeit clever) upon hacks upon a quirky client (browser) on the impedence mismatch of a protocol that doesn't really conform to the tasks trying to be achieved. Maybe something like a universal XUL, XAML, or Boxely client. At a sufficient level of complexity, it makes more sense to just remote an X or VNC session of a thick client than to tediously perform these sorts of workarounds. How many technologies do I need to be familiar with to create a rich client? HTML + JavaScript + DOM + XML + XML-RPC/REST + (some, perhaps multiple, server side technology) ? It all seems very brittle.

  Posted by: aaronh on April 27, 2005 at 01:52 PM

• There are some frameworks and dev tools that automates the generation of AJAX-enabled pages. For example JackBe. JackBe has a DnD dev tool that easies the development of AJAX interfaces. JackBe also is very concern about performance, so the footprint is really light and gets impresive responsiveness. JackBe is an example of a MVC AJAX solution, for some of the components obeys to this pattern.

  Posted by: gmunoz on May 13, 2005 at 11:23 PM

• As a survivor of the early dHMTL wars I shudder when I think about all the code I've written over the years to accomodate different browser quirks and I don't relish the idea of doing it again for AJAX. The truth is that very little in the JavaScript model is truly standardized and each browser and browser version has a slightly different take on how the language and DOM should be interpreted. If I'm building a web app that requires client-side XML processing I'd rather use Flash's XML handling abilities than write a bunch of AJAX code that may or may not work when the next version of IE, Mozilla, etc. arrives.
  Other reasons I'd use Flash:
  

  • It has a huge market penetration
  • Most user interface elements you can build in HTML can be built in Flash
  • You have the option of using the strongly-typed ActionScript 2 language rather than mushy javascript variables

  One knock against Flash may be that byte-for-byte a Flash XML module may be a somewhat bigger download than the equivalent AJAX code but I doubt it's worth fretting over unless you suspect a large chunk of your user-base will be accessing the application over dial-up.

  Posted by: elbow123 on June 17, 2005 at 09:36 PM

This work is licensed under a Creative Commons License.