Slashdot Mirror
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."
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?
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.
Been using iFrames to get around web restrictions since before you lost your virginity...
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
So I think I can keep javascript out of the game code
Stephan
http://stephan.sugarmotor.org
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).
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.
Python 2.5.2: /usr/bin/python
/home/jonathan/mirror/ajax/server.cgi in () /home/jonathan/mirror/ajax/server.cgi in print_showcase_frame() /usr/local/lib/python2.5/commands.py in getoutput(cmd=u'/usr/local/bin/link') /usr/local/lib/python2.5/commands.py in getstatusoutput(cmd=u'/usr/local/bin/link')
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.
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>
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>
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'
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'
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.
Vivin Suresh Paliath
http://vivin.net
I like
<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?
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.
Courtesy of the font tag.
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?
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.
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.
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'
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.
You can't handle the truth.
This is a bad idea. Can you imagine a project of any length written like this? It'd be completely unmaintainable.
What concept is this proof of?
www.blueapples.org
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.
Screw "gracefully" degrading... Move on and forward.
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.
All of the above was encrypted with a Quad ROT-13 method. Unauthorized decryption is in violation of the DMCA.
to don't fucking bother. Ajax is an ugly, slow, inconsistant clusterfuck anyway.
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". 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.
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.
... that he is a n00b!
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.
Read radical news here
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.
that explains the ugly bulges
Table-ized A.I.
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.
Terrorists can attack freedom, but only Congress can destroy it.
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).
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...
Reminds me of this Asimov short story, The Feeling of Power
there's nothing graceful about the solution
a quick peek at the source and there's frames buried in frames targetting other frames
while it might get the solution you want, imagine trying to update / maintain the thing
in addition a meta refresh is used to avoid the javascript timeout / interval methods
this gets a net effect of being able to keep the content pulled in up to date
unfortunately it means your content has to be a fixed height
so prepare for your site to look worse when the iframes' scroll bar pops in
(though in the demo's case it's like putting mascara on a pig)
the meta refresh also triggers the 'loading' indicator in browsers
when i see it go and i expect i'm supposed to stay on a page, i hit "stop"
it's not a major thing though
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.
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 talking about the html5
websockets, which finally will get us rid of that pesky ajax.
A backronym is when you take what may or may not be an acronym and produce a phrase you believe it represents. So far as I can tell from past articles I've read and this article which Wikipedia says is the origin of the term, AJAX really does stand for what they claim it is only a backronym for. That is, I think the original article has this wrong.
http://www.adaptivepath.com/ideas/essays/archives/000385.php
using frames is a step back to a time where websites tried to be little space of their own. forcing users to learn the concepts of their usually not so rich webbased applications.
if you need a fall back iframes is the worst way to go, it does not only force you to setup special little formatings and pages for each and every frame.
you have to make sure one frame is in sync with the other and additionally the right order of frames can not be assumed for screenreaders and such if they fetch the frame at all
there is simply no good in using iframes substituting ajax
the right way to fall back from ajax is simply to place links in the buttons, then replace them with js and manage the states on the server
its really fun when you also fall back if no cookies are allowed to rewriting all links correctly
(btw. try to have as few pages with state based content as possible)
if your site then also looks good, validates (strict if possible) , works fine with changing font sizes , has a style displaying it well on smaller screens too and has a tiny size then you stand out of the rest that are only script kids
and for those who think that that is too much to ask for a website especially on budget then you should rethink that.
because about 30% of the users tend to not have webdeveloper complying settings. if you include them where your competitor does not it results in 100% of the total sales in this segment. especially when youre competing heavily this can add a lot of profit to your business. provided you strive that for.