Proof of Concept For Ajax Without JavaScript

JonathansCorner.com writes "Even if Ajax was backronymed to 'Asynchronous JavaScript and XML,' it works with JSON substituted for XML. Here's a proof of concept that JavaScript/VBScript are not strictly necessary either. The technique, besides being used standalone, may be useful to provide a better 'graceful degradation' for Ajax applications used by clients with scripting turned off."

iFrame?

[Anonymous Coward]

Like a true slashdotter I have not read the article, but the precursor to AJAX was just to use iFrames (or pre-iframe frames). Is this any different or better?

Re:iFrame?

[uglyduckling]

No. It's someone who has stuck an iFrame in their page and written a python script to return different html for the iFrame depending on what you click. It's 1998 technology 'dynamic' pages. Nothing to see here...

Nothing to see here, etc

[hkz]

So you post a form to an iframe by pressing a submit button, and the iframe reloads with new dynamic content? And this is somehow AJAX? The whole interesting thing with AJAX is that you can interact with the web server while staying on the same page. You can type something into a search box, say, and the webserver sends you back some matching words in real time. Sure you could mimic the same thing with a POST and a results page, but that is exactly the paradigm that AJAX was supposed to replace.

Not Ajax

[Sephr]

It's not asynchronous, as the "ajax" parts have to load a whole new page with a new request. Ajax without JavaScript or iframes is multipart/x-mixed-replace.

Re:How is this new?

[uglyduckling]

It's not new. I got to the article before it was slashdotted. The author (who is also the author of the story) created a python script that spits out different inline CSS depending on the button you select to style some text, loading it into an iframe, in other words the sort of messy 'dynamic' pages that many sites used before being replaced by AJAX.

Re:How is this new?

[VTI9600]

Me too. The framework I used was JSRS [ashleyit.com]. IIRC, it worked by creating hidden iframes on the fly for server-side communication and had dispatchers for PHP, ASP, perl and others. I don't recall if it was asynchronous or not, but pretty much anything can be made asynchronous in javascript by using the setInterval or setTimeout functions. The only thing I could tell was different was the fact that AJAX used the XMLHttpRequest object.

So, naturally I was dumbfounded when people started talking about how amazing and cool AJAX was. I thought, "Hasn't this been around for years?"

Re:CGI scripts

[WoLpH]

Anything that depends on user input and can't be predicted before loading the page _will_ be faster with ajax if the server, client and internet connection are fast enough.
Rendering a full page is much heavier for the server so in that aspect it's an advantage.
Loading a full page for a client is heavier because there's more to parse.
Loading a full page takes up more bandwidth so it's worse on your internet connection too.

So there are only 2 cases I can think of where it might not be noticably faster.
1. A high-latency connection (which I suppose you have judging from your message).
2. A slow cpu that has trouble with handling all those small parts of data (opposed to 1 big stream).

In all other cases it should be faster in terms of user experience.

It isn't a backronym

[Anubis IV]

The name is barely even five years old and already people forgot where it came from? Here's the blog entry where the term was coined [adaptivepath.com]. The technology was around before the term was coined, but that doesn't make it a backronym. After all, when we discover new things and don't come up with a name until later, that's not a backronym, it's just a name. Sure, Ajax is an acronym, but its letters weren't given a meaning after the fact like you would with a backronym (e.g. "bump" meaning "bring up my post" on message boards). Rather, the letters were given meaning at the same time that the term itself was coined, as the blog entry I linked shows.