Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Programming The Internet Technology

Ajax Sucks Most of the Time 510

Posted by CowboyNeal 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."
This discussion has been archived. No new comments can be posted.

Ajax Sucks Most of the Time More

Ajax Sucks Most of the Time

Comments Filter:

  • as in all new directions... (Score:5, Insightful)

    by yagu ( 721525 ) * <yayagu@[ ]il.com ['gma' in gap]> on Wednesday December 07, 2005 @01:03PM (#14203147) Journal

    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?

    • Re:as in all new directions... (Score:5, Informative)

      by CaymanIslandCarpedie ( 868408 ) on Wednesday December 07, 2005 @01:15PM (#14203260) Journal
      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.

      • Re:as in all new directions... (Score:4, Insightful)

        by mpcooke3 ( 306161 ) on Wednesday December 07, 2005 @01:43PM (#14203528) Homepage
        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".

      • Re:as in all new directions... (Score:5, Insightful)

        by diverman ( 55324 ) on Wednesday December 07, 2005 @02:32PM (#14203971)
        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

      • Re:as in all new directions... (Score:4, Insightful)

        by Iriel ( 810009 ) on Wednesday December 07, 2005 @02:44PM (#14204047) Homepage
        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.
        • 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 [useit.com], number 2 is "Gratuitous Use of Bleeding-Edge Technology".
      • "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] :-)

    • Umm... Its a SPOOF (Score:5, Informative)

      by dsginter ( 104154 ) on Wednesday December 07, 2005 @01:15PM (#14203268)
      Read the bottom of the page. The article is a spoof.
    • My post here is to the objection I think the article states Ajax problems too harshly.

      Perhaps, but I think the problem set the author chose to examine is not where the deep and most fundamental problems with Ajax lie.

      The basic issue is simple - HTTP isn't a client - server protocol. There are several technologies that try to get around this issue, Java Applets, Flash Remoting and now Ajax. They all have their own set of issues, but the place that the break is in the design decision to try to turn an HTML br

      • Re:as in all new directions... (Score:4, Informative)

        by masklinn ( 823351 ) <.slashdot.org. .at. .masklinn.net.> on Wednesday December 07, 2005 @03:19PM (#14204306)

        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

        • 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 kno
    • 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 [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

      • 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 po

    • Re:as in all new directions... (Score:5, Insightful)

      by Ian Wolf ( 171633 ) on Wednesday December 07, 2005 @01:25PM (#14203380) Homepage
      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 article is spoof, doing an s/frame/ajax/ on an earlier posting as to why frames suck. While it is a spoof, it still has a point.
    • 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.

  • Misleading (Score:4, Insightful)

    by FortKnox ( 169099 ) * on Wednesday December 07, 2005 @01:04PM (#14203150) Homepage Journal
    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.

    • Re:Misleading (Score:5, Insightful)

      by garcia ( 6573 ) on Wednesday December 07, 2005 @01:11PM (#14203219)
      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.

    • Re:Misleading (Score:5, Informative)

      by owlstead ( 636356 ) on Wednesday December 07, 2005 @01:43PM (#14203532)
      "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.

  • Implementation (Score:5, Insightful)

    by kevin_conaway ( 585204 ) on Wednesday December 07, 2005 @01:05PM (#14203156) Homepage
    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?

  • I wouldn't go that far (Score:3, Funny)

    by reverend_rodger ( 879863 ) on Wednesday December 07, 2005 @01:05PM (#14203167)
    I wouldn't necessarily say AJAX sucks, but I've foudn that Tide does, indeed, do a better job...
    • 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).

  • I pull out the marshmallows..... (Score:3, Funny)

    by Anonymous Coward on Wednesday December 07, 2005 @01:05PM (#14203168)
    ...to cook them via the upcoming flame war.

  • ajax (Score:5, Insightful)

    by rayzap ( 700032 ) on Wednesday December 07, 2005 @01:05PM (#14203170)
    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.

  • It's a spoof (Score:3, Interesting)

    by Sugarcrook ( 795680 ) on Wednesday December 07, 2005 @01:05PM (#14203172)
    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.

    • Re:It's a spoof (Score:5, Funny)

      by smittyoneeach ( 243267 ) * on Wednesday December 07, 2005 @01:15PM (#14203266) Homepage Journal
      To paraphrase Karl Marx: History repeats itself, first as tragedy, second as XML.

    • Re:It's a spoof (Score:5, Insightful)

      by ivan256 ( 17499 ) * on Wednesday December 07, 2005 @01:17PM (#14203283)
      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.

      • Yeah, NOBODY! (Score:3, Informative)

        by brunes69 ( 86786 )

        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)

          by guet ( 525509 ) on Wednesday December 07, 2005 @02:47PM (#14204067)
          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.
    • 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.)

    • Re:It's a spoof (Score:5, Insightful)

      by DingerX ( 847589 ) on Wednesday December 07, 2005 @01:20PM (#14203325) Journal
      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.
      • Yep. There's a reason that the use of frames has dropped dramatically on the web over the past 5 years or so.

        • Re:It's a spoof (Score:3, Insightful)

          by drinkypoo ( 153816 )
          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...

    • When is a spoof not a spoof? (Score:4, Insightful)

      by DragonHawk ( 21256 ) on Wednesday December 07, 2005 @01:20PM (#14203327) Homepage Journal
      "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?
    • And like the original article, it points out some real problems.

  • Microsoft? (Score:4, Interesting)

    by takkaria ( 782795 ) <[takkaria] [at] [gmail.com]> on Wednesday December 07, 2005 @01:06PM (#14203175) Homepage
    "... 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.

  • RTFA (Score:2, Informative)

    by LordBodak ( 561365 ) *
    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.

  • Not a MS Technology (Score:2, Informative)

    by blaster151 ( 874280 )
    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.
    • Next you will tell us that MS did not develop the Internet!
    • No its not Microsoft specific, but I think they were refering to MS as creator of it. MS began using AJAX in the early 90s I think (of course without the cool new buzz-word) and was made possible by thier extenion "HttpRequest" (don't quote me on that as I'm not a web developer but I'm pretty sure thats the command) to the existing commands. This new HttpRequest was created to support Outlook Web Access (which I believe was the first "AJAX" application). Now I'm sure others can give a better history of t
    • 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."

      • The wiki is wrong - history lesson (Score:5, Informative)

        by brunes69 ( 86786 ) <`gro.daetsriek' `ta' `todhsals'> on Wednesday December 07, 2005 @01:50PM (#14203593)
        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.

  • The problem with AJAX is not with the technology it is, as is often the case, with the people using it. It's the current big new "thing" and some people will insist on using it everywhere they can. Look how many sites appeared that were pure flash when flash was the big new thing. There aren't as many now and those that are almost always offer a html version.

    I am sure that there are some really nice things that can be done with AJAX. We just need to find out what it's good at and what it isn't so good at.

    • Really, the problem with AJAX is that many of the developers and their users are trying to mix an "application" design paradigm with a connectionless browser design paradigm. AJAX breaks "back"? Of course it does. Applications don't have a "back" button, they have an "undo" button, and it performs a completely different operation from what the browser does when you hit back. If AJAX application developers want to not confuse their users, they force everything into a new window with no control bar, and p

  • Improving web accessibility? (Score:3, Insightful)

    by saskboy ( 600063 ) on Wednesday December 07, 2005 @01:08PM (#14203193) Homepage Journal
    "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.

  • Easily solved (Score:3, Informative)

    by dmoore ( 2449 ) on Wednesday December 07, 2005 @01:08PM (#14203195)
    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/ [unfocus.com]

  • Not always that bad. (Score:5, Insightful)

    by MartinG ( 52587 ) on Wednesday December 07, 2005 @01:09PM (#14203206) Homepage Journal
    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.

    • Re:Not always that bad. (Score:5, Interesting)

      by electroniceric ( 468976 ) on Wednesday December 07, 2005 @01:41PM (#14203509)
      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?
  • yhbt

  • And when it doesn't suck... (Score:3, Funny)

    by digitaldc ( 879047 ) * on Wednesday December 07, 2005 @01:11PM (#14203224)
    ...it totally blows.

  • I'm a user. All I want is the web page to load and to contain the information I'm looking for. Simple really. Does it matter what is used to generate the page? No. AJAX, XML, HTML, CGI... they're just tools for developers to use. AJAX has its place and if it's not the best tool, then either people will stop using it, figure out how to use it better, or it will be enhanced to work better. Why all the fuss?

  • I read the article and I am not impressed. The complaints are mostly trivial or nonexistent with proper coding and design. I especially like the bit about bookmarks...OH NO!!!! That's a deal killer for me. Obviously, AJAX is not the best tool for every situation, but when used correctly, the results are spectacular as seen in Google Maps, Yahoo Mail Beta, etc.

    gasmonso http://religiousfreaks.com/ [religiousfreaks.com]

  • Flash (Score:5, Insightful)

    by nmg196 ( 184961 ) * on Wednesday December 07, 2005 @01:14PM (#14203248)
    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...

    • Re:Flash (Score:3, Interesting)

      by dFaust ( 546790 )
      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

    • Re:Flash (Score:4, Insightful)

      by brassmoknets ( 933133 ) on Wednesday December 07, 2005 @02:13PM (#14203790)
      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 [google.com]
      Except perhaps...er... what was the name of that search engine...you know...er...

      • Re:Flash (Score:3, Informative)

        by nmg196 ( 184961 ) *
        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 navigat
  • I didn't RTFA yet, but I think this is the same complain as HTML frames (no back button, no printing, no bookmark correctly...). (there is even a no frames campaign [noframes.org], looks as a 1997 web page!) I think that if you are looking a web page as just a "page", yes, the author is right, AJAX suck. But if you see it as a web app, you should evaluate it as an app, not as a web page. In a typical app, you use provided buttons, print with provided menu (like Gmail) and so on.
  • I've told people time and again that client side programming is only useful for display. Any scripting that can be turned off and make your applications useless or insecure is potentially a danger.

    Sure, checking data before it is sent is nice but validating data is incorrect since that data can be changed without the script and sent to the server.

    AJAX is just the latest craze like FLASH was and it has the same problems that FLASH does and as a result, is just a nice display layer that can be turned off.

    Befo

  • Jakob Nielsen looks at usability in terms of "what is the worst possible thing a developer could do with this technology?", rather than "what are the benefits, and how can we avoid the pitfalls?".

    His main issue with Ajax is the breaking of the navigation model - well, I've got news for him: the model he describes isn't an end-all-be-all, perfect one. It's all fine and good to complain that people could use Ajax to break the back button, to create pages based on sequence of actions, et cetera - but that's

  • The fundamental design of the Web is based on having the page as the atomic unit of information...

    Stop right there, grandpa. That statement ceased to be true as soon as "IMG" tags were allowed.

  • Even worse, 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.

    I hate to state the obvious, but URLs have never really constituted a complete specification of the information shown. 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.

    Ask any experienced high school l
    • 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 [w3.org]. 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
  • Ajax Compatible Browsers: 78%

    No way.....85% use IE alone and IE is Ajax compatible. That's not even counting Firefox, Mozilla, and others.

  • Flash (Score:2, Insightful)

    by smallguy78 ( 775828 )
    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.

  • Huh? (Score:3, Insightful)

    by TheRealMindChild ( 743925 ) on Wednesday December 07, 2005 @01:36PM (#14203485) Homepage Journal
    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.

    • so close... (Score:3, Insightful)

      by javaxman ( 705658 )
      So close to being insightful [useit.com] 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 ar

  • AJAX is a baby step (Score:3, Interesting)

    by ThinkFr33ly ( 902481 ) on Wednesday December 07, 2005 @01:49PM (#14203582)
    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 [microsoft.com] 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 [opsan.com]), which is a subset of WPF that Microsoft is trying to make cross-platform, but what about non-Microsoft solutions?

  • All of this can be solved (Score:5, Insightful)

    by alphorn ( 667624 ) on Wednesday December 07, 2005 @02:02PM (#14203700)
    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/ [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 [search.ch]
    • 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 [search.ch]

    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)

    by R4modulator ( 771354 ) on Wednesday December 07, 2005 @03:54PM (#14204570)
    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/ [mozilla.org]

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

Slashdot Top Deals

Get hold of portable property. -- Charles Dickens, "Great Expectations"

Close