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."
... it has a name that people can easily refer to and brand as a technology. I'd seen/used AJAX implementations before, but now I have something to put on my resume. Simple as that.
"The need to build the internet comes from something inside us, something programmed... something we can't resist."
Try putting 100 users of said web app on your network and watch your traffic surge.
In a band? Use WheresTheGig for free.
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.
Nobody in their right minds runs random Java applets or activeX controls off the web, the same should be true of javascript. The hand-waving about AJAX ignores the fact that not all clients fully implement the W3C DOM or scripting. Every time it's mentioned, graceful degradation is brought up but that's crap because it relies on developers most of whom do not write documents that degrade. Nobody wants to be writing large apps in javascript and neither was HTTP designed for the current crop of "we can do it in the browser" kludges. That leaves easy cross-platform deployment as the only thing AJAX has going for it.
What the AJAX thing shows is that the time has finally come for Java.
I'd say at least 80% of the AJAX I see is being used not because it's the best thing but because it has the best marketing.
I am trolling
The Flex IDE and the Charting package is US$750, the Flex SDK which includes the command line MXML -> SWF compiler and the whole component library (ie. UI controls, RPC, everything else) is a free download from Adobe. Excluding charts, which is a component library anyway and not dependant on the IDE, you can build everything with the free SDK that you can with the package. You could always write your own charting components or find an open source one if you needed charts.
That's hilarious. I've been doing it professionally since the 90s.
That's a matter of opinion. Certainly there are some things that are clumsy workarounds. But that doesn't mean that every browser advancement in the past fifteen years is a clumsy workaround. Stating that "it's not part of the original design therefore it's bad" is monumentally stupid.
No it doesn't. It assumes that the user transitions from one place to another. There's nothing about that which says that documents must be static.
Now who knows fuck all about web programming? The reason why you think this is broken is because you don't know how the back button works. Seriously. Read the specification. The back button wasn't designed to provide a transparent view of the current system state. It was designed to allow the user to view what they have previously viewed.
If you're trying to fudge the back button to provide an up-to-date view, you are trying to do the opposite of what the back button was designed to do. You are taking a user interface feature designed to show the past and trying to make it show the current.
Please learn JavaScript from something better than the average "in 21 days" book. This is simply not true.
Different to what? Some of your rant simply doesn't make sense because you are missing bits out. I obviously touched a nerve somewhere, but you can't expect me to address all of your points unless you remain coherent.
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.... // Lots more ranting //
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 for power transmission over long distances? Nope.
But that's what was there before, and the step of changing that would be excessively expensive - so that step never gets taken.
Rant rant rant... 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.
Except that it isn't. Your 386sx DOS application works on one computer. It requires software to be installed. It doesn't work concurrently with other applications. If you forget your disks, you can't use your Mother's computer in a pinch over the holidays while you are visiting your folks. The software includes you and only you, it has no access to other information. You can't get current stock quotes. It has an inconsistent user interface. You can't copy/paste information from other running apps. You have to worry about backups, viruses, computer crashes. Your DOS application is not PC, Mac, Linux, Unix, BEOS, AND PalmOS compatible. How much longer should I go on?
Seems that you're forgetting an awful lot of the benefits that the "new model" as it's evolved has given you. Sorry that your development tools cause you so much frustration just to get a dynamically generated application out. Consider using a language designed for web development - I recommend PHP.
I personally LOVE web-based development. Combined with database transactions, sessions, HTML templates, etc. I get a rich, simple, RAPID development environment that's let me write truly large applications in record time, coordinating the efforts of hundreds of people in realtime, with an incredibly small initial investment. Because I know the program runs and then dies, I don't have to worry about memory deallocation, garbage cleaning, etc.
Debugging is a snap, because I can write a page script to rollback the transaction, so I can just hit reload over and over until I work out all the kinks. And then update the script to commit the transaction and move on to the next stage of application development. So much better than client-side development, where you have to close the app, recompile, and re-run before you can even try again!
Compatibility problems are really minor when compared to client-side development - yes there are browser issues, but I can test in IE 6, IE 7, and Firefox and call it a day. (I develop for FF first, then test in IE, THANK YOU IES4LINUX!) When I need to ensure a consistent document, outputting in PDF has worked very well with almost no complaints or support calls.
Again, if browser-based development is so incredibly painful for you, I suggest improving your development tools. Web-based development is a breeze!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
While I mostly agree with Bosworth's explanation, I have one thing to add. One reason that DHTML didn't succeed at first is that developers did not want to use it. I was doing DHTML in 1997 or thereabouts. Friends of mine have been doing it since at least 2000. All of us, at some point, came up with the plan to implement a desktop-like GUI environment using JavaScript and HTML. But all of us eventually backed out. The reason is that we realized we just weren't using the right tool for the job. Whatever you do, you're going to end up making lots of HTTP requests and sending enormous amounts of JavaScript down the tubes. Also, web browsers were and still are slow and lacking some controls and features one would want to use in interactive applications. I briefly campaigned for adding some simple, useful features, but, after ten years, none of them have been added yet. Eventually, I just lost interest.
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.
Please correct me if I got my facts wrong.