Mastering Ajax Websites
An anonymous reader writes to tell us that IBM DeveloperWorks has an interesting article introducing the uninitiated to the world of Ajax. From the article: "Ajax, which consists of HTML, JavaScript technology, DHTML, and DOM, is an approach that helps you transform clunky Web interfaces into interactive Ajax applications. The author, an Ajax expert, demonstrates how these technologies work together. Ajax is more than just the latest fad -- it's your stepping stone to build better Web sites through efficient use of your time."
. . . how when a new fad comes along, people say it's not a fad?
I too have felt the cold finger of injustice.
Interesting post. This kind of introduction might help beginners (like me) to know more about this new mix of different technologies and avoid confusion. Just these days a friend of mine said to me that he would like to learn this new "Ajax programming language". Many people still think that way. Thumbs up for the article.
A nice example of Ajax usage can be found at http://www.meebo.com/.
From the article:
... "Particular Way" for browser two ...
JavaScript code is the core code running Ajax applications and it helps facilitate communication with server applications.
Depending on JavaScript could be its downfall, since JavaScript has so many functional work-arounds for each browser. Even the article mentions (but dismisses) this problem.
From the article (again):
Microsoft's browser, Internet Explorer, uses the MSXML parser for handling XML (you can find out more about MSXML in Resources). So when you write Ajax applications that need to work on Internet Explorer, you need to create the object in a particular way.
"Particular Way" for browser one
Sounds like in an inherently poor design.
AJAX isn't an end in itself; it's just a tool. It's like JavaScript. Back when the web was old, if you wanted to do data validation for a form (for example), you had to send the page to the server and wait for a new page as a response. When JavaScript became popular and well-enough supported, the webpage itself could check data before sending it to the server - although the checks couldn't be that complicated. AJAX is similar; instead of limiting yourself to either using a new page or client-side data, AJAX lets you use JS to access server-side data.
As a concrete example, play with Google Maps for a couple of minutes, then try using a map from MapQuest. It will quickly start to annoy you that you can't drag the map and that you have to click to a new page to move the map around. GMaps isn't pure AJAX, admittdly, since it deals with picture data - it can just write the image tags to the page and move them around as you drag. But the side text and the map searches are AJAX - when you click search, you don't open a new page with the search results. You can keep using the map; the client will turn your search into an XML request, Google will process it, and send the results back as XML - asynchronously.
For another example, I wrote this week a dead-simple chat program (because I needed a specific feature). It was simpler to write a web app instead of a real app, because the latter would require networking, windowing, and whatnot - the web interface made GUI easy and manual networking irrelevant. Without AJAX, I would need to have the page reload every second to check if there are new messages - very distracting. I had the system asynchronously check for messages in the background, and when one arrived, update just that part without refreshing the page.
AJAX is a tool to be used when necessary. Don't freak out over it, but realize it's there whenever you need to use a more application-like interface instead of a page-like interface.
AJAX doesn't make it easy to develop cross-platform web applications. Look at all the browser incompatibilities in the developing of Gmail and more recently MSN's start.com page.
We need to re-standarize Javascript or at least make sure all the browsers implement a 100% compatible version. And I don't think that will work since not even HTML is properly rendered by any browser at all.
Recalling the Simpsons: "Only suckers buy [last year's] model. You are not a sucker, are you?"
I can't wait to start padding my resume with the latest and greates technology out there that will do the same thing we've been doing for decade but with more acronyms and steeper learning curve.
"Ajax, which consists of HTML, JavaScript technology, DHTML, and DOM, is an approach that helps you transform clunky Web interfaces into interactive Ajax applications."
DHTML is nothing more than javascript and html. And how the heck are you supposed to use javascript without using the DOM, aka Document Object Model? Talk about buzzword compliant...Well, as soon as we get all of the web browsers out there to adopt your so called "new language", we'll be all set. Your comment about Macromedia Flash made me laugh. Explain to me how Action Script interacting with the server with XML.send() is any different than JavaScript using XMLHttpRequest??
Obviously you're not a web developer ;)
Instead, how about a JavaScript 2.0? The language is only short a few key elements (like a native JSON serializer).
I started developing web based applications 7 years ago. At that time, JavaScript was really only useful for image mouse overs and was more or less useless and I refused to use it for anything.
Well, about 8 months ago I decided to give JavaScript another chance. All I can say is, wow it's come a loooong way.
I'm a bit skeptical of all of the frameworks that have popped up. They seem to overcomplicate things profoundly. I've looked at a lot of them, but haven't decided that any of them are less work than the solution I developed on my own.
My approach is to use JSON instead of XML. I have a server side script (can be any language, I used PHP for my last application) which acts as a listener script. The listener script accepts and sends JSON strings. The client JS composes and sends JSON strings with XMLHTTP request.
It's clean, fast and simple to maintain and expand. I think these claims of AJAX being "too complex" are ridiculous.
Kiteboarding Gear Mention slashdot and get 10% off!
The incompatibility you are talking about is the direct result of Microsoft implementing XMLHttpRequest with ActiveX, and everybody else implementing it as a native Javascript object. Microsoft are changing their implementation in Internet Explorer 7 to be compatible with everyone else.
So no "inherently poor design", just a historical artifact that is a) easily worked around, and b) going away.
Bogtha Bogtha Bogtha
You don't need polish to keep users, you only need polish to attract users. Take Slashdot as an example. Hideous design, atrocious implementation, no polish whatsoever, full of bugs, and yet people keep coming back to it.
Once you've attracted users, they rarely go away unless you give them a push (like endlessly posting repetitive articles on Ajax, for example).
Bogtha Bogtha Bogtha
You're almost there, but the number of users has nothing to do with it. You use it when it's appropriate to support a desktopish interaction model, and you don't want to reload the page every time.
Also, I'd clean up the terminology. You don't use it for web sites. You use it for applications.
Slashdot - where whining about luck is the new way to make the world you want.
Also, if you consider the popularity of the "NoScript" extension, you'll see that a lot of people turn JavaScript off. Having it permanently disabled is a part of many security policies, as well; I would estimate that at least 10% or so of people will have JavaScript disabled at least on their first visit. This is a lot more than a minority such as "Links users" or "the blind".
So... unless you disregard a significant percentage of viewers, you do need to provide an alternate version.
The article says: "Ajax is more than just the latest fad -- it's your stepping stone to build better Web sites through efficient use of your time." -- tell me how can AJAX save you time if you have to do _both_ versions of the site, multiplied by the number of differently behaving browsers?
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Not trying to spruik it or anything, but I'm currently working on a project of making a webapp using Laszlo.
It's an open source language/server for creating flash based applications.
We've found it to be very impressive how much you can do with so little code... and it's nice to have a proper OO backend to a flash frontend... the flash frontend means we can:
a) Make our interface very pretty and like a 'normal' application
b) Means it works in pretty much any browser...
c) on pretty much all platforms...
d) without a download of any plugin in most cases (just because of the penetration of flash)
I'm bored with these paradigms. Can we invent some new ones already? I propose Flash + Ads + Porn + Paypal = FAPP.
It's not just a fad!
Depending on JavaScript could be its downfall, since JavaScript has so many functional work-arounds for each browser. Even the article mentions (but dismisses) this problem. From the article (again): Microsoft's browser, Internet Explorer, uses the MSXML parser for handling XML (you can find out more about MSXML in Resources). So when you write Ajax applications that need to work on Internet Explorer, you need to create the object in a particular way. "Particular Way" for browser one ... "Particular Way" for browser two ...
Sounds like in an inherently poor design.
Im not a huge fan of AJAX, but this is one criticism you can't honestly level at it. Browser incompatibilities exist for pretty much all client-side, web-based technologies, and AJAX has only a single minor change to work around, as opposed to getting a complex CSS layout to work cross-browser. *shudder*
The simplest AJAX app relies on one piece of javascript functionality - the ability to make an http request through script. I've used this a number of times to submit data to a server when I didn't want to update the page.
Most AJAX then also relies on the ability of javascript to parse an XML document (to examine the results of the post) and some form of dynamic page-rewriting to change the current page based on the XML document (generally object.InnerHtml for content changes, or object.style for stylistic ones).
These features are fairly static - there's no need for them to change often. Simple AJAX - which is simply just offloading form submission - is good, useful, and most users don't even know it's there. As long as javascript keeps these three features, AJAX won't have major browser compatibility problems.
AJAX which rearranges the page after each XmlRequest is a bit more troublesome. It's also the flashy bit, which means its the bit every man and his dog tries to do. Using this technique, it is easy to write an entire site in one page - that is, there's one page the user visits, and the page rewrites itself based on their clicks. This is the stupidity of taking AJAX too far; you end up breaking basic functionality of the web (back buttons, refreshing, bookmarking, opening in new windows/tabs).
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
I just can't decide:
1) point out that AJAX is nothing new, it's just a fancy schancy buzzword for DHTML+XMLHTTPRequest, and that I'm so cool since I've been using it since 1997 long before someone coined the term. In fact, long before XMLHttpRequest was even invented!
2) "Web 2.0" is retarded why do we need to version the web, Flickr sux, GMale sux, Google Maps sux, and anything with fancy javascript interfaces, rounded boxes, and pastel colors sux
3) obligatory overused joke regarding AJAX the cleaning supply
-tom
If by useful you mean allowing MySpace to get pwn3ed, then yes, AJAX is useful.
Remember the Samy worm?
http://namb.la/popular/tech.html
He used html, java, dhtml, xml...
Especially XML
AJAX seems to be like Darth Vader... Powerful, yet dangerous.
[Fuck Beta]
o0t!
I've been working on a project that provides a web-based environment for people with a medical condition to get counseling and support online. Chat has been one of the desired features, but the various methods for implementing chat were presenting a problem. Java applets and Flash applications presented problems with time to load for modem users as well as issues with having the right versions of Java/Flash player installed on client. I thought setting up a Jabber server and letting folks use a client installed on their computer would be a good solution, but many (most) found it too difficult to install and configure a chat client. (These are older folks often with little computer experience.) AJAX came to the rescue. The "chat client" is part of the web application. It is as lightweight as the typical web pages being loaded. The exchange of messages between client and server require very little bandwidth. The chat application is just part of the same environment that the users are already comfortable using. I don't see AJAX as the answer to everything and, for the moment, having web applications chock full of AJAX doesn't make sense. But, it has come in very handy in the case of chat for the project I am working on.