Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Bosworth On Why AJAX Failed, Then Succeeded

Posted by kdawson on Tue Jan 30, 2007 05:37 PM
from the before-its-time dept.
The Internet Businesses Google
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.'"
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Bosworth On Why AJAX Failed, Then Succeeded 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

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

          • Re:Me too. (Score:4, Insightful)

            by swillden (191260) * <shawn-ds@willden.org> on Tuesday January 30 2007, @11:55PM (#17824184) Homepage Journal

            Lesson I learnt, NEVER go out of your way to do something cool on a school assignment. Look at the requirements, meet the requirements as well as possible, hand it in.

            Bah.

            Are you going to school to get a grade or to get an education? If the former, then by all means focus on giving the instructor exactly what he/she wants. If the latter, then put in the extra effort, do what's cool, and accept that some instructors will dock your grade because you confused them. Obviously, if you want to come out of the experience with a degree, you do have to play their game enough to pass the classes -- but don't, by any means, allow your focus on getting a degree to prevent you from getting the best education you can from the experience.

    • 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 ;)
      • 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>

  • 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

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

      • 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 alan_dershowitz (586542) on Tuesday January 30 2007, @10:06PM (#17823362)
          You obviously know fuck-all about web programming. Everything done to make dynamic web applications is a clumsy, tacked-on workaround to get around the built-in, inherent static document metaphor in all HTML browsers. Take the back button. It FUNDAMENTALLY ASSUMES STATIC DOCUMENT NAVIGATION. And you cannot change this. There was never any facility to define your own navigation on this button. Guess what, this breaks dynamic page navigation because whatever is in your browser cache could be outdated system state.

          So, to get around it you take advantage of some HTTP headers to convince the browser to do a round-trip every time the back button is hit, so you can serve up a fresh page--except that it often doesn't work, because you are using those headers for something they were never intended for, so several browsers all interpret them slightly differently from the way you want if they honor them at all, which you have literally no control over. And you can't reliably detect what browser the client is using to be sure, because there should have never been a need to do so because it was never intended to be doing what you want it to do. AND browsers WERE supposed to all interpret content the same for the same HTML. But they don't and it doesn't, so let's stack on a few more workarounds to glean out what the browser is. Then you can hack up a solution that'll break when MS releases an update.

          All this because we're stuck with the back button while breaking the design metaphor! But there's more.

          I mentioned the round trip. For years now to simulate a user interface, you essentially had to mimic playing chess by mail. You collect form input, interpret it and deliver back a dynamically generated page containing the requested info. This is why the back button can fuck you so badly. You are using forms for something they were never intended for, and it shows, because they are wholly inadequate for the job. If you want to ensure that an app works without javascript, you are stuck making concessions in your visible page design. Buttons have to be labelled a certain way. You have to arrange information to fit the hierarchical document model (notice the word "document" there) which may not fit your visual needs. You can't submit a form to a different location without javascript, which your client may or may not have. HTML form elements are not really fine-grained enough for many application needs, so to simulate this, let's kludge up some more javascript glue to make them act the way we want.

          So you've made a commitment to Javascript, you've got your AJAX, which would seem to solve a lot of these problems. Now you can asynch requests back to the server and dynamically update the document object model to make it act like a real desktop app.

          CONGRATULATIONS! It took over a decade of "technology progress", a browser that eats up to 30 megabytes and a more than a gigahertz of CPU cycles to simulate badly what a desktop app on a 386SX with 640K of RAM could do in the 1980's. And it still doesn't work right because all the leftover cruft from the discarded metaphor you subverted.

          Look, you are right that software can grow beyond it's original intentions. But browsers weren't hurt by complementary, evolutionary enhancements like bookmarks and inline images. When you start breaking the model, problems start popping up and you spend an inordinate amount of time on plumbing. It becomes painfully obvious that what you are doing is working IN SPITE of the medium. You need to consider moving on. I love the idea of a markup-defined, styled UI that you can capture events and handle using a simple but powerful interpreted programming language. It's funny that that's essentially what Firefox is (Chrome, CSS, XUL and Javascript), and it's built for running what's now an incredibly shittier version of itself.

          I wrote a very long rant. It's not actually too bad doing web development and programming, but you see the same problems over and over again dealing with your code, inscribed in books and on forums. Elaborate frameworks are constructed to hide and minimize them. Thousands of man-hours and fragile cathedrals of complexity all the direct result of professionally ramming a square peg into a round hole.

          • Re: (Score:3, Interesting)

            by mcrbids (148650)
            Everything done to make dynamic web applications is a clumsy, tacked-on workaround to get around the built-in, inherent static document metaphor in all HTML browsers. Take the back button. It FUNDAMENTALLY.... // Lots more ranting //

            So what? *ALL* technology evolves this way. Baby steps, incrementally improving on previous technologies. Why do we use 60-cycle A/C? Because Nikolai Tesla wanted to power the entire earth with radio power, and the resonating frequency of the Earth is 60 Hz. Is 60 Hz the optimum

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

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

      • 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

    • 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

  • 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

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

        • Re: (Score:3, Interesting)

          by Yakman (22964)
          The Flex IDE and the Charting package is US$750, the Flex SDK which includes the command line MXML -> SWF compiler and the whole component library (ie. UI controls, RPC, everything else) is a free download from Adobe. Excluding charts, which is a component library anyway and not dependant on the IDE, you can build everything with the free SDK that you can with the package. You could always write your own charting components or find an open source one if you needed charts.

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

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

  • 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.
    • I believe he is using a purposeful grammar mistake to intrinsically connect his comments with a feeling of antiquity. Namely he's trying to cause a subconscious connection to popularized caveman vernacular, such as "Me build big fire!"

      As the casual reader will not quite catch the absurdity of the underlying pronoun use, but more likely just catch that the pronoun is improperly positioned (me before group), that incorrect pronoun is then only caught in the subconscious resulting in that caveman associati

    • Re:i hear... (Score:5, Informative)

      by Kalriath (849904) on Tuesday January 30 2007, @06:37PM (#17821574)
      Actually, strangely, he speaks truth. Since V4 or V5 or something of Internet Explorer, the Microsoft.XMLHTTP object shipped with the browser. Before that, it was a free download. This is the core of what XMLHTTP is based on - confusingly enough (and perhaps frighteningly) Microsoft was the first to implement XMLHttpRequest in their browser. Unfortunately, it was ActiveX based. But it did get the other browser makers thinking "how about..." which is something that I can only consider to be a Good Thing for us developers and users.

      Microsoft was also the first to support the .selectSingleNode and .selectNodes functions of the XMLDocument object. Thankfully Mozilla, Opera and the KHTML team picked up on that pretty fast.

    • Re:i hear... (Score:5, Insightful)

      by abigor (540274) on Tuesday January 30 2007, @06:39PM (#17821596)
      Actually, XmlHttpRequest/XMLHTTP was invented by Microsoft for IE 5.0. They have a credible claim to the whole Ajax thing. Wikipedia has a nice history of it. I guess this is tough to swallow for people who place a lot of emotional value in their software.

    • Re:i hear... (Score:4, Informative)

      by dedazo (737510) on Tuesday January 30 2007, @07:01PM (#17821828) Journal
      The first successful, viable, externalized commercial "AJAX" application was Outlook Web Access (OWA). And it was that until GMail "discovered" out-of-band JS requests and some blogger re-christened it "AJAX".

      I guess there's a joke here somewhere about Google having to steal talent from Microsoft, given that Microsoft is usually accused of the same thing.

    • Re: (Score:3, Insightful)

      by EvanED (569694)
      Huh?

      Graphics can be disabled too. Are they only useful for toys?

      Heck, I can telnet into a host and issue the HTTP request myself. HTML rendering can be disabled too. Is HTML only useful for toys?

      If there's an application that needs Javascript, then the user will turn on Javascript or go somewhere else. If you don't care about the latter response, or if there's no alternative, then Javascript is a fine solution. The problem with "Javascript can be turned off" is if you don't take this into account for proble

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.