Slashdot Log In
Ajax Sucks Most of the Time
Posted by
CowboyNeal
on Wed Dec 07, 2005 12:02 PM
from the foaming-cleansers dept.
from the foaming-cleansers dept.
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."
Related Stories
[+]
The Future of AJAX and the Rich Web 303 comments
jg21 writes "This AJAXWorld Magazine article indicates how far AJAX has come since devs complained here two years ago that it sucked all the time. Eight experts were asked what questions we should now all be asking about where AJAX is headed next. The suggested questions are refreshingly hard-headed, including: 'How are we to fix the web?'; 'When will AJAX development finally be easy?'; and 'Do we really need JavaScript 2.0? Won't it be somewhat irrelevant by the time it becomes commonplace and thus usable?' One of the most interesting questions came from Kevin Hakman, co-founder of TIBCO's General Interface: 'On what timeline will AJAX skills become commoditized like HTML skills became?'"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
as in all new directions... (Score:5, Insightful)
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?
Re:as in all new directions... (Score:5, Informative)
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.
Parent
Re:as in all new directions... (Score:4, Insightful)
For "valid at one point" consider using "always valid".
Parent
Re:as in all new directions... (Score:5, Insightful)
The author talks about how "the page" is the basic idea that was behind the Web. Well, I hate to break it to him, but after 12+ years, things have evolved. The notion of the page has long since been an area of limitation with web applications and usability. This is why we've seen the uprising of many technologies in an effort to have more dynamic content interfaces. Users don't like having to wait for a full page load to make a small request within an application. There is complaint about the time it takes. Granted, this is largely a perception thing, but it is the reality of users.
The type of information being presented on the web has gone beyond thesis papers and simple static articles. The information that users are becoming used to is more complex, as the average user's understanding of relational information grows.
Now, the author does make some good points... but mostly these are when using AJAX in "pages". In this respect, I agree that overzealous, and possibly inexperienced web developers have gone overboard. But a good web developer considers the effects their choices have on a user, and they make the choice to go with one advantage over the loss of another. I am conscious that search engines can't necessarily index my content... so what! If I don't want it to be indexable, so be it... they can index the more "content" oriented parts of my sites, and users can then find the "features" and applications that use better technologies. The complaint about printing... please! A best practice is to take length articles and break them up into multiple pages. Ummm.. this has the same problems with printing. He kind of neglects to point that out.
As was stated previously, many of the arguments are presumptuous that the web is all about "pages". I also question the interpretation of his statistics. 1. Old browsers are likely unpatched browsers. With the vulnerabilities and security issues today, compatibility with AJAX is the least of their problems. Upgrade! 2. Mobile browsers have problems with MOST page content. Websites are designed for a minimum of 800x600 these days, if not 1024 wide. Websites still need to provide special pages to serve up content to mobile devices anyway.
So, I know this is a spoof article by the author about a previous article about Frames back in the 90's... but I think he sticks too much to the premise that existed back then, that the web was all about simple content and "pages", without recognizing that the information complexity has evolved, and that "applications" are becoming more and more necessary for usability of the information. Yes, improvements are needed. Yes, back button support should be support (but not required). Also as was said in an earlier post, many of the problems are not an issue with just AJAX, and many are an issue with the lack of understanding of the effects of the choices made when using ANY new technology.
-Alex
Parent
Re:as in all new directions... (Score:4, Insightful)
Personally, I think it's great for UI tricks and acynchronous form actions (checking for currently used user names, submitting to a shoutbox, and so on). If people think AJAX itself is bad, they should see the comments on Digg to AJAX articles. There are more comments like "If I see one more damn article on this..." than there are dupe notification comments here on Slashdot!
I think this new use of JavaScript has great potential, but the real message of the article can be gleaned in the first few paragraphs: Don't go overkill.
Parent
Umm... Its a SPOOF (Score:5, Informative)
Parent
Re:as in all new directions... (Score:3, Informative)
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 [zvon.org]. 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 shou
Re:as in all new directions... (Score:5, Insightful)
I swear, I've heard the same argument about PHP, Perl, C, and even the concept of object oriented programming. In every case the person uttering those words was an idiot or simply too entrenched in their chosen language to accept a new way of doing something. It all reminds me of a line from Scott Adams' Dilbert Principle. As best as I can recall it went something like this.
"Every technology has its detractors. I'm sure that somebody once stated that the pointy stick would never replace the fingernail as the fighting man's weapon of choice."
As for my disclaimer, the only thing I know about Ajax is that its not effective as Mr. Clean.
Parent
Re:as in all new directions... (Score:4, Informative)
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
Parent
Misleading (Score:4, Insightful)
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.
Re:Misleading (Score:5, Insightful)
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 that pointing these things out NOW is a great idea being that AJAX is now one of the biggest buzzwords in the industry. With marketing and management raving about AJAX and demanding AJAX applications be put everywhere including locations they shouldn't be, I think it's about time someone put an article out there that describes the negative effect that AJAX applications could have on the web.
Hopefully more media outlets will start picking this up and not just touting the successes of AJAX. Remember, buzzwords = $$$ in the eyes of those that are clueless.
Parent
Re:Misleading (Score:5, Informative)
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.
Parent
Re:Misleading (Score:4, Informative)
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.
Parent
Re:Misleading (Score:5, Informative)
Parent
Implementation (Score:5, Insightful)
Re:Implementation (Score:5, Funny)
This is the Internet. You can say "fuck" here.
Parent
Re:Implementation (Score:5, Funny)
Yeah. Especially when responding to an article headlined "AJAX sucks..."
Parent
Re:Implementation (Score:4, Funny)
Parent
I wouldn't go that far (Score:3, Funny)
I pull out the marshmallows..... (Score:3, Funny)
ajax (Score:5, Insightful)
It's a spoof (Score:3, Interesting)
Re:It's a spoof (Score:5, Funny)
Parent
Re:It's a spoof (Score:5, Insightful)
Parent
Yeah, NOBODY! (Score:3, Informative)
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 o
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.
Parent
Re:It's a spoof (Score:3)
(At least now I know why I didn't see the headline come through on the mailing list. If I had, it woud have been one of the 25% of Jakob Nielsen articles that I actually read.)
Re:It's a spoof (Score:5, Insightful)
Parent
When is a spoof not a spoof? (Score:4, Insightful)
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?
Parent
Microsoft? (Score:4, Interesting)
It doesn't appear to be new, and it doesn't appear to be Microsoft's anymore, either.
Re:Microsoft? (Score:5, Informative)
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.
Parent
Re:Microsoft? (Score:5, Informative)
http://developer.apple.com/internet/webcontent/xm
Parent
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.
Parent
Improving web accessibility? (Score:3, Insightful)
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.
Easily solved (Score:3, Informative)
Here's an LGPL'ed solution: http://www.unfocus.com/Projects/HistoryKeeper/ [unfocus.com]
Not always that bad. (Score:5, Insightful)
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.
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?
Parent
And when it doesn't suck... (Score:3, Funny)
Flash (Score:5, Insightful)
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...
Re:Flash (Score:3, Interesting)
Now, on non-application sites that are 100% Flash, it's a more valid concern. But
Re:Flash (Score:4, Insightful)
Except perhaps...er... what was the name of that search engine...you know...er...
Parent
Huh? (Score:3, Insightful)
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
All of this can be solved (Score:5, Insightful)
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.
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
Re:Huh? (Score:3, Informative)
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.
Re:Jokes often become "common knowledge" (Score:5, Informative)
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.
Parent
Re:Not a MS Technology (Score:3, Informative)
"Like DHTML, LAMP, or SPA, Ajax is not a technology in itself, but a term that refers to the use of a group of technologies together. In fact, derivative/composite technologies based substantially upon Ajax, such as AFLAX, are already appearing."
The wiki is wrong - history lesson (Score:5, Informative)
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
Parent
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.
Parent