Advanced Requests and Responses in Ajax

An anonymous reader writes "The Web is no longer a place where simple applications are tolerated; 'users have become more advanced, customers expect robustness and advanced error reporting, and managers are fired because an application goes down 1 percent of the time. It's your job then, to go beyond a simple Ajax application that requires a more thorough understanding of XMLHttpRequest.' This DevWorks article tries to help developers use Ajax to build a solid foundation in which an application handles errors and problems smoothly."

Comments

CS101

[slackaddict]

"...to build a solid foundation in which an application handles errors and problems smoothly."

Um, aren't these concepts something we learned in college??? This is just basic stuff... although I think it highlights how RAD languages can teach you sloppy coding habits if you don't take the time do do things correctly.

Re:CS101

[firewrought]

Um, aren't these concepts something we learned in college?u

Error handling wasn't taught well at my college. Yeah, you might fail one of Greenlee's assignments if you if you didn't check the return status of a system call, but that's not the same thing as knowing how to handle an error when you get one.

It wouldn't be difficult to add an error-handling module to an intermediate-level programming class. There are only a few basic response to any error situation: ignore it, propagate it, retry it, ask the user about it, log it to disk/email/syslog/database/whatever, log it to the GUI, and/or bail-and-quit. Talk about when and how to use each approach; throw in material about retry strategies, explicit vs. implicit error signaling, fail-fast behavior, ask-forgiveness, pitfalls of catching all exceptions, the needs of production systems, etc., and followup with an examination of a few platform-specific error-handling facilities.

If you're college taught all this, then great!!! Mine did not. Maybe I should email some of my old profs...

Re:CS101

[hey!]

What the issue at hand boils down to this: knowing how to program in an asynchronous enviornment. If you've done it before, you can skim the article in under five minutes, because it's just a small and managemeable set of conventions that sets dealing with the XMLHttpRequest that would be new to you. The strategy is just common sense, if you've done this sort of thing.

CS101 certainly touches on aspects of asynchronous programming, such as threads, but I suspect the student's first serious exposure is more likley to come in second or third year OS class. But in any case you have to expect a CS program to fill the student's heads with more knowledge than skills. I've even hired engineers with masters degrees who, while they had the basic theoretical knowledge needed to do this kind of work, don't have a decent feel for it.

The reason is that while they learned the theory, in practice details have always been taken care of by some framework or another. For example some ajax frameworks work by callback functions; clearly they're doing just this stuff under the covers.

I'm not saying this is rocket science; quite the contrary. Very, very little in CS is. Most practical skills in CS amount to this: attention to detail and taking care with making assumptions you make -- particularly knowing when an assumption can be trusted to hold and when it cannot. I've often reflected that doggedness and fastidiousness (well, mental fastidiousness at least) are equally important with intelligence in making a good programmer.

The problem is that programmers always have too many details to manage. Succeeding is what differentiates the good ones from the bad, and experience is very helpful. As in many things, an ounce of prevention is worth a pound of cure. It's all to easy to be careless or inattentive in the wrong places. Believing you know when to do this is what converts garden variety laziness into the hubris. Getting this stuff right isn't hard, but getting it wrong isn't hard either, in which case you end up with hard to debug problems or systems that are unresponsive.

Ironically

[RealProgrammer]

When I tried to download the code from the article, and clicked through the license, it said:

404 Not Found

Not Found
The requested URL /ibmdl/pub/software/dw/web/ wa-ajaxintro3_ajax-xhr_adv.zip was not found on this server.

Perhaps someone should write an article on how to write robust AJAX code. Oh, wait...

Re:AJAX?

[DeveloperAdvantage]

If you want a one hour summary, take a listen to our most recent audiobook at http://www.developeradvantage.com/products.html . It's free for now.

Re:AJAX?

[FooAtWFU]

Ajax was a king of Salamis, and a legendary hero of ancient Greece.

Users..

[onion2k]

users have become more advanced

They really haven't actually. They've stopped being mostly geeks and academics and now the internet is open to all. Users are much, much less advanced today than they were ten years ago. What has changed in more recent times is that the users now they're think more advanced. They're presented with interesting social networks (FlickR, Blogger, deli.co.us, etc), and they're capable of using these straightforward interfaces with lots of handholding (rebranding categories as tags for example) and they get the impression that they're learning something. Does that mean they know, or care, what an XMLHTTPRequest is? Nope.

The same goes for customers. Yes, they want advanced reporting and robust apps .. do they care how those are achieved? Generally, nope.

As for managers being fired for an application being unavailable 1% of the time .. the article talks about AJAX .. AJAX relies on JavaScript. Between 7% and 10% of web users have JavaScript turned off either implicitly or due to their IE security level. Surely if you're creating an AJAX application then you must realise the application is already unavailable to 7% of users even when your server is up and running? If high availability is key then you'd better not be using anything beyond HTML.

Re:Users..

[just_another_sean]

For all of you who've got ad blockers on and JavaScript and flash turned off, welcome to the beginning of the end.

Oh the delicious irony of seeing this post immediately after a sensible poster mentions graceful degradation.

See, I actually see things differently then you do. I do run with JavaScript disabled for the most part and AdBlock turned on. And you know what? I don't really have that many issues with websites. And if I do run into issues? Well, I really don't care if my browser doesn't work for them.

I think perhaps just because you have "They're not seeing our ads? Well F them then!" attitude towards customers does not a) mean all companies do and more importantly b) not all developers do. Standards are generally designed to implement some backward compatibility. I don't think, despite your gloomy predictions, that this is likely to change anytime soon. The majority of (useful, interesting) sites will continue to keep this in mind in order to take advantage of as many eyeballs as possible.

So I think I'll continue to use ad block, watch all my TV on DVR and skip the commercials, avoid tracking tools, like toolbars that integrate with my browser and in general keep myself as ad free as possible.

Meanwhile you and the rest of the mass marketing industry can try the RIAA route and whine to the government about it. Maybe they'll make my DVR and ad blockers illegal. Then, I guess you win.

Unfortunately...

[everphilski]

In this day and age a lot of us are asked to program who are not by nature computer programmers. In a perfect world all the programmers would be CS majors. For example, I am an Aerospace Engineer, however I spend 6 hours a day writing code in c++. It isn't pretty but it works. Why? The company I work for could either:

(a) Hire engineers who know engineering and are crappy programmers, and make them learn programming, or
(b) Hire CS majors who don't know engineering, and spend 4 years to teach them engineering

(a) makes more sense to me. A lot of my code looks like crap, and I know my CS friends could do better quicker, but they don't know the engineering principles I do. Long story short, I didn't have CS101, CS102, etc. There are a lot of us out here who are asked to code, who weren't brought up to be coders, who have to be taught some principles that aren't immediately apparent :P

Re:Unfortunately...

[AuMatar]

The correct answer is c

c)Have the people who understand the engineering write pseudocode algorithms and work hand in hand with real programmers.

The advantages you get from this- code that doesn't look like shit and have major architectural short commings, and much easier/cheaper maintenance. While I'm sure an Aero can learn to do basic programming in a month or so, it does take a few years to write good, well designed code. Whereas an experienced programmer can write equivalent functionality in 1/10 the time. By working together, you end up with higher quality software for much cheaper. This is the same way you see EEs and MechEs working with programmers in the embedded world.

Re:Unfortunately...

[Radres]

But c) will also half the maintenance costs of your crappy code.

Re:Unfortunately...

[AuMatar]

Not in the medium to long term. The improved maintainability (and very likely, quicker turn around time) of the programmer's code will very quickly make up the cost and more. If a good programmer can turn an algorithm from an aero to code in 1/4 the time (which is not, by any means, an unreasonable assumption) you end up saving money very quickly- you can hire 4 aero engineers to code, or you can hir 1 programmer and 1 aero engineer. And the aero might have free bandwidth to do more aero based stuff as well.

Pretty sparse

[Gopal.V]

The document is pretty much ranks in the category of 30 second ajax tutorials. It would have been better if the document has explained how you were supposed to handle concurrent XmlHttpRequests - a problem I am faced with. Yesterday, I noticed the new Y! libs released had - transaction ids for Ajax requests. I've been using closures in javascript to maintain the context info, but this way sounds much better.

Any decent webdev entering the field should know about http status codes, HEAD requests and all that. Also it should be noted that article didn't even mention how many times state 3 is hit for a particular request - I got caught by that one once.

Corrected URL

[RealProgrammer]

The download link in TFA has an error. To get the code from the article, use:

http://download.boulder.ibm.com/ibmdl/pub/software /dw/web/wa-ajaxintro3_ajax-xhr_adv.zip

Taking the "%20" away from the final "/" made it work.

(There should be no spaces in the URL.)

the web IS such a place!

[tjr]

The Web is no longer a place where simple applications are tolerated;

Sure it is. Most web applications that I use, whether if they make use of AJAX or not, could certainly be plenty usable and valuable without AJAX.

AJAX makes some things possible that aren't possible using plain HTML, but it doesn't make ALL plain HTML so much better that it would be impossible to imagine the site without it.

simple != intolerable

[blue_adept]

The Web is no longer a place where simple applications are tolerated

Not so. Simple = GOOD, just look at the success of google; no fancy front end required. AJAX, like good special effects in a movie, can enhance the end-user experience when applied selectively and intelligently. They are NOT an end in themselves.

The truth is, the web is a place were only USEFUL applications are tolerated, whether or not they use AJAX.

Re:AJAX?

[Serapth]

... and a bleach!

Re:AJAX?

[DeveloperAdvantage]

Thanks. Sometimes I really don't understand the censoring, I mean mod system here. Our audiobooks are currently freely downloadable, we have no advertising on our side, and it seems reasonable and on topic that if someone asks about Ajax to point them to our material. After all, this whole thread is about an article from a huge, profitable corporation. Maybe instead of audiobooks, I should call them "audicles", and then it will be ok to mention them when people are looking for information.

Anyway, thanks again.

I would prefer the JSON way

[moria]

Using JSON, JavaScript can load data from any address, when XMLHttpRequest requires you to stay in the same domain. Besides, JSON is JavaScript native and is therefore much easier to consume, for example, using MochiKit. As for the generator, it is trivial to convert native data to JSON data in a wide range of programming languages, including all the major server side scripting languages, like Python and Java. Yahoo has released a lot of their APIs on JSON and some excellent Python WebApp Framework has built-in support to speak to the client scripts in JSON.

No longer tolerating what??

[ben_1432]

Where's the ajax on slashdot? Are we supposed to be rebelling because it uses the traditional get/post methods instead of the (new name, old technology) "ajax" version?

Where's the ajax on msn & yahoo .com's? Or on mainstream news sites?

Ajax is a "web two point oh" buzzword, and 99% of "web two point oh" services/systems aren't going to be a success just because they utilize it.

I'm not disputing it can be useful and add something to an application, but the hype outweighs the benefit.

One thing I fear about ajax is the poor standards many developers work to - how long before we see phpbb/phpnuke/et al tearing servers apart because each visitor is suddenly making an extra 10 database queries a minute while previously they'd alt-tab back and hit refresh every few minutes?

AJAX Privacy and Security?

[WebCowboy]

Forget about the back button...that is an annoyance I've grown to tolerate (for almost a decade we've had to deal with "sticky" web pages). MY biggest concerns centre on SECURITY and PRIVACY.

One thing about Javascript is that it is very aware of the client's environment--we can use it to determine screen size, colour depth, browser type, browser history and so forth. Until the introduction of the XMLHTTPRequest object, developers were limited in how they could bring this information into the server. It wasn't impossible (you could do stuff with traditional javascript and server-side programming involving hidden input tags, cookies, automatic page submits/reloads, etc), however the user would usually have a visual cue (IE would produce an audible "click" during page submits and redirects by default, the page would blink, the "throbber" icon and status bar would indicate an HTTP request was happening, etc). Furthermore, such schemes were more easily breakable (disablihng cookies, etc).

Now with AJAX, a coder could write client side script that (for example) enumerates your browser's history and ships it back using the XMLHTTPRequest object. The page does not need to use cookies, install special software like IE "browser helper objects" or need to expose itself through the use of hidden input tags. It's the greatest thing since sliced bread for spyware developers (multi-platform, lightweight, not yet easy to detect). I think javascript is generally better contained than, say, VBS, from a security standpoint, but I still have my concerns.

Worse yet, there isn't much in the way of user control--a person can disable Javascript entirely but then the whole app breaks. Browsers like Firefox can limit the use of javascript to do popo-up ads, alter toolbars and such, but I see nothing regarding security control of the XMLHTTPRequest object. As far as I can tell, if Javascript is enabled at all, a script can make full use of that object, and it'd be REALLY easy to use it to report my browsing history on a constant basis, without me knowing about it unless I do a lot of sleuthing in source files and cache.

In any case, I have some questions for "seasoned" AJAX coders (I am well-versed in Javascript but am a neophyte with ful-blown AJAX apps): What do you do to make sure your app is secure from client-side shenanigans (perhaps an AJAX-equivalent to SQL-injection), what can a user do to manage security within your AJAX app, and have you used AJAX techniques for potentially intrusive purposes (sniffing a client's environment in particular)? You can post anonymously if you've had to "do evil" as part of your job if you want ;-)

(BTW, a competent AJAX developer would at least take measures to disable the back button's functionality, and there are measures that can be taken to handle the back button gracefully. It is mostly a matter of sound design...)