Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Programming

Proof of Concept For Ajax Without JavaScript 148

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:
  • iFrame? (Score:1, Informative)

    by 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?

    • 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?

      • Sorry. By "Apprently" I meant "Apparently," and by "Apparently" I actually meant "Apparently not."
         
        -1, spelling mistake

      • Re: (Score:1, Interesting)

        by g3k0 ( 1697032 )

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

          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.

      • by dave420 ( 699308 )
        It's both. In GMail they used to (I don't know about now) use the iframe method. If you check out their video searches, however, you'll see they use the # method. Both are pretty good, and far less clumsily-implemented than this demonstration. I'm not knocking the guy, but it's very existence is somewhat strange, akin to someone pointing out how blink tags and animated gifs are cool. Strangely anachronistic :)
    • Re:iFrame? (Score:5, Informative)

      by uglyduckling ( 103926 ) on Saturday April 24, 2010 @01:44PM (#31968468) Homepage
      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...
      • <type 'exceptions.OSError'> Python 2.5.2: /usr/bin/python
        Sat Apr 24 13:50:18 2010

        A problem occurred in a Python script. Here is the sequence of function calls leading up to the error, in the order they occurred. /home/jonathan/mirror/ajax/server.cgi in ()
        220 print_palette_frame()
        221 elif get_cgi(u'page') == u'showcase':
        222 print_showcase_frame()
        223 elif get_cgi(u'page') == u'text':
        224 print_te
        • <type 'exceptions.OSError'> Python 2.5.2: /usr/bin/python Sat Apr 24 13:50:18 2010 A problem occurred in a Python script. Here is the sequence of function calls leading up to the error, in the order they occurred. /home/jonathan/mirror/ajax/server.cgi in ()
          [snip]

          All those lines of code sure would be easier if they were sorted by line number ... maybe this 'JAXless AJAX can format the errors in a new way, too?

          • by cynyr ( 703126 )
            You must not do much in python, they almost always go like that, it's from the outer most function call to the inner most that generated the error, they are also mostly in different files, so sorting by line number would be of little help.
      • 1998 exactly (Score:1, Flamebait)

        by roman_mir ( 125474 )

        In 1998 I did this while working for Davinci tech in Toronto working on Coke Canada Intranet accounting site (remember, the Intranet was the buzzword of the time?) IFrames + javascript refreshing them and populating parent windows / frames.

        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.

        • remember, the Intranet was the buzzword of the time?

          Yeah, that and "push" technology. Anyone remember "push" technology, or is it just me? IIRC, it was supposed to be the opposite of "pulling" data off the web by visiting a website. Data would be sent to a program on your desktop...kind of like RSS/Atom

          • RSS/Atom are not push. Your RSS reader just regularly checks the feed for updates.

            • I know, but most of what people called "push" technology in those days (based on my admittedly hazy recollection) simply involved software that would poll for updates like an RSS reader. That was the best case. In the worst case it just meant using a cron script to send automated emails. That's why it was more of a buzzword than a true technology (involving server-initiated communication).

            • RSS/Atom are not push. Your RSS reader just regularly checks the feed for updates.

              RSS/Atom are content formats, and can be used for polling (not really "push", but what mostly passes for it) updates, or in a system that does real push (e.g., Google's PubSubHubbub push protocol, which strictly sspeaking isn't limited to Atom, but only has defined semantics for Atom.)

        • Re: (Score:3, Insightful)

          by Shin-LaC ( 1333529 )

          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.

          • Spare your pity :)

            Nothing has been happening in programming that is new in any way for decades now, I mean it and I welcome a single real example to the contrary.

        • I didn't find bittorrent all that different from eDonkey, which used a similar hashing system to figure out that a bunch of people had the same file, and would let you download multiple chunks from different people.
          • Or hitting multiple servers to ftp different parts of the same file by using "skip" to skip over a portion, then just cat them all together.
      • Re: (Score:2, Funny)

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

    • Re:iFrame? (Score:4, Funny)

      by WrongSizeGlass ( 838941 ) on Saturday April 24, 2010 @01:57PM (#31968542)

      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.

    • by WoLpH ( 699064 )

      The guy just invented the iframe it seems.

      Also... since AJAX is an acronym for Asynchronous Javascript And XML this would be AI? Asynchronous Iframe?

  • by Anonymous Coward

    Seriously? has existed longer than 'Ajax', this is not a new development or a novel new spin on existing tech. This is just, well, using/i> iframes.

    Lame.

  • iFrames? (Score:5, Funny)

    by BlueBoxSW.com ( 745855 ) on Saturday April 24, 2010 @01:42PM (#31968460) Homepage

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

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

      since your mother did

    • Re:iFrames? (Score:5, Funny)

      by ArcadeNut ( 85398 ) on Saturday April 24, 2010 @04:21PM (#31969452) Homepage

      ... before you lost your virginity...

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

    • Ditto. I was one of the first to do this. Actually I also used object tags.
      HTTP POST = outgoing packet. And the result were incoming ones. I had two implementations. One doing constant polling of the server for incoming packets and one constantly keeping an open connection with the server sending keepalive packets.
      I could serialize any data that JS could represent into my own lightweight form of EBML (a efficient binary markup) to the PHP server and deserialize them into PHP objects, or the other way around

      • I don't recall exactly, but it was with a version of IE, that if you copied or pasted in the URL field, it gave you an alert that said "Feature not implemented".

  • Just working on an online Rock Paper Scissors game [rpsmatch.com] .... 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

    Stephan

  • CGI scripts (Score:3, Insightful)

    by acid06 ( 917409 ) on Saturday April 24, 2010 @01:48PM (#31968482)

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

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

      • by acid06 ( 917409 )

        I'm talking about plain-old CGI, specifically.
        FastCGI is great and I've deployed several Perl applications using it.

    • Re: (Score:3, Interesting)

      by Tool Man ( 9826 )

      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 a

    • by monoi ( 811392 )

      The site advocates doing all the processing on the server, rather than offloading it to the client via JavaScript... can we spot any flaws there?

    • Re: (Score:3, Interesting)

      by evilviper ( 135110 )

      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

      • by acid06 ( 917409 )

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

        I didn't mention using AJAX or not using AJAX a single time in my original comment. You can use have a "real" AJAX site using plain-old CGI, I've done that myself. Hell, you can even run full-blown MVC frameworks such as Perl's Catalyst using CGI - it will just be slow as hell, but you can run it.

        CGI is only the interface and my point is that forking a process for each request sucks.

        Your site can still be Slashdotted even if you're using something like FastCGI, mod_xxxx and so on. But instead of being Slash

      • Re: (Score:3, Informative)

        by WoLpH ( 699064 )

        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 hi

        • Rendering a full page is much heavier for the server so in that aspect it's an advantage.

          Hardly. Rendering one large page in response to a request, rather than 10 smaller requests, does not really decrease load.

          Loading a full page for a client is heavier because there's more to parse.

          Except loading a page is handled MUCH differently from dynamic changes to an existing page, such that loading a full page is faster...

          Loading a full page takes up more bandwidth so it's worse on your internet connection too.

          In

          • It really does depend on what you're using Ajax for, like you sort of said. Google Suggest was the "first" very noticeable public demo of what Ajax was, and it's a very good application. However, a lot of developers found their proverbial hammer and decided that Ajax to refresh most or all of the page is somehow better, where in fact there's the additional steps of variable evaluation and DOM insertion before you even get to a browser render.

            Rendering one large page in response to a request, rather than 10 smaller requests, does not really decrease load

            This really depends on what's happening behind the scenes. Small r

        • So there are only 3 cases [...] where it might not be noticably faster.

          3) The designer and/or programmer are of average skill or lower

      • Re: (Score:3, Insightful)

        by merreborn ( 853723 )

        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 t

      • With ajax it depends heavily on the browser, on modern browsers good ajax usage is way faster than plain html, on older browsers it can become a problem, but it all depends on the usage and
        on how much of the dom is updated client side.

    • Why is this modded anything apart from off-topic? "The web server is dead, and therefore I'm going to rant about something that has absolutely nothing to do with the summary whatsoever."

      Good work, mods.

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

      No it isn't. This is a common myth that just never dies.

      I have built a whole web framework [cat-v.org] with the rc shell [cat-v.org] that does dozens of forks per request (calling commands like sed, awk, grep, echo, cat, etc), it is much faster than some php frameworks using fcgi, and certainly many magnitude order faster than perl or python takes to even start up.

      You can do many t

      • In short, the problem is not fork, bu ridiculously bloated and overly complex software.

        it has been said that process creation is cheap on Unix and expensive on NT, while the reverse is true of threads.

        • That is generally true, but there are exceptions, some badly broken supposedly "unix" systems like Aix and Solaris have ridiculously bloated and slow processes.

          Fortunately most such abominations are either dead or dying fast, and being replaced by systems like Linux where processes are extremely cheap (so cheap that 'threads' are implemented as pretty much normal processes that happen to share memory, in the style of Plan 9's rfork(2) [cat-v.org]).

          • That is generally true, but there are exceptions, some badly broken supposedly "unix" systems like Aix and Solaris have ridiculously bloated and slow processes.

            Is that why Solaris was one of the first Unixes to have a mature threading library? I always wondered.

  • by hkz ( 1266066 ) on Saturday April 24, 2010 @01:48PM (#31968488)

    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.

    • ...The whole interesting thing with AJAX is that you can interact with the web server while staying on the same page...

      And without taking the pageload/parsing penalty.

    • by rliden ( 1473185 )

      And this is somehow AJAX?

      No, it's not AJAX. That is, I think, his point. the point. The point of the demonstration doesn't seem intended to replace AJAX, but to provide a graceful degradation for those with Javascript turned off.

  • How is this new? (Score:5, Insightful)

    by vivin ( 671928 ) <vivin DOT paliath AT gmail DOT com> on Saturday April 24, 2010 @01:53PM (#31968518) Homepage Journal

    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.

    • I guess this guy just found out about them?

      Yah, I also was using iFrames to pass data around long before the term "AJAX" was coined.

    • The summary indicates that this new method does not require a scripting language (which is the point -- still provide some access to an application for non-javascript browsers and/or paranoid users.) Given this piece of information, the methods you describe would not be consistent with what the author of this application is doing; therefore, this is something new (or at least not 'not new' because of the prior implementations you've described.) Of course, we're all speculating because of the slashdotted a
      • Re:How is this new? (Score:4, Informative)

        by uglyduckling ( 103926 ) on Saturday April 24, 2010 @02:10PM (#31968608) Homepage
        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: (Score:1, Troll)

          by rliden ( 1473185 )

          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.

          It's often messy, but doesn't have to be. For that matter AJAX can get ugly and messy at times.

          I think the good point to take away from this, that many sites seem to have tossed away, is to provide a way to interact with the site if a user has Javascript disabled. One thing /. pedants often harp and bark about is how they have Javascript disabled and their shock that everyone doesn't. Maybe site owners and developers aren't interested in providing their pages to those who won't allow them to run JS, but

    • Re:How is this new? (Score:4, Informative)

      by VTI9600 ( 1143169 ) on Saturday April 24, 2010 @03:03PM (#31968952)

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

      • Indeed, the page you linked to mentions MSRS, which was one of the Java applet approaches to AJAX which existed in the "version 4" browser time frame. (XMLHttpRequest only came about after MS pulled MSRS due to the Sun lawsuit over Java.)

        As for the lack of understanding of AJAX-like techniques, some theories:

        - Netscape 4 and early versions of Mozilla were not stable with heavily dynamic pages, so devs tended to avoid them
        - Developers did not understand Javascript and DOM in general - real programmers thoug

    • by Zadaz ( 950521 )

      I love it when everything old is new again. I mean, you know, good for the kids to be trying stuff, but maybe they should read a little history so they work in new stuff instead of reinventing the wheel.

      Anyone remember server side image maps? Or how about server side push animation [radzone.org]?

      Yeah, don't reinvent those either.

    • No it is not new. But it is still cool and interesting and new javascript who wasn't around, when old-hands like you were implemeting ghetto-ajax, can learn some important web development history. So yes, you are a much smarter hacker than that guy will ever be, but please stop complaining lest we all be swamped with even more iphone and ipad spam-articles. k thx bye. :)
    • by Jay L ( 74152 ) *

      The 2000's? I used to do AJAX without AJAX in the early 1990s! The way you do it is you build a thin client with your own rendering engine, compression and protocols, you mail it to everybody every day so it's ubiquitous, then you put a few hundred thousand modems in colos and serve the content through those.

      The CGI-haters are right, though. Even we knew enough not to fork a process per request. AOLserver FTW.

  • Not Ajax (Score:2, Informative)

    by Sephr ( 1356341 )
    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: (Score:2, Offtopic)

      by catmistake ( 814204 )
      I thank you for posting. So, to recap, it's not asynchrinous, and it's not javascript. I'd say there's a flaw in whatever the logic is for this 'proof.' I just love what the kids are doing with language these days. Could this be just a poor attempt to draw attention to something not as well known as Ajax? wtf!!! [Sorry... I've been a little tender of late after having to witness the barrage of tech writers recently humiliating themselves by referring to an unknown prototype phone as something it couldn't po
      • iPhone = 1G, iPhone 3G = 2G, iPhone 3GS = 3G, next iPhone = 4G, for values of G equal to Generation. Hint #G doesn't have to refer to the network. Apple products have traditionally been referred to by the generation scheme as in: "I have a 5th generation iPod," or " I have a 3rd generation MacBook."

        • Except some times ago, they branded it "G#", not "#G". Willfully confusing customers? I don't see any reason to rule it out.
        • The problem with what you lay out in your post, besides being confusing, is that the iPhone and the iPhone 3G were nearly identical hardware platforms (the only differences being the radio and the gps), and Apple themselves does not see them as separate hardware generations, as can be seen by the identifiers for the hw:

          iPhone: iPhone1,1
          iPhone 3G: iPhone1,2
          iPhone 3GS: iPhone2,1

          so... what do you think the chances are of Apple pulling a "Rocky II" and completely skipping their own internal 3rd hardware r
          • No, that is the model identifier and doesn't have much to do with the generation of a product. I never said it was formal designation either. It's only confusing if you make it confusing.

            • No, that is the model identifier

              correct

              and doesn't have much to do with the generation of a product.

              Incorrect. Apple's model identifier has everything to do with what hardware generation the device is. It is one of the ways we know the differences between, and how we talk about the generational differences in the hardware. Obviously, a name doesn't magically make something a new generation. But Apple was kind enough to match their internal model identifiers to hardware generation for us. That's how they do it, and if you didn't know, that's what they're intended for (internally), and that's what t

  • by Anonymous Coward on Saturday April 24, 2010 @02:09PM (#31968602)

    Courtesy of the font tag.

  • This is news? (Score:3, Insightful)

    by bearinboots ( 743355 ) on Saturday April 24, 2010 @02:11PM (#31968610)
    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: (Score:2, Insightful)

      by Anonymous Coward
      Posted by timothy.
      • Wow. The barrier to entry for getting a comment on slashdot has really lowered, hasn't it? How is this even worth mentioning? ;)

  • Python 2.5.2: /usr/bin/python Sat Apr 24 14:34:09 2010 A problem occurred in a Python script. Here is the sequence of function calls leading up to the error, in the order they occurred. /home/jonathan/mirror/ajax/server.cgi in () 220 print_palette_frame() 221 elif get_cgi(u'page') == u'showcase': 222 print_showcase_frame() 223 elif get_cgi(u'page') == u'text': 224 print_text_frame() print_showcase_frame = /home/jonathan/mirror/ajax/server.cgi in print_showcase_fra
  • What concept is this proof of?
  • I used toothpicks and duct tape before all this new fangled Ecmascript and whatever-format-you-care-about naming it after a famous Greek warrior.
  • im repeating this in every discussion related to client side. there are innumerable reasons why client side is a bad idea and it shouldnt be leaned on. ill recide :

    - it is something that happens in a remote client pc, on which you dont have any control. there may be one small applet running in the tray, and it may fuck up execution of your code on that pc, costing you a visitor/sale/whatever.

    - client side scripting is a VERY good channel to infect visitor pcs, and this is why trojans, viruses are bein
  • First off, the "proof of concept" does not prove that you can do AJAX without the J. It presents a very simple use of the "target" attribute to the <a> tag that has been around since, oh, 1995 or 6 (with real frames, to be fair, but thats academic. Iframes were only invented because paper-obsessed layout & design types didn't like the frame bars).

    What it does prove, and it's a valid point, that there is plenty of page automation you can do without dependency on J or X. These days, because of the m

  • It isn't a backronym (Score:3, Informative)

    by Anubis IV ( 1279820 ) on Saturday April 24, 2010 @08:33PM (#31970838)
    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.
    • by Tim C ( 15259 )

      I was going to say exactly the same thing. Even more frustrating is that the Wikipedia article linked to makes no mention of it being a backronym either; the guy hasn't even read (or perhaps hasn't understood) his own reference.

  • These are the same sort of piss-poor "web professionals" who swear you need Javascript to do interesting things with menus. Hint: with CSS, you definitely don't.

    I'd put up a link to one of my own proofs of concept, but I don't want to /. my own server. Maybe the guy who wrote the silly article submission has some spare bandwidth for me?

  • This guy is promiting iFrames as Ajax alternative, this technique has been used before Ajax was there and there was/is a reason why Ajax is used for ppr, and that is flexibitlity, and iframes can cause hanging endless connections.

    Heck iFrames even still are used with Ajax as transport layer (in combination with javascript)
    because the ajax is broken due to the fact that it does not allow multipart form requests.

    I still do not know why this article made it on slashdot, it would be more interesting if it was t

"Hello again, Peabody here..." -- Mister Peabody

Working...