Bill Higgins asked for some eyeballs. Not sure I can provide any, but its potentially quite an interesting discussion over at Billy Newport’s blog.
I think it’s becoming clear now that AJAX enabled applications generate a higher load on an application server than a non AJAX application. I guess customers will have to size their boxes appropriately as a result.
I tend to agree with Boris Kuschel that the claim is unsubstantiated. I bet the folks at Zimbra have some good insights because their platform is both AJAXy and enterprisey. Scott – what’s the score? Some IBMers want to know. So do I actually.
Its worth pointing out that in a blog post, Scaling Up Zimbra, Scott doesn’t mention the effect Billy suggests. Another anti-evidence: gmail.
So we need to:
1. Establish whether AJAX methods do actually significantly increase server load
2. Work out what the implications are.
Mark Baker says:
April 19, 2006 at 11:47 pm
Zimbra’s *so* not enterprisey dude! Don’t go diluting the meme by associating it with useful software now! 😯 😎
Bill Higgins says:
April 20, 2006 at 3:08 am
thank you.
Fraxas says:
April 20, 2006 at 2:09 pm
Considering that one of the advantages of Ajaxy web apps is that they do *more* processing on the client side, I find this claim hard to believe on its face. Of course, it’s as possible to create Bad and Wrong and piggish Ajax webapps as it is to create traditional ones; there’s also the issue that there are some things that an Ajax app can do that a traditional one just can’t — and perhaps server backends perform poorly on that new class of activities?
John Dowdell says:
April 20, 2006 at 4:27 pm
People have been dealing with refreshes of less-than-fullpage-HTML for years. I don’t have links to good metrics offhand, but the biggest no-no seems to be polling back to the server too frequently, so that when the audience swells the server gets too many requests too quickly. Profiling your server load should reveal the key bottleneck in each different case.
Media servers have studied this area more than HTTP servers, but even with simple text transfers via XmlHttpRequest you have to think how the design will affect the eventual server load, particularly as the audience scales up.
jd/adobe
James Governor says:
April 21, 2006 at 1:39 pm
thanks guys! Fraxas – good design needed? whatever next.
Brilliant commentary from John too. Media servers as an analog – that’s very useful… in terms of precedent. and i guess given you’re at Macromedia you’re speaking from experience. again – good design matters for scalability.
and talking of architecture and design – that is why Zimbra *is* enterprisey. it was built with high scale in mind. the server basically runs on JEE man- http://www.zimbra.com/pdf/Zimbra%20Architectural%20Overview.pdf
Alexei White says:
April 21, 2006 at 6:57 pm
It’s an interesting tradeoff.. because some research has shown that Ajax drastically reduces total bandwidth requirements, but does increase the number of requests.. (http://www.developer.com/xml/article.php/3554271)
Anecdotally I can tell you than in situations where app servers are under extreme stress (like in an unnamed DND client), ajax was the only solution that offered real overall performance improvements.
Bogdan Nedelcu says:
April 24, 2006 at 1:28 pm
I’m not confident Ajax will have a big future. We all know Ajax has been there for 4 to 5 years ago from the technological point of view. I participeted in the development of a Ajax type of application a couple of years ago and we had to deal with some issues:
1.JavaScript is a pain when you write cross browser code – we decided to code only for IE
2.JavaScript in IE is slow, very slow if you try do perform complex operations on the client. Back then the computers weren’t so powerfull so performance was not so spectacular
3.JavaScript in IE crashes the browser from time to time.
4.JavaScript is difficult to write clean code and debug problems
5.Ajax style pages are not compatible with the “back/forward” button of the browser which people are so used to.
6.IE is not a platform for desktop-based applications, it was not designed for that and will not be changed in the near future.
7.Ajax based application have much more network calls than normal ones.
I am not so confident that enterprise application could be based on the Ajax technology as a framework. For sure there will be some gadgets which will mke life easyer but only locally, not as a general concept.
Let’s take a look at Yahoo beta, a wonderfull UI, close to what desktop Outlook has, but difficult to work with. It sees slower than the original one, the scrolling in the message list is very difficult, if you have hundread of messages and slow connection then there’s no chance.
HTML is good at representing information, pages, links but building a serious UI only with HTML has for now I think is not a good solution. HTML is not for UI, it is for presentation.
Mozilla XUL, XAML or other markup languages are more close to what a UI should look like, but there is no standard for these ones so we’ll wait some time before we can use one as a general purpose UI language.
Ajax is cool for now, but the need for a standard UI language is still open.
Bill Scott says:
April 28, 2006 at 7:12 pm
First, Ajax was not “really there” for 4-5 yrs. Its actually been in existence for 8 years (1998 it was introduced in IE 5). But the key is it was not across all of the modern browsers.
And sure there were a number of remote scripting techniques. I was using them as early as 2001 when I first started moving to the web from the desktop.
So in answer to the list:
1. Yep. That is the purpose of Ajax toolkits. Nope. It’s not there yet but now that Yahoo!, Google, Microsoft, and everybody else is really serious about this type of development expect changes. I know in our talks with the IE team and with Mozilla they really get the need to play nice together. If that were the only change Ajax brought it would be worth its weight in gold. And I personally know how serious Yahoo! is about this stuff and it is obvious Google is as well.
2. Yep. What’s great is that we can be smart. Right now DHTML/Ajax is not the choice for doing finance charts, complex graphics. But we can easily mix in flash components into a DHTML page (google finance is an example). Very snappy, yet all of the rest of the data is easy to make accessible, internationalized and the page is not very complex.
3. Sure there are things you can do to crash the browser. I hope IE7 is better. But really, I run lots and lots of Ajax apps and do crazy stuff and this event happens very infrequently. That however does not argue against DHTML/Ajax just the need to improve the platform. Believe me Redmond understands where the money is to be made. They are serious about getting their act together. Maybe IE7 will be rough, but I gotta think they care. Remember the IE 6 team was disbanded a few years ago. They thought the browser war was over. This caught them off guard.
4. Agree. Yep. Couldn’t agree more. However, with environments like Ruby on Rails the abstraction gets better. Lots of folks are working on debugging tools. There are new tools just in the last few months (like Firebug for CSS debugging and soon JS debugging) as well as the Eclipse initiative (ATF) that will make debugging more like debugging in Java. Look this is the same complaint I heard back when I first started using Java (when it came out). I heard it when C++ came out especially when we added templates and other crap. It takes good design & development skills to write good apps. Is it harder in JS? Yes. But look if people are developing in this stuff people will feel the pain and there will be folks who work really, really hard to be the savior and reduce the pain.
5. Back button issue. Ok, so if you have a content site, don’t use Ajax for browsing content for God’s sake. The user will be confused about the back button. You are breaking their model. But as you move along the continuum to a full app our design research at Yahoo! has shown over and over that users don’t rely on the back button in those kind of applications. They forget they are in a browser. The hard part is the hybrid apps. But the good news is that it is possible to fix the back button issue. And toolkits are working hard to make this transparent. Dojo is doing this. And we at Yahoo! are hard at work on better solutions. Backbase also has a solution and we have one in our Yahoo! Maps Beta (flash version; same problem)
6. Here you are completely wrong. We have met with the Microsoft Atlas team and they are dead-serious about making an incredible platform for web development for IE, Mozilla, Safari and Opera. They understand that the web delivery model is a very inexpensive delivery model for software. THey understand that revenues can be generated for applications in other than the traditional standard purchase revenue model. So Microsoft is not playing around. They are putting serious efforts into making sure the browser will become more powerful. It is a huge part of their revenue strategy. Follow the money.
7. That is such a general statement I don’t hardly know where to begin. Any client/server model can become chatty. Any client/server architecture can be stupid. You can choose to cache on the client and save work at commit points or strategic moments. There are ways to have local storage (Dojo is working on solving this; you can use invisible flash on the page to store local data in an app with the user’s permission) alleviating the need for frequent writes. Just because I have the capability to send micro bursts of information does not mean I need to do it all day. So at Yahoo! we have found some properties bring down server usage. Others bring it way up. In some cases it requires a lot more servers but we (in those cases) feel it is justified from a business perspective. Look at digg.com. Clicking the digg button to post a digg only has to send very minimal information. Contrast that with a post (about same info) but then a refresh back from the server to re-render the page. Now more people will do it; but hey guess what, that translates into being able to get more advertisers or more people to click on your ad words.
On the point about HTML not being great for UI. Yep, we all agree. But look its about ubiquity. The best tools do not win. Most often we are stuck with things that are more dumbed down that get wide acceptance. I mean look how simple REST interfaces are vs. SOAP. But REST is clearly starting to take off in a huge way. The classic VHS vs. BetaMax. Which was better? Which won?
Realize that there is a ton of inventory on the web in the form of HTML pages. There are a lot of web developers. Being able to incrementally add Ajax to a page and get a better more responsive UI (like digg.com did with the digg button– result traffic went up by orders of magnitude in a few days).
I recall back in 1990 when I was charged with deciding between Objective C and C++. There was no doubt in my mind that Objective C was a better language from a developer’s perspective. There were issues with performance but I knew that would eventually be overcome. However, I had to ask (and it was not clear then) who has the likelihood to succeed. The answer. Incremental change is always easier than revolutionary change if economic models are in control (see big oil & alternative fuels for another example). So I cast my lot with C++.
The landscape for the next 5 years is clearly DHTML/Ajax + Flash + Flex (Rich apps on a spectrum from content + Ajax to full fledge rich apps). This is a scrappy community and we tend to pull together what works. The challenge will be to bring in the best Computer Science practices into the wild west of web development (the good news is a lot of seasoned individuals have spilled over into the web community and helping the industry grow up.)
What that “Ajax” programming will look like is up to us. Better tools, better abstractions, better development skills, better design techniques, etc. This is where I choose to put my energy.