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.'"
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.
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.
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.
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.
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.
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.
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
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.