Bosworth On Why AJAX Failed, Then Succeeded 265
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.'"
...has yet to succeed... (Score:4, Insightful)
Pre XMLHTTPRequest (Score:3, Insightful)
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.
Re:...has yet to succeed... (Score:4, Insightful)
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)
* 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.
Thin and Thick Clients are not Mutually Exclusive (Score:5, Insightful)
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.
Why Bosworth Failed with AJAX in 97 (Score:5, Insightful)
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.
Re:...has yet to succeed... (Score:3, Insightful)
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.
Did I missed something... (Score:2, Insightful)
Re:i hear... (Score:5, Insightful)
Re:Javascript can be disabled... (Score:3, Insightful)
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.
Re:...has yet to succeed... (Score:5, Insightful)
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:...has yet to succeed... (Score:1, Insightful)
This cannot possibly be correct.
If you are referring to the original design of early web browsers, well then you also have to consider simple things like inline images and bookmarking to be beyond the domain of web browsers — after all, they were never originally designed to do that either.
If you are referring to the design of modern web browsers, well that's clearly not true because they do include this functionality.
You are assuming a premise that any additional features that weren't part of the original design must necessarily compromise the design of that software. This isn't the case; software not only can grow beyond original intentions, it usually does. The world would be a much poorer place if people stuck to their original plans instead of acting on new ideas.
Re:...has yet to succeed... (Score:3, Insightful)
Isn't that what X-Windows was designed for ?
GoogleMaps--Killer App is Super Simple (Score:2, Insightful)
Re:...has yet to succeed... (Score:1, Insightful)
He's saying that adding certain features to browsers to allow functionality that the original design didn't anticipate...
And like I'm saying, there's this unhealthy obsession with the original design that you two need to rid yourselves of. Why are you holding "the original design" up as infallible? The original design had constraints of much slower computers, much slower net connections and much smarter users. It was designed for technical documents published by scientists. The original design was not perfect! The original design was improved years ago! Leave the original design in the past where it belongs!
AJAX will never succeed... (Score:5, Insightful)
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:...has yet to succeed... (Score:5, Insightful)
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:Me too. (Score:4, Insightful)
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:AJAX will never succeed... (Score:5, Insightful)
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.