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."
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...
* Vendor independent GUI language (eg, WhatWG's stuff or XUL)
* Vendor independent cross-platform client language (EcmaScript+W3CDOM, Python, Ruby, maybe
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.
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".
See this diagram, and in particular the arrow from "people who refuse to use the word AJAX to "AJAX programmers"
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.