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."
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.
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.
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
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!
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.
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
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.
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.