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."
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...
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.
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.
See this diagram, and in particular the arrow from "people who refuse to use the word AJAX to "AJAX programmers"
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
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."