Slashdot Mirror


Ajax Sucks Most of the Time

Vo0k writes "It seems that everyone is excited with what AJAX promises, and only few look at what it breaks as well. The article at Usability Views offers a critical view at the new Microsoft technology, pointing out some problems it creates, like breaking bookmarking, making the 'back' button useless, problems with printing, accessiblity and more. The single-sided view from the article provides a good counter-balance for all the craze."

5 of 510 comments (clear)

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

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

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

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

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