Forgot your password?
typodupeerror
Programming

Proof of Concept For Ajax Without JavaScript 148

Posted by timothy
from the now-make-a-good-acronym-for-comet dept.
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."
This discussion has been archived. No new comments can be posted.

Proof of Concept For Ajax Without JavaScript

Comments Filter:
  • Re:iFrame? (Score:1, Interesting)

    by g3k0 (1697032) on Saturday April 24, 2010 @03:16PM (#31968638)

    Apprently. I find this line interesting: the reason browser back buttons work in Gmail is an invisible, seamless use of iframes that create browser history. Isn't this actually due to the use of # in the URL when you click things?

    Actually it is a bit more complex than that. A Hash is just an link to an anchor on the current page. I am not sure how gmail works exactly, but I use extjs at work and it manages the history with an iframe as well. It needs a way to keep track of all the history tokens so it uses an iframe. Check out its source code if you are interested. http://www.extjs.com/deploy/dev/docs/source/History.html [extjs.com]

  • Re:CGI scripts (Score:3, Interesting)

    by Tool Man (9826) on Saturday April 24, 2010 @03:17PM (#31968644)

    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:iFrame? (Score:2, Interesting)

    by larry bagina (561269) on Saturday April 24, 2010 @03:26PM (#31968702) Journal

    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:CGI scripts (Score:3, Interesting)

    by evilviper (135110) on Saturday April 24, 2010 @03:29PM (#31968718) Journal

    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.

Forty two.

Working...