What's Spreading "the AJAX Wildfire"?

An anonymous reader writes "AJAXWorld Magazine is running an article entitled "What's So Special About AJAX?" in which the majority of the contributors agree among themselves that AJAX "heralds a new, global sense of what the web can be and what the web can do, in ways that are so different but so much better than what we have been used to." While many of those the magazine consulted adduced technical reasons for the spread what one of them, Rich Internet Application pioneer Coach Wei, calls "the AJAX wildfire," only two mention how human nature — including that of software developers — is, well, notoriously susceptible to the latest fad. Which side would you agree with?"

Comments

not just a new fad

[Loconut1389]

AJAX is becoming popular because it helps do away with the concept of pages that have to have every element transmitted and redrawn on every roundtrip. AJAX does one better and essentially eliminates the roundtrip altogether. A button click just sends the data that's pertinent and redraws only the pertinent parts.

Ruby is more likely to be just another fad, AJAX is actually something new. That's not to say someone won't make a better way to do what AJAX does (they probably will), but AJAX is definitely something unique, new, and important.

Re:not just a new fad

[Anonymous Coward]

This is not an "insightful" comment, because it's wrong on at least two counts.

But I'll not toss away a mod point to say so, only to have it trashed by some Ajax fanboi in metamod.

1. Ajax does NOT eliminate the round trip between client and server. It just lends the ILLUSION of doing so. Sure it looks cool and wonderful, but requests still have to go to the server, and responses still have to come back over the wire. It only *looks* seamless if you've a broadband connection, which lots of folks still don't.

2. Ajax is NOT new. The technology has been around for a while now. For that matter, it's not even really dependent on XmlHttpRequest - you could do much the same thing with IFRAME elements, at least on your own site.

And Ajax has at least two potential problems in common with frames - poorly-implemented apps don't provide a way to bookmark results - if you use content from another provider, then you're dependent on that being available, and you need to provide a fallback in case they aren't.

I don't object to Ajax, I actually think it's pretty cool. But it's not new, and it doesn't change the way the Web actually works.

(And for anybody who thinks I'm just miffed by the parent's cheap shot at Ruby - I personally don't use or care about Ruby. But it was a cheap shot.)

Re:not just a new fad

[roman_mir]

I am sorry, did you just say AJAX is NEW? UNIQUE?

9 years ago I used hidden IFrame in the browser that communicated with the server and then passed the data back and forward between that hidden frame and the main window. It was exactly like AJAX but instead of XML I was using a simpler, a faster way to transfer data: key-value pairs. And I came up with that on my own too, but I know that others came up with the same (similar) solutions.

Of-course XMLHttpRequest makes the job easier, but actually the XML part does not.

Re:not just a new fad

[Monkelectric]

AJAX is just the tip of the proverbial iceberg. AJAX itself is a fairly ugly hack, the real usefullness of which has been to highlight the INADEQUATE nature of the www in its present state.

This is the classic progression of technology. A tool is being used for something it was not meant to, while technically feasable it is distasteful. This technology will be refined until it becomes apparent that a new framework is needed.

I see the most likely scenario as ajax being replaced by something designed to do the job far easier which is basically: Networkable GUI's

Re:not just a new fad

[CastrTroy]

The XML thing makes it easier in that you don't have to program in the data encoder/decoder. It handles being able to put any text in it with proper escaping, and have the data be easily read on the other side. Plus if you use a simple XML schema, it's not that much heavier than using key/value pairs. I mean, you could use something really complicated, but you don't have to, and your probably better off using a simple schema for many reasons. I don't think it is any different than what you are doing, especially since that what everybody does mostly isn't ajax, and is often just something that's very similar, but leaves out the xml part, in exchange for what's easier depending on your application. I've found it easier to just send back JS wrapped in an XML container so that there doesn't have to be a large library of code on the client to handle every little situation that they may encounter. Most of the stuff that ends up happening as the result of the AJAX call (showing a message, updating a couple of HTML elements, or removing a few) only take 2 or 3 lines anyway, especially with a very small library of helper functions on the client side. Plus you don't have to put up with building a complicated XML parsing engine in JS on the client side.

Re:not just a new fad

[roman_mir]

Easier to use XML rather than key/value pairs? ;)))) Dude, Javascript Arrays can be loaded with a single string that contains a list of key/value pairs with any number of dimensions. For some purposes you don't even need keys, just values. A list of values works perfectly fine without any additional placeholders.

Re:not just a new fad

[CastrTroy]

I was thinking more on the server side. If you need to read the data on the server, it's easier for it to be in XML as the parser is already built, in just about every server side language available. Even on the server side, you most languages offer a split/tokenizer function, however, it's not always that easy. Key value pairs work well, but what happens to your data when you send CRLF in the middle of a value, or other weird characters that may interfere with your parsing. If you're seperating keys and values with character X, what happens when you want to send that character otherwise, how well does your split/tokenizer function handle that? XML has all this figured out already. I mean, I could write my own parser, but I really don't see the point when a simple XML schema is only minimally more verbose, allows me to send hierarchical data if I ever need to, and is already coded and well tested.

Re:not just a new fad

[shawb]

Networkable GUIs?

There would be two ways to do that: 1)have a program that can parse a standard formatting language, and have a server push a description of the interface out to you or 2)push out a custom program that does the user interface work. It is also possible to have a combination with a standard program that can imbed the custom program.

Wait... Isn't that how the web already functions? A standards compliant web browser parses the language (HTML) and presents a user interface (web page.) Programs can be specially installed on your computer for specific tasks (such as Google Earth) for interfacing with the data, or they can be imbedded into a standard web page via Flash, Java or other techniques.

We are at the point where you basically have that networkable GUI. Any changes made will be evolutionary rather than revolutionary. Unless you can think of another way for IO to work. It really doesn't matter if the processing is done on the server or on the desktop, as long as you can get the data from the server out to the user (or user data sent to the server to be later processed by requests from that user or another user.)

I suppose the only advance you could put on is the ability to transfer the current state of your running GUI to a different computer. I imagine this would be best accomplished through some crafty hacks of virtualization, as long as there is adequate bandwith between the devices and a common enough language to be able to pause the program and transfer all related information and states. I know this is being worked on at the server end so a running process can be transferred between servers if one shows signs of impending hardware failure or otherwise needs servicing or upgrades. From there it would seem to be next to trivial to transfer the running states of the user end, say between a desktop and laptop. I suppose this would also allow for saving of the entire running state to another computer. Cloning of a running program's state would also be theoretically possible, although you may run into race conditions and problems with data access locks. This would also open up a very large avenue for malware attacks of all kinds.

But you would still be basically dealing with a user needing information from a server being pushed to their display. Bandwith and security concerns aside, it really doesn't matter whether the whole database gets sent to the user's computer, whether the server just pulls out the necessary information and sends it raw for a program on the user's computer to process, or whether all processing is done server side and the desktop acts pretty much as a dumb x-term.

Re:not just a new fad

[Jessta]

'AJAX' is networking support built in to javascript. Nothing new about it. Most scripting languages have had networking support for quite a while.

Re:not just a new fad

[PietjeJantje]

The ability to phone home, retreive data and update the page, without reload gives way to a whole range of new applications, not just the updated select boxes, rich internet applications and pimped sites. Essentially you can make anything you normally could with a custom client, limited by the mess that is javascript across browsers and your imagination. I myself have been exploring multi-user environments on web pages where the actions of one user has an effect on the pages of others (see sig). It's nonsense to say "AJAX is a fad" because it's an evolution of the browser that can't be turned back. Just like the gold fever that began a decade ago and ran for five years, where html, the web nor the internet went away. Many companies selling air, naming it "web 2.0" might go away, but that's another story.

Re:not just a new fad

[Millenniumman]

But that is simply not was http and web browsers are meant for. They are meant to have pages. If I want an application, I want an application, not a quasi-application web page running in a browser.

Re:not just a new fad

[FyRE666]

I think maybe you need to do a little more research. You'll find that we've been sending data from the browser to the server - even including those pesky CRLF character codes, without needing XML, for several years now ;-) Key/value pairs are much simpler and faster to decode at either end than XML; and although XML does have its place, it's certainly not the magic bullet you're making it out to be... I've also been doing "AJAX" data transfers with Javascript for several years now, both using iFrames, and piggy-backing data in cookies using image requests, before the XML HTTP Request object was available/stable. Why it's suddenly being touted as a "new" idea is beyond me...

Re:not just a new fad

[russellh]

I don't object to Ajax, I actually think it's pretty cool. But it's not new, and it doesn't change the way the Web actually works. You're either insane or you weren't there in 1994. From the perspective of one who thought CGI was stupid in 1994, AJAX is totally new and better. That is all.

Re:not just a new fad

[FyRE666]

I see the most likely scenario as ajax being replaced by something designed to do the job far easier which is basically: Networkable GUI's.

It's already here, and called "Flash". Although I'm happy to write Javascript all day long, and have used it for games, windowing systems etc, I see a lot of the AJAX examples and wonder why the authors haven't just used Flash for the job. Admittedly if the app is embedding a lot of HTML content, then it makes sense to use AJAX, but for many other projects, it seems a bit of a strange choice.

Re:not just a new fad

[Anonymous Coward]

XmlHttpRequest - you could do much the same thing with IFRAME elements, at least on your own site.

As far as I'm aware, XMLHttpRequest has the same restrictions as iframes and most other ways of accessing documents in different domains, so there's no difference in the "on your own site" aspect - in Mozilla it's the same origin policy and is applied to XMLHttpRequest too. That's actually quite annoying when you really want to load things from other domains; cross-document messaging is a handy solution (allowing one document to open itself to messages coming from anywhere, as long as it takes the responsibility to provide its own security to make sure nothing bad happens), though currently it's only implemented in Opera.

Re:not just a new fad

[trevdak]

Yes, HTML and browsers already use a standardized language, but there needs to be one further step. UI and behind the scenes computation are much more closely linked on computers than in Web interfaces. As a result, HTML is a standard language in browsers, but rarely anywhere else. That's why we see something like XAP popping up, an XML protocol that ties in UI, basic programming with macros, events, and server queries into one, allowing web applications to bridge that gap with as much ease as writing HTML. Additionally, XAP can be used with a client (check out demos at Nexaweb (Nexaweb is Coach Wei's company), meaning we can get real applications running on multiple platforms and operating systems, including AJAX.

Re:not just a new fad

[irc.goatse.cx troll]

No, JavaScript was new compared to "being there in 1994".

If he was there in 1999-2001 or so, it's nothing new.
Name 5 ways "AJAX" differs technologically from "DHTML".

Re:not just a new fad

[roman_mir]

On the server side if you want to make your application slower, than certainly, go ahead, use XML for client/server communications. I don't want to make my application slower, thus I will rather use key/values, lists of data. Obviously that is when encode() javascript function becomes useful and on the server side use properties handler.

Re:not just a new fad

[jozeph78]

Why doesn't anyone ever mention JSON on this forum? Why parse out XML into a javascript "object" when the literal notation is not much more difficult and a lot more efficient to "parse" back into the language that will be using it. Not only is it evaulated more efficiently but you'll probably learn a ton about advanced Javascript along the way. Since I don't believe in Ajax frameworks that completely remove you from the JS, I'm a big fan of JSON responses for this reason alone.

Is there something terrible about JSON that I have yet to be burned on?

Re:not just a new fad

[Vexorian]

But Ajax makes it so you only download the updated information instead of a whole page with all the layout and previous information, so it is still better, specially for those without broadband connection - as long as a "Please wait - updating" message or something like that is shown at the time of updating.

Re:not just a new fad

[CastrTroy]

I never said that XML was the silver bullet, or that it was the answer to all life's problems. A lot of the problems with XML tend to stem from the fact that you have to (or at least usually the way it's implemented) load the entire document into memory and parse it before you can start using it. And then, to get to any specific point within the document, you have to search from the beginning. This makes it quite a kludge when you are dealing large data files in the GB range. I'd rather use CSV for exchanging large amounts of data across a network in this situaion. However, in the situation we are talking about, that being Ajax, where you are generally sending no more than 1 K of text, usually less than 250 B, it doesn't really make that much of a difference. I have no problem with using key value pairs. I think that it could be useful in a lot of cases. However, I've found that using XML makes the data a little easier to deal with on both sides. Key value pairs would be a little bit lighter, and would provide basically the same functionality, yet I feel more comfortable using XML.

Re:not just a new fad

[heinousjay]

Comparing AJAX to DHTML isn't valid. They address different areas of technology entirely. You might as well ask someone to compare the taste of oranges to the responsiveness of a Mini Cooper.

Re:not just a new fad

[gr84b8]

I dunno, this sounds like you are trying to bring back 'client-server' as the future of web programming. I think you're saying that 'www' is inadequate because its built on a stateless protocol that forces us to build hacks (i.e. ajax) to have state - given that stateful client-server apps failed for numerous reasons I think it is a little shortighted to think that Ajax will lead us back to stateful protocols that would allow us not to 'hack' around stateless-ness.

Obviously we have been doing state over http for some time, and we have a million simple ways to do asynch requests over http - so the fact that ajax standardizes that communication is great, but its definitly not 'the tip of the iceberg'.

Re:not just a new fad

[phaggood]

>Easier to use XML rather than key/value pairs? ;)))) Dude, Javascript Arrays can be loaded with a single string

And, there's always JSON if you don't feel like hand-wrangling all those value pairs.

Re:not just a new fad

[roman_mir]

you don't need JSON to load an array and then to access array elements.

Re:not just a new fad

[jozeph78]

you don't need JSON to load an array and then to access array elements.

You don't need JSON to load an array. With JSON, you send the array. Of course that won't prove your programing ability to parse out the csv or DOM and "load" it all by yourself.

Re:not just a new fad

[roman_mir]

take a look. That's some of my code, there are strings there that load Array in one shot without any parsing. Refer to my earlier posts.

Thank you for your 'attention'.

Re:not just a new fad

[kiddygrinder]

XML makes things harder, it's just the way it is. From what you say the only advantage is not having to escape chars, i'd probably agree with that. XML was a good idea, however there needs to be more simple components available to access it, prolly (scarily) in SQL like syntax. I've fiddled with it quite a bit in python, then came across an article that basically said "If there needs to be code involved, why not just make it python? It's not like it's hard, we're not talking java here" and thus was enlightened. However, without the XML it'd just be AJA, and that alone would have forstalled it's entry into the mainstream.

Re:not just a new fad

[russellh]

No, JavaScript was new compared to "being there in 1994".

But javascript didn't change application architecture other than offloading field validation or allowing table column sorting, image swapping and stuff. AJAX breaks the web document model. A bigger change has come with other applications that use the web (ie http and URIs) outside of the browser - like RSS for instance. and websites that provide an API with xml-rpc or something similar. that's huge. the javascript change is nothing compared to that. web services, I guess they're called.

so to answer the question: is it a fad? yes, in the sense that now is the time to cash in with your 1115 page Bleating with AJAX book with DVD-ROM in the back and your smug mug on the front. yes, in the sense that lots of people will do unnecessary AJAX implementations for entirely selfish resume-style reasons. no, in the sense that the existence of AJAX points out the disconnect between the browser concept and what we want for applications on the net.

Re:not just a new fad

[70Bang]

How is Ruby lacking where lesser languages have lasted for so long? This isn't a question with hidden value or a bait for a flame war, I figured you'd finish your own comments:

"Ruby is more likely to be another fad because..." where's your argument?

"AJAX is actually something new..." despite the cries it's been around in a former life known as remote scripting, which has been in the ASP-supported languages[1] for several years. The difference is you can do...in AJAX wherease remote scripting was restrictive in the way ...

"but AJAX is definitely...important." because...

Unless you want to toss out karma points like toothbrushes when you find a hair in them, you might want to answer your own questions because you're leaving yourself open to challenge without making your point(s) known. You're either going to waste a karma point by posting incompletely or you'll have to come back in and waste a second one trying to defend your position.

This is going to sound nasty to some people, but I'm tossing a karma point out to you and anyone else who posts quick little quips. Take it as constructive criticism, even if you don't think it is.

I was really dirty in debates and public speaking (esp. the latter in college). In both of them, it was, "You're likely to hear this from someone following me. And when you do, I want you to listen for answers to the following questions. And if you get these answers, think about how appropriate they are for the given set of circumstances." The Persuasive speech (in college): "You're going to hear people get up here and talk about abortions & birth control, gun control & registration, involvement of the US as a force for peace in the world, yadda, yadda. I want you to think how much of that affects right now as you're sitting here. Most of us here are seniors and now live off-campus. Do you know what happens to you when you live off-campus? You still pay for one meal a day at the Dining Commons, even if you don't go. So if you're married, you're paying for a meal you're likely to never go to...yadda yadda". I watched a lot of pale faces as I sat down. Because almost everyone there had to get up and talk about everything I said basically said was a sucky topic yet found something they were paying for and never knew it. (I always went first because it was like Goren on Law & Order: Criminal Intent...no one ever knew what type of show was going to be put on and I wanted to get first shot at manipulating the crowd.

Take five minutes, at least write something that's reasonably complete. It doesn't have to be the magazine article some of us write who go through write, preview, edit, preview, edit, preview, etc. and spend twenty or twenty-five minutes to craft a post. Unless you've got a dilly of a one-liner. By all means, get it posted. But it'd better be good.
________________________________________
[1] Remember: ASP != VBScript. ASP is a platform|umbrella. It could be PERLScript, JScript, PHP, VBScript, and a couple of other languages which were made to fly.

Re:not just a new fad

[Jahz]

1. Ajax does NOT eliminate the round trip between client and server. It just lends the ILLUSION of doing so. Sure it looks cool and wonderful, but requests still have to go to the server, and responses still have to come back over the wire. It only *looks* seamless if you've a broadband connection, which lots of folks still don't.

While this is completely true, in many instances, it does significantly reduce the quantity of data transferred. This is especially true in systems like Amazon.com where lots of analysis is done on every page to present users with relevent information. That information no longer needs to be recomputed all the time.

2. Ajax is NOT new. The technology has been around for a while now. For that matter, it's not even really dependent on XmlHttpRequest - you could do much the same thing with IFRAME elements, at least on your own site.

Excellent! You're so close, now dig deeper.
We don't really care about "AJAX," do we? No... its the idea that excites any web developer. The concept of highly dynamic -- almost application like -- web pages without relying on any third party modifications (see: Java Applets, see: Flash). Is Ajax a fad? Probably. But its more than that. It's an evolutionary step in interactive web design.

Re:not just a new fad

[Anonymous Coward]

The XML thing makes it easier in that you don't have to program in the data encoder/decoder

No it doesn't "make it easier", look up JSON you retard. And the only thing you don't have to program with XML is the base parser to transform your XML in DOM objects, you still have to transform these XML objects in something you can actually print. As opposed to, say, sending HTML through the wire, which DOES allow you not to do any parsing/encoding/decoding.

Re:not just a new fad

[Loconut1389]

The discussion above seems to toss back and forth the good and bad points of my post, but perhaps I should tack on one clarification.

I said Ruby was more likely to be a fad because it is essentially just another programming language that does more or less the same things as any number of others, and like any language has its advantages and disadvantages. When a new language comes out it's always a fad, but at the end of the day, it's only whether the fad sticks around long enough to take root and get people sort of stuck doing things that way.

I said AJAX was something new because, although yes, you can do that sort of thing in iFrames, it's not really the same thing, is it? AJAX leverages new features in browsers (XMLHttpRequest among others) and reduces the complexity.

As someone pointed out, http wasn't designed for applications and AJAX is a shoehorn- sure it is, but HTTP/2.0 or whatever will probably address that and build something with AJAX's spirit right in.

To the point that there still is a roundtrip that occurs- sure, you're still transmitting data and getting a response, but the term roundtrip as far as web content goes has always had the connotation of packing up everything on the page, sending it back, getting some processing done, and sending it all back. So I'll clarify, rather than having to do a roundtrip of the viewstates of every object on the page and any new data from POSTs, you only need to send relevant material and only get relevant material back.

Re:not just a new fad

[zeemu]

AJAX and DHTML are already being utilized to produce Traditional GUIs in Web Applications.

APhPLIX allows the development of sophisticated web applications with traditional GUIs. Using APhPLIX development studio (GPL licenced), database driven web applications can be built in minutes.

A lot of people seem to get stuck on the web browser mentality, but with the use of AJAX and DHTML web browsers can be used to run desktop style applications.

Re:not just a new fad

[Maxmin]

This is not an "insightful" comment, because it's wrong on at least two counts.

It's almost as though you didn't read the parent post, or read just the words you wanted to. "Essentially eliminated" != "eliminate".

1. Ajax does NOT eliminate the round trip between client and server. It just lends the ILLUSION of doing so. Sure it looks cool and wonderful, but requests still have to go to the server, and responses still have to come back over the wire. It only *looks* seamless if you've a broadband connection, which lots of folks still don't.

Sorry, but it's not sending the ENTIRE page, which was the main point of the parent post that you seemed to miss. It's likely sending an insignificant fraction of the page, just the delta -- much less data to *retransmit*, and then *rerender* on the client. Quoth the OP:

AJAX ... helps do away with the concept of pages that have to have every element transmitted and redrawn on every roundtrip. AJAX does one better and essentially eliminates the roundtrip altogether. A button click just sends the data that's pertinent and redraws only the pertinent parts.

More clear? Think deltas, which means requesting, transmitting, and rendering only the portion of the page that actually needs to be changed... all the other gunk can stay right where it is.

Re:not just a new fad

[fforw]

The main benefit of AJAX is more uniform browser support and the absence of distracting things like a always running throbber. That's it -- no more, no less. So when the hype has faded the people who know what they're doing will still use it to shorten the UI flow.

Re:not just a new fad

[laffer1]

In a pure form yes. Most people use "ajax" to do dhtml like things. They make dippy drop down boxes and so forth. You could seperate the content of that box with an external javascript document that's dynamically generated too.

In my opinion, when someone uses "ajax" but with html and javascript only its really dhtml. Now if someone is really using xml documents and doing something original i'll give them credit for the latest fad.

Re:not just a new fad

[Not The Real Me]

"But Ajax makes it so you only download the updated information instead of a whole page with all the layout and previous information"

In theory you may be right. In practice this is not what I have seen. http://www.wireimage.com/ is an AJAX site that loads the whole damn page every single time. On broadband (768k DSL), wireimage.com can be a true pain in the ass to use.

Re:not just a new fad

[Anonymous Coward]

Lol Ajax. Flex 2.0 is where I will be.

Re:not just a new fad

[blippo]

Well, AJAX and DHTML are alreay beeing utilized to -m-i-m-i-c traditional GUIs in Web applications, ...though only much more crappier.

GIVE ME BACK MY APPS! Damn it. Remember "undo", or why not the right mouse button context menu?

Re:not just a new fad

[Bovarchist]

No, it's not a fad, it's just a new name. The technology has been available since IE4 and NS 4. Sure you had to use iFrames and it was an ugly hack (and it still is), but it WAS possible. What's new is that Google released Google Maps and showed all the suits out there that it really works and wasn't just some pipe dream that an occasional developer would talk about.

Re:not just a new fad

[flame_aphplix_org]

AJAX and DHTML are alreay beeing utilized to -m-i-m-i-c traditional GUIs in Web applications

Everything is mimicked now days, why the fax machine is nothing but a waffle iron with a phone attached

...though only much more crappier.

Sure, but we are comparing a system here with a few months of development behind it, against modern desktop GUIs with several decades of development behind them. I think it could make a good slogan though... "it's like a traditional GUI... only much more crappier".

Re: not just a new fad

[rettenator]

What would be really popular would be something that's less of a mashed up hack. They should call it A*h*AX. Maybe I'll have to wait for Web 3.0 - or for the M.S. crowd - Web "Vista"

What's so special about AJAX?

[The MAZZTer]

Nothing! The tech for it has been around forever, they just slapped a new name on it.

It IS nice to make web applications that can behave more like desktop applications.

Re:What's so special about AJAX?

[Osty]

Nothing! The tech for it has been around forever, they just slapped a new name on it.

To be fair, while Microsoft introduced the XMLHTTP object in 1999, other browsers didn't implement a similar interface until 2002 or later (2002 being the first implementation of XMLHttpRequest in Mozilla). So if your definition is of "forever" is "the last four years" then this has been aroud forever. (Note: I'm ignoring hidden iframe solutions that really have been around "forever", where "forever" is defined as "since rich web browsers have been around, such as IE4 and Netscape 4".)

I do agree that "AJAX" is just a flashy name for an already-existing technology, and any good web developer would've already been using the technology in appropriate places prior to the name change. However, "AJAX" does put a fancy name on the technology, and while it certainly can be overused it's not really a bad thing for the technique to get more publicity. "AJAX" as a fad will eventually die down just like "enterprise", "push", etc have in the past. The technology behind it won't, and will continue to be used where appropriate long after the Web 2.0 bubble has burst.

Re:What's so special about AJAX?

[polarian]

What is so interesting about the internet?

Nothing! The tech for it has been around forever (communication + electricity + silicon), they just slapped a new name on it.

What is sepecial about async. javascript based communication is the way it is being used, not the technology itself.

Re:What's so special about AJAX?

[Tablizer]

Nothing! The tech for it has been around forever, they just slapped a new name on it.

I have to kind of disagree. JavaScript was natoriously buggy in the earlier days. You could do fancy things with it, but at the risk it would crash or cause your fonts to evolve a personality and demand voting rights or some other wacky side-effect.

JavaScript and DHTML are finally growing stable enough to use to make reliable GUI components out of. It grew from just the ability for basic, mild-use scripting to be a systems-software-like building block for more complex frameworks. A 10-line program does not need the rubostness of a virtual OS, which a GUI framework has to be more or less. (Take *that* emacs :-)

Re:What's so special about AJAX?

[_DangerousDwarf]

While, in web terms if 4 years isnt forever then 7 years is. Let's not forget that back in 1999 MS had something like 95% of the browser market.

Both

[HotBlackDessiato]

Which side would you agree with?"

Both is the missing option here.

Slashdotted?

[gigne]

It would appear to be slashdotted already.

They should have invested in some more bandwidth and better servers to cope with all that AJAX overhead.

It's the latest fad

[Eli Gottlieb]

Computing power and responsibility has oscillated between the user's terminal and central servers for ages. With a user environment composed of unreliable, insecure software such as Windoze, it's really no surprise many users would rather that application data be held by the application maker. Application makers oblige by trying to take advantage of the most convenient platform universally available on user computers.

Unfortunately, that platform is the web browser, and attempting to run applications in it gives as AJAX, since Java failed to provide a suitable cross-platform environment. We could be running NeWS (NEtworked Window System by Sun, not the stuff you see on Slashdot), Flash, Java, or even remote-PC programs that transmit I/O across the network, now that sufficient compression is being developed. However, history overrides technology and gives us AJAX.

Re:It's the latest fad

[Andrew Kismet]

Flash is an awful development environment, albeit consistent compared to the Javascript issues between Mozilla, IE, and the others.
Java is slow and clunky, if you're talking about the applet form. It's alright to make stuff in, but the fact that it almost universally sits inside a browser window invalidates your point about not using browsers. NeWS and and remote-PC applications, those I can agree with you on. Except the former would, like Linux and Mac, only be adopted by a niche and create even more diversity/compatibility issues (delete as suits your personal views). That leaves just remote-PC applications... perhaps Microsoft have something in the pipeline? Sounds dangerously profitable to me. :-/

AJAX will have to do for the time being. Fad or otherwise, at least it works... I've yet to have a problem with Google Maps, or any similar web-app.

Re:It's the latest fad

[NateTech]

I wouldn't call 25 years "ages".

All this really seems to indicate is that "we" as a business entity haven't quite figured out with REAL numbers what the most efficient and productive use of computing resources is, yet.

If we knew for a fact that putting "X, Y, and Z" applications on the server, while those doing jobs related to "A, B and C" need to have that computing done on their desktops...

We might stand a chance in hell of becoming a real Engineering disipline someday.

"Best Practices" are nice, but show a distinct lack of maturity in the technologies used. "Codes" and "Standards" set over time with hard numbers to back them up are the world most "real" Engineers live in.

AJAX is an outlet for those who'd like web-browsers to do more than they were originally designed to do, is all. Useful? Extremely in some cases. But always? No.

Just like all other attempts to measure a technology by that technology's potential (e.g. The "bubble" bursting a few years back), this one is an exercise in futility.

Treat IT like a real business within your company and only dole out capital for IT that either makes or saves the company revenue -- and you'll have all those pesky things like "business models" fall into place. No need for a model -- use the real numbers. Only guess when you HAVE to.

AJAX as a technology then: Useful, to a point. Just like all technology enhancements. The real trick is to see if AJAX can save money over building a real app for a desktop or thin-client machine. Somehow, I truly doubt it. Does it possibly save money by forcing central-administration? Yeah, maybe, but I've seen companies so bogged down in the hassles of centralized administration to know that sometimes their business divisions NEED the flexibility of a custom application. Etc.

In short: We'll see how useful it is by looking at the REAL numbers of those willing to gamble with their IT budgets. If they're gaining ground over everyone else (Google certainly seems to be, but they might be the exception rather than the rulle), then perhaps it's time to make a shift within our own organizations.

Re:It's the latest fad

[ultranova]

"Best Practices" are nice, but show a distinct lack of maturity in the technologies used. "Codes" and "Standards" set over time with hard numbers to back them up are the world most "real" Engineers live in.

Most "real" engineers live in a world where the laws of physics don't change overnight, so hard numbers you calculate today have some meaning tomorrow. Software engineers, on the other hand, live in a world where not only are they not told how much load the thing they're building has to bear, but the very fundamental laws of physics - development goes on, after all - keep on changing and some maniacal black hats keep on trying to sabotage the whole thing so it falls down.

Comparing sofware and "real" engineers is stupid, since they just don't live in the same world, or even in the same Prime Material Plane.

Re:It's the latest fad

[NateTech]

No it's not "stupid". If more software "engineers" would demand this data they need to properly ENGINEER the product and their management would back that request up, things would get better for all.

The problem is, for every one engineer out there who WILL ask, there are ten or more who won't, or who (worse) are too stupid to even know what they need to ask.

Software "engineering" will only grow up after a software-driven event happens that causes great harm and pain to a whole lot of people. (Just like mechanical and civil engineering disciplines.) Guaranteed that it WILL happen, since as you pointed out... even good Software Engineers have "thrown up their hands" and given up on getting even reasonable specifications.

There are some areas where software ENGINEERING practices are followed... and they have good results. Avionics, and Aerospace come to mind. Also public-safety radio systems and most RF-based communication systems that have added computer controls over the years.

But the average "software" company just continues to shovel out the shit. Changing languages, changing coding styles, changing specifications on-the-fly. It really is bad when you sit way back and analyze it. And definitely not ENGINEERING.

Good comments... we'll see where it goes. The thing to remember is that whatever the large "event" is that hurts a lot of people because of a software problem from badly written software... you and I could be included in that list of "poor souls" who got hurt, all because some jack-ass coder was lazy and had no discipline.

What ever happened to XUL?

[pschmied]

It seems like XUL has/had so much potential to provide rich user interfaces via the web. Apart from Firefox extensions that may use bits of XUL, what are people doing with it? I remember an example of a XUL interface to Amazon.com that was quite impressive. I kept expecting web sites to start having XUL versions with very rich UIs. I seem to recall that Oracle was even interested in XUL for a while.

How is this on topic? Well, it seems like AJAX is delivering a lot of the rich UI stuff that XUL was supposed to, but in a slightly less elegant way (from my peripheral understanding of both technologies). Am I fundamentally misunderstanding something here, or is AJAX a popular but pale immitation of what XUL was supposed to be?

-Peter

Re:What ever happened to XUL?

[Alfred, Lord Tennyso]

Ajax runs on IE; XUL doesn't. That's going to increase its "installed base" by an order of magnitude.

Ajax also lacks an installation step. As far as I can tell you always had to download and approve XUL code before it could run, and sometime requires you to reboot your browser.

Availability is always going to trump elegance when it comes to environments.

Re:What ever happened to XUL?

[Anonymous Coward]

you are correct. as for why XUL hasn't caught on... see, there's this thing called Internet Explorer. the company who makes it is exteremly paranoid and has a severe case of not-invented-here syndrome, so they don't support XUL.

Re:What ever happened to XUL?

[Anonymous Coward]

> Ajax runs on IE; XUL doesn't

XUL can run in an applet or use Java Web Start. Of course at that point, who would want to use XUL anyway when you could just use Swing?

Of course IE doesn't come with java either, though it can install it as an ActiveX control as easy as flash, and anyone who plays online web games probably already has it.

Re:What ever happened to XUL?

[Ant P.]

Nobody uses XUL on the web for the same reasons nobody uses MS "HTML Applications". That's a good thing.

Re:What ever happened to XUL?

[pschmied]

I agree with your assessment about IE and availability, but I still would have thought there would be a few geek-focussed sites that might have cropped up with rich UIs in XUL. I mean there is a reasonably large Firefox install base now, and I'd have thought that for some sites, that would make writing the UI worthwhile. Maybe it's harder to write XUL than I think.

The only detail I'd nitpick is that the installation bit only affects certain classes of application. I'm not sure what makes an app require an installation and others not, but the Mozilla Amazon Browser seems quite slick and doesn't require installation (at least not in my Camino browser).

-Peter

Re:What ever happened to XUL?

[Brandybuck]

You didn't hear the answer the first time. Let me rephrase it differently. People no longer want brand-only stuff. They didn't like IE-only, they hated Netscape-only, and they abhor Firefox-only. It's not about being an open source browser, it's about FREEDOM to run a different browser than what the developer wants you to.

Re:What ever happened to XUL?

[CastrTroy]

The other problem is that you don't always get to use the browser you want. Many businesses are still IE only, and if that is where people are accessing your site from, they are going to be a little unhappy that they aren't getting the full experience, because your website doesn't run on the #1 browser (based on install base) in the world. There's a lot of other places such as web cafes where people don't really have a choice of what software they are running Although I would hate to run a web cafe with windows software, you'd have to reimage the computers every night. It would probably just be easier to run a Linux Live CD. Anyway, I think that AJAX provides a lot of the functionality that XUL does, while still allowing it to run on all modern browsers. Even among the geek community there's a lot of people who refuse to run anything but Opera, or even swear by IE. Some people are just stuck in their old ways.

Re:What ever happened to XUL?

[Jerf]

XUL, if you are speaking of XUL proper, just isn't that useful to make it worth toasting 90% of your audience. XUL is basically just some more widgets than what you get in HTML, highly focused on writing a browser. Anything you see in Mozilla or Firefox is XUL, so you can see a lot of the extra widgets just by poking around in the "preferences" dialog or looking at the browser's basic interface (menus, location bar, etc).

Mind what I'm saying; I'm not saying real menus or a real tree widget isn't useful; I'm saying they haven't made it worth cutting out the IE chunk of your audience. I'd love to see the W3C standardize a tree widget into (X)HTML, but that seems unlikely right now.

The behavior of XUL is specified with Javascript, and that's indistinguishable from how conventional HTML pages already have the full power of Javascript.

So, the only part of the traditional XUL platform left is XBL, which A: doesn't appeal to your average "cowboy" coder anyhow because they can fully understand the costs of using XBL but can't see the benefits and B: Has basically missed the window where it could impact anything because it's been buggy as all hell for a long time, to the point where even if they fix it a lot of us wouldn't notice. Basically, it works for writing a browser but my experience is that the minute you step outside of that domain, all hell breaks loose. Granted, that experience is from 2005, but it didn't materially differ from my experience in 2000 (no typo).

If you get down to the real causes, I think the basic problem with XUL/XBL etc. is that while it had promise in theory, it brought a lot of baggage into developing even simple applications (you need to understand XML, because XUL and XBL are based on it, plus you need to understand XUL and XBL itself, then you have to understand Javascript, DOM, and to really use XUL/XBL you also need RDF which is another can of worms entirely, and finally it was buggy and implemented just enough to write Mozilla in it and not much more), but it really doesn't offer a significant advantage over, well, much of anything else, really. Having tried to make XUL actually do something several times now, I'd rather develop in Visual Basic. Pre-dot-Net. And I say that as someone who really doesn't like Visual Basic. Basically, six+ years after starting to develop this stack and the advantages are still theoretical; the only existing apps, as near as I can tell, require full-time teams to fix up the Mozilla core in conjunction with the team actually writing the app, and that's just stupid when you've got so many great choices already available to you, from Visual Basic all the way to my preferred Python+wxWidgets (or PyGTK, or PyQt, or heck, even the Tk interface). By the time you get to the point where you are skilled enough programmer to master the stack of Mozilla technologies, you are aware of better choices.

Including just sucking it up and going pure HTML, which is what I ended up doing, writing my own XBL-esque technology to help me. And I've noticed a number of the Javascript libraries like Dojo share the same basic Widget design as my library, so even the majority of advantages of XBL are available in conventional HTML now with readily available open-source libraries, again, leaving what's left not worth it. (Especially if you count the XBL bugs.)

So, the basic problem with XUL, considered as a whole stack, is that the costs are staggering and the benefits very, very marginal. As a result, it's basically dead; there's never a case where XUL is a better solution than either pure HTML or a real app.

Re:What ever happened to XUL?

[pschmied]

Thank you for the thoughtful answer. I've not coded any XUL myself, so it is interesting to hear the perspective of others who have.

Can someone comment on if Mozilla is still pushing for XUL as a way of creating general purpose UIs for the web (maybe they never were?), or have they given up on that in favor of using it strictly for thick client apps such as Firefox?

-Peter

Re:What ever happened to XUL?

[MattPat]

I agree with your reasoning, but because I'm an annoying nit-picker who needs a hobby (who also happens to extensively enjoy Googling)...

DXULi, a DHTML XUL interpreter for IE

It also appears that XUL in IE and other applications on Windows is possible through the Mozilla ActiveX control. Will it catch on? Doubt it, if XUL catches on as a means for rich interfaces for remote applications, Microsoft will just write their own implementation before people start using the Mozilla control. Being the gracious company that it is, Microsoft will gladly embrace XUL, and maybe even extend its functionality out of the goodness of their heart.

Just my 2 cents.

Re:What ever happened to XUL?

[kbahey]

Gmail happened.

Yes, the advent of Gmail, and Google Maps changed the landscape. It proved that using XmlHttpRequest and Javascript is a practical and cross browser way for rich applications.

XUL would have been better since the front end is not as "active" as Javascript.

There is something called XULRunner that is supposed to be a standalone application for XUL front ends, and not tied to a browser.

Re:What ever happened to XUL?

[niittyniemi]

As far as I can tell you always had to download and approve XUL code before it could run, and sometime requires you to reboot your browser.

Wrong. Try this in Firefox:
http://www.hevanet.com/acorbin/xul/top.xul

Re:What ever happened to XUL?

[hritcu]

Firefox extensions are written with XUL, and there are plenty of them.

Re:What ever happened to XUL?

[jrumney]

As far as I can tell you always had to download and approve XUL code before it could run, and sometime requires you to reboot your browser.

You always have to download DHTML pages and their associated Javascript and CSS too. You don't have to approve them because the designers of Javascript took the position of limiting what the language could do instead of the approach taken by XUL, Java, .NET and ActiveX which was to require user approval for actions that could potentially be dangerous. As for rebooting your browser, that is true of extensions, but XUL-only applications do not require it.

Re:What ever happened to XUL?

[jrumney]

if XUL catches on as a means for rich interfaces for remote applications, Microsoft will just write their own implementation

They did, it's called XAML and has about the same rate of adoption as XUL. The problem with both of these languages is that they are markup languages targetted at programmers. Programmers don't want markup languages, they want programming languages. UI Designers want markup languages, but they are not programmers so languages like XUL with its reliance on Javascript to do anything useful, and XAML which is basically the Win32 API written in XML, are not useful for them.

Re:What ever happened to XUL?

[Jerf]

I'm going to hazard a guess that if I got a +5 on Slashdot goring what used to be a very sacred ox (the benefits of XUL), and then you posted this question basically begging for someone to justify that XUL will become something in the future, and you got 0 answers after ~15 hours (not even one contradicting me), that the ferver is dead. The set of people who would post that message is probably still non-zero, but it used to be you couldn't spit without hitting one on Slashdot.

The project continues, I know, but I think the evangelism and the hope amongst the general population has passed. I know they are building their XUL runtime, with the goal of separating out Firefox and Thunderbird and Sunbird and the other things currently based on XUL so they can all share a runtime instead of requiring one customized copy of the (large) backend per app, and theoretically other things could run on it, but that's probably about it for XUL for a while.

Meanwhile, the real widget platforms like GTK and QT are growing ever more powerful capabilities, and you can attach Python or Perl or Ruby or a number of other things to those platforms, all of which are better than Javascript right now for large programming projects, and all of which are better than C or C++ for GUI application development in the general case. (Javascript is better than most people think, but it's missing some key features for app development right now, like namespaces, a threading model, and a few other things.) By the time Mozilla gets to where they want to go, I'll bet QT is basically there, only with everything else QT can do, too. (Take a look at their API sometime, even if you aren't interested in a QT app at the moment, or the GTK API. What you can do with those things is amazing.)

Re:What ever happened to XUL?

[Anonymous Coward]

Wrong. Try this in Firefox: http://www.hevanet.com/acorbin/xul/top.xul

I tried it in Not Firefox. Nothing happened. See the difference between that and Ajax?

Re:What ever happened to XUL?

[ultranova]

Wrong. Try this in Firefox:
http://www.hevanet.com/acorbin/xul/top.xul

I tried it. It works, but is horribly slow to scroll. And would likely be horrible to use too, due to the sheer amount of buttons.

Don't make rich UIs, make usable UIs. Keep it simple, stupid !

Re:What ever happened to XUL?

[aevans]

All XUL does is take away table formatting. I've developed XUL apps and ended up scrapping a bunch of HBOX/VBOX formatting and going back to HTML. What we really need is a HTML way to build "components" (a la Tapestry) or "widgets" from basic HTML tags. Trees and Menus and custom selectors like sliders with images.

scalable eCommerce reach-around compatibility

[Anonymous Coward]

with AJAX your enterprise solutions become web 2.0 reach-around standards compliant!

AJAX is putting the D into DHTML

[usrusr]

We have all been seeing DHTML being an incredible fad for so long time and without there ever being anything really dynamic to it.

Now that we finally see dynamic HTML happen (even if the name has changed), how could we not expect the hype about the real thing to at least match the past hype about the early attempts?

Sure the name is stupid, but who cares! We do need some good hype to get standardization of something like that xml request object done and a catchy name can only help.

I'd call it a Cognitive Avalanche

[smug_lisp_weenie]

AJAX is actually made up of a bunch of separate ideas from the last five years, each of them too small to penetrate the fog of internet... But the term AJAX just triggered all of these ideas as a group into a "Cognitive Avalanche" (to possibly coin a new term :-)
The ideas are as follows:

1. Javascript, despite what people used to think, is actually quite powerful and well designed
2. Google and their employees are super smart- Maybe if you look at their source code you can capture some of their magic
3. Humans are kind of primitive- If you make your program do something flashy while fetching its data (as opposed to just freezing up the browser for a few seconds as a page loads) the humans think your software isn't as slow as it actually is.
4. You know, browsers have this thing called DOM that allows for ultra-powerful tweaking of web pages
5. Standard web forms are slower and more tedious than you think
6. The web used to serve up documents- That is a bad idea: Serving up data would is a better idea
7. In an ideal world, all the world's software/data/operatingsystems/etc would just live on the web

None of these ideas were really important enough to push through to the web developer consiousness and have just kind of quietly developing while no one was noticing- Then some dude calls this stuff AJAX and BAM! the web 2-dot-whatever avalanche begins in earnest.

Re:I'd call it a Cognitive Avalanche

[CosmeticLobotamy]

Don't worry guys, I did the legwork for you. Here's the secret message:

AJAX Javascript is actually quite powerful look at their source code make your program do something flashy isn't as slow as it actually is browsers have this thing called DOM Standard web forms web bad idea data quietly developing AJAX.

Re:I'd call it a Cognitive Avalanche

[Anonymous Coward]

Aw, that was a good one. I laughed and laughed. :)

Re:I'd call it a Cognitive Avalanche

[cperciva]

You missed the really secret message, which was hidden in the italics, not the boldface. Unfortunately the punctuation was lost, but here's the secret message (including punctuation):

Separate each of them, too. Small humans are kind of primitive; slower, tedious documents -- better idea. BAM!

I think he's conveying instructions on how to teach children: One-on-one teaching, using simple and straightforward teaching materials.

Re:I'd call it a Cognitive Avalanche

[Anonymous Coward]

Who knew Emeril had such interest in pedagogy?!

Re:I'd call it a Cognitive Avalanche

[Phroggy]

6. The web used to serve up documents- That is a bad idea: Serving up data would is a better idea

Serving up documents is not a bad idea. Taking data that is not a document, mangling it into a document and serving it up is a bad idea. Round peg in square hole, and all that.

Re:I'd call it a Cognitive Avalanche

[Herkum01]

Must be a manager because he added all those words that don't mean anything then...

Re:I'd call it a Cognitive Avalanche

[smug_lisp_weenie]

> Taking data that is not a document, mangling it into a document and serving it up is a bad idea.

If you asynchronously fetch data (ala XML) and format it onto the screen as a document with Javascript using AJAX this is clearly a danger. But "serve up data, not documents" is definitely a philosphy behind AJAX.

Re:I'd call it a Cognitive Avalanche

[grammar fascist]

I think he's conveying instructions on how to teach children: One-on-one teaching, using simple and straightforward teaching materials.

And then hit them. BAM!

Re:I'd call it a Cognitive Avalanche

[maxwell demon]

Javascript, despite what people used to think, is actually quite powerful and well designed

Well, the problem with JavaScript was never that it is not powerfull enough (although before DOM it indeed was much less powerfull). The problem always was the security risks. And those still exist. Especially with XmlHttpRequest!

In an ideal world, all the world's software/data/operatingsystems/etc would just live on the web

I strongly disagree! I don't want to be dependent on an internet connection when I access my data/applications. And I like to have my data on my own hard disk.
Ok, in an ideal world, internet access would be free, ultra-high bandwidths would be the norm, there are never any problems whatsoever ...

Re:I'd call it a Cognitive Avalanche

[Bogtha]

Google and their employees are super smart- Maybe if you look at their source code you can capture some of their magic

Please don't. Google are good at server-side stuff, good at user-interfaces, and good at picking out the best mix of unusual features. They suck at client-side web development. GMail is great, yes, but that's because of the features and because they chose to use XMLHttpRequest - not because of the actual quality of their code. If you learn from Google's code, you'll learn wrong. IBM had a good series of tutorials on Ajax, and the DOM Scripting book is reputed to be very good. I suggest you learn from those instead.

Re:I'd call it a Cognitive Avalanche

[Anonymous Coward]

Google's emploees are posting articles on slashdot instead of thinking about something really new instead of stealing other people's ideas. You can call it whatever you want. Google is dying plonkhead!

Not a fad

[Phroggy]

AJAX is not a fad. People aren't using AJAX just because it's AJAX. It's not for buzzword-compliance, although it has become a buzzword. It's not for adding useless frills, although it can be used for useless frills. AJAX is a tool to enable web developers to build sites that are actually better for the user, in a very real way. Better functionality, better usability, overall a better user experience. Things that simply weren't possible to do before.

Slashdot's new comment system uses AJAX to make my Slashdot experience better. They're not done with it yet, but what they've got so far makes it easier to browse Slashdot. The link to read the rest of a very long truncated comment now loads the rest of the comment inline into the page, instead of reloading the entire page like it used to; I can read replies without opening the links in a new tab and switching back and forth like I used to, I can even change my thresholds without reloading. Sometimes I like to open several articles on my laptop and read them when I'm offline; that works better now. Next will be a more convenient way to moderate, and a better way to write replies.

Will AJAX go away? Sure, after a better technology comes along. But until then, AJAX is genuinely useful.

Re:Not a fad

[RLiegh]

>Slashdot's new comment system uses AJAX to make my Slashdot experience shittier.

Fixed to reflect the truth. The new comment system might be circlejerk omg! web 2.0 AJAX Ponies! compliant; but as a dialup user I find it a huge pain in the ass, though I think it would still suck even if I had better bandwidth (I read at -1, and I have to adjust the threshold for each thread? Fcuk that!).

I can't speak for anyone else, but the minute they eliminate the old comment system is the minute I'll probably abandon slashdot.

Re:Not a fad

[mark_lybarger]

it's not a fad in the same way that the j2ee servlet container isn't / wasn't a fad.

but... the current tools for ajax lack the common patterns of solid software development systems. mvc for one. with a traditional mvc framework (struts, turbine, whatever) it's very easy to tie an html data item to a back end data store. it's even fairly simple to tie an entire page of data (view/model) to a backend object store (also known as rdbms) and have the "business logic" or controler handle the flow of the application. with ajax, afaik, the entire process of tieing a page of data to the backend store isn't standardized and there aren't good frameworks for handling this common pattern.

Re:Not a fad

[Starruler]

If you use the floating window on the left and set it so all comments are visible that carries through to each thread.

Re:Not a fad

[Phroggy]

as a dialup user I find it a huge pain in the ass, though I think it would still suck even if I had better bandwidth

I can see how it would be annoying on dialup, because it loads all the comments on the page (truncating the really long ones) right away, thus making the whole page take much longer to load.

(I read at -1, and I have to adjust the threshold for each thread? Fcuk that!).

Wait a minute, what? You read at -1, does that mean you always see every comment in its entirity and just manually scroll past any you don't care about? That's perfectly fine, but it completely negates my previous criticism about making the page take longer to load, since you're loading all the comments anyway. And what's this about adjusting the threshold for each thread? You can change your default thresholds in your user preferences - that's what user preferences are there for!

AJAX/Remote Scripting Hype

[y5]

The AJAX hype is like the DHTML craze all over again. IMO if you can't create a site using remote scripting without suppressing the urge to advertise to the world that you're doing so, chances are you're abusing the technology. Why should your user base care what the hell technology you're using? It should just work.

Re:AJAX/Remote Scripting Hype

[Zontar The Mindless]

...if you can't create a site using remote scripting without suppressing the urge to advertise to the world that you're doing so, chances are you're abusing the technology. Why should your user base care what the hell technology you're using? It should just work.

Spot on. The coolest apps are those that *don't* waste the user's time by singing and dancing and shouting, "Look at me! I'm a cool app!"

Re:AJAX/Remote Scripting Hype

[Phroggy]

Exactly! Notice that Slashdot's new comment system uses AJAX, but doesn't advertise itself as AJAX, it just says it's the new comment system. Some of Google's recent projects (Google Maps, GMail, etc.) don't advertise themselves as AJAX, they just work.

I hate AJAX....

[sloths]

For the most part. Gmail does it well, but I can't stand Digg.com.

Re:I hate AJAX....

[frazras]

Digg only sucks on IE, worse on IE7... dont tell me you still use IE *gasp* http://getfirefox.com/ NOW!

Re:I hate AJAX....

[sloths]

What's wrong with IE? I used to use firefox, but it uses way too much memory than it needs to. And stop advertising that stupid browser. I swear, everyone who uses it acts like a cult member.

Re:I hate AJAX....

[frazras]

Im sorry but as a web designer, a browser that obeys about 50% of the web standards SUXXORZ! i hate it when I design a "standards compliant" site in firefox which looks absolutely different in IE. Firefox supportors don't support becuse its a fad, its our bad experinces with IE that gives us the urge to go on. I thought this would have knocked sense in microsoft for IE 7 but from what I hear its worse. IE is SLOW and a popup generator, just to get rid of those popups u need to install programs that together with IE take up way more memory the FFOX. But then again, thats why I use linux [no popups] but thats another story.

Re:I hate AJAX....

[sloths]

Well stop visiting website that serve popups you idiot. Nearly all of those websites are BS anyway.

Sure, on my fast computer I use firefox, but on this one I do not. Remember, the Internet is SERIOUS BUSINESS.

Re:I hate AJAX....

[grammar fascist]

I swear, everyone who uses it acts like a cult member.

I haven't got a clue what you're talking about.

Now if you'll excuse me, I have a chicken to sacrifice.

Isn't it obvious?

[noidentity]

Dirty countertops everywhere are the number one cause.

Re:Isn't it obvious?

[dominique_cimafranca]

Of course! AJAX is also SOAP.

Re:Isn't it obvious?

[WilliamSChips]

AJAX is Snakes on a Plane?

What's in a name?

[dominique_cimafranca]

Never underestimate the power of a catchy name. AJAX's underlying technologies have been around for a while, but it wasn't until someone slapped the acronym onto it that it's really taken off. AJAX is easy to say and easy to remember, evokes a bit of mystery and jargon (one more conspiracy against the layman), and is named after a legendary Greek hero. What more could a marketing person want? The name is simply an inspired choice.

Re:What's in a name?

[williamhb]

Never underestimate the power of a catchy name. AJAX's underlying technologies have been around for a while, but it wasn't until someone slapped the acronym onto it that it's really taken off.

You mistake synchronicity for causation. The term AJAX was coined when the first very-widely-used "cool app" to use the technique (Google Maps) was noticed by the online public. Many dozens of other organisations were already developing their "cool apps" using this technique before Google Maps was released, and much before the name "AJAX" was coined. It's just much quicker to coin a buzzword than to finish building a software product, which is why all those other sites appear to have only emerged after the buzzword was coined.

The actual trigger was more likely that cross-browser support for it had become good enough, and the version of IE that supported it had been out long enough that developers could reasonably count on users to have that version and not an older unsupporting version of IE [users before Windows XP might not have upgraded their browser, so WinXP needed to have been around for a couple of years to have gained usershare]. Then add to that a delay to prototype, build and release an application.

If it's a wildfire then, get me some matches, stat

[JoeShmoe]

I'll admit that the concepts behind AJAX excite the hell out of me. It's really something when you think about the fact that...it's really nothing new so much as, a theory that finally has some real practical applications and examples. Everyone I think has always known that...the worst thing about the web is the idea that you'll be in the middle of a process, like filling out a financial form, or managing a shopping cart of items, whatever and then be interrupted by a need to click a link. How many of us will be filling something out, not understand it, and see a Help link and for a brief second worry that when you click it, you won't get a nice friendly popup but get whisked away to some help page and have to start the whole damn thing over? (raises hand) That's the kind of ugliness that breaks things like webmail or shopping carts or financial forms. I can't tell you how many times I cussed a blue streak because I accidentally lost focus from the mail field in Hotmail, hit backspace meaning to erase a word and ended up back in the inbox where, thank you dynamic pages, pressing forward takes me to a new empty compose mail window.

Now obviously, that's the programmers fault...webmail should never throw anything away regardless of the user clicking Back and Forward on their browser. And I think that's the theory behind the AJAX effect. Really, back and forward are supposed to be the last things I'll ever hit. In fact, Google Maps I believe has to go through considerable kludges to even have entries show up in the Back and Forward browser list...and I can tell you there are plenty of times I wish I could go "Back" to my previous map location but instead, got taken back to the original empty Direction page I started at. So, if AJAX is done right...everything I ever need to click is right there. And that's what have been valuable since Windows was born. A poorly written web application/interface is like having to use Calc.exe Notepad.exe Paint.exe and CharMap.exe to make a document instead of WinWord.exe doing it all in one place.

In fact, I'm a little upset the whole stampede behind AJAX apparently caught so many developers and programmers napping. I've been hiring PHP/MySQL programmer for years now but, I start asking questions like... can't we have it so when someone clicks this header it just drops down a propigated list of choices instead of having to pop them up in a window or regenerate the page? And they stare at me like I'm asking for the moon or wanting an entire database of 400 items preloaded on the page before it renders. The guys with "AJAX" on their resume are...well they apparently know what that buzzword is worth and have their hands full writing the next Flicr or Digg or whatever.

And I'm one of them. I've had an idea for a web-based application but...because it involves just so darn much data, I've been having it developed as a template/macroset in Word because I can piggyback on the already present features like AutoText and Toolbars to provide an interface and packaged output. Now, I'm excited that I can have something just as dynamic and immediately accessible, but available on any platform and any location and without relying on software I don't control (I've already found two critical bugs in AutoText that Microsoft has admitted are bugs present since Word 2000, cannot be fixed by any option/registry setting, and will hopefully be fixed in the next version but possibly the one after that...oh gee thanks). So I want to start my own wildfire by creating something that would make a wonderful application, but have ability to distribute that application to thousands and tens of thousands of users as easily as sharing a link. That's amazing. That's why it's a wildfire. I just wish the store wasn't sold out of all the matches.

- JoeShmoe
.

Stronger than dirt!!!

[absurdist]

God, I AM showing my age...

Re:Stronger than dirt!!!

[Paradise Pete]

God, I AM showing my age...

You're not the only one. Speaking of cleanser commercials, check out what's still rattling around inside my head:

(singing)
Mis...ter... Clean gets rid of grease and grime and dirt in just a minute.
Mr. Clean will clean your whole house, and everything that's in it.
Mr. Clean Mr. Clean...

that box

[Anonymous Coward]

How do you make that little popup box stay away? I keep trying to "help out" checking the new code, but that dang box will NOT stay away. X it out, a second later it pops back up. It covers a lot of the comment, and you can't drag it out of the way either.

Now I am on slashdot "low res" version when I use it, maybe that's the reason, but I can only take 60 second or so of it before I stop trying it out.

Re:that box

[LiquidCoooled]

There might be a problem with the lowres bar, but in the full version, it covers the left bar only and doesn't encroach upon the comment space.
Perhaps the centre top bar they used to use would be better for compressed screens, or even the first one which didn't even move with the page.

Re:that box

[Phroggy]

It reappears when you mouseover the comments (it's not a time delay). I'm not on the "low res" version; as someone else said it only covers up the left sidebar and doesn't really get in the way (originally it spanned across the top and was really horrible; this is much better). There's probably a bug with the "low res" version they haven't addressed yet.

I agree that having it reappear all the time is annoying. They should make it stay gone when you close it, then have an obvious way to show it again when you want (currently I know of no way to re-show it aside from hovering the mouse over a comment, which is bizarre behavior).

Anyway, other than that, the rest of the AJAX stuff is nice. :-)

Re:that box

[maxwell demon]

Is it actually AJAX? That is, does it secretly make a round trip through the server, instead of just manipulating the already loaded page content (aka DHTML)?

Re:that box

[Phroggy]

Now that you mention it, I'm not entirely sure. The "Read the rest of this comment..." link is AJAX, but the rest probably isn't.

Deja Vu all over again

[sotweed]

It seems to me that you have to separate out why Ajax is spreading among developers, and why Ajax-based applications are popular with users. These are not totally independent, of course, but worth thinking of in different ways.

I see Ajax-based applications as being very reminiscent of the what used to be called "full-duplex" applications. Unix, because it was based on using teletypes for I/O to the user, and because teletypes were inherently full-duplex, seemed much more interactive, at least with some applications. Nothing quite like Ajax, but a step in that direction. Conventional main-frame apps, based on either half-duplex (I type, then I hit carriage return, and the keyboard locks until the system responds) or electronic versions of that (such as with the famous 3270 displays, which would lose characters if you typed when the system wrote to the screen), were much more ... well, boring.

So, it seems to me that, from the user's viewpoint, Ajax can allow the app builder to effectively decouple user input and system output, and make the whole "flow" between system and user be much more continuous, and less synchronized. Another way of seeing this is thinking of an overseas phone call in the days of poor channel allocators, which really made it necessary to stop talking when the other person started, or neither of you would hear the other. Nothing at all like a really engaged, face-to-face, conversation.

Not a fad

[Anonymous Coward]

"Will AJAX go away? Sure, after a better technology comes along. But until then, AJAX is genuinely useful."

XMPP

Not a fad, not a revolution.

[Anonymous Coward]

It's just the next step in rich user interfaces on web pages. Nothing more, nothing less. Not a fad, but not a revolution, either. Web 2.0 doesn't exist. It is a stupid idea thought up by marketing guys with nothing better to do. There will not be a sudden shift in the way everything is done. Instead, things will gradually improve over time. The technology behind AJAX is cool enough, but it does not warrant the immense bullshit marketing and exposure it gets.

coral cache version

[Anonymous Coward]

The linked to site seems dead. Here's a coral cache version: http://ajax.sys-con.com.nyud.net:8090/read/256389. htm (posted anonymously to prevent karma whoring)

Google is Evil

[Saint Stephen]

This is on-topic, because this week Google ajaxified their home page a little, moving Groups to an web 2.0-ey submenu that takes me 1 extra click to get to, and replacing it with the ridiculous Video web-2.0 ey thing. I view these actions as evil, because they are more about making Google money and less about what I want to do - which is quickly search groups for answers to programming questions. (When you ask a programming question on the web page all it takes you to is one of 40 spyware/spamware awful wrappers around usenet anyway, and if you just click to groups you see the exact same text minus the horrible ads and popups).

Google drifts evil every once in a while, and then to their credit they drift back, but currently they are drifting evil.

Okay, so, it's a little off-topic, but since there was no thread about Google's big change this week I needed to vent. (They also switched dictionary.com to answers.com which is more spam-mey and popup-ey).

Re:Google is Evil

[abh]

Are you unable to bookmark the Google Groups search? If you're complaining it takes you too many clicks to get there, perhaps you should change your starting point...

Re:Google is Evil

[Saint Stephen]

The way I use it to answer programming questions is usually to bop back and forth from web to groups refining the question. It's usually better to find it under web first, but if hits all come up as obvious usenet-wrapped spam pages (the worst is that experts exchange which hides part of the thread, AND fires off a popup), I zap to groups.

Re:Google is Evil

[vtcodger]

***Google ajaxified their home page a little, moving Groups to an web 2.0-ey submenu that takes me 1 extra click to get to, and replacing it with the ridiculous Video web-2.0 ey thing.***

I'm not sure of the cosmic significance, but if your browser doesn't support Ajax, Google presents the submenu on the main page where you (and I) want it. Perhaps this is a subtle warning from God that she disapproves of AJAX and will eventually smite those who embrace it mightily.

Re:Google is Evil

[Anonymous Coward]

This is on-topic, because this week Google ajaxified their home page a little, moving Groups to an web 2.0-ey submenu that takes me 1 extra click to get to, and replacing it with the ridiculous Video web-2.0 ey thing. I view these actions as evil, because they are more about making Google money [...]

Two points.

1) Froogle makes money. Groups makes money. Both are ad-supported. Video does not make money; it does not show ads. The not-making-money one (video) was promoted and two making-money ones (Froogle, Groups) were demoted.

2) Making money is not evil. You do have a salary, don't you? Are you evil?

Re:Google is Evil

[WilliamSChips]

By 'she' I assume you mean Alanis Morrisette, right?

Re:Google is Evil

[dnse0508]

Google's been using Answers.com for about a year now... and it has absolutely no pop-ups. (It's one of Firefox's drop down engines as well)

"All-in-one" is the wrong way to do things.

[Anonymous Coward]

So, if AJAX is done right...everything I ever need to click is right there. And that's what have been valuable since Windows was born. A poorly written web application/interface is like having to use Calc.exe Notepad.exe Paint.exe and CharMap.exe to make a document instead of WinWord.exe doing it all in one place.

Long before Windows was "born", many of us were using UNIX or UNIX-like systems. And what we found was that it is often a very bad idea to have software that tries to do everything. Indeed, it has proven time and time again to be perhaps one of the worst ways to develop software. The end result always has certain traits, regardless of whether the all-in-one product is Microsoft Office, OpenOffice.org, Emacs, or Nescape Communicator: instability, security vulnerabilities, slowness, bloat, and low usability.

Systems like GNU/Linux, BSD, Solaris, System V, AIX, HP-UX, etc., follow the principle of small, versatile applications that do one task very, very well. It's a methodology that has been proven to work wonders. Small commands are better understood both by the developers and users. Bugs are easier to track down. Changes can be made far easier, and with a greater degree of safety. Overall, there is a high degree of cohesion within the applications, but between the applications there is a low degree of coupling. Through the use of pipes, their inputs and outputs can be linked in numerous ways, depending on the task to be performed. It's a strategy that focuses on simplicity and quality, and that's exactly what we end up with.

Functionality should be separated as much as is sensibly possible to do. It's best to have many smaller applications that each perform a function very well, rather than one big application that tries to do everything, but ends up doing basically everything very poorly. Best of all, if you don't like one of the components, you can swap it out with an alternative with ease. That's not something you can really do with Microsoft Word, for instance.

Any AJAX application that tries to do most everything has ended up being a piece of shit. I've tried several of the online AJAX-based email clients, and several of the AJAX-based office suites. None have proved any better than using well-tuned UNIX applications. Take GMail, for instance. Pine works just as well as GMail for sending and reading email. It's very easy and effective to use grep to search through my mail directory. And I don't have to worry about any 2 GB limit. Using ssh, I can access Pine from virtually any computer, without needing an AJAX-compatible browser (or even a windowing system!). The traditional UNIX way has again proven to be more efficient, effective and usable than the all-in-one crapfest preferred by yourself and Windows.

Re:"All-in-one" is the wrong way to do things.

[wibs]

>> It's best to have many smaller applications that each perform a function very well, rather than one big application that tries to do everything,

From a technical standpoint, I understand and agree with what you're saying. From a human standpoint, requiring multiple applications to be used at once to accomplish one task decreases usability and increases complexity. Considering that lots of people try to do more than one thing at once on a computer, for anyone who's not a UNIX guru (and there's a fair number of people who aren't and don't wish to be) you're more or less expecting someone who only listens to pop music to conduct an orchestra.

Bloated applications suck. But combining associated tasks into a single coherant interface is not an inherently flawed concept.

Re:"All-in-one" is the wrong way to do things.

[JoeShmoe]

Okay, Mr. "I-was-peeing-in-the-UNIX pool-before-you-were-out-of-diapers" can you tell me how many people you know who regularly carry around the following itmes: two screwdrivers, a pair of pliers, a wirestripper, a wiresnip, a bottle opener, a hole punch, a knife, and scissors. Now, how many people do you know who carry around a Leatherman or a Swiss Army knife? Maybe there is a place for a bundle of tools which are basic and general enough to get most jobs done even if they aren't "the best" at any particular job? I mean, I hate having to rotate the whole off-center tool to turn a screw but, it sure beats a trip home to find a philips screwdriver.

Tools are meant to be specific and single-purpose. The best screwdriver is a screwdriver, not a hammer too. So yes, I agree that if I was writing a tool, the last thing I should be doing is letting feature-creep run the show. But an "application" is not a "tool" and comparing Word to pico/nano is just stupid. Comparing GMail to pine is just plain stupid. Tell me, how do view images in pine again? Or use rich text formatting? Or view PDF files without any external applications? Or notice that the person I was emailing is online so I can just send an instant message instead? Maybe pine is a tool for viewing plain text and GMail is an application of communication features in addition to just viewing plain text. Maybe there's people who want want that. You know, I'd be willing to bet dollars to pesos there are more people who use GMail today than are using pine.

So, you go right ahead and lug around your giant toolbox of specific perfect tools so when someone asks you to open a pickle jar you'll be able to use the 5" pipe wrench that you've never used before and probably will never need again. I'll tap the lid with the back of a butter knife or whatever else is handy and just get the job done.

- Joeshmoe
.

This is whats so special

[gooberguy25]

"What's So Special About AJAX?"

The Calcuim carbonate, sodium carbonate, anionic surfactants, bleach, the quailty control agents, fragrance, and the color!

Here's what I think it is.. as a web app developer

[Anonymous Coward]

We've been writing apps with .Net since 1.0. C# is our preferred lang, but we strive for "Pure .Net". In the new VS from MS, I can deploy a Windows Forms app (desktop app) via a bundled technology called "ClickOnce" or something like that.

If your .Net binaries are pure .Net, there is a seamless deploy & install. Coupled with SOAP/RPC for your data layer and you've got something that blows the shit out of anything you can do in HTML.

We're going Windows.Forms w/ RPC/SOAP for the next big version of our app. Why constrain ourselves to the browser???

The overhead of AJAX.

[Anonymous Coward]

Most people (even administrators and web developers) don't realize the overhead associated with AJAX.

We were recently considering using a AJAX-based email front end for email on our internal network, and had a chance to evaluate it. What we found was quite startling. With our previous plain HTML web-based email interface, we'd push about 15 to 30 KB of data per page view on average, or sometimes slightly more if it was a longer email. With the AJAX-based system, however, we were seeing each "task" (ie. writing a new email, displaying an email, etc.) needing well over 150 KB of data transfers.

At first we thought this may have been a problem with the cache settings of the web browsers we tried. Not so! We even used the browser settings recommended by the vendor. Again, there was no decrease. From what we've seen, the massive bandwidth usage must be attributed to the overhead inherent with AJAX.

One of our tests included logging in, opening up certain messages in the inbox, sending two emails, opening up several more messages, and then logging out. We tried multiple trials using each email system. What we found was that for that particular session, the older pure HTML system would transfer about 350 KB of data. The AJAX system, on the other hand, used a whopping 1.8 MB for that very same session. That doesn't sound like much, but when the system would be used by about 4000 people at a time during the busiest periods each day, it just proves to be unworkable. The hardware investments we would have needed to make to make the AJAX-based system viable would have far outweighed the minor benefits of making the switch.

Re:The overhead of AJAX.

[jozeph78]

Most people (even administrators and web developers) don't realize the overhead associated with AJAX.

Don't forget about AJAX's ability to SAVE you bandwidth. If all you do is strap AJAX on then yeah, it increases bandwidth. If you use it cleverly to say, change the table and only the table instead of reloading all the sidebars as well as teh button to update the table, you can SAVE bandwidth. Or if you use a drop down to avoid wildcard searches, you can save unnecessary queryies from ever being ran. Precious long running wildcarded queries at at.
A problem with it being all new is that developers want to slather it all over themselves and talk about how Ajaxified their site is. Used correctly it can provide a benefit. Otherwise, it's like reloading your page every 3 seconds. Just because it seems so doesn't mean it's no longer a distributed app.

Re:The overhead of AJAX.

[maxwell demon]

If you use it cleverly to say, change the table and only the table instead of reloading all the sidebars as well as teh button to update the table, you can SAVE bandwidth.

You'll especially save the bandwidth formerly used by those customers which left you because they can't bookmark your pages any more.

Personally...

[Traegorn]

Personally I just think that nothing could turn out to be radder than my personal webpage with a black background...

Ajax Security

[mrkitty]

http://www.cgisecurity.com/ajax/

hi res

[Anonymous Coward]

yep, that's it. just switched to check it out. If you opt for low res, the box covers coments (badly, makes it very hard to use). In full bloat it only covers the left hand nav bar. It still won't go away if you click the x to close box though, it respawns rapidly.

Hopefully the code gods might see this comment subthread so it can be fixed.

Also happening gradually over the last few years..

[Mongoose Disciple]

Another thing that's been happening gradually to make excitement about this possible is the replacement/upgrade of web browsers.

Like many of the other people weighing in, I'd developed web pages with features basically amounting to AJAX years ago. The problem was, especially if you were developing a commercial website, is that there'd still be a decent-sized chunk of people using old-ass browsers that didn't support JavaScript (or who had turned it off.)

Most companies aren't willing to flip even 5-10% (or whatever) of their potential online customers the bird, so what you end up doing is either not creating something AJAX style, or essentially implementing it twice and switching between the two depending on what a user's setup will support.

I haven't seen numbers, but I'd bet there percentage of people using aforementioned old-ass web browsers is a lot lower now than five years ago. Probably, you could get away with having a site that only worked the AJAX way.

Javascript security will hurt it

[mycall]

With new Javascript exploits which detect internal network information, there could be a decreased use of Javascript at companies and enterprise networks. This could hurt AJAX.

Definite Need, HTML-centricism suuuucks!

[Tablizer]

Whether AJAX will satisfy it or not, Web interfaces are clunky and weak. Retrofitting technology meant for e-brochures to be business GUI's instead has proven problematic. Everybody misses real GUI's, both developers and customers. Whether usable thin-client is possible or not, current efforts have failed such that people are becomming impatient with it and want features of fat/rich clients back. We want MDI forms, useable editable data grids, drag-and-drop, form tabs, etc.

If we have to rely on JavaScript tricks to get it, then that is fine by me. There may be better ways if we start from scratch, but it takes years to mature such technologies, and JavaScript/DOM is already in every browser.

I don't like fads either (look how I bash OOP, see sig), but this one at least tries to satisfy a big existing need instead of try to sell you on a problem you didn't know you had.

Re:Definite Need, HTML-centricism suuuucks!

[zeemu]

Everybody misses real GUI's, both developers and customers.

APhPLIX
AJAX/DHTML applications with real GUIs

Re:Definite Need, HTML-centricism suuuucks!

[Tablizer]

It seems PHP-specific. That is not necessarily a bad thing, but a kit that is server-language-neutral would have wider use. Also, I didn't see a decent editable grid widget in the list. Perhaps I missed it, but the documentation is poor IMO, at least on the large-scale.

Re:Definite Need, HTML-centricism suuuucks!

[flame_aphplix_org]

It seems PHP-specific. That is not necessarily a bad thing, but a kit that is server-language-neutral would have wider use.

If someone is keen to do it, there is nothing stopping them from re-implementing the PHP backend in another language. PHP is my language of choice, so the backend is written in PHP. I don't think this would be very difficult to re-implement as the bulk of the code is in the Javascript frontend and would require very little modification to work with a new backend.

I didn't see a decent editable grid widget in the list.

There is no editable grid as I have not had a need or request for one yet. But an hour ago there was no popup color selector widget... and now there is. I've built a base set of widgets (most of which can be data bound) and have been building extra widgets as required. If you want a specific widget built, put together some specs on what you want and request it. Or you could always jump in and build it yourself. Either way I am more then happy to help.

the documentation is poor IMO, at least on the large-scale.

Yep, the documentation sucks. At the moment the Programming Reference Manual is being build directly from my comments in the code and is far from complete, but this is improving on a daily basis. And if you download APhPLIX there is a sample application included that gives more of an understanding of how the whole system works, along with a lot of extra documentation in the code, and skeleton classes for building custom plugins and widgets.

APhPLIX has been in development for less then a year and has only been publicly available for a little over 2 months, so we are in the very early stages of development and there are bound to be some rough edges. Having said this, the APhPLIX Rapid Application Development environment (APhPLIX Development Studio) is an example of the kind of stable, feature rich application that can already be built using the APhPLIX toolkit. There are also several large scale proprietary applications that have been built using the APhPLIX toolkit & APhPLIX Development Studio.

APhPLIX is entirely GPL licensed and is being very actively developed. Improvements and contributions to the APhPLIX codebase will be gratefully accepted.

--
flame
lead developer, APhPLIX.org

Re:Definite Need, HTML-centricism suuuucks!

[Tablizer]

I appreciate your dedication. As far as an editable data grid, I have been searching for an open-source one for quite a while now. It is the most missed feature from the fat-client days IMO.

Business apps

[Anonymous Coward]

Basically there's a whole host of business applications that keep there data centrally and would've previously required difficult to code, debug, deploy and support multiplatform standalone applications to realize. Doing these things using something like the Google Web Kit to produce AJAX web apps is a way more cost effective option, and anything that can be used to save money will generate a buzz.

Re:If it's a wildfire then, get me some matches, s

[Anonymous Coward]

I've got one word for you: STFU.

I second that

[Belial6]

I too was doing this long ago. But if Amazon's one-click is new and innovative, AJAX must be too.

Arg, they have no idea

[rickla]

It's pretty simple, the two dominant browsers now are no longer broken and can actually do this! I remember trying to make nice tabbed pages, and all kinds of other widgets without using applets or activex. But alas ie and netscape differed a hell of a lot and netscape was extremely broken in many areas of this kind of rendering. Now ie and firefox are the top dogs and they both work.

I call it the tail wagging the dog

[serutan]

I remember finding out about the XmlHttpRequest object in 1999 and thinking this was how Microsoft was going to take over the web. Web pages would become little client-server apps. State maintenance headaches between pages would go away. Instead of a web app being a suite of pages to navigate, a single page would just sit there and make data requests and update parts of itself. I happily started coding XmlHttpRequest in my own job and waited for the revolution to happen. But it never did. For three years Microsoft had the lead with this really cool capability, and they did absolutely nothing to hype it or encourage it. It only rated a few pages in MSDN. Right before IE6 was introduced I remember asking a manager on the IE team what kind of new features to expect. He said it wouldn't be anything much, because Netscape was pretty much dead and therefore there was not much point in putting any dev effort into IE anymore.

Three years later when Mozilla started supporting off-channel requests they did it in native mode, while Microsoft was still using an ActiveX object. MS had all that time to set a new standard for dynamic web pages and they just sat on it. Finally, somebody comes along and invents a buzzword for it and somehow gets it in everybody's face. A few people write packages to make it a little easier. Now Microsoft is playing catch-up with their own version called Atlas. At least that's a cooler name, but jeez. AJAX is a case of Microsoft dropping their own ball and then showing up late to join the game.

Ajax SOAP no help.

[sparkeyjames]

When you have clogged pipes you need something a wee bit stronger.
Say like a fat pipe and a SERVER THAT CAN HANDLE IT. HINT.
Someone up this months server meltdown count by one please.

The evolution of web fads...

[hutchike]

Question: What do all the following web fads share:

1. The <marque> tag in IE
2. The animated GIF89
3. The <iframe>
4. Flash animation
5. The HTTP XML Request/Response in JavaScript

Answer: When people first used them, they way over-used them, but then they just kinda sank into the mix. In time they all became useful, but in small doses. AJAX is no different. For a great example, see finance.google.com.

Flash is too expensive for hobbyists

[tepples]

I see a lot of the AJAX examples and wonder why the authors haven't just used Flash for the job.

Because they learned AJAX as a hobby when they didn't have $699.95 plus tax to throw away for a copy of Macromedia Flash.

Re:Flash is too expensive for hobbyists

[Marcus Green]

It takes a few hours to become passably OK with HTML, it takes a week or so to become passably OK with Flash.

The interpreter is pre-installed

[tepples]

'AJAX' is networking support built in to javascript. Nothing new about it. Most scripting languages have had networking support for quite a while.

It's networking support built into a scripting language that's already present on the end user's computer. The advantage of using an end user's existing script interpreter is that home users (who can't be bothered to install your interpreter) and office users (who can't install your interpreter on company machines per Group Policy) can still use your app.

Re:The interpreter is pre-installed

[Jessta]

That doesn't make it innovation.

Probably a fucking a botnet

[SlappyBastard]

Isn't that how most things spread on the internet?

AJAX means ease of deployment

[tepples]

But that is simply not was http and web browsers are meant for.

That's not what web technologies were meant for. But as soon as XMLHttpRequest was added, that's what they became meant for.

They are meant to have pages. If I want an application, I want an application, not a quasi-application web page running in a browser.

The advantage of AJAX over EXE is that AJAX is an order of magnitude easier to deploy. You don't have to convince your users to install it, and you don't have to hope that your users can convince their system administrators to let them install it.

Thank you Captain Obvious

[_newwave_]

I'm not an Ajax fan...err, "boi," but I really can't stand obnoxious assclowns.

1. "...essentially eliminates" is what was said. He even went on to say, "A button click just sends the data that's pertinent..." Which is quite ironic as this statement also serves to point out the idiocy of mentioning broadband vs dial-up in your response. As if unessential data in a request/response is actually better for dial-up.

2. The proliferation of Ajax is absolutely new. Just as the proliferation of the Internet itself was new in the 90's after Al Gore invented it.

Now please don't respond with an explanation of how Ajax is not a technology in and of itself and that it's really a combination of blah blah blah.

And it's XMLHttpRequest smartypants....Javascript is case sensitive.

False Pretense

[Anonymous Coward]

AJAX makes a web application to work like a client-server application. But there is
no underline engine to support true client-server applications. A Web Server is not, for
example, a Java engine.

What's so Stupid About Ajax!

[euroBob]

Ever since google used this thing to make google maps everyone and their dog is talking about Ajax! I for one would like it to stop along with all the other HYPED up fads in the webdevelopment world ( RUBY most noteably ).

However, these Ajax yappers completely miss a few points.

Just like 'FLASH' Ajax will have adverse effects if used in a site:

1. Makes it unreadable for the blind or anyone else using a browser that doesn't use a fancy javascript.
2. Makes it less readable or unreadable to google and yahoo search engines.
3. Adds yet another step in the web development pipeline
4. Further supports M$'s "we'll make our own javascript" cause. IE handles AJAX differently then the rest ( big surprise ).
5. Breaks the standard accepted policy of unified pages ( essentially re-introducing frames )

Lastly and most importantly,

AJAX yappers talk about response and app like look and feel. If you encounter one of these people then rest assured that they don't know what good layout design and CSS are!

They more than likely have 5+ things happening on the screen at the same time or have too much information on the screen such that user interaction causes the page to have to be completely reloaded.

With proper layout and CSS you can make a web site or application respond and look just like an Ajax one without having to use Ajax or code up some JavaScript piping. The browser will cache the layout correctly and thus the extra 3k of information that AJAX supporters say they avoid is in fact already avoided.

Re:What's so Stupid About Ajax!

[Anonymous Coward]

I totally agree with the poster in parent thread.
There are some other problems with AJAX, I find totally confusing and annoying.

- back and forward buttons don't work (this is a HUGE problem!)
- no way to bookmark a page, or save to disk
- no (automatic) feedback whatsoever that something is loading, or when done loading.

Think about it, it's a useability nightmare for ordinary users.
If the server is slow, it becomes totally unworkable, and you don't have a clue what's going on.

We use an hour registration tool at work that uses AJAX, if you add new users, for some reason the server takes about 10 secs to process it. However because of AJAX, the gui doesn't freeze for 10 secs, but returns instantly. Because of this, people navigate away from the page, and start adding new users, so if there's an error, it is lost. This could create all kinds of concurrency problems.

Offcourse, if you would code it properly this could be avoided (sortof), but if it would freeze the browser, no one would have a problem with it. I think the reason why they implemented this, is so that enduser think it's a fast app, while in reality it's dog slow.

In the end it's just another case of putting design above functionalty. Also as the parent poster notes. If you design your site properly and people are on broadband anyway you can create pages that load just as seamlessly as AJAX requests.

just my 0.02 $

Re:What's so Stupid About Ajax!

[Bogtha]

1. Makes it unreadable for the blind or anyone else using a browser that doesn't use a fancy javascript.

Ajax is no different to any other kind of JavaScript - if you know what you are doing, there's no reason it should cause problems for the blind or people without JavaScript. You have formed this opinion because lots of people who don't know what they are doing are using Ajax, not because Ajax inherently has this problem.

2. Makes it less readable or unreadable to google and yahoo search engines.

Again, Ajax is like any other JavaScript in this respect. If you know what you are doing, this isn't a problem.

3. Adds yet another step in the web development pipeline

Well yes, in general, if you want to add features, you have to add development time. This is to be expected.

4. Further supports M$'s "we'll make our own javascript" cause. IE handles AJAX differently then the rest ( big surprise ).

You have that backwards. Internet Explorer handles Ajax differently because it provided the XMLHttpRequest object first. When the other browsers copied it, they implemented it differently.

In actual fact, the differences are trivial. It's a few lines of generic code to make Internet Explorer act like the other browsers. And Microsoft, rather than encouraging the different interfaces, is actually changing Internet Explorer 7 to work like the other browsers.

5. Breaks the standard accepted policy of unified pages ( essentially re-introducing frames )

Web pages haven't been unified since <img> was introduced in Mosaic. What you are concerned with is addressability, another thing in which poor coders are giving a false impression.

AJAX yappers talk about response and app like look and feel. If you encounter one of these people then rest assured that they don't know what good layout design and CSS are!

Utter nonsense. In fact, I'd say the opposite is true. If you are concerned with look and feel, then good layout design is what you are striving for, and CSS is the way that you achieve it.

With proper layout and CSS you can make a web site or application respond and look just like an Ajax one without having to use Ajax or code up some JavaScript piping.

This is simply not true. You can make all the same features work, but they don't work as well, and certainly don't respond as quickly.

The browser will cache the layout correctly and thus the extra 3k of information that AJAX supporters say they avoid is in fact already avoided.

When web developers talk about the layout being cached, they mean the stylesheets that define the layout. Things like sidebars, headers, menus etc aren't cached themselves, they still appear in the HTML as content. It's just how they look, as defined in CSS, that is cached. You aren't avoiding downloading all of that superfluous information when you cache a stylesheet, you still have to download the content. Ajax avoids that.

Re:What's so Stupid About Ajax!

[foniksonik]

"With proper layout and CSS"

So if I want to build a dynamic query, which is basically a decision tree, using select menus.... and pull the info from a db... I have to load up all the possible combinations of select menus which could be 9*9*9 (9 options with 9 2nd options and 9 3rd options) and then HIDE all but 3 of the menus?

Or maybe I should reload the page each time someone makes a selection which since it's being built from a db means no cacheing and thus there will be a refresh of the rest of the page?

NO. Instead I will use javascript and an asynchronous call to a server-side script which will perform a db query and return html with fresh select menu and options and then use javascript again to write it out to the document in a DIV with id of X.

Now IF browser developers, et al would introduce XForms and expose the DOM via some other standard scripting language I would gladly use that alternative instead.

For those without javascript enabled browers... I will refresh their browser 3 times and populate the form elements the old fashioned way.... calling the document as the forms action and passing whatever vars need be....

BUT I won't simply discard AJAX for vanilla form processing, there's no need to.

Re:What's so Stupid About Ajax!

[Tablizer]

Just like 'FLASH' Ajax will have adverse effects if used in a site:

I think intranets and B-to-B is where most of the need will be, not ads and public sites. Whether ads can and will abuse it or not is another matter.

AJAX seems like unneccesary work

[programmerar]

AJAX seems like unneccesary work. why don't the browser makers just make it so that the page stays visible while loading, and change only at the last second when all neccesary data has been loaded? this would render the same result as AJAX. the only difference is that every damn coder alive didn't have to code AJAX over and over for every website.

or am i missing the obvious here... ok maybe that all page data doesn't have to be reloaded, but hey - it's broadband days now..

Re:AJAX seems like unneccesary work

[euroBob]

Nope you're not.

Infact browsers do infact cache CSS and images and if done correctly yes they won't reload the images and flash the screen. Its just that you have to use css and layout mechanisms correctly which most AJAX hypers don't do...

Re:Here's what I think it is.. as a web app develo

[euroBob]

If you use .net you are ^not^ a web app developer.

You are a special needs kid using visual basic drag drop. The only thing you can make are little crapplets that further the hold that companies are taking on the internet.

You are only part of the problem concerning the internet and its corporate take over.

Learn how to code you moron.

Thank Goodness for NoScript

[stereoroid]

These AJAX sites expect you to have JavsScript enabled, before they will work at all, and this is where they sneak in tracking crap like Google Analytics, Tacoda, etc. NoScript lets me see the sources of the scripts in each page, and whitelist only the ones required to get the site to work. I regularly see tracking scripts that are not declared, that have nothing to do with the service provided by the site.

Slashdot is embedding Tacoda scripts in every page: have a read of their privacy policy for details of what they admit to collecting and selling back to OSTG. If you examine the source code of a Slashdot page, get the script URL and open it, you can how see the script is obfuscated, it generates another script as it runs. Why are they hiding what they do? Why does Slashdot collaborate with these bloodsucking bottomfeeders? How much are Slashdot reader eyeballs worth?

Re:Thank Goodness for NoScript

[euroBob]

Good point steroid.

Javascript has been abused for so many years by devious people.

I would disable it in my browser however there are just too many sites to require it for use. The problem is thus.

In Reality:
JavaScript, Flash, Ajax have about 25% legitimate functional uses and the other 75% is either useless, devious, or down right stupid.

new and shiny embraced

[beaverfever]

The technical attributes of different technologies can be debated to no end, but never underestimate the propensity for people to embrace "new and shiny". That includes everyone, including you (and me).

Watch out about Ajax

[einhverfr]

Ajax the Great committed suicide after slaughtering a herd of sheep. He was angry about his armor being given to Odysseus.

The Name is spreading the Ajax Wildfire

[Qbertino]

Before that guy of that windbag elititst shop "addaptive path" (pardon the rant, but there is some truth to it) coined the term "Ajax" the whole sheeban was just called 'doing nice, interesting and pratical stuff with JavaScript and maybe taking advantage of the fact that current browsers have more simular JavaSrcipt engines that 5 years ago.' That Term of course is way to complicated for most people and bears the dangers of Execs and decision makers mixing up JavaScript and Java. With the obnoxiously omnipresent term 'Ajax' that isn't the case anymore. I actually use it myself when talking to customers and it actually helps bring JavaScript funcitonality to the table.
It's all about the name, that's all.

Javascript security.

[Jartan]

I'm a little suprised that nobody here is talking about this. AJAX is basically the concept of using proper client/server methods for web pages.

The thing that's always held this concept back though is security. You can't just download clients from web pages because running code is dangerous. Javascript attempts to somewhat solves this problem but hasn't it always been widely regarded as having some security flaws in it's security policies?

Why is everyone all the sudden ignoring this fact and going whole hog on javascript to create these dynamic web pages? It worries me because I think the reason it's happening is that everyone really needed dynamic web pages to compete and they could no longer wait for something a bit more secure so now we may be stuck with a dangerous precedent.

Three Reasons for AJAX's Success

[kap1]

As I see it there are three reasons for AJAX's success:

1. It enables a paradigm shift from developing forms based webapps to component GUI webapps.
2. Developing webapps this way is more efficient and less error prone.
3. Both of the above reasons drive many companies to adopt Ajax into their software and change their business model, to SaaS, for example.

Re:Three Reasons for AJAX's Success

[Anonymous Coward]

bullshit bingo!!

AJAX is totally unreliable

[Anonymous Coward]

Disabled javascript = AJAX broken.

No good webpage should depend on javascript, the user can disable it, or it may be disabled for them by somebody else while they are completely unaware of why your page does not work at all.

Ban javascript!

Re:It's Annual Review Time at Microsoft

[Anonymous Coward]

Well said EuroBob. One piece of positive info today:

It's August and so it's annual review time at Microsoft. Which means approximately twenty percent of the pompous MS is being faced with the axe and all the horrors associated with parting ways from MS. Those that have made it to this point of August termination have no doubt already escaped more covert attempts at terminaton such as police stops after leaving bars. But, they still face the more traditional slander dissemination to colleagues to reinforce the leadership of the still-in-place management teams. Suffice it to say that these hitherto pompous lads will face years of unfavorable "chance circumstances" in specialy constructed MS petri dishes and generally find life to be a house of pain.

So, rejoice my Linux loving friends, some MS folk are are ingesting the first of many doses of serious toxins at this moment.

Re:Here's what I think it is.. as a web app develo

[Anonymous Coward]

What building on the MS campus are you writing from.

Re:Is Microsoft Evil - As an Employer?

[Anonymous Coward]

Is Microsoft evil as an employer too? I know of all the evil stuff they do in the marketplace and in selling their inferior wares, but did not know anybody who every worked there.

Come to think of it, I do remember them making this huge sales pitch on SlashDot with this really dorky guy saying how good it was to be an employee - despite the fact that he had a new manager every six months or so. Maybe the managers are just scheming all the time?

Bunch of hype...cool..but hype

[Anonymous Coward]

We've been doing this sort of thing for many years, just not with a built in mechanism. A long time ago we figured out we could submit to a tiny window and retrieve information in the background - and then use that info to populate pull downs and what not. So please - it is NOT new. It's just easy for the masses now and offically accepted by M$. Whatever.

I dunno...

[RoadWarriorX]

What's Spreading "the AJAX Wildfire"?

Could it possibly be AJAXWorld Magazine??? Considering that an "anonyomous reader" writes this summary, maybe they indulged some shameless self-promotion using little popular web sites like /.

eh, I could be wrong, tho. I just sick of hearing the word AJAX. By my 5 years (yes, 5 years) in this mashed up set of technologies we now call AJAX, I learned that it's no silver bullet. Bandwidth is the number one issue, because AJAX can suck your bandwidth dry if done wrong. Passing XML back and forth sucks just as bad, because you have to tear-apart, process, and reguritate. Quirky clients, especially ones that have proxies and pop-up blockers, is the bane of any application that uses AJAX. Geez, I am giving myself a headache.

AJAX circumvents Javascript's slowness

[Anonymous Coward]

Whenever we try to do too much in javascript, we run into performance problems because javascript is slow on most computers out there for doing things like... sorting tables several hundred entries big. AJAX allows us to do that processing in perl on the server, which gives us acceptable performance. So we get our kick ass javascript tables with their sortable filterable goodness. And we get them sooner than the 30 seconds it took the javascript code to render when it was doing all the computation itself.

The Sun Micro guys got it mostly right

[Dan Farina]

What I find terrifying about this whole AJAX thing is that now modern web development is entirely hinged on the implementation of an interpreter for a language in different browsers. The Mochikit Javascript library says this best: "Mochikit Makes JavaScript suck less"

What if I don't want to write in Javascript? What if I feel that, for whatever reason, that I'd rather write my browing control applications in some other language of my choosing? And wouldn't it be slightly easier to standardize on a bytecode format (eg, what Java may have supposed to been for the web) rather than the rules of a language in all its gory detail?

Re:The Sun Micro guys got it mostly right

[Anonymous Coward]

If you don't want to write in Javascript, you already have the right mind-set to write a real web application without any headaches.

For the rest you will need something like http://witty.souceforge.net/.

Networkable GUI's?

[mdm42]

Oh, I guess you mean Java applets...

Which is not indexable....

[jotaeleemeese]

WHich makes Google and toehrs, useless.

Thanks fo your solution buddy, keep it to yourslef though.

Re:Here's what I think it is.. as a web app develo

[140Mandak262Jamuna]

IMNAWAD (Web App Developer). But when I words like "Seamless deploy and install" promoted by the folks who brought you the Browser Helper Objects, I am worried. I dont know what this SOAP washes but I assume RPC is remote procedure call.

I assume you are real legit on the up-and-up developer hawking some legitimate service/software over the net. If the world is made up exclusively of people like that we dont need to worry about minor head aches like security, trust, hostile environment etc. But you know, there are bad people out there, and it takes a very small number of them to gum up the works, to make a mess for everyone.

"Why constrain ourselves to the browser?"

No anti-virus/security company is going to recommend to their clients to shut off the browser. (Well, I wish they would advice their clients to shut off IE, but that aint gonna happen either.) But some virus/worm attack happens and they advice the users to shut off a critical part of SOAP/RPC/.Net/Forms or whatever the hell is putting food on your table.

Whatever happened to SECURITY?

[Anonymous Coward]

I, for one, am glad for installation steps. It means I am less at risk with every click.

The minimum security that I require is provided by Java Web Start. Downloaded JAR files need to be cryptographically signed, and I can follow the certificate chain before launching the program.

Your mileage may differ, but having foreign code run in my browser after an innocent enough click seems like a nightmare to me. And sandboxes are broken once in a while.

Oh, and BTW, if someone knows something like JWS for Smalltalk, especially Squeak, please do let me know. Crypto-sig a must!