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

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

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

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.

Re:Unfortunately...

[Radres]

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

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