Slashdot Mirror

← Back to Stories (view on slashdot.org)

Ajax Sucks Most of the Time

Posted by CowboyNeal on 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."

90 of 510 comments (clear)

  1. as in all new directions... by yagu · · 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:

    • most of the listed grievances are not unique to AJAX, have been addressed in the past, and are probably soluble for AJAX too. (e.g., how many remember the broken first browser paradigms where there simply was no easy way to get the information from a web page to some printer? It's not perfect today, but it's doable. This problem is ultimately soluble for AJAX too)
    • AJAX is the (to many) latest and greatest. Many will hold on and gain purchase. Some will bail. I think AJAX or some derivative thereof is here to stay. Like technology before AJAX, there will always be naysayers, and there will always be glitches. For this to justify a "Just Say No to AJAX" philosophy is naive and maybe even misguided.

    From the article:

    Ajax is currently so hard to learn that many page authors write buggy code.

    Huh? So? Is this unique to only Ajax?

    Also from the article:

    Many websites that offer users a choice between regular and ajax versions have found that most users prefer ajax-free designs.

    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?

    1. Re:as in all new directions... by CaymanIslandCarpedie · · Score: 5, Informative

      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
    2. Re:as in all new directions... by interiot · · Score: 2, Informative
      most of the listed grievances are not unique to AJAX

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

    3. Re:as in all new directions... by Ian+Wolf · · Score: 4, Insightful

      Ajax is currently so hard to learn that many page authors write buggy code.

      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.

      --
      "The words of the prophets are written on the Slashdot walls."
    4. Re:as in all new directions... by mpcooke3 · · Score: 3, Insightful

      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.

      For "valid at one point" consider using "always valid".

    5. Re:as in all new directions... by drinkypoo · · Score: 2, Informative

      Also, I can't find the reference, but most browsers won't cache passwords when you go back and then forwards,

      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.'"
    6. Re:as in all new directions... by diverman · · Score: 5, Insightful

      I am glad that you made this statement. The whole time I'm reading the article, I kept thinking that it was basing the vast majority of its argument on false assumptions that AJAX is predominantly being used on content pages. The best use of AJAX, that I see, is with improving user interactivity with a web application. Web applications are becoming more and more of a need, and I think this is where AJAX is gaining the most ground.

      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

    7. Re:as in all new directions... by interiot · · Score: 2

      No, not HTTP-AUTH. I thought I was talking about password fields, but I can't remember specifically where I read that at (RFC2616 is hard enough to keep in your head).

    8. Re:as in all new directions... by Iriel · · Score: 3, Insightful

      I think the major point of the article is that AJAX is currently being used (like a lot of upstart web technologies) in many places were it just confuses things more than needed. Give it time, and people will stop using it just for the sake of jumping on the new craze bandwagon and we'll find out where it shines and where it should never go.

      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.

      --
      Perfecting Discordia
      www.stevenvansickle.com
    9. Re:as in all new directions... by sootman · · Score: 2, Funny

      "This is a spoof article. Please compare it with the original and you will see how little it has been changed."

      He didn't even change the indefinite article in the graphic--"This is a Ajax free site" [emphasis added] :-)

      --
      Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
    10. Re:as in all new directions... by masklinn · · Score: 3, 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

      --
      "The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
    11. Re:as in all new directions... by The_Wilschon · · Score: 2, Interesting

      I think the major point of the article is that AJAX is currently being used (like a lot of upstart web technologies) in many places were it just confuses things more than needed. Give it time, and people will stop using it just for the sake of jumping on the new craze bandwagon and we'll find out where it shines and where it should never go.

      True indeed. In fact, if you look at the author's Original Top Ten Mistakes in Web Design, number 2 is "Gratuitous Use of Bleeding-Edge Technology".

      --
      SIGSEGV caught, terminating

      wait... not that kind of sig.
    12. Re:as in all new directions... by islanduniverse · · Score: 2, Insightful

      Also, notice if you click the link for "The Original" it was written December 1996...

      I mean -- look at these 'statistics' :

      The November 1996 browser statistics from Interse show the following distribution of browser usage:
      Netscape 2: 13% of users
      Netscape 3: 47% of users
      Internet Explorer 3: 28% of users
      Other browsers or earlier versions: 13% of users
      Percentages sum to 101% due to rounding. Thus, 13% of users would not even be able to see a site with frames.

      [Frames Suck Most of the Time (Jakob Nielsen's Alertbox December 1996): Link: 9612.html , Dec07th, 2005]

    13. Re:as in all new directions... by Haeleth · · Score: 3, Informative

      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.

    14. Re:as in all new directions... by Aewyn · · Score: 2, Informative
      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.

      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).

    15. Re:as in all new directions... by amitola · · Score: 3, Informative

      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.

    16. Re:as in all new directions... by diverman · · Score: 2, Insightful

      I don't know. After 12+ years websites that have learned to use technology effectively have become MUCH better. I don't deny there is a lot of cruft and crap out there as well. But because there are idiots in the world doesn't mean the genius (not necessarily claiming this for myself) that has emerged don't exist.

      It seems that almost everyone that argues against me on this keep bringing up simple, static, content pages as their support. But if you people bother reading my postwith the context of THAT POST (as opposed to the bucket your charged up brain has placed it into), you'd see that I am focusing on Web Applications. These are not pages that generally need to be bookmarked. These are not pages that NEED a back button.

      I mean, bitch about the limitations of Banking websites all you want. The dynamic content is what allows you to HAVE a banking website. The limitations have little to do with the JavaScript or AJAX. The limitation that you can't go BACK on those pages has to do with general state and flow management. And the "Back button" issue that you mention has nothing to do with the "Back button" issue the article's author mentioned. Your back button issue has existing since the beginning of dynamic web pages/web applications. It is specifically THESE limitations that have driven technologies like AJAX. I mean, if you process a transaction for a transfer, and then try to hit "back", bringing you back to a processing page and the interface just lets you... you're more likely to make a mistake of retransferring money (duplication). The choice your bank made is to not let you go back. Others handle it by just not processing a resubmit on a transaction, but let you back button all you want. Another option would be to use AJAX within the scope of a transfer transaction "application". Hitting the back button would take you to the page you were at before the transfer request. This would actually be idea, since loading into the middle of a completed transaction's form is simply "invalid use".

      Hmmm... I think your issue with your bank's "back" button restrictions is actually an argument FOR something like AJAX!

      So, once again... your arguments are not with AJAX or similar technologies. Your argument seems to be against poorly implemented applications. The back button issue you descrobe, not allowing simultaneous windows, etc... these are not issues with AJAX or similar technologies. These are issues with the back-end session and transaction management of the application. But since much of that level of backend development isn't inherant to existing frameworks, it becomes a lot more development (and QA/testing) to support. AJAX could actually help alleviate your specific issues, by reducing the client behavior that causes banks like yours to be so restrictive.

      -Alex

    17. Re:as in all new directions... by Midnight+Thunder · · Score: 2, Insightful

      The truth is what makes a technology bad is using it in the wrong way. When it comes to the web we see much more of this happening. Take Flash as one example, where IMHO it is used badly most of the time, yet there are some things which can benefit from Flash, such as an embeded game. AJAX is the same, there are a few valid uses for the technology. For example one good use of the technology is Google Maps.

      --
      Jumpstart the tartan drive.
    18. Re:as in all new directions... by DavidTC · · Score: 2, Informative
      Technically you are correct.

      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?
    19. Re:as in all new directions... by diverman · · Score: 2, Insightful

      Er, since when there's any need for AJAX for banking? Mine could certainly work just fine without it. Should be perfectly doable with web forms and cookies.

      I said it was a possible solution to the "issues" you stated regarding your banks interface. Your issues have little to do with AJAX, JavaScript, or any other scripting. They are issues inherant to a web application not designed to handle specific cases as gracefully as you would like (but they could, if designed to).

      Hint #1: I don't like web applications. Gmail is all nice and cool, but I don't give a damn about it, I'm very happy with my IMAP server.

      Hint #2: *I* will decide what I want to bookmark and what not, thank you very much.

      Hint #3: *I* will decide when I want to use the back button, instructions not to use it will never cease to annoy me.

      And yeah, I know about the back button being a way to re-submit a transaction. But any bank should be sane enough not to process it again, which is exactly what I want: To go back to the previous page, without harmful consequences.

      Um... your bank interface is a web application. Search engines are web applications. Pretty much anything that does logical user interaction is a web application! So, you don't care for most websites these days? Oh yeah, slashdot is a web application!

      Interesting. Can you bookmark results on POST submits? No AJAX, but certainly can't be reflected in a URL. But then again, form submissions/results are a web application, but I forgot... you don't like using them.

      Not if the site is designed to not give you the page. Considering that the website is likely more responsibile for effects of misuse, are the ones that DESIGN and GIVE you an interface and workflow to use, I think it's well within their right to control workflow on THEIR website. If you don't like it, don't use it. Now, a properly designed site will make these choices either seemless or unobtrusive to their users. So, again, you aren't complaining about AJAX, JavaScript, or other scripting, but rather a poor implementation. But place blame with it belongs, not on the first thing you notice to be related to the issue.

      If the bank for whatever reason wants to offer a richer interface they can do it perfectly well with say, a Java application which won't have any of the problems all this AJAX mess has.

      What crack are you smoking? Do you KNOW what AJAX is? AJAX is not something that is going to send up a warning because you hit your back button. That's JavaScript, yes... and probably what I'd call annoying as well. But AJAX is a way for a single web page to make requests behind the scenes without stepping from page to page. If AJAX were used for specific transactions, hitting your back button would present NO risk as it sounds like there currently IS with your bank. There would be a "transfer" page, and the steps of the transaction would not load a new page, but just be handled on that one page with requests done in the background. You could then hit back and forward all you want with little risk to transaction or your account. It would give you the freedom to use your back button without stepping into pages that are invalid or "dangerous", but still go to pages that ARE stable landing points.

      And as for using Java as a solution to your issues? Why would this be? Java is just another programming language for the backend, unless you're talking about a servlet. It is prone to the exact same problems as PHP, Perl, C#, ASP, or even C (God forbid) would have in a stateless protocol. If something that uses Java on the backend IS behaving better, it's only because the implementation of the site has chosen to handle flow control better. But this could be the same regardless of the underlying language.

      AJAX, as I said could be ONE solution to help with the problems you mentioned. Personally, I think it would also make the overall "steps" easier

    20. Re:as in all new directions... by diverman · · Score: 2, Interesting

      Okay, I'm going to reply to you, and the other guy who are so ignorant about security as to lightly suggest just switching POST to GET.

      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

  2. Misleading by FortKnox · · Score: 4, Insightful

    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!
    1. Re:Misleading by garcia · · Score: 4, Insightful

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

    2. Re:Misleading by owlstead · · Score: 4, Informative

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

    3. Re:Misleading by FortKnox · · Score: 3, Informative

      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!
    4. Re:Misleading by RustyTaco · · Score: 4, Informative

      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.

  3. Implementation by kevin_conaway · · Score: 5, Insightful

    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?

    1. Re:Implementation by Anonymous Coward · · Score: 5, Funny

      You can misuse ANY technology to f things up.

      This is the Internet. You can say "fuck" here.

    2. Re:Implementation by ThinWhiteDuke · · Score: 4, Funny

      This is the Internet. You can say "fuck" here.

      Yeah. Especially when responding to an article headlined "AJAX sucks..."

      --

      It would be nice to be sure of anything the way some people are of everything.
    3. Re:Implementation by toggles · · Score: 2, Funny

      This is the Internet. You can say "fuck" here.

      I believe the correct terminology on the internet is "fsck".

    4. Re:Implementation by Arandir · · Score: 3, Funny

      You can also say "flbgrtyu", but why would you want to?

      --
      A Government Is a Body of People, Usually Notably Ungoverned
  4. I wouldn't go that far by reverend_rodger · · Score: 3, Funny

    I wouldn't necessarily say AJAX sucks, but I've foudn that Tide does, indeed, do a better job...

  5. I pull out the marshmallows..... by Anonymous Coward · · Score: 3, Funny

    ...to cook them via the upcoming flame war.

  6. ajax by rayzap · · Score: 5, Insightful

    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.

  7. It's a spoof by Sugarcrook · · Score: 3, Interesting

    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.

    1. Re:It's a spoof by smittyoneeach · · Score: 4, Funny

      To paraphrase Karl Marx: History repeats itself, first as tragedy, second as XML.

      --
      Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
    2. Re:It's a spoof by ivan256 · · Score: 4, Insightful

      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.

    3. Re:It's a spoof by Kelson · · Score: 2

      And, like the best satire, it raises good points. Careless use of AJAX does indeed have many of the problems raised, so careful planning and graceful degradation are -- as always -- the key to producing a usable site.

      (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.)

    4. Re:It's a spoof by DingerX · · Score: 4, Insightful

      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.

    5. Re:It's a spoof by drinkypoo · · Score: 2, Insightful

      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.'"
  8. Microsoft? by takkaria · · Score: 4, Interesting

    "... offers a critical view at the new Microsoft technology ..."

    It doesn't appear to be new, and it doesn't appear to be Microsoft's anymore, either.

    1. Re:Microsoft? by amliebsch · · Score: 5, Informative
      And it most certainly is NOT and NEVER WAS a Microsoft technology. Microsoft has nothing to do with the new widespread adoption of AJAX. This comment in the article really really bothers me. Microsoft deserves absolutely no credit for things they had nothing to do with.

      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.
    2. Re:Microsoft? by clear_thought_05 · · Score: 5, Informative
      You are correct. It was first Microsoft's idea.

      Microsoft first implemented the XMLHttpRequest object in Internet Explorer 5 for Windows as an ActiveX object. Engineers on the Mozilla project implemented a compatible native version for Mozilla 1.0 (and Netscape 7). Apple has done the same starting with Safari 1.2.


      http://developer.apple.com/internet/webcontent/xml httpreq.html
  9. RTFA by LordBodak · · Score: 2, Informative
    Right at the bottom:
    This is a spoof article. Please compare it with the original and you will see how little it has been changed.
    --
    LordBodak's journal.
  10. Not a MS Technology by blaster151 · · Score: 2, Informative

    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.

    1. Re:Not a MS Technology by slackmaster2000 · · Score: 2, Informative

      True enough. According to the wiki:

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

  11. Improving web accessibility? by saskboy · · Score: 2, Insightful

    "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.
  12. Easily solved by dmoore · · Score: 2, Informative

    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/

  13. Not always that bad. by MartinG · · Score: 5, Insightful

    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 .@adgimnoprstu
    1. Re:Not always that bad. by electroniceric · · Score: 4, Interesting

      I'd mod you up, but I prefer to reply instead. This is very insightful statement, and I believe it's the basis of Jakob Nielsen's complaint. Web-as-content really is distinct from web-as-application. The web browser works beautifully for web-as-content, but is rather limited for web-as-application.

      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?

    2. Re:Not always that bad. by tpjunkie · · Score: 2, Funny

      The web is used (rightly or wrongly) to deliver two distinct things.

      1) Porn

      2) Spam

    3. Re:Not always that bad. by brauwerman · · Score: 2, Interesting

      Back (aka Undo) is definitely needed in desktop apps and one of the main annoyances of webpages like google mail and google maps.

      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).

  14. And when it doesn't suck... by digitaldc · · Score: 2, Funny

    ...it totally blows.

    --
    He who knows best knows how little he knows. - Thomas Jefferson
  15. Re:Nielsen? Never mind. by netean · · Score: 2, Interesting

    Hear hear... have you seen his website... designed by blind donkey. http://www.useit.com/http://www.useit.com Hardly a good model for usable, effective web design.. But a shining example of the "usability" of the internet circa 1996

  16. Re:Huh? by amliebsch · · Score: 2, Informative
    How is it suddenly a Microsoft technology?

    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.
  17. Flash by nmg196 · · Score: 5, Insightful

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

    1. Re:Flash by dFaust · · Score: 2, Interesting
      When using Flash in the way that AJAX is meant to be used (typically for applications), Flash is actually far more mature. Problems with printing, bookmarking, etc. are all problems that both Macromedia and the Flash community have worked on for some time to rectify. As far as indexing, not something you really need or even want for an application. So, put blunty your "FAR WORSE extent with fewer workarounds" is bullshit.

      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.

    2. Re:Flash by brassmoknets · · Score: 4, Insightful
      No search engine in the world is going to evaluate your flash files
      http://www.google.com/search?hl=en&lr=&safe=off&q= filetype%3Aswf+contrary+evidence
      Except perhaps...er... what was the name of that search engine...you know...er...
    3. Re:Flash by nmg196 · · Score: 2, Informative

      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.

  18. Umm... Its a SPOOF by dsginter · · Score: 5, Informative

    Read the bottom of the page. The article is a spoof.

    --
    More
  19. Re:Jokes often become "common knowledge" by killercoder · · Score: 5, Informative

    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.

  20. When is a spoof not a spoof? by DragonHawk · · Score: 3, Insightful

    "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.
  21. Flash by smallguy78 · · Score: 2, Insightful

    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
  22. Huh? by TheRealMindChild · · Score: 2, Insightful

    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
  23. Let's get a few things straight by ArwynH · · Score: 2, Insightful
    Asynchronous JavaScript and XML (AJAX) is not a technology in itself, but is a term that describes a "new" approach to using a number of existing technologies together, including: HTML or XHTML, Cascading Style Sheets, JavaScript, The Document Object Model, XML, XSLT, and the XMLHttpRequest object. When these technologies are combined in the AJAX model, web applications are able to make quick, incremental updates to the user interface without reloading the entire browser page. This makes the application faster and more responsive to user actions.

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

  24. Yeah, NOBODY! by brunes69 · · Score: 2, 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 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. Re:Yeah, NOBODY! by guet · · Score: 4, Interesting

      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.

      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.

  25. AJAX is a baby step by ThinkFr33ly · · Score: 2, Interesting

    AJAX is a baby step on the march back to rich clients.

    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 .NET 2.0, although it has its limitations as well. (Windows-only being a big one.) It looks as though Windows Vista is going to try and blur the line between Windows and the Web as much as possible, making rich client applications created with WPF (Avalon) fully hostable inside the web browser. (With code access security restrictions, of course.)

    Of course, this has the same problems as most .NET solutions at this point... it's Windows only. One of the great thing about web apps is that they run pretty much anywhere. I suspect that many companies will say that 90% market coverage is good enough for the benefit of web-deployed rich client apps.

    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 .NET Framework on other platforms? I know about WPF/E (Windows Presentation Foundation Everywhere), which is a subset of WPF that Microsoft is trying to make cross-platform, but what about non-Microsoft solutions?

  26. The wiki is wrong - history lesson by brunes69 · · Score: 5, Informative

    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.

    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 .Net is a "Microsoft Technology", even though there is Mono.

    1. Re:The wiki is wrong - history lesson by brunes69 · · Score: 2, Insightful

      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.

    2. Re:The wiki is wrong - history lesson by wfberg · · Score: 2, Insightful

      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
  27. Re:Javascript overused by Caspian · · Score: 2, Informative

    "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?
  28. AJAX is far behind what Microsoft created by davegust · · Score: 4, 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.

  29. Re:An odd complaint here.... by Kelson · · Score: 2, Insightful

    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.

  30. All of this can be solved by alphorn · · Score: 5, Insightful
    The problems mentioned can all be avoided.

    • The back button can be made to work. We went to great lengths to make sure the back button takes you to the previous view in http://map.search.ch/ . Try clicking it for a zoom, then hit the back button.
    • The fact that URLs don't auto-update doesn't mean that permalinks are impossible. We create a permalink every time you do a search or enter the "email this page" screen. See http://map.search.ch/zurich
    • Even auto-updating URLs when navigating inside an AJAX app are possible, we have plans to implement that in the future.
    • And of course, our map works just fine without javascript. http://map.search.ch/?s=1

    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.
  31. Re:Please not again! by serutan · · Score: 3, Interesting

    I agree 100% with the above post, because PromptZero cut and pasted most of it from one of my recent posts on this subject. I guess imitation is flattery.

    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.

  32. This is SO ironic! by Spy+der+Mann · · Score: 2, Interesting

    One of the reasons people used frames was to avoid HAVING TO RELOAD the pages on webapps! And this is what AJAX gives us. (Personally i'd be pretty happy when XUL engines become available for all browsers).

  33. so close... by javaxman · · Score: 2, Insightful
    So close to being insightful and yet so far...

    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!

  34. Wrong, again by brunes69 · · Score: 2, Informative

    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.

  35. Shameless Plug by mattwarden · · 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 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.)

  36. Mod parent up by Exaton · · Score: 2

    So the article is a spoof -- knew I'd read all that already somewhere -- but I say it's illegitimate : comparing AJAX to frames is most insulting in the most unjustifiable way.

    Moving on, *NEWSFLASH* : technology can be misused !

    AJAX is all about being used properly, respecting and avoiding the navigation problems it can raise. So why's everybody so upset about something they have to be careful with ? It's powerful, mind how you handle it !

    Bunch'a unhappy crybabies. Badly used AJAX is just another way to root out incompetent Web developers ; the more such red flags there are, the better. Natural selection, you know ?

    Please respect the healthy and non-AC troll, thank you.

  37. AJAX for Forums... by PJ+Brunet · · Score: 2, Interesting

    One thing I noticed lately, more sites have edit boxes so that when you click "submit" the edit box fades out and your text magically merges with the page... great for forums especially...saves time--there's no page refresh, and it's cool. Busy forums will benefit greatly from AJAX--I'm thinking that you'll be able to watch the threads move down and the post counts change in realtime--you'll have something like a chatroom but much more powerful. If you want to take it to the next level, come up with an AJAX blog monitoring system that takes data from blogs and aggregates it into a threaded forum format, take all the comments and trackbacks and put them all under one thread--and allow the user to collapse by reply/offsite-comment/trackback/offsite-trackback, now your forum is flying--then you would need some filters to keep it under control. If you decide to this, send me a copy please ;)

  38. Re:Flash - You need AFLAX - Quack !!! by dbdweeb · · Score: 2, Funny

    It looks like a duck.. It quacks like a duck... It's not that insurance company... it's AFLAX... http://www.aflax.org/

  39. Firefox 1.5 is 1st browser with AJAX accessibility by R4modulator · · Score: 4, Interesting

    We can't ignore the fact that the exciting part of the web is moving away from documents and into applications.

    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/

    W3C roadmap for the developing standard here:
    http://www.w3.org/WAI/PF/roadmap/DHTMLRoadmap11050 5.html

  40. Part of the problem is the ignorance by TheSkepticalOptimist · · Score: 2, Interesting

    AJAX is NOT a Microsoft technology, in fact, AJAX isn't a specific technology, it's using a bunch of web technologies together (http://en.wikipedia.org/wiki/AJAX).

    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.

    --
    I haven't thought of anything clever to put here, but then again most of you haven't either.
  41. Some validity but ... by Wilmerr · · Score: 2, Informative
    I would contend that the statement :
    "URLs stop working: the addressing information shown at the top of the browser no longer constitutes a complete specification of the information shown in the window. If an author copies the URL in order to include it as a hypertext anchor in one of his or her own pages then that anchor will not lead readers to the desired view but to the initial state of the page."
    Doesn't just apply to AJAX, but also applies to legacy pages constructed using frames - you can often relate to the site content initial state but not the state of the content. So if you exempt that from being a benefit of AJAX then do the other benefits stand on their own ?
  42. Solution for backslash by hemabe · · Score: 2, Interesting

    I use Ajax in a few applications and there is no problem with "backslash".

    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. 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/

  43. Great when used for appropriate situations by Denis+Lemire · · Score: 2, Insightful

    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.

  44. AJAX is the new XML by bearinboots · · Score: 2, Insightful

    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.

  45. These Articles are foolish by JimBrownie · · Score: 2, Insightful

    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.