Slashdot Mirror
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."
It's the rather scary idea of using JavaScript on a webpage to run XML-RPC requests to a remote server and update the local page, allowing for flashy stuff like Google Maps and GMail that does not require a new page to be loaded.
Too bad it requires JavaScript!
-mkb
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.
ConsultingFair.com
Perhaps someone should write an article on how to write robust AJAX code. Oh, wait...
sigs, as if you care.
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.
FREE - Java, J2EE and Ajax Audiobooks for Software Developers - www.DeveloperAdvantage.com
I think the article covers some things that are missing in a lot of ajax classes available, but really is nothing new. My own ajax class is far, far superior (trying to get the okay from work to OSS it).
Too many classes are using a global httprequest object. This is not good if you are doing many requests (though I suppose uses less memory). There's also no timeout for graceful handling of a slow server. I've done quite a bit in the way of error handling.
At least this one doesn't make you learn a damn mini-language... a major pet peeve of mine!
Not the most definitve source, but this should give you an adequate overview:
http://en.wikipedia.org/wiki/AJAX
...This DevWorks article tries to help developers use Ajax to build a solid foundation in which an application handles errors and problems smoothly.
That's good, because none of the commercial "enterprise class" software that I have to work with handles errors and problems smoothly. They just crash or send an error message that has no relation ot the actual problem.
You never really know how close to the edge you can go until you fall off.
Ajax was a king of Salamis, and a legendary hero of ancient Greece.
The World Wide Web is dying. Soon, we shall have only the Internet.
users have become more advanced
.. do they care how those are achieved? Generally, nope.
.. 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.
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
As for managers being fired for an application being unavailable 1% of the time
http://twitter.com/onion2k
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:
:P
(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
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.
Quidquid latine dictum sit, altum videtur
http://download.boulder.ibm.com/ibmdl/pub/softwar
Taking the "%20" away from the final "/" made it work.
(There should be no spaces in the URL.)
sigs, as if you care.
Every Ajax application uses the XMLHttpRequest object, so you'll want to be intimately familiar with it to make your Ajax applications perform and perform well.
I think this is true right now, at least to some extent, but as frameworks solidify and become proven, there will be less benefit to being "intimately familiar" with the XMLHttpRequest object. Of course, knowing more about the underlying technology can't hurt, and you will need to know them if you are the one writing a framework.
For a very good source on frameworks, take a look at http://ajaxpatterns.org/Ajax_Frameworks
FREE - Java, J2EE and Ajax Audiobooks for Software Developers - www.DeveloperAdvantage.com
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.
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.
"Is this just useless, or is it expensive as well?"
The Web is no longer a place for information exchange. It is a place to invest your money, to hire more and more coders/artists/testers/managers, to maintain all this eye-candy. There is a reason: It looks just like a real application inside your web browser!
We don't have anything special to say. But now instead of looking for a `Back' button, you may drag-n-drop our whole corporate site directly to your Recycled Bin!
... and a bleach!
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.
FREE - Java, J2EE and Ajax Audiobooks for Software Developers - www.DeveloperAdvantage.com
You'd be wrong. I don't believe slashdot uses any Javascript, except maybe some ad stuff. And even if it did, that's not a good definition. The point of Ajax is updating the client's display with new data from the server without reloading the entire page. This is why Ajax is so trendy - these pages are more pleasant to use because they respond more quickly, and without unrelated parts of the display going away and coming back or causing everything to scroll away from what you were looking at.
Ajax accomplishes this with the XMLHttpRequest() object. (It's a misnomer - XML doesn't have to be involved at all.) It's just a way to issue a request and execute some code when it completes (by success, failure, or timeout). That code can update a status bar, add some text to the page, or do something more sophisticated.
So have they figured out how to have the back button not wreak havoc on the page yet?
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.
The core concept of AJAX is to use Javascript in the browser to make requests to the server and then update the browser without having to load a new web page. This is accomplished by using the XMLHTTPRequest object which is available in one form or another in the lastest major browsers. This concept isn't particularly new (I worked on a project in 1999 that used a Java Applet to do the work that XMLHTTPRequest now does). However, what is new is that the technology is available natively in the major browsers, and can be used to make web-based applications more interactive and user friendly, without requiring any additional plug-ins. However, AJAX is currently a hot buzzword and way over-hyped. Anyone who already has solid Javascript skills and knows a server side scripting language should be able to pick up AJAX in a couple of hours. Eventually, there will be a nice OSS AJAX library available that will hide the details, but for right now, there's nothing better than an intimate understanding of the XMLHTTPRequest object.
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?
.com's? Or on mainstream news sites?
Where's the ajax on msn & yahoo
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?
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...)
It's that stuff you clean your bathtub with.