Tuesday, September 27th, 2005

What’s Wrong With Ajax?

Category: Articles, Editorial

<>p>Dan Grossman, the VC that brought us Top 10 Ajax Apps, has now told us what is wrong with Ajax.

He has brought out the old chestnuts:

First Problem: User Interface Issues

  • The back, stop, and refresh buttons don’t always work.
  • Since Ajax applications generate pages dynamically, there generally aren’t static links available for bookmarking or sharing with others.
  • Pages don’t always print well.
  • Applications don’t run offline.
  • Clicks and actions generally don’t get included into a browser’s history table.

We need to be aware of issues like this, but we have fixes for many of these already, and more are coming.

Second Problem: Ajax requiring JavaScript and ActiveX on IE

Sure, sure. Is that such a huge issue these days? And IE 7 will have native support for XHR at least.

If we keep coming up with quality Ajax applications, then that will be the reason to have JavaScript turned on!

Third Problem: perceived application performance

It is easy to make something slow, or seem slow. However, you only need to play with Yahoo! Mail beta to see how a fully functional app runs like a charm. So, we can do it, and it will only get better for us!

There are definitely issues, and there are MANY things that we all wish we had. But, none of these should scare us.

It is interesting to read Desktop Ajax as Desktop.com Returned where Paul says:

What I really want from Ajax apps is for them to do stuff that it’s too hard to do with binary apps. I want them to be sensibly integrated with online resources; I want them to support realtime collaboration. I want them to do different stuff from Word/Excel/Powerpoint, not just do the same thing with a different engine under the hood.

We need to find our way with Ajax applications. Let’s not just port over to the web way, with a poorer version due to the limitations. Rather we need to embrace the differences and do as Paul says. Do things that suit the web better.

Related Content:

Posted by Dion Almaer at 9:28 am
12 Comments

++---
2.8 rating from 10 votes

12 Comments »

Comments feed

these are nitpicks – the larger glaring issue is how immature and toy-like the entire ajax stack is compared to traditional appliction development. if this is how we are really going to do application development (and it looks like it is), some major architectural strides need to happen:

1. language independence. you can’t tell me with a straight face that javascript is the application development languae of the future. we need an ABI that takes supported languages in client-side documents and compiles them at render-time into a supported object/binary format. meaning it should be as easy for me to do client side coding in ruby or javascript, and the user should not know or care as long as ruby is also supported by the browser. does this mean “really fat” clients? perhaps, but browsers are already fat and i am willing to accept a couple more MB in download to develop apps in a real language.

2. state. state modelling in browsers is confusing and application dependent.

3. developer tools. compare visual c++ to the javascript debugging console and tell me if you think ajax developer tools need improvement.

4. binary transmission standards. json is just a hack attempt at a condensed ascii transmission standard and it should be scrapped in favor of a true binary standard.

5. client side caching and recovery model tied to applications.

6. get more REAL developers involved, SYSTEMS engineers. i like the ALA type guys too, but these designer types have never done hardcore development and they aren’t the kind to push out hardcore development tools.

etc etc etc

long way to go folks if you really want browser apps to replace dekstop apps

Comment by grumpY! — September 27, 2005

I want to comment on the “perceived application performance” problem in the original post.

I used to work for a company that pioneered ajax infrastructure in ’99, back when ajax was a brand of soap (not SOAP:-). I conducted a study comparing a Web application using an asynchronous interaction pattern (made possible by ajax) vs. the same application where the interaction was synchronous. Both versions of the app allowed a user to initiate a transaction that was submitted to a back-end process that would take some amount of time to complete its work before providing a response. Both versions took the same amount of time to perform the back-end process. The synchronous version made the user wait until the process was complete before allowing the next transaction to be initiated, while the asynchronous version returned immediately and updated the UI when the work was done. The total time to complete 5 transacations was identical.

When subjects were asked questions about each version’s performance, they overwhelming thought the asynchronous version was faster. Interestingly enough, they also thought it was more robust and reliable, even though that wasn’t demonstrable in the test.

Bottom line, the type of interaction style afforded by ajax solutions can lead to the perception of increased performance. I agree that interpreted code runs more slowly than compiled code, so obviously there are certain types of applications that would not be performant when run in the browser. But for distributed applications requiring collaboration between nodes, ajax-enabled web apps can prove to be compelling *and* performant.

Comment by Dave Rowley — September 27, 2005

I agree with many of grumpY!’s comments, but there are solutions to most of his issues if you don’t take AJAX too literally: replace “JavaScript” by “Java” and you get industrial strength solutions, a real programming language, real programming tools, etc.

Check out the following article that explains:
http://www.developer.com/design/article.php/10925_3526681_3

Comment by Marc Domenig — September 28, 2005

AJAX, like Flash, appears to suffer from the same state-awareness issues. A limited, but insightful article on the cost of usable Flash written by Kevin Airgid talks the the efforts (and cash) required for proper implementation of Flash.

http://www.flash99good.com/?p=77

Read the article and mentally replace the word Flash with AJAX.

Comment by Benjamin Long — September 28, 2005

Benjamin – flash is outside of the DOM so it is not a viable alternative

Marc – client side Java died many years back, it is never coming back. it also breaks the DOM, and on another level, MS will never play nice with it, and even many linux distributions won’t touch it since the jvm is not “free as in speech”, so you are really looking at a fringe audience of people willing to run applets at this point (and from what i can tell from the artcile – yes i did RTFA, this is applets redux).

as an aside -why does this site require me to enter a (fake) email address before i post?

Comment by grumpY! — September 28, 2005

grumpY: The DOM isn’t sacred. In fact, the DOM isn’t all that great. What’s needed is a better way to deliver applications to the client. The browser makes it easier for IT deparments, but it’s worse for developers and end-users. Reducing the complexity of web development and improving the interativity should be the most important goal. DOM be damned!

Comment by Peter Eddy — September 28, 2005

I agree that AJAX does have some shortcomings, but I believe the advantages far outweight them. I have been developing web applications for years and I believe:

1. AJAX helps tremendously when it comes to server/client data transfer amounts/times. Capturing FORM data and only sending the changes to the server, with a quick response to invalid/missing data is a lifesaver.

2. Not having to reload pages from the server after processing is a huge plus. Being able to communicate with the server “behind the scenes” make the app much more responsive.

3. Most of my projects are “web applications”, not simple public web pages. AJAX is perfect for these types of applications since they are windowed and thus don’t suffer from the “back button breaking” problems and bookmarking issues.

4. There are “middleground” methods that employ similar methods of AJAX to achieve a more responsive app. One way to do this is with hidden (or 0 width/height) IFRAMEs that can be used to send commands and receive data from the server asynchronously. I have used this method on several successful projects with very impressive results. Plus with IFRAMEs there is no need to worry about ActiveX being enabled on a particular IE browser.

5. My web applications employ a custom printing system that is in its own IFRAME or window, so AJAX doesn’t interfere with printing.

A great example of a commercial AJAX application is the Weight Watchers online version. That application is very responsive and doesn’t seem to suffer from any performance issues.

Comment by m2pc — September 29, 2005

Thanks for sounding some sanity on the Ajax Buzz / Bandwagon.

For the first time in 5 years we’re going to be seeing some rapid evolution in the Browser space – whether it will lead to a richer set of widgets than HTML (like XUL or XHTML), or ActiveX Mark 2 (Ajax features locked down in the browser for real or imagined security reasons) remains to be seen.

The ’5 years ago’ comment is also relevant to the state of the Ajax frameworks. 5 years ago everybody coded at a relatively low level (JSP / ASP etc) where they needed to be very aware of the underlying technologies. Ajax is at a similar point. From the point of view of maintainability , I’m hoping that the frameworks (such as DWR, Java Server Faces, Ruby on Rails) evolve quickly. Visual Basic for Ajax giving Drag and drop design anyone?

Comment by Paul Browne — October 7, 2005

you might be intested in the new XML processing model
http://vtd-xml.sf.net

Process SOAP with VTD-XML @ XML JOURNAL

http://xml.sys-con.com/read/48764.htm

Comment by jimmy zhang — October 13, 2005

Ajax is definately the new face of websites. I think the issue that it will face from a website ownership point of view will be way more maintainance, difficult to troubleshoot.

Like with other new technologies, implementations by strong teams will be much more stable. Many applications will be very flaky, and perhaps will be rebuilt using matured frameworks.

Overall, Ajax is here to stay…

http://theyogi.blogspot.com

Comment by Yogi — October 20, 2005

The AJAX hypo is far reached,

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/IETechCol/dnwebgen/ie_leak_patterns.asp

http://codeproject.com/useritems/LeakPatterns.asp

One has really to think about using JavaScript for non-trivial stuff.

Comment by peter — November 14, 2005

Ajax plays very important role for data transaction between server/client. It always does good if managed well.

Comment by Mattg — January 15, 2007

Leave a comment

You must be logged in to post a comment.