![The Internet The Internet](http://a.fsdn.com/sd/topics/internet_64.png)
![Businesses Businesses](http://a.fsdn.com/sd/topics/business_64.png)
![Google Google](http://a.fsdn.com/sd/topics/google_64.png)
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.'"
Me too. (Score:5, Interesting)
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."
Re: (Score:2)
Re:Me too. (Score:5, Funny)
It was a high school web design class. By which I mean it was WYSIWYG-based, no HTML, no JS, no coding. The irony lies in the fact that I still couldn't pass it.
Watching that teachers house burn down was one of the greatest feelings I've ever had, and for only the cost of a liter of gasoline...
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: (Score:2)
Re:Me too. (Score:5, Funny)
Re: (Score:2)
I'm curious, how did you overcome the JavaScript security restriction against HTTP-fetching pages from more than one domain?
Re: (Score:3, Informative)
Re: (Score:2)
at JC a long time ago, the instructor
did not know C when he started the course,
I probably knew more of C than he did at
the end, he gave me a "C" in the class.
Re: (Score:2)
Re: (Score:3, Funny)
<assistant type=limerick>
<prompt>You appear to be writing a limerick...</prompt>
<suggestion>
There was once an instructor at JC
Who taught but didn't even know C
A student of course
complained because
in the end he saw a C for C
</suggestion>
<assistant>
Re: (Score:2)
I know about the formatting, but I just end up
doing it. I really dont know why, or where it
came from. See what I mean?
Re: (Score:2)
Someone (was it you?) made a similarly formatted post sometime back that someone else commented looked a bit like poetry.
The words may be clear
but who can know the reasons,
why the words lie so.
Re: (Score:2)
few comments ( and complaints... ). I have
noticed that there are a few others that
do it also. Might be the same form of
brain damage I have.
The reason AJAX worked this time.. (Score:4, Interesting)
Re: (Score:2)
In 2001, I needed this functionality, but I had an impossible time finding any documentation on whether it was even possible to do anything like XMLHttpRequest in a browser, especially in a cross platform way. One of the biggest changes is that we know what to search for now that the AJAX name took off following Google Maps' success.
As a C/Java programmer who had to cross over to some minor web development for an in-house app, I couldn't find the righ
Re: (Score:2)
But yup, it wasn't cross-platform, simply because the same thing doesn't exist for other browsers (not without jumping through hoops anyway).
Re: (Score:2)
...has yet to succeed... (Score:4, Insightful)
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)
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: (Score:2)
Well, IFRAME is deprecated, as are many other horrendous mistakes.
Re: (Score:2)
Re: (Score:3, Insightful)
Isn't that what X-Windows was designed for ?
Re: (Score:2)
Re: (Score:2)
No, he really isn't. He's saying that adding certain features to browsers to allow functionality that the original design didn't anticipate compromises the value and usefulness of that functionality relative to a design that included the functionality from the start.
Re: (Score:2)
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: (Score:2)
With apologies to Steve Taylor, trying to build an application platform on top of the Web is like trying to make an octopus by nailing extra legs on a dog.
Re: (Score:3, Interesting)
So what? *ALL* technology evolves this way. Baby steps, incrementally improving on previous technologies. Why do we use 60-cycle A/C? Because Nikolai Tesla wanted to power the entire earth with radio power, and the resonating frequency of the Earth is 60 Hz. Is 60 Hz the optimum
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.
Re: (Score:2)
Gee why don't you just say "By the way, it must be pessimised to the lowest common denominator using poorly supported and poorly implemented standards"
I'll just throw out one suggestion that is older than anything you mentioned and certainly a better solution for remote applications than AJAX:
Terminal and Telnet
Write your server side in any language you would like,
Re: (Score:2)
Re: (Score:2)
(Thank God for curses and termcap)
Re: (Score:2)
Re: (Score:2)
The only non-open thi
Re: (Score:2)
Re: (Score:2)
There are open actionscript compilers out there, but even so
Try using MTASC to compile any nontrivial AS2 app that was written for Adobe's tools, and you'll find out you can't, because the version 2 components aren't legally available without buying Flex. If you're willing to pay for Flex, they'll give you a license to let you use the version 2 components, but you'll have to patch them extensively to make them work with MTASC. Try using an open-source compiler to compile AS3 code that was written for Fle
Re: (Score:2)
In the Mozilla implementation, it uses XBL to allow you to write behind-the-scenes JavaScript (a la XUL) to implement presentation stuff that keys off the appearance and data type declarations to enhance the presentation.
See http://en.wikibooks.org/wiki/XForms [wikibooks.org]
Re: (Score:3, Informative)
http://en.wikibooks.org/wiki/XForms/Calculator [wikibooks.org]
I can't wait!
Re: (Score:2)
Recently I wrote an entire webmail application with a small PHP back end that outputs the mailbox list, the message list, and individual messages as XML (each addressed by a URL using the REST [wikipedia.org] methodology -- XForms works very well with REST). The UI, written entirely in XHTML+XForms, is 300 lines.
There's a little bit of JavaScript used to supplem
Re: (Score:2)
I don't think WHATWG's work is XForms on steroids, and I don't think WHATWG thinks it either. WHATWG explicitly rejects XML and explicitly rejects the separation of data from presentation (if I understand what I read correctly). Their emphasis is on incremental addition of attributes to HTML4 to add new behaviors that add incremental value but aren't required.
XForms starts with the premise that XML is the data format, and that you want to keep your data in one plac
Re: (Score:2)
Why would you consider Python, Ruby, or
Re: (Score:2)
* Already installed on every internet-connected desktop.
Re: (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.
Re: (Score:2)
Re: (Score:2)
The big flaw is this stupid idea that we will find the One True Way that every application needs to work. I don't want to r
Re: (Score:2)
I don't think the problem is that there are ways you should not use AJAX, but more that there are NO ways that you should use AJAX. And this is coming form a, Pre AJAX as a term, AJAX developer. I'm not talking without knowing what I am talking about. I was the driving force behind a very successful XUL/AJAX based application. It worked cross platform, with the platform specific UI, was relatively fast and extremely scalable. The was one "Page L
Re: (Score:2)
Maybe the browser was never originally intended for this use, but PCs were probably never originally intended for any of the stuff that's being done with it.
There may be better ideas out there, what it takes is someone to figure out how to make them worthwhile.
Re: (Score:2)
And how many of them run inside a sandbox that every single web user is already familiar with, and has an installed copy of?
Web apps work because everyone already has client application installed (the browser), and uses it regularly.
I'm sure you *could* come up with a better "universal client". I'm sure there are already some out there. But the browser's already installed on every PC out there, and users don't want to install new software.
Re: (Score:2)
Re: (Score:2)
Well, it allows formating of content by people who can't program. Whether that's good or bad is a matter of opinion.
Ahem... (Score:5, Funny)
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...
Re: (Score:2, Funny)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
Java Applets can provide even better functionality
Agreed!
but unfortunately no one seems to be able to develop responsive
Not always... there is Swing.
Out of necessity, I wrote a suite of applets that given XML provide common controls like trees, lists and popup menus. I know there are other projects out there that do this, but they did not exist at the time I started the projects; besides it's fun to maintain. They are databound and in some cases threaded to provide a consistent user experience. When I build a complex UI, I use them all of the time. Yes they are free and open source, but I'm the only person wh
Asynchronous xml, something (kinda) new from M$ (Score:5, Funny)
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.
Re: (Score:2)
I was probably joking. Funny, Melinda is a name derived from the greek, the greek root meaning something sweet, used for honey and... apple
Melon (greek), malum (latin), mela (italian, we have Melinda brand apples too).
Microsoft rebel (Score:2)
I predict that 90% of the comments here will be people saying the use AJAX things in the 1990s too.
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.
Re:Thin and Thick Clients are not Mutually Exclusi (Score:2)
Re: (Score:2)
Re: (Score:2)
But, as the previous poster mentioned,
Of course, this doesn't really help people targeting more than Windows. Mono helps that a bit.
Re: (Score:3, Interesting)
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: (Score:2)
The biggest problem I found *wasn't* browser support. There was lots of great stuff to work with. Only, it was completely different from browser to browser.
Li
Did I missed something... (Score:2, Insightful)
AJAX == Thick Client (Score:2, Interesting)
Try putting 100 users of said web app on your network and watch your traffic surge.
Am I the only one who thought... (Score:3, Funny)
AJAX is a silly acronym (Score:4, Interesting)
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.
Re:AJAX is a silly acronym (Score:5, Funny)
Re: (Score:2)
Well, if you ask me, it's just a blatant wannabe move. Wa-ay back in the mists of 2001, the inimitable Damian Conway created the Acme::Bleach [cpan.org] Perl module. Part of the stunningly [sic] inspired Acme [cpan.org] series of Perl modules, it creates the cleanest code ever in the history of programming.
Now some web wanker with a re-tread idea from the nineties indulges in a bit of shameless self-promotion, whoring himself first to Microsoft, then to Google, and when
Re: (Score:2)
We Need a Generalized Acronym (Score:4, Funny)
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.
Re: (Score:2)
While I agree that we need a generalized term...
DAMN. That is one of the funniest things I've seen in a long time.
AJAX not adopted earlier due to lack of broadband? (Score:2)
But often, the apps which use AJAX are also using big graphics and video, cumbersome libraries and other bling that require high bandwidth to be enjoyable.
1997 called to say it put Java on hold (Score:2, Interesting)
Someone remind me... (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
GoogleMaps--Killer App is Super Simple (Score:2, Insightful)
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: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.
The story of XmlHttp (Score:4, Informative)
http://www.alexhopmann.com/xmlhttp.htm [alexhopmann.com]
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."
Another Reason (Score:3, Interesting)
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.
Re: (Score:3, Funny)
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 associati
Re:framework (Score:5, Funny)
Re:i hear... (Score:5, Informative)
Microsoft was also the first to support the
Re: (Score:2, Informative)
Re: (Score:2)
Re:i hear... (Score:5, Insightful)
Re:i hear... (Score:4, Informative)
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.
Re: (Score:2)
Re: (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 proble
Re: (Score:2)
Re: (Score:3, Funny)