Slashdot Mirror
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.
More useful examples would include Google Maps, Gmail, Flickr, etc.
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.
Half the opinions about Ajax is that it's not worth all the effort. Too complex.
Too complex? As compared to what? Having each and every server-side action also generate a page for the user? With AJAX, you can have one or two pages for display, and the rest of the scripts just for sending or retrieving data.
I don't think the parent was implying the AJAX, itself, is too complex, but rather that JavaScript is, a statement which I entirely agree with. To do anything in JavaScript requires many lines of code -- and kludgy code, to me. JavaScript needs to either be seriously revamped or entirely rewritten. Unfortunately, the time it will take to a) get this new language written and, most importantly, b) get it standardized in all the major browsers (*ahem* especially IE) would probably just be too long. I don't think JavaScript is going to get a major revamp anytime soon. I think it's time for an alternative, though. Hey, client-side Python would be great; I'm all for it! :)
That's why it works so much better for web applications than normal web pages. Why would you bookmark a page in your Gmail account ;)
That's not Ajax, that's developers who have screwed up. You can have Ajax and addressability (bookmarks, back button, etc) for 99% of the things Ajax is good for. It's just you have all these newbie web designers jumping on Ajax like there's no tomorrow, so most of the things you see have had lots of shortcuts taken, and some of the things you see shouldn't have used Ajax in the first place.
A good rule of thumb for knowing when it's appropriate to use Ajax is where you intend on posting something to the server, and then redisplaying the page you just came from. For example, Slashdot's moderation. It makes no sense to regenerate the entire page just to tell the server what you think of one particular comment. This is also the situation where bookmarks, the back button, etc aren't going to break.
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.
A good rule of thumb for knowing when it's appropriate to use Ajax is where you intend on posting something to the server, and then redisplaying the page you just came from.
Completely. AJAX should only be used when you would've POSTed something to the server and made a slight change - both of those are non-bookmarkable and non-addressable. (Good) web designers seem used to when to GET and when to POST, so only use AJAX in the latter case. The general rule for that, by the way, is that POST should change stuff on the server, and GET should only retrieve data. Thus, you can only bookmark a view of data, not a change of it - you've already changed it once you're ready to bookmark.
AJAX can actually help with the entire problem of tabs and forms - if the form only changes data but doesn't update the view, you can use a regular link to see a different view of it.
The other solution is to do what Google Maps does - since they're using AJAX to retrieve views, they have a button called "Link to this view" or something that gives you a context-free URI to that particular view.
Websites done in Flash make my ban list.
Thats not complex. It may be bandwidth intensive, but that is different.
The Kruger Dunning explains most post on
A web application framework, like Ruby on Rails, can isolate you from most of the JS. Here is a introduction to Rails and Ajax.
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
He used html, java, dhtml, xml...
He used JavaSCRIPT. Big difference.
Being bitter is drinking poison and hoping someone else will die
Flash isn't a language, but ActionScript is. And, to be fair to Flash, I've seen a (very small) number of sites that actually use it for practical interface work -- an online reservation system, or the new Yahoo! maps beta, and it's good or better than any AJAX system I've seen. Flash is really a pretty good system for "rich internet applications" (the buzzword before "Web 2.0" became fashionable); it's just that developers (as opposed to designers), and users, have grown to think of it as a system for little more than producing annoying animated advertisements and unnecessarily frilly web pages. That it's gotten that reputation is largely Macromedia's fault, but it's not really a correct perception of it, and hasn't been since Flash 5, at least.
At any rate, it may not be the best use of your time, but were I actually developing a web-based application that needed a sophisticated client, I wouldn't rule Flash out, depending on what the back end system I was developing on was. Like it or not, Flash has one big advantage over Ajax and, for that matter, HTML/CSS in general: it bypasses browser compatibility issues entirely.
I'm genuinely confused. What does AJAX give you that Java applets do not? For example, people talk about Google's mapping application, and the ability to drag the map around. Isn't this something that Java was supposed to be able to do? And as far as browser incompatibilities go, isn't that what a Java applet program could circumvent?
What am I missing here? Furthermore, AJAX seems to force open source -- all of your source code is available so that malicious people can exploit its vulnerabilities.