Ajax Sucks Most of the Time 510
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's a spoof (Score:3, Interesting)
Microsoft? (Score:4, Interesting)
It doesn't appear to be new, and it doesn't appear to be Microsoft's anymore, either.
Please not again! (Score:1, Interesting)
When I first learned about XmlHttpRequest in the IE5 days, I thought it was going to revolutionize the web. All the problems of session state maintenance would disappear and web pages would become little client-server apps. MS had this capability first with the ActiveX control. They could have hyped this capability and taken the lead with it back in 1999. ASP.Net would have been another great opportunity to showcase this feature and create standards. Instead the ASP.Net philosophy seemed to be to make as many trips to the server as possible. For a while MS virtually abandoned the idea of out-of-band requests. So now, years after introducing this feature, somebody at Microsoft finally realizes what they had going and decides to jump on the bandwagon. Good job guys, but a little late.
Re:Nielsen? Never mind. (Score:2, Interesting)
Re:Not always that bad. (Score:5, Interesting)
Now it happens that a web browser also has two excellent characteristics as a application deployment platform. One is that it is pre-installed nearly everywhere, so as long as you can get a coherent set of standards for what it provides and how it works, it's an outstanding application deployer. It basically enforces separation of UI from logic. The second is that the web was built on an asynchronous protocol, which builds in excellent network resilience. Applications that go over a public network like the Internet must fundamentally assume that the network is of variable and unknown quality, and work gracefully in those scenarios.
AJAX is basically a hack to get the content-oriented browser to work like a proper GUI toolkit. Why should a developer work with the document (note content orientation) object model, when every sane GUI toolkit builds on windows, widgets and event listeners? AJAX is necessary largely because of MS' squashing of Java as a viable network application platform, and because the Java-makers (i.e. Sun) have never prioritized geting a really performant, usable UI toolkit for Java into widespread use. In short, what you really want to build internet apps is a sandboxed deployment environment you know will be on every machine, and that defaults to asynchronous communication for network use. AJAX basically gets you there, but it ain't pretty. My hope is that once people get used to using Internet apps there will be momentum for getting that kind deployment environment on every machine.
PS: I know Javaheads are going to flame me for that one, but compare the comfort of using your average Java app to anything written in QT/KDE,GTK, MFC,.NET, etc. Why the hell is Swing only starting to work at the level that an app like Eclipse does, when QT widgets have worked smoothly and quickly?
AJAX is a baby step (Score:3, Interesting)
Web apps are great because of their ease of deployment. There is no "upgrade cycle" for users. They just refresh the page and they get the latest and greatest.
Rich client apps are great because of the ability to have a rich UI and far more control over the presentation of your application. Speed is almost always better. You can just do more.
AJAX is an attempt to merge the two. Sometimes it works very well, sometimes not. But it's just a stop-gap solution that tries to use existing web technology to mimic the experience users know and love from rich client apps.
The real solution to this problem is to allow for rich client apps to have the ease of deployment of web apps. There are a few possibilities in this area.
One solution is Microsoft click-once deployment paradigm in
Of course, this has the same problems as most
Does anybody know of similar projects coming down the pipe that will offer this to more than Windows clients? Something other than people implementing WPF and the
Re:Flash (Score:3, Interesting)
Now, on non-application sites that are 100% Flash, it's a more valid concern. But again I call bullshit because in my experience the problems only seem to present themselves more often because I see more Flash sites, not because a larger percentage of Flash exhibit these problems compared to AJAX sites. But moreover, problems with the back button, bookmarking, and printing, at least, CAN be dealt with. Most of it without using a "workaround" or hack of any sort, but by using the capabilities of Flash that Macromedia has provided specifically to address these issues.
Now, that's not to say that page authors implement these capabilities. But that's their fault, not Flash's. You can create a steaming pile of poo with any technology, but I think it's a matter of exposure that leads many people to think Flash sucks. People see more pieces of crap written in Flash, so they assume Flash itself is crap.
So to sum up, before talking about how capable a platform is of dealing with a problem, it might help to know anything about the platform. Flash is, at present, far more mature when it comes to addressing many of these issues.
Note: this is not meant to be a pro-Flash rant, so don't take it as such. I'm merely correcting some statements made by the o.p. that I feel aren't entirely accurate.
AJAX is far behind what Microsoft created (Score:5, Interesting)
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.
You are absolutely correct. In fact, Microsoft 5 years ago went far beyond what AJAX is today. The XMLHttpRequest object can act as a data source for binding directly to the IE DOM controls - without scripting to parse the data. I created an statewide budgeting app based on this technology 5 years ago for the Idaho Division of Financial Management. It allows a collaboration app like experience with reduced deployment effort. An ideal IT solution.
Re:Please not again! (Score:4, Interesting)
The article makes some valid points about the Back button and Bookmarks, but these are problems that can be solved pretty easily. Microsoft no doubt would have solved them several years ago, had they seen the potential of the off-channel request technique and acted on it. But as one MS manager told me shortly before IE was released, with Netscape pretty much dead by that time they saw no point in developing IE any further. See how market dominance encourages innovation? I think Firefox now has native support for off-channel httprequests, whereas IE is still using an ActiveX control.
This is SO ironic! (Score:3, Interesting)
Shameless Plug (Score:2, Interesting)
I know that pimping one's own stuff is severely looked down upon here, but I actually do a pretty good job of pointing out the caveats in my AJAX chapter in Professional LAMP [wrox.com] by Wrox/Wiley, just released a few days ago. I also point out the likeness of AJAX misuses to the misuses of Flash.
Basically, there is a lot of hype because that's what gets out first. Books don't really create hype. Articles and articles about articles create hype. These have quick turnaround, so they get out first. Then you get a wave of articles about the other side. It takes more room to talk about both sides, and this usually happens in books, which have a much longer production cycle.
In other words, I think we're definitely over the crest of the hype wave. Now we can get onto actually using AJAX for useful things.
Burn, karma! Burn! (At least I didn't post the amazon link with my associate code, which I've seen many fellow pimps do.)
Re:Yeah, NOBODY! (Score:5, Interesting)
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.
1> There's no need to be so obnoxious - an iframe is not a frame, and the original article was talking about frames, which did break the web and were a Bad Thing.
2> The back button should be usable to navigate from resource to resource. Each URL should identify a resource, and each unique resource (message,post,whatever) should have an URL.
Sometimes web apps break this rule, and when they do, it can be bad. Obviously state shouldn't be bookmarkable, but resources should be. Ever tried to give someone a link to a product on the Apple store? Applications which misuse AJAX can have this problem if they use it exclusively and don't change the url, or worse put some garbage to do with THEIR session info in the url which is shown to the user. Gmail gets away with it because you mail is private and you don't need to send links, with google maps it's kind of annoying because you have to click the 'link to this page 'kludge to send the map to someone else, and you can't click back through various locations easily.
Not that I'd agree that AJAX sucks most of the time, it doesn't at all, can't work out why everyone is getting so worked up about a small part of the toolset.
AJAX for Forums... (Score:2, Interesting)
Re:Not always that bad. (Score:2, Interesting)
Bookmarks are equally important for content navigators (of which maps and mail are examples), and for this functionality google has gone to the effort to provide bookmarks (for maps) and stars (for mail).
Firefox 1.5 is 1st browser with AJAX accessibility (Score:4, Interesting)
It's possible to make DHTML/AJAX/Javascript applications act like desktop applications with respect to keyboard navigation (on IE and Firefox) and support for accessibility tools (currently Firefox only). This was part of the accessibility code that IBM contributed to Firefox.
Information and examples here:
http://www.mozilla.org/access/dhtml/ [mozilla.org]
W3C roadmap for the developing standard here:
http://www.w3.org/WAI/PF/roadmap/DHTMLRoadmap1105
Part of the problem is the ignorance (Score:2, Interesting)
It gets pretty funny when people jump on the bandwagon and flog Microsoft, without doing their homework first. Someone really wanted to criticize Microsoft, and just comes off as being ignorant of the technology they are criticizing.
Re:as in all new directions... (Score:3, Interesting)
True indeed. In fact, if you look at the author's Original Top Ten Mistakes in Web Design [useit.com], number 2 is "Gratuitous Use of Bleeding-Edge Technology".
Solution for backslash (Score:2, Interesting)
For example: I'm developing a (german) flirt-portal, which makes extensive use of ajax and google maps.
Each interaction and it's result is stored in a cookie. If a user changes the zoomlevel of recenters the map, the new values are stored in a cookie. Next time the user visits the back, the cookie is read and the values are restored. Works peferct.
You may check this out: www.citybeat.de/flirt [citybeat.de]. Zoom into the map, select something from the menue on the "right side". leave the map and return, you will see you last settings.
Here's another ajax-thing, I'm working on: An Ajax-Chat, it's in early beta, but it's working finde. www.citybeat.de/chat/ [citybeat.de]
Re:as in all new directions... (Score:3, Interesting)
SSL solely encrypts the communication over the wire. It does not protect the user from having local files (history, etc) from being captured later. This opens them up to considerable risk if all queries (say with SSN, passwords, etc) are communicated using GET. It also stores all of that information in the web logs on the server. This is often a prime target of hackers to collect information. I can easily go on with several other risks to both the server for getting hacked because of GET parameters, and of the user, but I'll leave it at those two major ones. Read ANY book about good practices on building secure web interfaces, and one of the first thing any of them will say is to NOT use GET.
As for fully stateful attempts... that's the purpose of session cookies... to bring a stateless protocol into the stateful world. Technologies such as AJAX are about improving limitation on UI responsiveness, primarily, and not about making things fully stateful.
As for slashdot being bookmarked... no, it can't. You can't bookmark the page you get after posting, nor several others invovled in mid-process form responses. But you can bookmark the important ones (which is also supportive of my view on a good balance and design for appropriate areas of your site).
Actually, I did get your comment abou Java. It was not 100% clear, so I responded with BOTH contexts. You apparently didn't read my whole post. And in addition to all the complexities I mentioned about implementing a thick client based solution, there are massive security concerns as well. Banks have considered the idea of thick-clients (I know because I've worked with some to analyze critical risks to business logic being placed on the client), and decided they are too big a risk, even for many local branches. To remain secure, they would end up turning a Java client almost into a slightly more advanced web browser. Most are actually looking at AJAX or similar solutions to gain the UI advantages while maintaining the need for security. And by the way, if you were made to install and use a Java application for every service that had need for more advanced and interactive services, you'd be bitching about how they need to come up with a more central standard for their applications (ie. the web browser). Applets (or similar technologies) are a decent step in that direction, but are also prone to the same security concerns.
So, it doesn't make sense. It's not practical. People would have to install apps left and right, including those who are not technically savy, but can use a web browser. It doesn't make sense from a perspective of being successful while taking into account the reality of the user base, and what would happen if every other company people needed to deal with required their own special application installed. It's just not reasonable. That is what the advantages of the web browser was about. A common, central platform to build client-server interfaces (yes, applications).
You're right that web browser apps don't compete with desktop apps in terms of flexibility in UI. But we're not talking about things like calculators, Photoshop, or Word. We're talking specifically client-server oriented applications, where the communication is one of the primary things to deal with (behind the scenes, that is). Desktop apps have other limitations that are more crippling when we're talking about secure client-server applications. Oh yeah... you know all those bugs in IE and other clients for interacting with servers... just imagine EVERY one of those apps people need to use having those vulnerabilities without the financial backing to respond/fix immediately because of a non-centralized pooling of resources (like the IE development team that can have so much resources because of the popularity of the app). And I won't even go down the business/cost advantages beyond what I did i