Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
The Internet Businesses Google

Bosworth On Why AJAX Failed, Then Succeeded 265

Posted by kdawson from the before-its-time dept.
An anonymous reader writes "eWeek has a story describing a talk by former Microsoft developer Adam Bosworth, now a VP at Google, entitled 'Physics, Speed and Psychology: What Works and What Doesn't in Software, and Why.' Bosworth depicts issues with processing, broadband, natural language, and human behavior; and he dishes on Microsoft." Quoting: "'Back in '96-'97, me and a group of people... helped build stuff that these days is called AJAX,' Bosworth said. 'We sat down and took a hard look at what was going to happen with the Internet and we concluded, in the face of unyielding opposition and animosity from virtually every senior person at Microsoft, that the thick client was on its way out and it was going to be replaced by browser-based apps. Saying this at Microsoft back in '96 was roughly equivalent to wandering around in a fire wearing matches,' he said. 'But we concluded we should go and build this thing. And we put all this stuff together so people could build thin-client applications... Now you hear about AJAX all the time, but this was built in '97,' Bosworth said. Yet, AJAX failed for a variety of reasons, including some 'big mistakes.'"
This discussion has been archived. No new comments can be posted.

Bosworth On Why AJAX Failed, Then Succeeded More

Bosworth On Why AJAX Failed, Then Succeeded

Comments Filter:

  • Me too. (Score:5, Interesting)

    by linkedlinked ( 1001508 ) on Tuesday January 30, 2007 @05:43PM (#17820902)
    Yep, I created an AJAX-like system as a pet-project in my high school web design course (boredom++) back in about 2000. I'm not sure if "AJAX" had really taken off by that point, but for fun, I decided to use JS to load remote pages, particularly of the scripted variety.

    Ironically, I got a D- on my final project, which was a self-updating news feed reader (pulled XML news feeds from a few sites), because it "wasn't very user friendly."
    • Not sure what the ironic part of this is, AJAX has nothing to do with being user friendly...

      • Re:Me too. (Score:5, Funny)

        by linkedlinked ( 1001508 ) on Tuesday January 30, 2007 @06:23PM (#17821406)
        Yeah, sorry, let me clarify-
        It was a high school web design class. By which I mean it was WYSIWYG-based, no HTML, no JS, no coding. The irony lies in the fact that I still couldn't pass it.

        Watching that teachers house burn down was one of the greatest feelings I've ever had, and for only the cost of a liter of gasoline...
      • Your statement is a bit ambiguous, but if you are implying that AJAX applications are not user-friendly then you are confusing technology with implementation. AJAX can make applications more user-friendly if done properly.

    • Re:Me too. (Score:5, Funny)

      by mdobossy ( 674488 ) on Tuesday January 30, 2007 @05:47PM (#17820950)
      And I've seen plenty of AJAX-based apps put out just this year that deserve a D- for user friendliness as well, so dont feel too bad ;)
    • I've been meaning to do something like this.

      I'm curious, how did you overcome the JavaScript security restriction against HTTP-fetching pages from more than one domain?

    • Re: (Score:2)

      by Duhavid ( 677874 )
      I hear you. I took a C course
      at JC a long time ago, the instructor
      did not know C when he started the course,
      I probably knew more of C than he did at
      the end, he gave me a "C" in the class.
      • C what happens when you know more than the teacher...

      • Re: (Score:3, Funny)

        by TheLink ( 130905 )
        Interesting formatting.

        <assistant type=limerick>
        <prompt>You appear to be writing a limerick...</prompt>

        <suggestion>

        There was once an instructor at JC
        Who taught but didn't even know C
        A student of course
        complained because
        in the end he saw a C for C

        </suggestion>
        <assistant>

        • Re: (Score:2)

          by Duhavid ( 677874 )
          Very funny!

          I know about the formatting, but I just end up
          doing it. I really dont know why, or where it
          came from. See what I mean?

          • Re: (Score:2)

            by TheLink ( 130905 )
            Not complaining :p.

            Someone (was it you?) made a similarly formatted post sometime back that someone else commented looked a bit like poetry.

            The words may be clear
            but who can know the reasons,
            why the words lie so.

            • Re: (Score:2)

              by Duhavid ( 677874 )
              It might well have been me. I have had a
              few comments ( and complaints... ). I have
              noticed that there are a few others that
              do it also. Might be the same form of
              brain damage I have. :-)

  • The reason AJAX worked this time.. (Score:4, Interesting)

    by xENoLocO ( 773565 ) * on Tuesday January 30, 2007 @05:44PM (#17820908) Homepage
    ... it has a name that people can easily refer to and brand as a technology. I'd seen/used AJAX implementations before, but now I have something to put on my resume. Simple as that.
    • This shouldn't be underestimated as a legitimate reason.

      In 2001, I needed this functionality, but I had an impossible time finding any documentation on whether it was even possible to do anything like XMLHttpRequest in a browser, especially in a cross platform way. One of the biggest changes is that we know what to search for now that the AJAX name took off following Google Maps' success.

      As a C/Java programmer who had to cross over to some minor web development for an in-house app, I couldn't find the righ
      • The XMLHTTPRequest documentation has been readily available on MSDN for a looonnnggg time already, plus several other guides on how to use it, and I am pretty sure since 2001.

        But yup, it wasn't cross-platform, simply because the same thing doesn't exist for other browsers (not without jumping through hoops anyway).
    • As always, things only exist for us in the social world once we have a name by which we can mutually refer to them. Without the word, there is no way to leverage the object. With the word, the object is called into existence even if it grows increasingly weak ontologically. Ask any linguist or sociologist.

  • ...has yet to succeed... (Score:4, Insightful)

    by xero314 ( 722674 ) on Tuesday January 30, 2007 @05:47PM (#17820958)
    Having been there working on Asynchronous XML request long before the term AJAX was dreamt up I can tell you that it was just a bandaid for the plague that is browser applications, and still is to this day. The only thing AJAX has succeeded at is keeping the belief going that browser applications are a viable solution. The more we add to the web browser and the more dynamic and complex our client side scripting becomes the more we head toward having application clients and dumb terminals rather than PCs with Browsers. I only hope that someone with the influence to change things figures this out and stops this web based madness. There are other, better, solutions to the client server paradigm.

    • Re:...has yet to succeed... (Score:4, Insightful)

      by Rosco P. Coltrane ( 209368 ) on Tuesday January 30, 2007 @06:02PM (#17821130)
      Exactly. The problem with web browsers is they were never meant to do any of the things we make them do today. They're essentially document viewers with the ability to retrieve documents remotely. Anything else added to it, especially things that need to maintain state consistency between pages or views, is a kludge and, as you say, a bandaid.

      The way forward as I see it either a set of clearly defined standards for networked applications, with either the client taking the brunt of the workload, or the server, or a combination of both, or going back to thin clients and dumb terminals, which shouldn't work all that bad these days with broadband.

      • Re:...has yet to succeed... (Score:5, Insightful)

        by rainman_bc ( 735332 ) on Tuesday January 30, 2007 @07:19PM (#17822028)
        The problem with web browsers is they were never meant to do any of the things we make them do today

        Unfortunately it is what it is.

        When the iframe was added to the browser spec a bunch of us used it to feed data to and from a server and do what ajax does today.

        Happens all the time - things morph into something they were never intended for. Doesn't make it wrong. If it was wrong browser developers would pare things back. Instead they ( rightly so ) move forward.

        • When the iframe was added to the browser spec a bunch of us used it to feed data to and from a server and do what ajax does today. [...] If it was wrong browser developers would pare things back.

          Well, IFRAME is deprecated, as are many other horrendous mistakes.

      • I have been thinking for a while now that we need some sort of "enhanced browser" if you will, something specifically designed to run applications, without all of the headaches that come with fat-client applications. This way you can easily deploy applications, have a common platform (the "browser"), and distribute the workload across client and server. It seems so obvious that it has to exist already.

      • Re: (Score:3, Insightful)

        by cats-paw ( 34890 )
        "The way forward as I see it either a set of clearly defined standards for networked applications, with either the client taking the brunt of the workload, or the server, or a combination of both, or going back to thin clients and dumb terminals, which shouldn't work all that bad these days with broadband."

        Isn't that what X-Windows was designed for ?

    • Re:...has yet to succeed... (Score:5, Insightful)

      by Anonymous Coward on Tuesday January 30, 2007 @06:09PM (#17821222)

      There are other, better, solutions to the client server paradigm.
      And pray tell what are they? By the way, they must fulfill these needs,

      * Vendor independent GUI language (eg, WhatWG's stuff or XUL)
      * Vendor independent cross-platform client language (EcmaScript+W3CDOM, Python, Ruby, maybe .Net... that kind of thing)

      Just don't seriously suggest applets and Swing or something crap like that. We're not using HTML+JS because it's useless, it's because it is the best thing right now.

      • Re: (Score:2)

        by xero314 ( 722674 )

        There are other, better, solutions to the client server paradigm.

        And pray tell what are they? By the way, they must fulfill these needs,

        Gee why don't you just say "By the way, it must be pessimised to the lowest common denominator using poorly supported and poorly implemented standards"

        I'll just throw out one suggestion that is older than anything you mentioned and certainly a better solution for remote applications than AJAX:
        Terminal and Telnet

        Write your server side in any language you would like,

        • Will this be using windows or unix line breaks? Or mac?
          • And which character for delete? 127 or 8? Is backspace destructive? What happens when you hit backspace at 1,1? How about when you put the cursor at 25,80?

            (Thank God for curses and termcap)

      • Re: (Score:2)

        by Yakman ( 22964 )
        Flex is close (http://www.adobe.com/products/flex/). It might not be "vendor independent" but it's based on a lot of open standards and it's client platform has an extremely high penetration:
        • ActionScript 3 is based on the latest draft ECMAScript spec, includes goodies like E4X for painless XML parsing
        • There are open actionscript compilers out there, but even so...
        • The Flex 2 SDK (including the MXML compiler and the component library) is "free" (the Eclipse based IDE and Charting isn't)

        The only non-open thi

        • Agreed on the whole Flex thing. And it's a remarkably good IDE for a 2.0 version (owes a lot of that to Eclipse). I can only imagine Flex Builder 5.0 or the like.

        • There are open actionscript compilers out there, but even so
          Try using MTASC to compile any nontrivial AS2 app that was written for Adobe's tools, and you'll find out you can't, because the version 2 components aren't legally available without buying Flex. If you're willing to pay for Flex, they'll give you a license to let you use the version 2 components, but you'll have to patch them extensively to make them work with MTASC. Try using an open-source compiler to compile AS3 code that was written for Fle

      • Try XForms. It's vendor independent, standard, and aims to obviate 80% of scripting.
        In the Mozilla implementation, it uses XBL to allow you to write behind-the-scenes JavaScript (a la XUL) to implement presentation stuff that keys off the appearance and data type declarations to enhance the presentation.

        See http://en.wikibooks.org/wiki/XForms [wikibooks.org]

        • Re: (Score:3, Informative)

          by merreborn ( 853723 )
          Wow, you can write a basic calculator in only 300 lines of xforms code! That's so much better than the 30 lines of javascript it'd take!

          http://en.wikibooks.org/wiki/XForms/Calculator [wikibooks.org]

          I can't wait!
          • I don't think the calculator is a particularly good example; the person who wrote it encoded the state machine of the keys by switching entire bindings in and out.

            Recently I wrote an entire webmail application with a small PHP back end that outputs the mailbox list, the message list, and individual messages as XML (each addressed by a URL using the REST [wikipedia.org] methodology -- XForms works very well with REST). The UI, written entirely in XHTML+XForms, is 300 lines.

            There's a little bit of JavaScript used to supplem

      • Re: (Score:2)

        by samkass ( 174571 )
        Just don't seriously suggest applets and Swing or something crap like that.

        Why would you consider Python, Ruby, or .Net, but exclude Java and Swing? Java is faster than any of those three, and is very cross-platform, well-documented, open source, and easy code to develop and maintain. I understand it's uncool to like Java these days, but it's actually one of the best solutions for this sort of problem out there today.
      • You forgot:

        * Already installed on every internet-connected desktop.

    • Re: (Score:3, Insightful)

      by sheddd ( 592499 )
      "I only hope that someone with the influence to change things figures this out and stops this web based madness"

      If we all boycott browser apps, they'll be forced to change; no more /. for you and me; no ebay, no amazon, no google. Good riddance!

      Kidding aside, klunky web apps are a cheap easy way to make services accessible to MANY people. AJAX helps with the clunkiness on occasion.

    • It's a marketing success. Everyone has now heard the AJAX buzzword. Technically, though, it's still a solution in search of a problem. HTML+JS is a compatibility nightmare as Internet Explorer development repeatedly creates a JavaScript/JScript incompatibility. First it was DOM, and now that Firefox and IE agree on DOM, it's time to bastardize JavaScript into the next, incompatible JScript. The whole point of AJAX and using the Web Browser as a basic app client is that it's portable. JScript will find a way
    • I think there are certainly ways you Should Not use AJAX. There are strengths and weaknesses to the technology. AJAX works best when small parts of the screen change in response to user action. If large parts of the screen will change, just use a link. And if the screen needs to change constantly without user interaction, PLEASE don't do it with JavaScript! Write a control or something!

      The big flaw is this stupid idea that we will find the One True Way that every application needs to work. I don't want to r

      • Re: (Score:2)

        by xero314 ( 722674 )

        I think there are certainly ways you Should Not use AJAX.

        I don't think the problem is that there are ways you should not use AJAX, but more that there are NO ways that you should use AJAX. And this is coming form a, Pre AJAX as a term, AJAX developer. I'm not talking without knowing what I am talking about. I was the driving force behind a very successful XUL/AJAX based application. It worked cross platform, with the platform specific UI, was relatively fast and extremely scalable. The was one "Page L

    • AJAX has yet to succeed? It seems to be succeeding, with numerous small to massive sites using it.

      Maybe the browser was never originally intended for this use, but PCs were probably never originally intended for any of the stuff that's being done with it.

      There may be better ideas out there, what it takes is someone to figure out how to make them worthwhile.

    • There are other, better, solutions to the client server paradigm.

      And how many of them run inside a sandbox that every single web user is already familiar with, and has an installed copy of?

      Web apps work because everyone already has client application installed (the browser), and uses it regularly.

      I'm sure you *could* come up with a better "universal client". I'm sure there are already some out there. But the browser's already installed on every PC out there, and users don't want to install new software.

  • Ahem... (Score:5, Funny)

    by Infinityis ( 807294 ) on Tuesday January 30, 2007 @05:48PM (#17820972) Homepage
    In Soviet Russia, AJAX succeeded, then failed.

    AJAX is still failing for me, you insensitive clod.

    Yeah, but does AJAX run Linux?

    1. Invent AJAX at Microsoft
    2. Use AJAX at Google
    3. ???
    4. PROFIT!!!

    Ajax is still failing. Netcraft confirms it.

    I, for one, welcome our new AJAX-inventing overlords.

    Imagine AJAX naked, petrified, and covered in hot grits.

    AJAX must be new here...

  • Pre XMLHTTPRequest (Score:3, Insightful)

    by c0d3r ( 156687 ) on Tuesday January 30, 2007 @05:59PM (#17821096) Homepage Journal

    I implemented an app that recorded all of the browsing and events in a frame that generated Javascript to re-play the browsing session to a hidden frame and saved the script via a Java Applet that connected to a Servlet like java program on the server way before XMLHTTPRequest existed. Java Applets can provide even better functionality, but unfortunately no one seems to be able to develop responsive, multithreaded applets in AWT for any browser, hence applets gained the reputation of being sluggish and unresponsive.

    • Java Applets can provide even better functionality

      Agreed!

      but unfortunately no one seems to be able to develop responsive

      Not always... there is Swing.

      Out of necessity, I wrote a suite of applets that given XML provide common controls like trees, lists and popup menus. I know there are other projects out there that do this, but they did not exist at the time I started the projects; besides it's fun to maintain. They are databound and in some cases threaded to provide a consistent user experience. When I build a complex UI, I use them all of the time. Yes they are free and open source, but I'm the only person wh

  • Asynchronous xml, something (kinda) new from M$ (Score:5, Funny)

    by marcello_dl ( 667940 ) on Tuesday January 30, 2007 @06:07PM (#17821204) Homepage Journal
    So, contextualizing the story a little:

    Microsoft embraces and extends*.

    One day, by mistake, Microsoft creates something new.

    Microsoft then proceed to bury the mistake until the folks of Mozilla discover and implement it.

    Having become a competing technology Microsoft embraces it and AJAX becomes a success.

    * Bill's wife is in fact from soviet russia. She embraces and "extends" him.
  • It doesn't seem to hard to be a Microsoft rebel. Oh, and Microsoft even - wow!
    I predict that 90% of the comments here will be people saying the use AJAX things in the 1990s too.

  • Thin and Thick Clients are not Mutually Exclusive (Score:5, Insightful)

    by ThinkFr33ly ( 902481 ) on Tuesday January 30, 2007 @06:10PM (#17821252)
    People seem to constantly suggest that the future is either with thin clients or with thick clients, but they never really explain why.

    I think this is a false dichotomy. Thin clients and thick clients each have their uses. Thin clients are great as some things (deployment, maintenance, cross-platform capabilities, client security, etc.), where as thick clients are great at others (leveraging the local machine, UI flexibility, speed, privacy, etc.)

    The successful applications utilizing AJAX are those applications which really don't need to the capabilities of the local machine. Those that try to do what a local app is much better at are doomed to fail, at least for the time being. (AJAX office suites, for instance.)

    I see the line between these two kinds of applications slowly but surely blurring. I really doubt that HTTP/Javascript/XML will take us a whole lot further than we're seeing now. It just wasn't meant for this kinda stuff. While the various implementations of "rich" web applications are quite ingenious, they're hacks, and hacks can only take you so far.

    Instead, I see HTTP and the browser being the primarily delivery mechanism for rich applications running inside a sandbox on the client. Essentially the Java model, but done right. (And, perhaps more accurately, done at the right *time*.)

    You can see the beginnings of this with technologies like XUL [wikipedia.org], ClickOnce [microsoft.com], XAML [wikipedia.org], XBAP [msdn.com], and WPF/E [msdn.com].

    It's just a matter of time before these things catch on.
    • I've already mentioned this in another comment [slashdot.org], but Adobe Flex [adobe.com] is here today and lets you build Rich Internet Applications that compile down to SWF files that run on Flash Player 9. Unlike all the other technologies you've mentioned, Flash Player 9 will work on the majority of systems and browsers out there today.
      • Flash Player 9 crashes on my Ubuntu box. More importantly, Flash is a highly proprietary technology in many ways. There's a plethora of licensing restrictions that make it impossible to produce a fully source-code-compatible OSS implementation of the whole Flash toolchain. The audio and video codecs it supports are also patent-encumbered in the U.S.

  • Why Bosworth Failed with AJAX in 97 (Score:5, Insightful)

    by ingo23 ( 848315 ) on Tuesday January 30, 2007 @06:23PM (#17821402)
    I do not find his explaination of AJAX failure convincing. I also created an AJAX-like app in 2000 (well, ok, not in 97), but the main problem was not the network bandwidth, browser performance or app compexity.

    The main problem was the browser support.Yes, I had it working in both IE and Netscape. But at that time IE 4.0 was still quite popular, and good luck making any AJAX (or even pseudo-AJAX) working there.

    Ten years ago the web/HTML/HTTP concept was still based on request/response/full reoundtrip for each page, as it was originally concieved. DOM was not a standard (or at least was a standard on paper only), and using a browser as a thin client was not much better than developing a thick client - either you stick to a particular version of a particular vendor (a corporate application), or you go Java applet/activeX route which is essentially a thick client.

    Both browser performance and network bandwidth are an excuse for bad design and poor coding. If done right, AJAX apps can use even less bandwidth, then a traditional full page refresh.

    Bottom line - once the mainsteam browsers started to provide a decent and more or less uniform DOM support and other features like XMLHTTPRequest (although the latter was not really critical, but rather a convinient shortcut) - AJAX became feasible on the large scale.

    • That's funny, I was writing AJAX-like stuff around the turn of the century, too... only my method for getting data updates from the server was to request JavaScript objects inside a scoopable, re-sourceable element. Actually, I remember working on this product in "proof of concept" around... 1998. It was shortly after I got my first ISDN line. Anyhow.

      The biggest problem I found *wasn't* browser support. There was lots of great stuff to work with. Only, it was completely different from browser to browser.

      Li
  • I'm still waiting for AJAX to take off.
  • Ironically, while a web browser is commonly thought of as a "thin client", some major Enterprise Applications companies, wanting full client functionality on their web-based products, require downloads exceeding 2MB(!) for their "thin client" Javascript apps.

    Try putting 100 users of said web app on your network and watch your traffic surge.

  • Am I the only one who thought... (Score:3, Funny)

    by Dadoo ( 899435 ) on Tuesday January 30, 2007 @06:45PM (#17821668) Journal
    "...then I'm happy and sad for it"

  • AJAX is a silly acronym (Score:4, Interesting)

    by Dracos ( 107777 ) on Tuesday January 30, 2007 @06:46PM (#17821682)

    Most people agree that AJAX is a silly acronym. (I personally think DHTML is much sillier). Let's examine it.

    • "Asynchronous": I'll buy that.
    • "Javascript": won't be alone here for long.
    • "And": who makes a conjunction significant in an acronym?
    • "XML": the ideal, but not only, data format.

    Javascript can do a lot, but it wasn't originally designed for heavy application logic. Without getting redesigned to allow it to used outside the browser or web server, I believe Javascript will become a limitation for "AJAX" eventually.

    Also, the folks at Mozilla have plans to allow application developers using Gecko to completely sidestep javascript with other scripting languages, the first being Python:

    <script type="text/python">

    When this happens, will we see a new "technology" called APAX? Embedded scripting with Ruby begets ARAX? When does it end? Or does AJAX become an umbrella term like LAMP?

    "And" is only there to make the name pronounceable. It also just happens to leave us with a somewhat familiar word.

    XML here implies that you can only work with XML formatted data, which is not the case. XMLHTTPRequest also maintains a copy of the response as plain text, so it's just as easy to work with CSV, for example. Except there's no CSV parser built into Javascript.

    AJAX is a silly name, but we're probably stuck with it.

    • Re:AJAX is a silly acronym (Score:5, Funny)

      by EvanED ( 569694 ) <evaned@g[ ]l.com ['mai' in gap]> on Tuesday January 30, 2007 @07:04PM (#17821874)
      See this diagram [hermann-uwe.de], and in particular the arrow from "people who refuse to use the word AJAX to "AJAX programmers"

    • Re: (Score:2)

      by grcumb ( 781340 )

      AJAX is a silly name, but we're probably stuck with it.

      Well, if you ask me, it's just a blatant wannabe move. Wa-ay back in the mists of 2001, the inimitable Damian Conway created the Acme::Bleach [cpan.org] Perl module. Part of the stunningly [sic] inspired Acme [cpan.org] series of Perl modules, it creates the cleanest code ever in the history of programming.

      Now some web wanker with a re-tread idea from the nineties indulges in a bit of shameless self-promotion, whoring himself first to Microsoft, then to Google, and when

    • Re: (Score:2)

      by oliverk ( 82803 )
      First off, I agree with you wholeheartedly. That said, I've been working with some teams lately that refer to AFLAX as a shorthand for data-driven Flash. I think this is less about finding the right acronym and more giving the marketing types something they can actually utter without sounding profoundly illiterate. :)
    • Clearly, once other languages get involved we'll need a different acronym.

      I propose Asynchronous Scripting Embracing XML Using Any Language

      ASEXUAL. It works to both describe the technique and many of the people who use it. Bah-dum-ching! Thank you, thank you, I'll be here all week.

      • Re: (Score:2)

        by Dracos ( 107777 )

        While I agree that we need a generalized term...

        DAMN. That is one of the funniest things I've seen in a long time.

  • Ironically, AJAX should arguably be most useful for people with slow internet connections, as it allows one to send small chunks of data without reloading an entire web page.

    But often, the apps which use AJAX are also using big graphics and video, cumbersome libraries and other bling that require high bandwidth to be enjoyable.

  • 1997 called to say it put Java on hold (Score:2, Interesting)

    by Anonymous Coward
    Nobody in their right minds runs random Java applets or activeX controls off the web, the same should be true of javascript. The hand-waving about AJAX ignores the fact that not all clients fully implement the W3C DOM or scripting. Every time it's mentioned, graceful degradation is brought up but that's crap because it relies on developers most of whom do not write documents that degrade. Nobody wants to be writing large apps in javascript and neither was HTTP designed for the current crop of "we can do it
  • AJAX, that's the thing that makes my PC freeze for 45 seconds every time I load a /. article, right?
    • Only if you check the "Yes, I'm willing to help test Slashdot's new discussion system" box.

      • Re: (Score:2)

        by svunt ( 916464 )
        you mean...the AJAX discussion system is thew one with AJAX? Thanks for the clarification!
  • The whole AJAX craze was a big bait and switch. Everybody oohed and aahed over Google maps. Then the developers ran out and added to their projects. And then the big ol' wait happened. Unless the data you're getting is miniscule, AJAX is pig slow. My business customers all assumed that every bit of data was free and so they all started asking for these post-less pages full of AJAX. I cursed the day they ever heard that damned acronym. Google maps is a super easy and uncomplicated implementation of AJ

  • AJAX will never succeed... (Score:5, Insightful)

    by evilviper ( 135110 ) on Tuesday January 30, 2007 @09:53PM (#17823256) Journal
    AJAX is going to be a buzzword for a couple years, then it's going to fade out just as quickly. Just like Java applets before it. Once the "new" factor wears off, people will more clearly see the limitations and problems, and stop bothering.

    Let me ask this... who the hell WANTS to move their apps to the web? Web pages are a mess of inconsistency that is rather painful to navigate... As much as people complain about desktop apps, the biggest differences there are nowhere near the variations in web pages.

    AJAX apps have to be perfect, because the baseline (the browser footprint and network response time) puts them at significant disadvantage, before you even start adding any features. From there, it can only get worse.

    What's more, AJAX really only stands a chance of replacing the most basic programs (There's not going to be an AJAX version of Photoshop any time soon). So for all this overhead, you're still only doing what a tiny, lighting fast desktop program has been doing, and doing well, 2 decades ago. And my tiny, non-AJAX e-mail program is faster, better, more readable, more customizable, and has far more features, many not even technically possible via AJAX.

    AJAX strikes me as the kind of thing that is popular, just because it can be.

    And personally, I avoid any companies that go out of their way to remove backwards compatibility, for flashy new features.

    • Re:AJAX will never succeed... (Score:5, Insightful)

      by Bill, Shooter of Bul ( 629286 ) on Wednesday January 31, 2007 @12:12AM (#17824302) Journal
      Interesting perspective. There are apps that were made for AJAX and those that do work much better on the desktop, like photoshop. Basically web apps make sence for two reasons:
      1. Instalation problems dissapear
      2. Apps need to access centralised data that cannot be stored locally


        1. You can make a good application on windows, mac, linux easily now, with minimal problems with instalation or dependancies, but it wasn't alwasy that way. We've all seen terrable desktop apps ( Real player? What a joke) that crash, don't install correctly, have conflicting dependancies with other apps, ect. Going to the web removes all of that. ALl you need is IE 6 or firefox. Thats it. No instalation, no upgrading, instant functionality. Ajax and other javascript can make the app handle more like a simple desktop app.

          Then there are applications that CAN NOT exist on the desktop. Do you really want to install amazon to buy books? What if you find a better deal at barnesandnoble? you have to somehow find the app and install it. Comaprison shopping takes a nose dive. Furthermore, the app has to communicate with a remote server some how inorder to get new products and place orders. WOuldn't it be nice if there was a standard way to create interfaces to interact with these remote services? Well, now your just recreating HTML/ Javascript.

          I don't know who you are or what you do. You really remind me of someone I used to work with. We had this same argument. Not about ajax, but web vs Desktop. Are web apps perfect? of course not. Are they always better than a desktop equivalent? No, but they can be. Don't avoid something just because its popular, or it has "hype". You have to apporach any new technology with an open mind and objectively evaluate the facts. Unfortuantly, it doesn't stop there. The moral of this article is that the "facts" change over time. What was once a useless technology now has a use. Keep evaluating technologies in light of new developments.

  • The story of XmlHttp (Score:4, Informative)

    by Anonymous Coward on Tuesday January 30, 2007 @10:54PM (#17823778)
    There seems to be a difference of opinion of how AJAX came to be, according to the developer that actually implemented the first prototype:

    http://www.alexhopmann.com/xmlhttp.htm [alexhopmann.com]

    The work to create what became known as XmlHTTP was done by folks in the Outlook Web Access, and it was a gradual development, it did not come in the form of a spec by a third party group, but some brainstorming and mixed ideas as those developers were trying to build OWA (they were using clever post backs at the time), he describes it as:

    At some point Brian Valentine (who was still the GM of Exchange at the time) asked us to figure out what to do with OWA for Exchange 2000. There were two implementations that got started, one based on serving up straight web pages as efficiently as possible with straight HTML, and another one that started playing with the cool user interface you could build with DHTML. When I first got a demo of the DHTML work that Jim Van Eaton and Bob Gering were doing I was just blown away. However they were basically doing hacky form-posts back to the server and had some of the same scalability and dynamic data problems of the old version.
    The guy that implemented the feature joined Microsoft in 1997, and would not start working on it until 1998 and the work did not start until 1998 (he said "probably in late 1998"). In fact, according to that history, they had to scramble to get the feature into IE5 (finally released in March 1999):

    Meanwhile the IE project was just weeks away from beta 2 which was their last beta before the release. This was the good-old-days when critical features were crammed in just days before a release, but this was still cutting it close. I realized that the MSXML library shipped with IE and I had some good contacts over in the XML team who would probably help out- I got in touch with Jean Paoli who was running that team at the time and we pretty quickly struck a deal to ship the thing as part of the MSXML library. Which is the real explanation of where the name XMLHTTP comes from- the thing is mostly about HTTP and doesn't have any specific tie to XML other than that was the easiest excuse for shipping it so I needed to cram XML into the name (plus- XML was the hot technology at the time and it seemed like some good marketing for the component).
    Which is at odds with Bosworth's claim that they helped invent AJAX in 96-97.

    Like many people at the time, the idea of calling code on the server was around, Netscape even shipped in 1997 shipped a browser that contained an IIOP client (IIOP is a binary protocol, part of CORBA) that allowed the browser to communicate with IIOP servers on the other end:

    http://cgi.netscape.com/newsref/pr/newsrelease389. html [netscape.com]

    Forté and Netscape have already begun work on this seamless access. Forté has exposed its services to IIOP and is working with Netscape to allow Visual JavaScript to call these and other IIOP-components. Using Netscape Visual JavaScript, enterprise developers can rapidly build Crossware, a new category of on-demand applications that run across networks, operating systems and platforms and are based on open standards. Crossware is an ideal mechanism for customers to take advantage of the distributed functionality of Forté applications within an Intranet or Extranet environment.
    This was part of the "Netscape ONE" an effort to create a fully web-based development platform.

    At the time Netscape was touting the benefits of using this new API as a way of building rich applications. So the idea predated Microsoft and Bosworth, but never got mass adoption.

    So who came up with the idea first is hard to tell. But it seems obvious that Ajax did not originate within Bosworth's own team in the 96-97 time frame, but in another team: the Exchange group in late 1998 to 1999.

    As they say, "Success has many fathers, and failure is an orphan."

  • Another Reason (Score:3, Interesting)

    by RAMMS+EIN ( 578166 ) on Wednesday January 31, 2007 @03:28AM (#17825188) Homepage Journal
    While I mostly agree with Bosworth's explanation, I have one thing to add. One reason that DHTML didn't succeed at first is that developers did not want to use it. I was doing DHTML in 1997 or thereabouts. Friends of mine have been doing it since at least 2000. All of us, at some point, came up with the plan to implement a desktop-like GUI environment using JavaScript and HTML. But all of us eventually backed out. The reason is that we realized we just weren't using the right tool for the job. Whatever you do, you're going to end up making lots of HTTP requests and sending enormous amounts of JavaScript down the tubes. Also, web browsers were and still are slow and lacking some controls and features one would want to use in interactive applications. I briefly campaigned for adding some simple, useful features, but, after ten years, none of them have been added yet. Eventually, I just lost interest.

    The landscape changed when toolkits started to become available that hid all this madness from developers. Nowadays, you can develop DHTML apps in sane languages, and have all the crud that is needed to make things sort of work in browsers be automatically generated. Coupled with faster computers and faster network connections, both the developer and the end user get an acceptable experience. I think that's what really caused DHTML to take off.

    And yes, I'm saying DHTML, rather than AJAX, because XmlHttpRequest is just one way to poll the server; the essential feature is dynamically updating the page.

Slashdot Top Deals

Ocean: A body of water occupying about two-thirds of a world made for man -- who has no gills. -- Ambrose Bierce

Close