×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Proof of Concept For Ajax Without JavaScript

timothy posted about 4 years ago | from the now-make-a-good-acronym-for-comet dept.

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

148 comments

iFrame? (1, Informative)

Anonymous Coward | about 4 years ago | (#31968446)

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? (0)

LBArrettAnderson (655246) | about 4 years ago | (#31968454)

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?

Re:iFrame? (1)

LBArrettAnderson (655246) | about 4 years ago | (#31968464)

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

Re:iFrame? (0, Funny)

Anonymous Coward | about 4 years ago | (#31968500)

-1, Grammar Nazi.

Re:iFrame? (0)

Anonymous Coward | about 4 years ago | (#31968550)

It depends on the browser. IE uses the iframe, firefox uses the hash.

Re:iFrame? (2, Interesting)

g3k0 (1697032) | about 4 years ago | (#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:iFrame? (2, Interesting)

larry bagina (561269) | about 4 years ago | (#31968702)

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:iFrame? (1)

dave420 (699308) | about 4 years ago | (#31968642)

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? (5, Informative)

uglyduckling (103926) | about 4 years ago | (#31968468)

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

Degrades gracefully? I think not. Here's the page. (1)

tomhudson (43916) | about 4 years ago | (#31968502)

<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_text_frame()
print_showcase_frame = <function print_showcase_frame at 0xfbcec1ec> /home/jonathan/mirror/ajax/server.cgi in print_showcase_frame()
    149 css = styles[get_style()]
    150 text = get_cgi(u'text')
    151 link = commands.getoutput(u'/usr/local/bin/link')
    152 timestamp = time.asctime(time.gmtime()) + u' UTC'
    153 print u'''<html>
link undefined, global commands = <module 'commands' from '/usr/local/lib/python2.5/commands.pyc'>, commands.getoutput = <function getoutput at 0xfbce6fb4> /usr/local/lib/python2.5/commands.py in getoutput(cmd=u'/usr/local/bin/link')
      42 def getoutput(cmd):
      43 """Return output (stdout or stderr) of executing cmd in a shell."""
      44 return getstatusoutput(cmd)[1]
      45
      46
global getstatusoutput = <function getstatusoutput at 0xfbcec02c>, cmd = u'/usr/local/bin/link' /usr/local/lib/python2.5/commands.py in getstatusoutput(cmd=u'/usr/local/bin/link')
      51 """Return (status, output) of executing cmd in a shell."""
      52 import os
      53 pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r')
      54 text = pipe.read()
      55 sts = pipe.close()
pipe undefined, os = <module 'os' from '/usr/local/lib/python2.5/os.pyc'>, os.popen = <built-in function popen>, cmd = u'/usr/local/bin/link'

<type 'exceptions.OSError'>: [Errno 35] Resource temporarily unavailable
            args = (35, 'Resource temporarily unavailable')
            errno = 35
            filename = None
            message = ''
            strerror = 'Resource temporarily unavailable'

Re:Degrades gracefully? I think not. Here's the pa (1)

WrongSizeGlass (838941) | about 4 years ago | (#31968552)

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

Re:Degrades gracefully? I think not. Here's the pa (1)

cynyr (703126) | about 4 years ago | (#31969172)

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.

Re:Degrades gracefully? I think not. Here's the pa (0)

Anonymous Coward | about 4 years ago | (#31970152)

GP is asking for a new way to format python errors to match the new method of AJAXless AJAX. I believe he's trying to be funny or a smart ass (though they are not mutually exclusive, the later is almost always a given).

1998 exactly (0, Flamebait)

roman_mir (125474) | about 4 years ago | (#31968782)

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.

Re:1998 exactly (1)

VTI9600 (1143169) | about 4 years ago | (#31969052)

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

Re:1998 exactly (1)

Quantumstate (1295210) | about 4 years ago | (#31969162)

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

Re:1998 exactly (1)

VTI9600 (1143169) | about 4 years ago | (#31969388)

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

Re:1998 exactly (0)

Anonymous Coward | about 4 years ago | (#31969168)

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

Except RSS and Atom are still dependent on the client sending out the request to check if anything new has been published (i.e., they're "pull" technology). The whole "push" thing was dependent on the main servers having an idea of where all their clients were on the interwebs and then shoving data out to them without receiving any sort of initiating request.

Re:1998 exactly (2, Insightful)

Shin-LaC (1333529) | about 4 years ago | (#31969610)

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:1998 exactly (1)

roman_mir (125474) | about 4 years ago | (#31969762)

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.

Re:1998 exactly (1)

CastrTroy (595695) | about 4 years ago | (#31970426)

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.

Re:iFrame? (2, Funny)

Anonymous Coward | about 4 years ago | (#31969880)

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? (3, Funny)

WrongSizeGlass (838941) | about 4 years ago | (#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.

Re:iFrame? (1)

WoLpH (699064) | about 4 years ago | (#31970254)

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?

and the grounbreaking solution is.... iframe (1, Insightful)

Anonymous Coward | about 4 years ago | (#31968452)

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? (4, Funny)

BlueBoxSW.com (745855) | about 4 years ago | (#31968460)

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

Re:iFrames? (1)

mutemutt (1341901) | about 4 years ago | (#31968494)

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

since your mother did

Re:iFrames? (0)

Anonymous Coward | about 4 years ago | (#31968618)

Ah, so you've never done it before either... ;)

Re:iFrames? (2, Funny)

coolgeek (140561) | about 4 years ago | (#31969164)

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? (1)

Hognoxious (631665) | about 4 years ago | (#31969236)

before you lost your virginity /rimshot

I'm a Catholic priest, you insensitive clod!1!!

Re:iFrames? (0)

Anonymous Coward | about 4 years ago | (#31970076)

It still counts as losing your virginity even if they're the same sex as you and under the age of consent.

Re:iFrames? (0)

Anonymous Coward | about 4 years ago | (#31968620)

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

You're going to start sometime in the future?

Re:iFrames? (0)

Anonymous Coward | about 4 years ago | (#31969240)

I haven't lost my virginity yet, you insensitive clod!

Re:iFrames? (0)

Anonymous Coward | about 4 years ago | (#31970278)

... which is why most of your sites probably suck. Using IFrames is like banging rocks together hoping to get a spark that will start a fire.

Continuous server polling (1)

sugarmotor (621907) | about 4 years ago | (#31968472)

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

Re:Continuous server polling (3, Funny)

Culture20 (968837) | about 4 years ago | (#31968560)

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

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

Re:Continuous server polling (1)

maxume (22995) | about 4 years ago | (#31968588)

It's already exploded. I started a game and then it told me that game was full when I tried to join it.

CGI scripts (2, Insightful)

acid06 (917409) | about 4 years ago | (#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:CGI scripts (3, Insightful)

Anonymous Coward | about 4 years ago | (#31968534)

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 (1)

acid06 (917409) | about 4 years ago | (#31968694)

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

Re:CGI scripts (2, Interesting)

Tool Man (9826) | about 4 years ago | (#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:CGI scripts (1)

monoi (811392) | about 4 years ago | (#31968660)

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:CGI scripts (1)

PhrstBrn (751463) | about 4 years ago | (#31969232)

No, I don't see the flaw. You always do processing server side. You can do sanity checking client side if you'd like, but you still need to do it server side.

Re:CGI scripts (2, Interesting)

evilviper (135110) | about 4 years ago | (#31968718)

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 (1)

acid06 (917409) | about 4 years ago | (#31968750)

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 Slashdotted with a few requests per second, it will potentially handle maybe a hundred per second or even more.

Re:CGI scripts (2, Informative)

WoLpH (699064) | about 4 years ago | (#31970298)

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 (0)

Anonymous Coward | about 4 years ago | (#31969670)

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.

undeadly.org [undeadly.org] seems to do fine with CGI.

Re:CGI scripts (0)

Anonymous Coward | about 4 years ago | (#31969788)

How do computer generated images make anything suck? They made the movie hackers totally awesome!

Re:CGI scripts (1)

Blakey Rat (99501) | about 4 years ago | (#31970428)

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.

Nothing to see here, etc (3, Informative)

hkz (1266066) | about 4 years ago | (#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.

Re:Nothing to see here, etc (1)

coolgeek (140561) | about 4 years ago | (#31969184)

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

Re:Nothing to see here, etc (1)

rliden (1473185) | about 4 years ago | (#31969306)

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? (4, Insightful)

vivin (671928) | about 4 years ago | (#31968518)

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? (1)

Blakey Rat (99501) | about 4 years ago | (#31968578)

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.

Re:How is this new? (1)

nathan.fulton (1160807) | about 4 years ago | (#31968580)

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

Re:How is this new? (3, Informative)

uglyduckling (103926) | about 4 years ago | (#31968608)

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? (0, Troll)

rliden (1473185) | about 4 years ago | (#31969340)

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 that doesn't mean this isn't a useful lesson to those who might like that.

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

VTI9600 (1143169) | about 4 years ago | (#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?"

Re:How is this new? (1)

Zadaz (950521) | about 4 years ago | (#31969094)

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.

Re:How is this new? (1)

bjourne (1034822) | about 4 years ago | (#31969214)

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

Re:How is this new? (1)

Jay L (74152) | about 4 years ago | (#31969308)

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 (2, Informative)

Sephr (1356341) | about 4 years ago | (#31968576)

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:Not Ajax (1, Offtopic)

catmistake (814204) | about 4 years ago | (#31968632)

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 possibly be, over and over, and they're still doing it (the iPhone 4G: proof that journalists are idiots-- hint: no 4G network, no 4G phone).]

Re:Not Ajax (1)

edalytical (671270) | about 4 years ago | (#31969106)

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

Re:Not Ajax (1)

Schmorgluck (1293264) | about 4 years ago | (#31969558)

Except some times ago, they branded it "G#", not "#G". Willfully confusing customers? I don't see any reason to rule it out.

Re:Not Ajax (1)

catmistake (814204) | about 4 years ago | (#31970220)

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

btw, it is universally accepted that using the capital 'G' after the number always refers to cell technology, and this is espescially true when talking about cell phone hardware.

Re:Not Ajax (0)

Anonymous Coward | about 4 years ago | (#31970318)

I agree with the GP that G can refer to both the generation (I have a 2G iPod Touch, or iPod Touch 2G, means i have an ipod touch with bluetooth support) or it can refer to the data network.

Please stop sucking that tiny cock Apple constantly puts in your mouth.

Next up... styling without CSS (5, Funny)

Anonymous Coward | about 4 years ago | (#31968602)

Courtesy of the font tag.

This is news? (3, Insightful)

bearinboots (743355) | about 4 years ago | (#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:This is news? (2, Insightful)

Anonymous Coward | about 4 years ago | (#31968630)

Posted by timothy.

Re:This is news? (0)

Anonymous Coward | about 4 years ago | (#31970416)

Hired, and still not fired, by CmdrTaco.

Maintenance Nightmare (0)

Anonymous Coward | about 4 years ago | (#31968648)

I've had to maintain an application written in this very fashion. Part of the problem was inconsistent naming of activities across the application code base, however the other part of the problem was the difficulty in tracing out which part of the application was doing what and when.

Much like with ajax, if you're going to use the above technique:
1) be careful (and consistent) with your naming
2) make it obvious what the 'background stuff' is doing
3) make it discoverable (so the background stuff being returned can easily be queried by future developers wondering wtf?)
4) keep the controlling code in one place.

The worst part of the app I was fixing was that there was interplay happening between the js on the parent page and on the iframe. Either put all of the logic in the parent and the iframe just contains data, or put the logic in the iframe. If you put logic in both spots you're just making the problem needlessly complicated.

Timothy needs QA (0)

Anonymous Coward | about 4 years ago | (#31968710)

Yesterday, a year old report of two thirds vote controversy. Today, stop the press on obvious and not particularly interesting use of iframes. What's for tomorrow?
Seriously.

thanks for the info... (1)

2fuf (993808) | about 4 years ago | (#31968762)

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_frame() 149 css = styles[get_style()] 150 text = get_cgi(u'text') 151 link = commands.getoutput(u'/usr/local/bin/link') 152 timestamp = time.asctime(time.gmtime()) + u' UTC' 153 print u''' link undefined, global commands = , commands.getoutput = /usr/local/lib/python2.5/commands.py in getoutput(cmd=u'/usr/local/bin/link') 42 def getoutput(cmd): 43 """Return output (stdout or stderr) of executing cmd in a shell.""" 44 return getstatusoutput(cmd)[1] 45 46 global getstatusoutput = , cmd = u'/usr/local/bin/link' /usr/local/lib/python2.5/commands.py in getstatusoutput(cmd=u'/usr/local/bin/link') 51 """Return (status, output) of executing cmd in a shell.""" 52 import os 53 pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r') 54 text = pipe.read() 55 sts = pipe.close() pipe undefined, os = , os.popen = , cmd = u'/usr/local/bin/link' : [Errno 35] Resource temporarily unavailable args = (35, 'Resource temporarily unavailable') errno = 35 filename = None message = '' strerror = 'Resource temporarily unavailable'

No (0)

Anonymous Coward | about 4 years ago | (#31968794)

This is a bad idea. Can you imagine a project of any length written like this? It'd be completely unmaintainable.

Horse and carriage (0)

Anonymous Coward | about 4 years ago | (#31968898)

This is like saying, "yes, you can move around without using fuel", and point to a new invention called horse and carriage, while wildly ignoring this is what the cars replaced to start with.

why? (0)

Anonymous Coward | about 4 years ago | (#31969124)

Screw "gracefully" degrading... Move on and forward.

Better idea would be (0)

Anonymous Coward | about 4 years ago | (#31969218)

to don't fucking bother. Ajax is an ugly, slow, inconsistant clusterfuck anyway.

Not Ajax, and not a backronym (0)

Anonymous Coward | about 4 years ago | (#31969350)

I remember the day Jesse James Garrett posted that article where he coined the term Ajax, and he introduced it as "shorthand for Asynchronous JavaScript + XML" [adaptivepath.com] . So unless he first named it after a Greek god, a scouring powder or a Dutch soccer team, it's not a backronym.

What TFA describes is not Ajax, but a much older technique using iframes. Congratulations, you just rediscovered the Web of your ancestors.

Back in my day... (1)

nickdwaters (1452675) | about 4 years ago | (#31969352)

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.

Proof of concept: (0)

Anonymous Coward | about 4 years ago | (#31969448)

... that he is a n00b [jonathanscorner.com] !

client side BAD IDEA (0, Redundant)

unity100 (970058) | about 4 years ago | (#31969534)

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 being written exclusively on client side stuff for a decade or more.

- due to the above fact, privacy, security, firewall, antivir programs etc are very hostile to client side scripting, and scrutinize it. most cause failures in client side with execution, or block it altogether, killing your site for your visitor. you wont know any of these cases unless some enterprising visitor can understand whats going on and report - even then you will lose heaps of visitors for every report you get.

- on the web you cant take risks - every visitor is important in our time. therefore, the above problem constitutes a very good reason why not to use client side scripting - you must make sure you catch every visitor.

- scaling and shit. you cant trust it. it is something that also happens on client side, according to the code you have written, and even the scaling back code itself is prone to the issues above. it may get locked up due to some app causing it to malfunction, it may be prevented by security programs, it may fail due to lack of memory, it may fail due to innumerable things.

- EVEN if it doesnt fail, you still wont know how did your website present itself on the other side. maybe some important widgets malfunctioned, so the client cant order now ? or communicate ? you will never know because most visitors will just close down your site and move away, instantly forgetting that they have ever been at your site.

.......

thats why you need to go with server side scripting :

- ALL the parameters are under your control. you will be sure your code executes, doesnt run out of memory, successfully completes and sends the result to the client, in acceptable speed.

- Because youre sending pure html and css to the visitor client computer, you will be sure that what you sent has reached them. there is little reason as of now for security programs to shun html and css, or any runaway or irrelevant app causing any lockdowns, crashes or any other issue. what you produced serverside, goes to client side much more probably than client side.

and many more.

Re:client side BAD IDEA (0)

Anonymous Coward | about 4 years ago | (#31969616)

Or in short form, "Don't expect IE to execute your javascript" - at least for the parts of the rant above that aren't utter bullshit. For instance:

viruses are being written exclusively on client side stuff for a decade or more

WTF does this statement even *mean*? Are you seriously asserting that every virus in the last decade has been written in Javascript?

Because youre sending pure html and css to the visitor client computer, you will be sure that what you sent has reached them.

Yeah, except for the part where Norton Internet Security's "ad-blocker" drops images that match a particular pixel size. Or their connection is flaky and times out your responses, etc.

scaling and shit. you cant trust it. it is something that also happens on client side, according to the code you have written, and even the scaling back code itself is prone to the issues above. it may get locked up due to some app causing it to malfunction, it may be prevented by security programs, it may fail due to lack of memory, it may fail due to innumerable things.

Here, the OP's lack of English skills make it completely impossible to figure out WTF he's talking about. Whatever it is, it's got fuckall to do with "scaling" by any meaningful definition of the term.

What's next? Do you refuse to use CSS because selectors might not behave exactly the same way in every browser?

Re:client side BAD IDEA (0)

Anonymous Coward | about 4 years ago | (#31969724)

You've really enlightened us with your knowledge of the difference between client side scripting and server side scripting. Be sure to send this to Google, Facebook, Twitter, and the dozens of other massive web sites that safely serve millions of users per hour using JavaScript.

Have you been posting this same message since 1998? How about you just get comfortable with JavaScript and get used to the idea of scripting on the client. Don't be scared it is quite fun and powerful. Oh, and it isn't going to go away.

First Reason I've had to Post on /. (0)

Anonymous Coward | about 4 years ago | (#31969796)

I've been reading Slashdot for 5 years without ever posting. The only reason I've ever had to post on an article was to comment about how ridiculous the article is and the fact that it made it on to Slashdot as "Ajax Without Javascript" is utterly insane. Slashdot is now 100% useless. Wow. Wow.

Re:First Reason I've had to Post on /. (0)

Anonymous Coward | about 4 years ago | (#31969908)

You must be new here.

Old is new again? (1)

RomulusNR (29439) | about 4 years ago | (#31970108)

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 maddeningly and increasingly high-level focus of web development, a web programming shop will immediately reach for the AJAX hammer to hit even the simplest nails, instead of using the most efficient tool for the job.

Before AJAX we had DHTML, before DHTML there was cross-frame scripting, and before that there was client pull and server push. We do nearly all of these things now with AJAX and as a result, simple tasks are developed as unnecessarily complicated monstrosities.

Really, an Iframe? (0)

Anonymous Coward | about 4 years ago | (#31970238)

That thing is from before the phrase AJAX even existed.
I was expecting some sort of funky hacking around with CSS and server-side.

But what i think is better is the fact that they used an iframe.
The iframe was a wonderful invention.
Why is it almost getting to the point where it might actually be deprecated in the near future?
An iframe creates a very logical separation between 2 separate pages.

You shouldn't kill iframe just because browsers CAN create elements and deal with HTML natively and generate pages and so on.
Iframe should be brought in to the new age of web development instead of being stuck in yesterdecade.
The only major issue with iframes is they take a huge hit in loading content (mainly due to little effort being applied to optimizing the process) and some pretty silly security problems, and abuse of embedding others pages on your site and reaping the benefit.
And worse yet, websites then were allowed to interact 100% with the parent page via "top.", including changing the URL, which led to all sorts of annoyances and abuse.

Iframes simplified the making dynamic pages massively. And it still does today. But there is some sort of hatred for them, as if they are some lowest-class-possible citizen.
Is there no love for Iframes left in your heart..?
How many of you can say you never loved them when you first got to play around with them? It opened a whole new area of web development to explore...

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...