Slashdot Mirror
Bosworth On Why AJAX Failed, Then Succeeded
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.'"
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."
... 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.
"The need to build the internet comes from something inside us, something programmed... something we can't resist."
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.
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...
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 association previously described.
Having subliminally caused hundreds of slashdot readers to equate him as such, he is then lent a slightly higher credence as "a good ol' boy" from "way back" who has obviously had a lot of experience.
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.
Teenagers.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
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.
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
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, ClickOnce, XAML, XBAP, and WPF/E.
It's just a matter of time before these things catch on.
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.
Try putting 100 users of said web app on your network and watch your traffic surge.
In a band? Use WheresTheGig for free.
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.
.selectSingleNode and .selectNodes functions of the XMLDocument object. Thankfully Mozilla, Opera and the KHTML team picked up on that pretty fast.
Microsoft was also the first to support the
For a site about things like basic rights, Slashdot users sure do like to censor "dissent".
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.
"...then I'm happy and sad for it"
Sit, Ubuntu, sit. Good dog.
Most people agree that AJAX is a silly acronym. (I personally think DHTML is much sillier). Let's examine it.
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.
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.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
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 problems like security and validation. If not having it enabled can affect OTHER people, your program's designed wrong; if it only affects the person who doesn't have it enabled, that's fine.
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 in the browser" kludges. That leaves easy cross-platform deployment as the only thing AJAX has going for it.
What the AJAX thing shows is that the time has finally come for Java.
Niiiiice. I'm pretty sure that is NOT how you spell nice! ;)
music lover since 1969
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.
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 AJAX. The way it works is: if you're about to go to a cell for which the image is not already downloaded, it is triggered to go get it. That's it. It just gets images as needed. No hard-core calculations or anything. So simple because the job it's doing is really simple.
Yeah, and Exchange 2000 used XML & Javascript for a massive chunk of its functionality. Then again, 5.5 OWA had done a bunch of javascript (but XML, not so much).
www.voiceofthehive.com - Beekeeping and Honeybees for those who don't.
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.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
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.
It breaks my pluginses, my precious!
http://www.alexhopmann.com/xmlhttp.htm
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: 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): 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
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."
Where exactly do you see it's deprecated? W3schools doesn't mention it, Wikipedia does neither, and on the W3 page for iframes nothing is mentioned about deprecation. If you mean the oh so hip use of using a hidden iframe to send all kinds of crap back and forth instead of the XHR object, then yes.
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.
Please correct me if I got my facts wrong.