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."
LordBodak's journal.
AJAX is not a Microsoft-specific technology. My understanding is that Microsoft has an AJAX implementation called Atlas, but that AJAX itself is a set of conceptual ways of blending existing technologies to provide more interactivity to users of web apps.
The AJAX problems with bookmarking and the "back" button are easily solved with some careful scripting.
Here's an LGPL'ed solution: http://www.unfocus.com/Projects/HistoryKeeper/
IIRC, Microsoft did in fact invent the async XML transport functions that underlie much of the "magic" of AJAX, way back in the late 90's.
If you don't know where you are going, you will wind up somewhere else.
It is worth noting this statement at the bottom of the page.
This is a spoof article. Please compare it with the original and you will see how little it has been changed.
That said some of the points are valid, but the article was basically showing how those same things were valid at one point for using frames as well.
"reality has a well-known liberal bias" - Steven Colbert
Read the bottom of the page. The article is a spoof.
More
Ummmmm, I hate to do this - god I hate to do this, but I'm actually going to support MS on this one.
The paradigm of Ajax: "The transfer of XML to a web page in the background so that javascript can load data/initiate actions without loading a new page" was in fact a Microsoft innovation. They shipped it with Internet Explorer 4 and the first packaged MSXML controls.
I was writing applications of this type over 7 years ago targeted at Internet Explorer 4. The latest incarnation of AJAX still uses the MSXML parser on IE Browsers, but extends the support to FireFox and Netscape variants.
Please note, Microsoft did not coin the term AJAX, but they did do it first.
I know I'm going to hell for this.
In fact, they're so non-unique that the HTTP protocol actually specifically points out that method=POST, PUT, and DELETE should not be retried. Also, I can't find the reference, but most browsers won't cache passwords when you go back and then forwards, as a security precaution, and that's basically standard practice. The back button has LONG been broken.
That doesn't mean we should ignore the criticisms of AJAX, but I think the take-home message should more be "be aware that there are these downsides, and web authors should everything they can to minimize those downsides. In some situations, this may mean using a simpler method than AJAX. However, AJAX as a whole is something that is beneficial, rather than harmful."
tell that to Advanced Access. They still have several "new websites" (I use the term VERY loosely) that they develop that use frames.
Correct me if I'm wrong, but didn't Microsoft invent XMLHttpRequest? In which case, most AJAX, which uses XMLHttpRequest, is in fact built on Microsoft technology, and they deserve credit for having a played key role.
If you don't know where you are going, you will wind up somewhere else.
"And if you want to print from gmail, it shouldn't be a print of the screen, but a specially built printable html page."
Funny you should say that, because the W3G specifically designed HTML so that it could be read from screen as well as printed on a printer (and other media like screen readers etc.). Same with CSS really. The whole idea that you should generate a special HTML page goes straight against this policy. I blame the current browsers for not doing a well enough job on printing HTML pages. If they had strictly sticked to HTML standards and recommendations for this, this should not have happened.
As for AJAX: the page *should* be printable as well. Just use the latest DOM and follow CSS guidelines and you should be OK. *IF* both sides implement HTML standards the way they are meant to be. Currently this only works well if you are an inhabitant of Utopia.
Yeah, NOBODY uses frames in development anymore. Thats old news!
What's that? GMail uses hidden iframes? Google Maps uses hidden frames? Yahoo maps? AdSense? Slashdot? Nah, those guys are all small potatoes!
</sarcasm>
Get a clue. Just because you can't see frames, does not mean they are not there. Frames are used all over the freaking place. Nearly every web page you visit has an ad in an iframe in it.
This is the reason that this article, and also the one it spoofed, are both wrong. Not every state of a web page has to be, or should be, bookmarkable. The back button was never meant to be an 'undo' and should not be treated as such. etc etc...
Both frames and Ajax are very useful and powerful in web applications.
http://developer.apple.com/internet/webcontent/xm
AJAX relies on the XMLHttpRequest object to do anything. Without it, there is no AJAX (you could say it puts the A in AJAX). Microsoft invented this object, it has shipped with the MSXML COM object for a long time. They first used it in Outlook Web Access in the late 90s.
.Net is a "Microsoft Technology", even though there is Mono.
AJAX only started to get popular in the media after Adaptive Path coined a stupid buzzword for it, but IE-specific developers had been using it for years. Adaptive Path just stumbled upon it being more sueful because Firefox started also shipping an XMLHttpRequest object.
But Microsoft *did* create it, so it is totally accurate to call it a "Microsoft Technology". Just like SMB networking is a "Microsoft technology", even though there is Samba, and
"Flash" is not an acronym.
Christ, I'm so fucking sick of people thinking any one-syllable technical term, or any technical term of five or fewer letters, is necessarily an acronym. "MAC" (by which people usually mean "Macintosh", not the networking term), "LINUX", etc.
Am I really the only one left who cares about getting these things right?
With spending like this, exactly what are "conservatives" conserving?
I'm not suggesting that you can't print a gmail page, but I'm suggeting that if you want to print an email, you'd want to remove extra data that doesn't need to be on the page.
In other words, I want the email header along with the subject and body. No need to have my folder information and how many new messages on the printout.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
If you mean HTTP-AUTH, you're wrong here. The auth seems to be stored until the browser is closed. Some implementations, until the tab is closed.
These days most people are doing authentication manually with cookies (although there ARE ways to specify a cryptographically secure exchange with http-auth on modern browsers, it still doesn't integrate into the page as well) and it's all a moot point.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
It's called a print stylesheet, they're usually populated with things like #sidebar { display:none; } so that the exact same page looks right when printed.
Do you even know what AJAX stands for?
Asynchronous
Javascript
And
XML
See that first part? Asynchronous? You can't do that without XMLHttpRequest*. AJAX is not a methodology without it.
Basically, AJAX *is* XMLHttpRequest, because you would not use XMLHttpRequest for anything else, and you can't do AJAX without it. The whole acronymn is retarded and useless, and created by a marketing junkie at Adaptive Path to drive up business. It is no more a "methodology" than wiping your ass.
* I am not including iframe refresh hacks here, because they are not really asynchronous (watch your web browser spinning icon!), though they accomplish the same goals.
HTTP is not a stateful protocol -- ok
HTTP is not a connected protocol -- ok
HTTP is not a client-server protocol -- WTF? What are you smoking here? Of course HTTP is a client-server protocol
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
Read my post again!
Yes, of course google can index PDFs, Flash, Images etc, but in the context of navigation it's pretty useless. Google does NOT know how to click buttons in flash files. Therefore if your navigation is done entirely in Flash, Google will not crawl your site. The reason I know this is because I do a lot of work in Search Engine Optimisation. Clients come to us and say "why I can't I find my products by using google". Usually it's because a flash-happy designer has made all the fancy navigation drop down menus in Flash and google hasn't been able to follow links from within the flash to the other flash content or even static pages.
It's one thing to be able to rip text out of a raw SWF file, but its another thing entirely to for Google to actually understand what the point of the flash file is, understand any embedded heirarchy and follow links within the file. I expect Google will never do this unless Macromedia specifically make it easier for them to do so.
They've introduced some new editors recently that just aren't very good
Um, dude, this story was posted by CowboyNeal... I'm reasonably certain he's not new here.
No they don't.
First of all, there's no need to make "special pages" when the presentational fluff can be separated in CSS so that the pure HTML still makes sense.
Second, even your average poorly designed page can usually be rearranged to look OK on a small screen. Do View/Small screen in desktop Opera to get an idea of how it can look like.
Mobile devices are actually becoming quite decent as long as there's not excessive amounts of Javascript (though Flash-only sites are even worse).
HTTP is not a stateful protocol -- sort of, if all you know is RFC 2616. But if you're using any kind of language to create dynamic content on the server, the first thing that happens is almost always to set a session cookie for purposes of maintaining state.
HTTP is not a connected protocol -- sort of, unless you count persistent connections which have been allowed since RFC 2068 (HTTP 1.1). And now XmlHttpRequest muddies that question even more.
This isn't the Constitution we're talking about; I don't know why people bother to argue from "first principles" such as "HTTP is not stateful." There's nothing morally superior about a stateless protocol. The protocol has changed over time. There's no point pretending it hasn't.
Yeah, HTTP can be used for p2p. Off the top of my head Gnutella uses it at least for messages, possibly other things, and the Grapevine anonymous p2p project
(http://grapevine.sourceforge.net/) is entirely over HTTP.
But only if you ignore the fact that protocols rarely maintain any state.
For example, FTP. A stateful protocol, right? You move around in directories and whatnot.
Except the server remembers where 'you' are, your directory, but that isn't part of the 'procotol' by any means. Your client hopefully is trying to keep track of where you are, and the server is keeping track of where you are, but these do not have to be the same places, and technically the FTP server could leap you randomly to a different directory, on its end, every two seconds.
The only difference is, with FTP, it knows who 'you' are based on your TCP/IP socket, whereas in HTTP it uses cookies. There are advantages and disadvantages to each method. FTP is more secure in that it's near impossible to hijack other people's TCP/IP connections (Ignoring the whole 'plaintext password' issue specifically with FTP.), but HTTP rocks in that you can stay 'logged in'.
Anyway, the difference between 'stateful' and 'stateless' is not the absolute people seem to think.
At one end, a 'most stateful' protocol would never even let you log out. You are who you are, period, and the server knows that forever, even between shutdowns and reboots. Imagine a serial terminal hooked to a server. You can't ever stop being that terminal.
At the other end, a 'most stateless' protocol would send a single packet in response to a packet, and then forget about you. DNS actually is this.
Most end-user things have some sort of middle ground, where 'state' exists as long as needed, and then is discarded on the command of either end. This state may or may not be tied directly to a TCP/IP socket. Sometimes a protocol is designed as tied to a socket, and then 'upgraded' to allow disconnect/reconnect, like HTTP cookies, or 'screen' which lets you keep remote state while logged out, or FTP resumes, which let you restore a very limited state, specifically where in the file you are.
If corporations are people, aren't stockholders guilty of slavery?