Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Bosworth On Why AJAX Failed, Then Succeeded

kdawson posted more than 6 years ago | from the before-its-time dept.

The Internet 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.'"

cancel ×

265 comments

Sorry! There are no comments related to the filter you selected.

AJAX? stop the web 2.0 buzzword bullshit (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#17820828)

you didnt invent "ajax" in 1996, its part of the fucking javascript language.. and it didnt work then because your a shitty coder.

Re:AJAX? stop the web 2.0 buzzword bullshit (-1, Troll)

Anonymous Coward | more than 6 years ago | (#17821192)

its part of the fucking javascript language

Haha. No, asshole. The technology you Firefox- and Google-fanbois love so much has been developed by Microsoft. Go suck a fat wad of semen out of Billy's greasy cock, you fucking loser.

Re:AJAX? stop the web 2.0 buzzword bullshit (0, Redundant)

telchine (719345) | more than 6 years ago | (#17821224)

you didnt invent "ajax" in 1996, its part of the fucking javascript language.. and it didnt work then because your a shitty coder. I agree with your sentiment, but not your language (both the harshness and the poor spelling)

Re:AJAX? stop the web 2.0 buzzword bullshit (0, Redundant)

Thuktun (221615) | more than 6 years ago | (#17821490)

you didnt invent "ajax" in 1996, its part of the fucking javascript language.. and it didnt work then because your a shitty coder. I agree with your sentiment, but not your language (both the harshness and the poor spelling)
You're replying to an AC about language and spelling, and you included your response in the quote. Niiiiice.

Re:AJAX? stop the web 2.0 buzzword bullshit (2, Funny)

djdavetrouble (442175) | more than 7 years ago | (#17822306)

Niiiiice. I'm pretty sure that is NOT how you spell nice! ;)

Compatability (1)

bendodge (998616) | more than 6 years ago | (#17820836)

It was a browser standards issue...it didn't work the same for everyone a few versions ago, now it is fairly consistant.

i hear... (0)

User 956 (568564) | more than 6 years ago | (#17820848)

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.

I hear that this guy also invented the internet.

Re:i hear... (5, Informative)

Kalriath (849904) | more than 6 years ago | (#17821574)

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.

Microsoft was also the first to support the .selectSingleNode and .selectNodes functions of the XMLDocument object. Thankfully Mozilla, Opera and the KHTML team picked up on that pretty fast.

Re:i hear... (0)

Anonymous Coward | more than 7 years ago | (#17821908)

The origional MS remote scripting used to drive us nuts, we had a huge system written in it, and there was nothing like it at the time. The debugging capabilities were poor and it would lock up all the time.

Re:i hear... (4, Insightful)

abigor (540274) | more than 6 years ago | (#17821596)

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.

Re:i hear... (3, Informative)

dedazo (737510) | more than 7 years ago | (#17821828)

The first successful, viable, externalized commercial "AJAX" application was Outlook Web Access (OWA). And it was that until GMail "discovered" out-of-band JS requests and some blogger re-christened it "AJAX".

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:i hear... (1, Informative)

Anonymous Coward | more than 7 years ago | (#17821876)

Xmlhttprequest wasn't necessary. You could get similar functionality using a hidden IFrame to load and execute JavaScript.

from TFA (1)

Roland Piquepaille (780675) | more than 6 years ago | (#17820878)

For instance, Bosworth said a cardinal rule of his is KISS, or, in his words, "Keep It Simple and Stupid." Gestures like tooling, icons, right-click and drag-drop are too obscure, he said

I guess nobody listens to him at Microsoft then...

AJAX killed Twofo (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#17820890)

Twofo [twofo.co.uk] Is Dying

DC++ [dcpp.net] hub.twofo.co.uk:4144

It is official; Netcraft confirms: Twofo is dying

One more crippling bombshell hit the already beleagured University of Warwick [warwick.ac.uk] filesharing community when ITS confirmed that Twofo total share has dropped yet again, now down to less than a fraction of 1 percent of all file sharing. Coming hot on the heels of a recent Netcraft survey which plainly states that Twofo has lost more share, this news serves to reinforce what we've known all along. Twofo is collapsing in complete disarry, as fittingly exemplified by failing dead last in the recent Student comprehensive leeching test.

You don't need to be one of the Hub Operators to predict Twofo's future. The hand writing is on the toilet wall: Twofo faces a bleak future. In fact there won't be any future at all for Twofo because Twofo is dying. Things are looking very bad for Twofo. As many of us are already aware, Twofo continues to lose users. Fines and disconnections flow like a river of feces [tubgirl.com] .

N00b Campus users are the most endangered of them all, having lost 93% of their total share. The sudden and unpleasant departures of long time Twofo sharers fool_on_the_hill and Twinklefeet only serves to underscore the point more clearly. There can no longer be any doubt: Twofo is dying.

Let's keep to the facts and look at the numbers.

Sources indicate that there are at most 150 users in the hub. How many filelists have been downloaded? Let's see. 719. But 1621 IP addresses have been logged, and 1727 nicks have been sighted connecting to one user over the last term. How many searches are there? 600 searches in 3 hours. The highest sharer on campus, known as "firstchoice", or Andrew.Maddison@warwick.ac.uk in real life, was sharing over 1 TiB, despite working in ITS and not being on the resnet. He's only there so people off campus who think they're too good for bittorrent can continue to abuse the University's internet connection.

Due to troubles at the University of Warwick, lack of internet bandwidth, enforcements of Acceptable Usage Policies, abysmal sharing, retarded leechers, clueless n00bs, and ITS fining and disconnecting users, Twofo has no future. All major student surveys show that Twofo has steadily declined in file share. Twofo is very sick and its long term survival prospects are very dim. If Twofo is to survive at all it will be among p2p hardcore fuckwits, desperate to grab stuff for free off the internet. Nothing short of a miracle could save Twofo from its fate at this point in time. For all practical purposes, Twofo is dead.

Fact: Twofo is dying

Me too. (5, Interesting)

linkedlinked (1001508) | more than 6 years ago | (#17820902)

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."

Re:Me too. (1)

aicrules (819392) | more than 6 years ago | (#17820938)

Not sure what the ironic part of this is, AJAX has nothing to do with being user friendly...

Re:Me too. (5, Funny)

linkedlinked (1001508) | more than 6 years ago | (#17821406)

Yeah, sorry, let me clarify-
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. (1)

hobo sapiens (893427) | more than 7 years ago | (#17821992)

Your statement is a bit ambiguous, but if you are implying that AJAX applications are not user-friendly then you are confusing technology with implementation. AJAX can make applications more user-friendly if done properly.

Re:Me too. (5, Funny)

mdobossy (674488) | more than 6 years ago | (#17820950)

And I've seen plenty of AJAX-based apps put out just this year that deserve a D- for user friendliness as well, so dont feel too bad ;)

Re:Me too. (1)

jamessnell (857336) | more than 6 years ago | (#17821452)

Wow, what a 'tard of a teacher you must have had. Annoying how common that sort of insanity is.

Resume? (0)

Anonymous Coward | more than 6 years ago | (#17821798)

What the fuck is a resume?
Are you doing something wrong if you got to sell yourself?
People buy me, like a pro

Re:Me too. (1)

DysenteryInTheRanks (902824) | more than 7 years ago | (#17821898)

I've been meaning to do something like this.

I'm curious, how did you overcome the JavaScript security restriction against HTTP-fetching pages from more than one domain?

Re:Me too. (2, Informative)

lysergic.acid (845423) | more than 7 years ago | (#17822188)

just have a server-side script fetch the page from the remote site?

The reason AJAX worked this time.. (3, Interesting)

xENoLocO (773565) | more than 6 years ago | (#17820908)

... 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.

Re:The reason AJAX worked this time.. (1)

currivan (654314) | more than 6 years ago | (#17821248)

This shouldn't be underestimated as a legitimate reason.

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 right search keywords to figure out how to do an unprompted request from the server. Maybe that's because the Microsoft execs didn't want to promote this guy's work.

Re:The reason AJAX worked this time.. (1)

AndroidCat (229562) | more than 7 years ago | (#17822162)

The first I'd heard of XMLHTTP was when spammers started using a secuity exploit in ActiveX to use it to load an executable and then save the nasty via AdoStream to disk. It wasn't until a couple years later that I read more and thought "Oh, so that's what it's for!" (Silly me, I'd been using it to pull all the jpgs from .. umm .. sites.)

me and a group of people??? (0, Troll)

Chineseyes (691744) | more than 6 years ago | (#17820934)

I apologize for being a grammar Nazi but I just could not help myself.

Re:me and a group of people??? (2, Funny)

aicrules (819392) | more than 6 years ago | (#17821006)

I believe he is using a purposeful grammar mistake to intrinsically connect his comments with a feeling of antiquity. Namely he's trying to cause a subconscious connection to popularized caveman vernacular, such as "Me build big fire!"

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 association previously described.

Having subliminally caused hundreds of slashdot readers to equate him as such, he is then lent a slightly higher credence as "a good ol' boy" from "way back" who has obviously had a lot of experience.

Re:me and a group of people??? (0)

Anonymous Coward | more than 7 years ago | (#17822348)

'me and a group of people'

strikes me as a blowhard... almost sounds as though he should say 'ME et al others' and just make his assention that much easier.

Nazi (0)

Anonymous Coward | more than 7 years ago | (#17821886)

I find your use of the term Nazi in a prerogative sense offensive

Nazis are people too, just remember that

Re:Nazi (0)

Anonymous Coward | more than 7 years ago | (#17822178)

Nazis are people too?

But so are aborted fetuses! They're people! Tasty bite-size morsels of 100% people!

Ahh, throw another one of those "shrimps" on the barbie.....

Never forget about the people!

...has yet to succeed... (4, Insightful)

xero314 (722674) | more than 6 years ago | (#17820958)

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.

Re:...has yet to succeed... (3, Insightful)

Rosco P. Coltrane (209368) | more than 6 years ago | (#17821130)

Exactly. The problem with web browsers is they were never meant to do any of the things we make them do today. They're essentially document viewers with the ability to retrieve documents remotely. Anything else added to it, especially things that need to maintain state consistency between pages or views, is a kludge and, as you say, a bandaid.

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... (4, Insightful)

rainman_bc (735332) | more than 7 years ago | (#17822028)

The problem with web browsers is they were never meant to do any of the things we make them do today

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... (1)

hobo sapiens (893427) | more than 7 years ago | (#17822100)

I have been thinking for a while now that we need some sort of "enhanced browser" if you will, something specifically designed to run applications, without all of the headaches that come with fat-client applications. This way you can easily deploy applications, have a common platform (the "browser"), and distribute the workload across client and server. It seems so obvious that it has to exist already.

Re:...has yet to succeed... (1, Insightful)

Anonymous Coward | more than 7 years ago | (#17822120)

The problem with web browsers is they were never meant to do any of the things we make them do today.

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... (3, Insightful)

cats-paw (34890) | more than 7 years ago | (#17822156)

"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."

Isn't that what X-Windows was designed for ?

Re:...has yet to succeed... (1)

AVonGauss (1001486) | more than 6 years ago | (#17821172)

Amen... I'd mod your post up higher, but it's already at the highest...

Re:...has yet to succeed... (5, Insightful)

Anonymous Coward | more than 6 years ago | (#17821222)

There are other, better, solutions to the client server paradigm.
And pray tell what are they? By the way, they must fulfill these needs,

* Vendor independent GUI language (eg, WhatWG's stuff or XUL)
* Vendor independent cross-platform client language (EcmaScript+W3CDOM, Python, Ruby, maybe .Net... that kind of thing)

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:...has yet to succeed... (0)

Anonymous Coward | more than 6 years ago | (#17821352)

"By the way, they must fulfill these needs"

Why? Because you say so?

Re:...has yet to succeed... (1)

xero314 (722674) | more than 6 years ago | (#17821506)

There are other, better, solutions to the client server paradigm.
And pray tell what are they? By the way, they must fulfill these needs,
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, just make sure your server supports the telnet protocol. It worked over 20 years ago and still works today. Do I think it's the best solution, not at all, but you wanted vendor independence.

Re:...has yet to succeed... (0)

Anonymous Coward | more than 6 years ago | (#17821640)

I thought so, you don't actually have an industry solution for OSS, Microsoft, IBM and Sun to agree upon.

Re:...has yet to succeed... (1)

xero314 (722674) | more than 6 years ago | (#17821742)

I thought so, you don't actually have an industry solution for OSS, Microsoft, IBM and Sun to agree upon.
And why would... hey wait a second, every single one of those have a telnet solution available.

Re:...has yet to succeed... (0)

Anonymous Coward | more than 7 years ago | (#17822008)

Still no serious answers for an industry-wide solution then?

Re:...has yet to succeed... (1)

Breakfast Pants (323698) | more than 7 years ago | (#17821888)

Will this be using windows or unix line breaks? Or mac?

Re:...has yet to succeed... (1)

Yakman (22964) | more than 6 years ago | (#17821696)

Flex is close (http://www.adobe.com/products/flex/). It might not be "vendor independent" but it's based on a lot of open standards and it's client platform has an extremely high penetration:

  • ActionScript 3 is based on the latest draft ECMAScript spec, includes goodies like E4X for painless XML parsing
  • There are open actionscript compilers out there, but even so...
  • The Flex 2 SDK (including the MXML compiler and the component library) is "free" (the Eclipse based IDE and Charting isn't)

The only non-open thing about it is the Flash Player, which may bug you. At least the Flash Player works the same on every browser, unlike HTML + Javascript.

I'm biased though, I just got a job at an Adobe partner.. :)

Re:...has yet to succeed... (0)

Anonymous Coward | more than 6 years ago | (#17821762)

Flex is pretty good. But yeah I don't think that companies like IBM or Microsoft would choose it because of the ties to Adobe. It's good tech though :)

Re:...has yet to succeed... (1)

illegalcortex (1007791) | more than 7 years ago | (#17821866)

Agreed on the whole Flex thing. And it's a remarkably good IDE for a 2.0 version (owes a lot of that to Eclipse). I can only imagine Flex Builder 5.0 or the like.

Re:...has yet to succeed... (1, Interesting)

m50d (797211) | more than 7 years ago | (#17822062)

We're not using HTML+JS because it's useless, it's because it is the best thing right now.

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.

Re:...has yet to succeed... (1)

leighklotz (192300) | more than 7 years ago | (#17822218)

Try XForms. It's vendor independent, standard, and aims to obviate 80% of scripting.
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:...has yet to succeed... (0)

Anonymous Coward | more than 7 years ago | (#17822378)

Hmmm... I think Mozilla/Firefox are now working on WhatWGs stuff (which -- to use a crappy metaphor -- is XForms on steroids). That XForm/WhatWG is heading in the right direction though :)

Re:...has yet to succeed... (2, Insightful)

sheddd (592499) | more than 6 years ago | (#17821404)

"I only hope that someone with the influence to change things figures this out and stops this web based madness"

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:...has yet to succeed... (1)

mandelbr0t (1015855) | more than 6 years ago | (#17821468)

It's a marketing success. Everyone has now heard the AJAX buzzword. Technically, though, it's still a solution in search of a problem. HTML+JS is a compatibility nightmare as Internet Explorer development repeatedly creates a JavaScript/JScript incompatibility. First it was DOM, and now that Firefox and IE agree on DOM, it's time to bastardize JavaScript into the next, incompatible JScript. The whole point of AJAX and using the Web Browser as a basic app client is that it's portable. JScript will find a way to make sure it isn't.

Re:...has yet to succeed... (1)

Profane MuthaFucka (574406) | more than 6 years ago | (#17821530)

It's all 1's and 0's. That's all it is. It is so SIMPLE I cannot believe that we haven't thought of it before. We're using http and xml and Javascript and virtual machines and browsers and ajax. Bah! It's complications that are unnecessary. Forget all these client-server monstrosities and your silly ajax and just realize the simplicity. There's better solutions out there if you just stay simple. It's all just 1's and 0's.

What? Why are you looking at me? I'm the idea man. Now go out there and build me something simple with yer 1's and 0's.

Re:...has yet to succeed... (1)

xero314 (722674) | more than 6 years ago | (#17821630)

I realize you were being sarcastic, but you are so close to the truth it's scary.

Re:...has yet to succeed... (1)

Profane MuthaFucka (574406) | more than 6 years ago | (#17821756)

I'm a consultant for a large company. I was being sarchastic, but the real question is am I also self-depricating?

Re:...has yet to succeed... (1)

Jake73 (306340) | more than 6 years ago | (#17821658)

Perhaps. But the browser has brought one very important thing to the table and that is a description language for form presentation. This was very lacking in most previous "thick client" applications. This absense dramatically increased the costs of building such applications.

This description language makes application development much faster and flexible. Although present in one way or another in some things like MFC or more modern incarnations, having a "standard" helps tremendously.

Re:...has yet to succeed... (1)

CDarklock (869868) | more than 6 years ago | (#17821778)

I think there are certainly ways you Should Not use AJAX. There are strengths and weaknesses to the technology. AJAX works best when small parts of the screen change in response to user action. If large parts of the screen will change, just use a link. And if the screen needs to change constantly without user interaction, PLEASE don't do it with JavaScript! Write a control or something!

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 run Word or Excel over the internet, but I don't want my email stored locally on every machine I use. What's hard about that?

Re:...has yet to succeed... (1)

xero314 (722674) | more than 7 years ago | (#17822066)

I think there are certainly ways you Should Not use AJAX.
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 Load" in the entire application which loaded all the UI elements and then used xml http requests to handle all the server interaction. The application works well and even has a completely separated API that can be used by any UI that is built for it.
My point was never that you can't make a usable ajax application, I'm just saying that it requires just as much work, or more, as other client/server options, is harder to maintain and causes endless amount of confusion. It is limited and slower that a native client, by noticeable amounts. No matter how hard you try, GMail will not be as fast, as secure or as stable as a local, native, mail client. And as much as I think ECMAScript is actually one of the, if not the, best high level language available, it's runtime evaluation as implemented in the current browsers is to slow for real use. Complicate that with parsing the overly verbose XML and you get more wasted cycles(of the human kind) than running excel on a windows emulator on a vic 20.
But alas, I wouldn't have been able to write this post if I wasn't waiting for an AJAX applications to complete it's crash.

Re:...has yet to succeed... (1)

Jeff DeMaagd (2015) | more than 7 years ago | (#17821878)

AJAX has yet to succeed? It seems to be succeeding, with numerous small to massive sites using it.

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:...has yet to succeed... (0)

Anonymous Coward | more than 7 years ago | (#17822054)

"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."

No, I'd say the PC is being used today pretty much as orginally intended.

Ahem... (5, Funny)

Infinityis (807294) | more than 6 years ago | (#17820972)

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...

lol (0)

Anonymous Coward | more than 6 years ago | (#17821020)

mod parent up

Re:Ahem... (2, Funny)

Kelson (129150) | more than 6 years ago | (#17821148)

Wow... Imagine a Beowulf cluster of AJAX!

Re:Ahem... (0)

sconeu (64226) | more than 6 years ago | (#17821662)

In Korea, only old people use AJAX.

Re:Ahem... (-1, Troll)

Negadecimal (78403) | more than 6 years ago | (#17821364)

I work with AJAX. So I am really getting a kick out of most of these replies.

Some of you guys are very good at making it sound like you know what you are talking about.
But trust me.... You don't. I think you just want to make yourself sound smart, when in reality you don't know what you are talking about.

This is how bad info gets passed around. If you dont know about the topic....Dont make yourself sound like you do.

Cuz some Slashdotters believe anything they hear.

Re:Ahem... (1)

Negadecimal (78403) | more than 6 years ago | (#17821414)

Yeah, I know it wasn't a true /. cliche... go easy.

Re:Ahem... (1)

loganrapp (975327) | more than 6 years ago | (#17821794)

"You may think you know, but you have no idea. You don't even know!"

C'mon, dude. Explain.

Re:Ahem... (1)

ThinkFr33ly (902481) | more than 6 years ago | (#17821580)

Want to perhaps be a bit more specific?

Re:Ahem... (1)

DittoBox (978894) | more than 6 years ago | (#17821624)

Do not taunt Happy Fun AJAX...

Javascript can be disabled... (-1)

Anonymous Coward | more than 6 years ago | (#17821050)

... and therefore AJAX is completely unreliable and only useful for toys.

Re:Javascript can be disabled... (3, Insightful)

EvanED (569694) | more than 7 years ago | (#17821904)

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.

Pre XMLHTTPRequest (3, Insightful)

c0d3r (156687) | more than 6 years ago | (#17821096)


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:Pre XMLHTTPRequest (2)

Mr. Stinky (753712) | more than 7 years ago | (#17822258)

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 who maintains (or uses) them.

Some basic attributes that applets have that no other browser technology have are:
  • they interface with the parent OS's clipboard. You can actually copy Java Objects to the clipboard and they can be stored in multiple flavors (mime types).
  • the windows are highest-level in the OS, so popup windows can span across frames, and outside of browser windows.
  • Drag-n-drop can happen accross frames, because it's actually moving an array of different flavors of objects. Also with Java you can drop on the desktop or other apps. You can drag-n-drop accross frames in JS, but it's a hack. Note dnd does suck in most Linux implementations.
  • You can drag-n-drop files directly from your desktop onto areas of the applet, like the tree, and it will perform client-side uploads.
  • They can operate in a threaded manner when events are triggered. Though you can simulate this in Javascript, it can blow in terms of trapping errors...
  • They can scale very huge, as you can take advantage of java's garbage collector, and because the browser does not do well with 10,000s of event listeners like onchange.

http://drknowledge.com/JX/?slashdot [drknowledge.com]

Forgive my shameless self-propping and horn tooting, but I've used Java to enhance UIs since long before AJAX so I thought I'd chime in.
-=DG

framework (0)

Anonymous Coward | more than 6 years ago | (#17821100)

What do real sites like myspace and suicidegirls use?

Re:framework (4, Funny)

Rosco P. Coltrane (209368) | more than 6 years ago | (#17821184)

Teenagers.

Asynchronous xml, something (kinda) new from M$ (4, Funny)

marcello_dl (667940) | more than 6 years ago | (#17821204)

So, contextualizing the story a little:

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.

You're probably joking... (0)

Anonymous Coward | more than 6 years ago | (#17821634)

...but Melinda Gates was born and raised in Texas. http://en.wikipedia.org/wiki/Melinda_Gates [wikipedia.org]

Microsoft rebel (1)

hey (83763) | more than 6 years ago | (#17821230)

It doesn't seem to hard to be a Microsoft rebel. Oh, and Microsoft even - wow!
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 (5, Insightful)

ThinkFr33ly (902481) | more than 6 years ago | (#17821252)

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 [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 (1)

Yakman (22964) | more than 6 years ago | (#17821728)

I've already mentioned this in another comment [slashdot.org] , but Adobe Flex [adobe.com] is here today and lets you build Rich Internet Applications that compile down to SWF files that run on Flash Player 9. Unlike all the other technologies you've mentioned, Flash Player 9 will work on the majority of systems and browsers out there today.

Thin and Thick Talk are Mutually Exclusive. (0)

Anonymous Coward | more than 7 years ago | (#17821962)

Ditch HTTP and use XMPP.

Those who don't understand security (-1)

Anonymous Coward | more than 6 years ago | (#17821370)

So this is the person responsible for nearly as many security breaches as Microsoft Windows.

Those who don't understand security are doomed to plague the rest of us with their folly.

It's time to rewrite javascript, now. But this time, get it right.

Why Bosworth Failed with AJAX in 97 (5, Insightful)

ingo23 (848315) | more than 6 years ago | (#17821402)

I do not find his explaination of AJAX failure convincing. I also created an AJAX-like app in 2000 (well, ok, not in 97), but the main problem was not the network bandwidth, browser performance or app compexity.

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:Why Bosworth Failed with AJAX in 97 (1)

stormeru (1027946) | more than 7 years ago | (#17821998)

"Ten years ago the web/HTML/HTTP concept was still based on request/response/full reoundtrip for each page, as it was originally concieved."

Ten years ago we had frames and we still have them now. Although not that pretty as AJAX, they were used to reload only parts of the web page. The <iframe> tag is more common than ever these days.
Frames are easy to understand and they don't require any programming skills. I keep wondering why the W3C comission didn't extend this frame model for more HTML elements. Just read the following 'could have been' HTML code, no programming involved, and imagine the AJAX code you have to write to get such an effect:

<div id="container">
        <div id="left_column">
                <a href="some_page.php?id=1" target="right_column">link 1</a><br />
                <a href="some_page.php?id=2" target="right_column">link 2</a>
        </div>
        <div id="right_column"></div>
</div>

But no sir! They even had to remove the target attribute from XHTML Strict! Notice how my code would have been XHTML+CSS valid without this restriction that makes me write more hacks (rel="external" and an ugly JS to add the target attributes on page load).

Re:Why Bosworth Failed with AJAX in 97 (1)

ingo23 (848315) | more than 7 years ago | (#17822138)

Ten years ago we had frames and we still have them now.
Yes, and we are still trying to get rid of them. People abuse frames (and iframes) to the point that most of the sites (that are not "web applications") that use frames are examples of horribly designed UI/page structue.

You cannot (consistently) bookmark a framed site, you cannot correctly print it, just to mention a few. Remember, I am not talking about "web applications", just simple sites with a navigation on the left and content on the right.

What you are asking for is a "nice to have" for applications (I would not mind having it that way, by the way, dojo toolkit provides something like that relatively inexpensively), the problem is that it encourages building those "frameset" pages.

AJAX is not for your regular "content centric" pages, although it may enhance them. And yes, I agree, you can do "AJAX" with just frames/iframes (that's how everybody was doing it before XMLHTTPRequest). That was not the point. It was DOM support that did not let AJAX to take off, and frames would not help you here.

Re:Why Bosworth Failed with AJAX in 97 (1)

background image (1001510) | more than 7 years ago | (#17822312)

What the heck are you talking about? What is it that you're saying you should be able to do with this HTML that you can't do with frames in the same amount of code?

But besides the first point's incomprehensibility, the second point:

But no sir! They even had to remove the target attribute from XHTML Strict! Notice how my code would have been XHTML+CSS valid without this restriction that makes me write more hacks (rel="external" and an ugly JS to add the target attributes on page load).

...is ridiculous. If you need the target attribute so badly, use HTML 4.0 Transitional or xhtml 1.0 Transitional. No problems. Better yet, if you're using frames, why not use the right doctype in the first place? iframes [w3.org] and target attributes [w3.org] are alive and well in xhtml 1.0 Frameset...

Did I missed something... (2, Insightful)

creimer (824291) | more than 6 years ago | (#17821496)

I'm still waiting for AJAX to take off.

AJAX == Thick Client (2, Interesting)

helixcode123 (514493) | more than 6 years ago | (#17821502)

Ironically, while a web browser is commonly thought of as a "thin client", some major Enterprise Applications companies, wanting full client functionality on their web-based products, require downloads exceeding 2MB(!) for their "thin client" Javascript apps.

Try putting 100 users of said web app on your network and watch your traffic surge.

Am I the only one who thought... (2, Funny)

Dadoo (899435) | more than 6 years ago | (#17821668)

"...then I'm happy and sad for it"

AJAX is a silly acronym (3, Interesting)

Dracos (107777) | more than 6 years ago | (#17821682)

Most people agree that AJAX is a silly acronym. (I personally think DHTML is much sillier). Let's examine it.

  • "Asynchronous": I'll buy that.
  • "Javascript": won't be alone here for long.
  • "And": who makes a conjunction significant in an acronym?
  • "XML": the ideal, but not only, data format.

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 (5, Funny)

EvanED (569694) | more than 7 years ago | (#17821874)

See this diagram [hermann-uwe.de] , and in particular the arrow from "people who refuse to use the word AJAX to "AJAX programmers"

Re:AJAX is a silly acronym (1)

grcumb (781340) | more than 7 years ago | (#17821952)

AJAX is a silly name, but we're probably stuck with it.

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 he needs to come up with a name, he - again, shamelessly - stands on the shoulders of Giants like Professor Conway and dilutes the namespace with a pale echo of Damian's greatest masterpiece since his translation of Perl into Klingon.

Note to the humour-impaired: Follow links before modding Troll or Flamebait.

Re:AJAX is a silly acronym (1)

beady (710116) | more than 7 years ago | (#17822002)

AJAX is a silly name even now. The XML portion is being replaced more and more by JSON (Javascript object notation). So yes, AJAX is an umbrella term even now.

Re:AJAX is a silly acronym (1)

oliverk (82803) | more than 7 years ago | (#17822146)

First off, I agree with you wholeheartedly. That said, I've been working with some teams lately that refer to AFLAX as a shorthand for data-driven Flash. I think this is less about finding the right acronym and more giving the marketing types something they can actually utter without sounding profoundly illiterate. :)

AJAX not adopted earlier due to lack of broadband? (1)

CopaceticOpus (965603) | more than 6 years ago | (#17821800)

Ironically, AJAX should arguably be most useful for people with slow internet connections, as it allows one to send small chunks of data without reloading an entire web page.

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 (2, Interesting)

Anonymous Coward | more than 7 years ago | (#17822030)

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.

No Google Video? (0)

try_anything (880404) | more than 7 years ago | (#17822444)

I can't find the talk on Google Video, and now I'm all pissed off.

Kudos to Google for raising my expectations this high, I guess.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>