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

Comments

iFrames?

[BlueBoxSW.com]

Been using iFrames to get around web restrictions since before you lost your virginity...

Re:iFrames?

[coolgeek]

No, it just means he could have been doing it last week, and it would still be before you lost your virginity /rimshot

Re:iFrames?

[ArcadeNut]

... before you lost your virginity...

You're making a pretty big assumption there....

Re:iFrames?

[jgagnon]

Never waste your mod points on AC.

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

CGI scripts

[acid06]

Site is Slashdotted.

And this is the reason why you shouldn't use CGI scripts these days - the interface sucks and forking a process for each request is very expensive.

By the way, before any Perl-bashing trolls come around: they're CGI scripts written in Python (How shocking, huh? Anything sucks when you're using plain old CGI).

Re:CGI scripts

[Anonymous Coward]

If you are forking a sub-process for every CGI script call, you're doing it wrong .-)

Fastcgi came around in the nineties and there exists various pooled process executors for various techs (perl, C etc).

I agree CGI is a web relic, but it isn't necessarily as bad as you painted it.

Re:CGI scripts

[Tool Man]

CGI can (and does) work just fine. What people need to understand in general is that anything you do dynamically, has to be done efficiently. An old company I worked for had a heavily-used site for the day, on modest hardware. CGIs in C, using file access to parse template files and stuff with content. The CGIs forked, so did Apache, but it was unnecessary database use which we learned to avoid.

The system which replaced it was supposed to permit new content to be added with minimal dev help, and used Java and Oracle. Not to blame either, but the purchased solution using all the then-latest enterprisey goodness *ahem* was a festering pile of dung, even with dramatically more infrastructure than the old system. The team got it stable-ish, sorta, eventually. If you ever have to work with Open Market's Content Server, I hope to hell it wasn't the code base it was then. I would have killed for the simplicity and durability of the old CGI system.

Re:CGI scripts

[evilviper]

And this is the reason why you shouldn't use CGI scripts these days - the interface sucks and forking a process for each request is very expensive.

You're suggesting sites which use AJAX heavily have never been slashdotted?

With non-AJAX sites, the pages are smaller without all the javascript, including code for every different bug in every different browser is not only a programming nightmare, but makes for a far less responsive page...

Everyone treats it like a foregone conclusion that AJAX is faster... It may be true if you have something painfully simple like a calculator in the middle of an HTML-massive page, but otherwise, the performance is undeniably worse on any modest PC (never-mind portable/embedded devices!).

GMail's Basic HTML version is certainly faster, though missing a feature here and there due to being a second-class citizen. Google Maps is even worse... Sure, being able to click and drag an online map was neat when it first came out, but faster than clicking an arrow in the corner? Not for me... I'd rather have it move in whole, consistent, step sizes. And faster? Hell no! I sit around waiting several seconds for Google maps to load up, prompt after prompt to "keep waiting" or else any address you type in will get munged. If good old mapquest had stayed HTML, but included aerial photos (satellite/birds-eye), I don't believe Google would have gained any traction there... And don't try to tell me how much worse the responsiveness would be... The displayed images are already cached, the CSS and JS is cached, so only the main page needs to be fetched, along with a couple new map squares. Reloading an HTML page is blazing fast... And not just faster, but better, as my browser doesn't lock up for at least a couple seconds on every action/request.

AJAX has become a trend, an gone far off the rails as to where it's actually a benefit over the oh so "old fashioned" technologies that worked damn well for decades...

And I say this as someone who has written a couple AJAX apps... the "simple calculators" mentioned above. But make no mistake, it would have been only a trivial amount more work to make it a CGI script instead, and nominally slower or more disruptive.

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.

Re:CGI scripts

[merreborn]

Sure, being able to click and drag an online map was neat when it first came out, but faster than clicking an arrow in the corner? Not for me... I'd rather have it move in whole, consistent, step sizes. And faster? Hell no! I sit around waiting several seconds for Google maps to load up, prompt after prompt to "keep waiting" or else any address you type in will get munged.

Wow. How's the weather back in 1998?

I've got a PC that I built for $300 in 2008, and two macbooks (the bottom of the line models. Not the Pro). They're all behind a perfectly average comcast cable modem. Running Google Chrome, google maps loads just as fast as any desktop app, on any and all of 'em. This is not a bleeding edge setup.

So... Is it your Pentium 2, or your 9600 baud modem that's holding you back?

You're right... AJAX doesn't run great on systems built before the turn of the century. If you don't like it, pick up a system that has more than 64 meg of ram. You have every right not to upgrade, but if you choose not to, you have no right to bitch.

The "everything should run on my Windows 95 machine" mindset drives me nuts. I bet driving your Model T on the interstate isn't much fun either.

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.

How is this new?

[vivin]

Posting to an iframe and loading the iframe with dynamic content?

Haven't RTFA (slashdotted), but I used to do "AJAX" without "AJAX" in the early 2000's. You would post to a hidden iframe and the dynamic content that was loaded in the iframe was Javascript, which would manipulate the parent page. Either that or it was JSON would you would then access from the parent page.

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. 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:iFrame?

[WrongSizeGlass]

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?

Well, it's AJAX without all the pesky 'JAX' ... but it does have an iFrame*, so it's 'Ai' ... not to be confused with 'AI' which is something completely different. Now, the 'Ai' may have a JSON appended to replace the 'X', which would make it 'AiJ' which is completely different from AJAX, though not necessarily better (not necessarily as in not).




* iFrame has no relation to iPads, iPhones, iPods or any other iApple product. The occurrence of the vowel is purely coincidental ... though I think iFrames are about as popular with good web designers as iApples are with Linux coders.

Re:Continuous server polling

[Culture20]

Just working on an online Rock Paper Scissors game .... I didn't want to get into javascript before sorting everything out without it. But everything seems to work fine, just by using
META HTTP-EQUIV="Refresh" CONTENT="3/...poll-url"
So I think I can keep javascript out of the game code

1994 weeps for your server and network load, especially since /. is going to give you a free scalability test in 3, 2, 1

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.

Next up... styling without CSS

[Anonymous Coward]

Courtesy of the font tag.

This is news?

[bearinboots]

Wow. The barrier to entry for getting an article on slashdot has really lowered, hasn't it? How is this even worth the blog post?

Re:This is news?

[Anonymous Coward]

Posted by timothy.

Re:iFrame?

[larry bagina]

going backward and forward updates the has component in the url. A timer event monitors the url. If the hash changes, then you update your app state, etc.

The iframe is a hack for IE. IIRC, If you programmatically set the url hash, it doesn't go into the IE browser history, so back/forward are broken. But if you update the iframe address, it does update the history.

Re:Bad idea

[coolgeek]

That it is better to be a fool and remain silent, than to speak and remove all doubt.

Re:1998 exactly

[Shin-LaC]

There is NOTHING new in programming technology and hasn't been for a longest time. Really, in 16 years I can only truly say that bit-torrent was somehow a unique/new idea, but I think even that wasn't that radical, just the protocol was new.

I mean this in the nicest possible way, but the only reason why you think that is that you have an extremely limited perspective on programming.

Re:iFrame?

[Anonymous Coward]

AJAX itself is 1960's technology. I mean holy shit, people get a fucking stiffy over being able to update a user interface without pushing a button.

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