24 Feb 2005 | seth said...

It's great that the industry is finally coming around to this style of programming. I've been at it for about 3 years now :)

"Ajax" does allow for more interactivity and better user experiences in some cases but also poses a host of other problems that weren't dealt with before.

Programming JS in an asynchronous, event driven system like this has a lot of "gotchas" associated with it. I remember developing a browser based asynchronous stock trading application that used to MAX OUT the CPU of the host computer because of the frequency of the messages coming in. Combine that with the amount of processing that needed to be done to update the UI and you can see where problems might start to crop up.

A lot of developers will need to learn the ins and outs of profiling javascript and designing smart code paths that minimize CPU drain. Luckily we have better browsers these days (Firefox) with faster JS interpreters. Recently in an app I'm working on I timed FF taking 1/2 the time IE was to perform an onload handler....Ouch!

Welcome to the future web developers :p

24 Feb 2005 | David Schontzler said...

Personally, I hate to see it called "Ajax". I'd hate my to win my bread developing applications that share a name with a soap.

24 Feb 2005 | Dysfunksional.Monkey said...

"Ajax"... does that lead to clean code?

24 Feb 2005 | Steve said...

"Ajax"... does that lead to clean code?

No.

24 Feb 2005 | AK said...

and how long until we have to write different versions for the different browsers? With all the possibilities with this implementation, are we going to be blindsided by more hacks than it's worth?

24 Feb 2005 | brian b said...

My main qualm with all this is that Javascript is never introduced as a full-fledged language, every book i've picked up on it stops short of any real meaty stuff. So if anyone knows where i can learn more about this, please inform me. I'm looking to implement it into a new product my company is working on as well.

So how much MORE does this drain the CPU than a standard web app?

24 Feb 2005 | Mark Wubben said...

AK, You already have to adapt your code for different browsers... nothing new with Ajax.

Aside from being a soap, Ajax is also a soccer club in Amsterdam. So... I'm not really making the connection between the technologies and this name. Too bad.

24 Feb 2005 | Bob said...

What were talking about is technolology, not the user experience.

Speaking of an unfortunate typo... ;)

24 Feb 2005 | Adam Michela said...

technolology

that's a good name for it :D

24 Feb 2005 | Jonathan Fenocchi said...

Except that "Ajax" reminds me of that nasty, vomit-inducing cereal, I'm glad the concept now has a name.

24 Feb 2005 | ADAM said...

brian b,

Actually JavaScript is a full fledged programming language. I've been writing OO javascript for some time. It can be very frustrating at times but it can be very powerful too. Its a loosely bound, loosely types OO language (with some quirky syntax to be sure) that I can use to do a wide range of things.

Doug Crockfor has done some amazing things with javascript that makes it much easier to work with. I wish I had this 4 years ago.

The only real compliant I have with writing javascript based web applications is that you spend orders of magnitude more time writing code for widgets (treeviews, sliders, etc) than you do writing business logic. A couple of years ago, I started a project (though a colleague did most of the work) to convert the Java SWING libraries into JavaScript. Our company folded before we could finish it. It would have been nice to have around.

24 Feb 2005 | Jake said...

I would love to have a book/tutorial/set of tutorials...SOMETHING that actually got into the meat of JS! Ideas?

24 Feb 2005 | brian b said...

Re: Adam: I know its a language in its own right. My gripe was that most of these tutorial books stop short of the MEAT of it. basically what Jake is referring to.

24 Feb 2005 | Stu Schaff said...

THANK YOU, Jason, for the following two quotes:

However, lets proceed with caution. What were talking about is technology, not the user experience.

As with anything, its not the technology that matters, its the proper application and the execution of that technology that counts.

Just like other technologies out there, people think that Ajax is the be-all, end-all. Use it and you'll have the most "L33T" site out there! The same thing is true for web standards, from what I've seen.

Prediction: Look for uses of Ajax in places it really doesn't add a whole lot other than the possible "wow effect".

Me? I'll stick to the "just because you can doesn't mean you should" philosophy and use Ajax where it is truly the right tool for the task.

24 Feb 2005 | Micah Calabrese said...

Proper application and the execution are important but with technology this new it's a lot harder to figure out the what and how without people out there experimenting with the just-because-you-can mentality. Things like Google maps may have sounded like "wow" stuff until somebody made it real and found it useful.

24 Feb 2005 | Adam Michela said...

My gripe was that most of these tutorial books stop short of the MEAT of it

brian: Then maybe you should stop looking for MEAT in tutorial-styled books then.

Speaking strictly of books, there are plenty of excellent sources that will provide reference on anything and everything you could possibly want to know about JavaScript.

I would personally recommend O'Reilly's "JavaScript: The Definitive Guide" or "Dynamic HTML: The Definitive Reference". Actually the author of the latter, Danny Goodman, has plenty of great references.

If you wan't to talk about websites... there's even more great resources abound. PPK's Quirksmode for instance.

Not to mention Netscape's JavaScript Guide/Reference. Even Microsoft's MSDN Library is full of practical information that isn't as IE-centric as you might assume.

My point is... there is more than enough knowledge being shared out there. Maybe you're just not looking hard enough?

Oh... and please don't confuse me with the original "Anonymous-Adam" who you are currently conversing with. I'm the other Adam ;)

24 Feb 2005 | pb said...

Does there exist plain english instructions on how to program XMLHttpRequest to call a server on a different domain? Does this require weird browser privilege changes?

24 Feb 2005 | Adam Michela said...

pb: google "xmlhttprequest". each one of the top results is relevant and each one will tell you all you need to know (the links from apple and jibbering [#1 and #2] are particularly useful).

xmlhttprequest is really very very very simply stuff. don't be scared by the long winded name or the capabilities of it's wizardry.

the alternative methods of achieving the same goal may even simpler.

if that's still not enough... feel free to steal my code from higgle (sorry [almost] for shameless plug). pretty much the only thing going on there (for now) is a subscription form powered by xmlhttp(request). it will give you a decent idea of a basic production implementation.

24 Feb 2005 | Bronwyn said...

What a pity that nobody's remembered the original Ajax...or thought about Asimov's "Sword and Sorcery" (in Magic) long enough to conclude that it really ought to be called Odysseus.

After all, Odysseus was wily enough to do things that people thought couldn't be done, such as listening to Sirens, and getting away alive. He's much more on-target than Ajax, who was simply big and strong.

24 Feb 2005 | Adam Michela said...

ah crap. i thought i caught the stop button in time.

anyhow... while waiting for that post to post... i read your post again (say that three times fast!).

i see now that you're asking specifically about cross-domain scripting.

the answer is... no. you can't use xmlhttp reliably to request data from other domains. sorry.

some of the alternative methods do work across domains though. however they lack some of xmlhttp's better capabilities. then again, they sometimes make up for it with other positives.

check out my comments on Rakesh's blog for a basic script i posted ONE of those alternative methods. it's more applicable to the question/argument at hand in that post then it is viable production use... but it should get your gear's crankin'.

24 Feb 2005 | MH said...

I've used this technique, with great results (as in usability boost). The big issue looming in my mind is: Accessibility.

If screen readers choke on Ajax-type stuff (all evidence shows they know not what happens when the DOM is updated), is the onus on us web developers to avoid using Ajax, or on the screen reader developers to improve things from their side?

The potential usability gains are too substantial to ignore.

Adam "other adam" Michela:
Surprisingly, shockingly, XMLHttpRequest gets not a single mention in the Danny Goodman DHTML book (in all other respects it is excellent). Not sure whether the latest JS Def. Guide addresses it.

24 Feb 2005 | Adam Michela said...

MH: Why can't "Ajax" (man I hate using that I'm using that term) be accessible as well?

You shouldn't use an XMLHttp method unless you have a traditional fallback.

For instance in the link I posted earlier, your name/email is posted to the server via XMLHttp.

However, this process occurs on the "submit" event of the form. If any problem occurs during this process... such as the absence of a DOM capable browser (screen reader) or just a crap browser like Opera (;)), the form submission proceeds as normal... posting to the server... and the server brings you back a new page marked up appropriately.

Actually, in my opinion, one of the significant benefits of XMLHttp over the alternatives is that it is very easy to make accessible because it provides you with feedback (readystate & status) for everything it does.

25 Feb 2005 | Patrick Haney said...

When I first read about the "Ajax" methods that are starting to pop up, I thought maybe it refered to some sort of web code "cleaning" product. Then I read through Jesse's article and it made more sense. Although I'm not sure it's the best name for what it is, it's better to at least have a name for it I suppose.

I agree with most people here that Ajax might be overdone in the future in places it doesn't need to be. Designers and developers should always consider the usefulness of new technology before they just throw in a new techy feature that people didn't need, didn't want, and don't know how to use. At the same time, I see some really great benefits of using Ajax on the web, Ta-da List being one of them.

I'm also concerned with how people use it and how well it will degrade in certain applications. In the example of a zipcode lookup form from webpasties, if the browser doesn't support XMLHttpRequest, then the user would simply fill out the form as usual. However, if the browser does support the object, than the user inputs their zipcode and the city/state information is retrieved automatically. Of course, this comes right back to your point about users in the "what just happened?" state of mind. Perhaps this example infused with some sort of Yellow Fade Technique would be even better.

25 Feb 2005 | MH said...

Adam: Sure, you could provide a fallback, but that means twice the UI development work: you have to provide a "whole-page" version and a "piecemeal" version (I'm talking about the functionality needed to serve the content, not the content itself). And then you have to keep them in sync when changes occur in the future. (You may be right, and developing two UIs might be the only solution; however, I'd rather that there was a better way :)

Do any of the current XMLHttpRequest apps (Flickr, Google Maps, Google Suggest, etc.) have a traditional fallback?

What about Basecamp? Will Ta-da List even work with Javascript turned off?

25 Feb 2005 | Adam Michela said...

MH...

You're right. It is, sort of, twice the work. (More like 1.6x the work to be accurate, hehe)

However, I think relatively, the effort required to implement a robost and accessible Ajax app is relatively low.

Then again, it's all talk unless I show you something eh? Well, all I can show you for now is the subscription form at Higgle.

Still though, that's not much. It's a single form. Pretty basic stuff but it demonstrates the concept... and shows how Ajax can make something as simple as a "coming soon" form that much cooler.

To satisfy your needs and the requests of others, I decided last night to build something basic, yet useful, that I can show you for `how-to` type purposes. I then realized... may as well do it with a blog, eh?

So I started last night. I'm building a custom blog using a bundle of Ajax, with flOpera and old browser fall-backs.

Today I gave it the name Tackboard after I realized it felt like I was "tacking" comments onto the blog rather than POSTING.

I'm almost done now (like I said... basic but useful) and I will post it up here sometime this weekend. If you don't plan on checking back... leave your e-mail... or e-mail me your e-mail.

To answer your question about current apps... I just opened up Opera and took a look.

... not a single one works 100% in flOpera. Basecamp is the only one that comes close. You can use it, but lose some functionality.

Honestly, I wasn't surprised about any of them except Ta-da. I thought for sure Ta-da would have fall backs built in. It would only require a teensy bit of effort to make Ta-da 100% accessible.

The rest, I'm not surprised because the entire application is focused around GUI wizardry. If you don't have the wizardry... what's the point (almost)?

I have to give kudos to Basecamp though. I was surprised that it worked as well as it did. It's like 99% there (based off my 2 minute assessment... haha)

Anyway...

I'll put up something this weekend. We can then pick it apart... and I can go back to my hole :)

25 Feb 2005 | JF said...

It would only require a teensy bit of effort to make Ta-da 100% accessible.

If you want to donate the Javascript to make it work we'll have a look and implement it if it's solid.

25 Feb 2005 | Adam Michela said...

Sure thing J. I'll run through once I put up this Tackboard thing this weekend.

26 Feb 2005 | John said...

Adam Michela:

Tired to subscribe to higgle.com but I get this error, "Oops! Your e-mail looks wrong..."

I think it's because my email address has a "." before the "@" sign.

e.g. [email protected]

26 Feb 2005 | Adam Michela said...

John: Thanks much for that! Darn regular expressions ;)

All better now. Thanks for trying to sign up at least :) hehe.

27 Feb 2005 | John said...

No problem :)

Good luck on the launch!

27 Feb 2005 | Terry said...

JF how come you are always the sensible one?

27 Feb 2005 | MH said...

> It would only require a teensy bit of effort to make Ta-da 100% accessible.

> If you want to donate the Javascript to make it work we'll have a look and implement it if it's solid.

I thought it was the Javascript that was the problem in the first place...

27 Feb 2005 | Adam Michela said...

MH... not inherently.

Relying on JavaScript is the problem. Relying on non-standardized JavaScript compounds the problem. Building your back end to rely on input from JavaScript worsens the problem.

To each degree you have to weigh your options.

By improving the JavaScript you can solve some of the problems relating to say... Opera.

...

You'll see what I mean. Still churning away... give me a couple hours.

28 Feb 2005 | Adam Michela said...

Alright guys, I apologize for the delay. Had an anniversary with my lovely girlfriend to tend to ;)

The Tackboard Development Journal is online and powered by Tackboard 0.1 "Infant" ;)

For today at least, this will reside on a underpowered development server until I am confident enough in the backend to put it onto a production database. Please bear with me. I hope to publish Tackboard to one of our more powerful servers tomorrow evening.

The point of Tackboard is to demonstrate the ability of Ajax to make the everyday task of reading and participating in a blog, easier. All the while remaining accessible and standards compliant.

Tackboard will make extensive use of XMLHttp(Request), and a good bit of my version of 37signals Yellow Fade Technique.

I will be blogging on tackboard.axentric.com, for better or worse, here-on-out. In the next day or so, you will see Tackboard evolve rapidly as I enhance the feature set to at least fulfill the requirements of a basic blogging tool. I will also post detailed explanations of the hows & whys behind Tackboard.

I wish Tackboard to be an open excercise for all of us to learn a little more, and hopefully, make better use of these trendy new technologies. Please just have fun with it... take from it what you will... and we will keep building upon it from there :)

03 Mar 2005 | Tim said...

Regarding the 3 Ajax-style apps mentioned above, Flickr, Google Maps and Google Suggest-- Google Suggest works like normal Google without Ajax. As for the other two, do they really need to be accessible? Is a mapping site or a photo sharing site at all useful to the blind? Getting directions could still be useful, but maps and photos are inherently inaccessible.

03 Mar 2005 | Blah said...

Can you guys quit using the name "ajax" already. Sounds like you're making web pages with SOAP. Har har.

Seriously, quit it.

03 Mar 2005 | tlack said...

Check out my new toolkit for doing Ajax -- Sajax. http://www.modernmethod.com/sajax/ It's PHP only for now but I would love a Ruby+Rails backend

06 Mar 2005 | Currency Conversion said...

I'm worried about Safari support. None of the google stuff seems to work well in safari. I think this technique just can't be used widely until safari users can see it.

07 Mar 2005 | Anonymous said...

Google Maps works with the latest version of Safari. If you google for "XMLHttpRequest", the first link is to an Apple Developer article talking about how well it this stuff works in Safari.

07 Mar 2005 | tom said...

Really nice place u got here! Keep up the good work! Thank you for the info too!