Slashdot Mirror
Ajax Sucks Most of the Time
Vo0k writes "It seems that everyone is excited with what AJAX promises, and only few look at what it breaks as well. The article at Usability Views offers a critical view at the new Microsoft technology, pointing out some problems it creates, like breaking bookmarking, making the 'back' button useless, problems with printing, accessiblity and more. The single-sided view from the article provides a good counter-balance for all the craze."
Up front Disclaimer: I realize the article is "just saying no to Ajax" with constraints. My post here is to the objection I think the article states Ajax problems too harshly.
Reading the article it seems to me:
From the article:
Huh? So? Is this unique to only Ajax?
Also from the article:
When an article wants to rant or complain about a technology, an un-cited and broad statement like this is a huge red flag. It doesn't state what the percentages are, it doesn't state the reasons for preferences. In the middle of an article espousing "no Ajax", this is a non-sequitor. Please expand.
I'm having great fun experimenting with AJAX and am getting interesting new approaches for old solutions improving customer and user experiences. I'm not about to walk away from this until a more thorough trial. So far I'm liking what I'm seeing. Yeah, there are glitches to solve, isn't that kind of what we're here for?
The article is about using AJAX on a webpage, but the biggest use of AJAX is on a web application.
Sure, putting ajax on the companies webpage may not be the best idea, but how often are you using bookmarks on gmail (a web application)? And if you want to print from gmail, it shouldn't be a print of the screen, but a specially built printable html page.
I think the article writer was focusing mostly on webpages where AJAX is clearly geared towards the web application developer.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
Its not the technology, its the implementation that causes those errors. You can misuse ANY technology to f things up. Why should this be any different?
ROTFLMAO AJAX is no different than any other programming set of tools. If used correctly it rocks, otherwise it sucks. We use it a lot in our web application and it has provided us the ability to deliver greatly enhanced interactivity and reporting. It's kinda like the blind date that gets overly hyped. The reality will never match the hype even if she was pretty.
"13% of users would not even be able to use a site with ajax. Sure, it is possible in principle to use graceful degradation to serve alternate content to these users, but most designers don't bother designing two versions of their pages and reserve the no script option for a "helpful" link to the download site for an ajax-supporting browser version."
Wouldn't it be nice if Frontpage or Mozilla Composer would allow a plain HTML page to be saved and linked along side one with javascript, flash, and other advanced web designs?
It really annoying too how Tab-clicking at javascript link ends up producing a blank tab in Firefox. That AJAX breaks the Back button is nothing new too. All sorts of sites tell you that you'll be re-submitting data if you press Back on a screen you've just sent information from. That's essentially a broken Back button. And printing a webpage? Good luck if it isn't plain HTML.
Saskboy's blog is good. 9 out of 10 dentists agree.
I was interested in reading the article until I found out it was by Jakob Nielsen. If it were up to that guy the web would be stuck in 1995.
I am a strong proponent of usability and user interface issues, but this guy doesn't even like using different colours for links.
What does interest me is he makes a lot of money by going around telling people this. I want to get in on that action.
The web is used (rightly or wrongly) to deliver two distinct things.
1) Content.
2) Applications.
For (1) ajax _does_ suck most of the time for all the reasons stated, but for (2) is makes sense because it makes the app behave more like a desktop app. "back" and "bookmarks" stop making sense anyway. You wouldn't expect to have those features in your desktop apps, so why in an app delivered over the web.
The great shame is that these two opposing requirements have not forked into the data-web and the application-web. Things went wrong IMO the day someone thought of putting forms in html.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
Nearly all of the problems cited in the article are present to a FAR WORSE extent with fewer workarounds if you write your website so it makes heavy use of Macromedia Flash. That includes problems with bookmarking, back button not working, no printing etc. Yet Flash is used on millions of major websites. As other posters mention, the problem is not with the technology but misuse of the technology.
Some flash developers get what I call "flash happy" and write the entire website in flash. This is lunacy. For a start, (and this is possibly a problem with AJAX heavy sites too) your site cannot be indexed by any search engines if it's navigation is entirely flash based. No search engine in the world is going to evaluate your flash files or run your AJAX scripts in order to attempt to crawl the site. If AJAX is used sparingly where necessary, then I'm pretty sure it won't cause any major problems. It's not like Flash seems to have suffered...
For what it's worth, the original was completely correct, and frames (mostly) died a quick death. Almost nobody uses them in new development anymore.
aye, and frames do suck most of the time, for the reasons specified. I am continually annoyed by those things. So I assume we're supposed to sit back and chuckle that "them naysayers are just like the luddites who said frames were bad". Frames still stuck, most of the time, even with a decade of workarounds to fix the broken functionality.
"If you read the bottom of the article, you'll notice that it's a spoof and a simple rewrite about why frame suck most of the time."
It's interesting to note that while the article is apparently a spoof, many of the objections still apply. (Sure, this is way over-generallzing, but work with me here for a minute.) Also, note how frames went through a period where everybody used them, then use gradually taper off. I think people realized that much of the time, frames just got in the way and the "old ways" worked just as well, if not better.
It does seem like the computer world loves to make the same mistakes over and over and over and over again. We keep doing it. (ObRef to The Mythical Man-Month by Fred Brooks.) What's that about not learning history?
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Flash can't be bookmarked either, probably the most annoying feature behind pure flash websites that puts me off.
The main problem is people want to be able to serve miniature applications via the web, whilst even with new standards it's still about providing glorified word documents with a smarter navigation.
Nothing costs nothing
Isnt this the EXACT same reason we are told not to use frames? I think the problem isn't AJAX and FRAMES, but that we all need to evolve past the "You are looking at a flat page" ideology. Maybe look at it from the point of view of 'bookmarks', 'back button', 'Printing', and 'Accessibility', were all there with the 1.0 browsers 12+ years ago. HTTP has evolved. HTML has evolved. The whole idea of what the web is has evolved. Why do we insist on keeping the webpage paradigm the same? It simply doesn't make sense.
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
-- quoted from http://developer.mozilla.org/en/docs/AJAX
In otherwords the technology is not new and isn't a Microsoft Technology. Although to give them due credit they did invent the XMLHttpRequest object which makes AJAX possible.
Personaly I think the article is nothing more a than an annoying rant. Every technology has it's weeknesses and it's strengths. And just as you should do with any technology you must weigh up the pros and the cons of using it for your specific goal before you do. Saying something is trash and that it should not be used at all for anything is down right stupid.
The big problem is that, unlike books, the Web is digital and dynamic -- what you read at a given URL today can be moved, edited, deleted, or p0wned by the time you get there tomorrow.
Sure, it can be moved -- but that doesn't mean it should be. Keeping a page at a particular location makes it much easier for people to find it, whether via search engines, their own bookmarks, links on other sites, etc.
This doesn't mean it can't change. Linking to, say, a product page on Amazon is extremely useful. You can expect the price, reviews, recommendations, etc. to change over time, but you should expect the same product to be there the following year as long as they still sell it.
And yes, we've had all of this from day one - months before google maps. Admitted, many AJAX apps still dont bother to do any of this - I'd say let's adress that instead of abandoning AJAX.
Yeah, we got CSS allowing us to use absolute positioning, and iframes allowing us to have floating frames. Consequently, there are few times when you would want to use frames any more...
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
My first clue that something was wrong with this was in the article summary... since when is AJAX considered a "Microsoft technology" ? If there's a defining AJAX app, isn't it Google Maps ? Is there some Microsoft AJAX app or developer kit I should be aware of ?
I'm going to have to disagree with something you've said, though :
we all need to evolve past the "You are looking at a flat page" ideology.
Why ? Flat pages are very useful for documents. Hyperlinks are great for linking documents. "Plain old web pages" remain, IMHO, the most useful aspect of this thing we now call "the web"... cool apps like Google Maps are cool and all, but they'd be just as cool ( probably cooler ) outside of a browser. Requiring a high-speed connection and robust ( or even particular ) Javascript implementation on the client side just to view your web page is what doesn't make sense, at least to me.
Then again, maybe I'm just getting old, but back in the day, we just had static web pages and forms, and we liked it!
Copying another response...
IFrame refresh hacks are not "asynchronous" because the user can see them happening, just by watching the browser load icon.
They also break the back button even worse than Ajax. With Ajax at least the back button takes you back a page, if you are doing iframe nonsense and do not know what you are doing (ie, using location = instead of location.replace) it frequently just moves the iframe back a page, resulting in it doing nothing, or worse, sending/retrieving duplicate data.
IFrame refresh hacks are not "asynchronous" because the user can see them happening, just by watching the browser load icon.
That's not quite what being asynchronous means. Asynchronous means not sitting idly by waiting for a (remote procedure/http) call to finish. For example; while you're loading one thing, you might be sorting a table of data (even if the javascript isn't even on the page, check out the handy sort table bookmarklet).
It's OK for the user to know things are going on in the background; for example, when you press the Print button in Microsoft Word, it doesn't make you wait for the print job to finish, it continues in the background. You won't get your hardcopies any sooner (so you might still have to wait for that job to finish to do the next thing you have to do), but the program isn't stuck waiting for the call to finish.
The Gmail interface is actually not such a good example of asynchronisity. It makes you wait while it's sending mail, for example..
An (I)frame refresh hack might be slightly more visible, but if you can still use the application (i.e. its javascript functionality), it's still asynchronous.
SCO employee? Check out the bounty
The problem with AJAX and many new technology paradigms is the early adopters who implement it "just because."
If you save AJAX for the projects that will actually benefit from it you will benefit from it much more, instead of annoying your end users.
AJAX is for on-line applications, using it everywhere is not a good idea.
Example of poor use:
A site that uses AJAX for navigation across the entire site. In this situation you now can't bookmark a specific article or piece of text, nor do you necessarily (depending on the site) have the ability to bookmark that particular section.
Example of a good use:
I built an on-line calender for scheduling various events within my organization. Before I added AJAX to the code the entire monthly calender view had to be reloaded on when you click an event to zone in on its details. The old way caused the entire months summary to be reloaded, reparsed, etc just so the end user could see the details for one event. Now that it uses AJAX one can click each event and have the details load almost instantly without regenerating the entire month view.
AJAX is a tool like any other. Like XML before it, all the hype will cause it to be used and abused for all sorts of things for which it is not suitable (remember "We don't need a database, we have XML!"?)
After the hype subsides, AJAX will become just another tool to be used when appropriate and eschewed when not.
As a developer i see myself like any other worker, and I use the tool that works. Depending on the needs and criteria of a certain project, one may need to be versatile. People who stick onto one technolgy are narrow-minded and tend to write "inefficiet code" trying to force a lannguage to do things it was never intended to do. Like i said, there are reasons for it, preference just should not be one of them.