Anyone doing serious Ajax development?

[roymond]

I'm curious where you are with it and where it's going. Also your resume.

Comet, SoftScrub and generic Bleach jokes appreciated

[Tonamel]

I'd be into ajax if I knew any web programming at all. I should really learn php and javascript sometime. Also possibly sql. I was going to learn ruby on rails, but it turns out the people hosting my site don't support it.

[mico saudad]

I'm curious where you are with it and where it's going. Also your resume.

Comet, SoftScrub and generic Bleach jokes appreciated

And of course slightly more obscure jokes about European soccer camps.

[bz£]

And of course slightly more obscure jokes about European soccer camps.

Yah, I bet I don't pronounce that word the same way Roy does
Ajax actually has one of the better football academies in Europe-- they do plenty of serious development.

[Lunkhead]

So far the most experience I've had with it was when I had to dig into an Ajax Jabber client (http://jwchat.org/) for work. Other than that I've done some dynamic loading of content into a div using dojo.io and some other XmlHttpRequest wrappers. I really want to try out more of the dojo toolkit, and script.aculo.us and prototype. I've also looked into the Ajax toolkit from http://www.zimbra.com and found it to be pretty overwhelming since they basically rewrote Swing/SWT in JavaScript and then some.

[jb]

how long before we see the first megabyte-sized ajax web page?

[Lunkhead]

I think it's still too difficult to code for that to happen anytime soon. At this point anybody who's willing to code up that much JavaScript, without the use of a good editing environment, which still doesn't exist as far as I know, would hopefully be smart enough (like the Zimbra people) to serve up their JavaScript compressed and gzipped. They manage to get their whole massive workgroup client down to 90kB I think they said or some reasonable size. Maybe when Ajax is a lot more accessible and just anybody can use it there will be more people who completely abuse it to make super-fat and/or uncompressed clients.

[jb]

The danger is more that, like standard desktop applications, libraries and pre-fab code bases will be thrown up willy-nilly without an attempt at optimization. Expediency rules. If you can download one Ajax page that lets you do everything you could do with 50 pages previously (like a gallery for example, loading pictures and captions), excellent. But if you have 90k worth of Ajax and you still load a new page for every picture in your gallery-- well obviously you're not using Ajax appropriately, but also you're ballooning your bandwidth and general congestion. All we need is that next-gen Geocities to let people do this and whoooo the bitching and moaning will commence.



I'm not complaining. Just speculating, based on a little experience with how things work on the Web.

[mico saudad]

Would you guys care to describe Ajax? I'd use W|K| but I know how we feel about that around here...

[roymond]

Obviously pedestrian Ajax will bloat and crash and everything else unguided consumer-produced garbage can do. But companies that implement strategic code refactoring and optimization achieve some amazing stuff. That's where I need to go with this.

AJAX is cross-browser-asynchronousrich-client-dynamic-HTML-client-server technology. Typically tricked-out javascript on the client talking to whatever on the server side.

Think Google: gMail, Maps, etc. are Ajax enabled web services that act like (sort of) desktop apps in their responsiveness and some of the interface abilities, which were previously unseen in web apps.

[Lunkhead]

What Roymond said. The biggest deal about it, I think, is that people can write code that makes your Web browser request some more content in a way that doesn't ncessarily cause the whole page to reload. So you can have a Web e-mail client, for example, that is all on one page which only loads once. All subsequent requests for new content are done in JavaScript behind the scenes, and JavaScript is used to update the already rendered page to display the new content, usually in a way that modifies only a small area of the screen. Or you can have a Web chat client that has some JavaScript that polls the server in the background to get IMs people sent you and display them in the appropriate chat windows. Really it's best used, I think, when trying to write a Web -application-, not a Web site. So most people won't really find much use for it on homepages [hopefully], or other sites that don't use lots of forms or other UIs for working with data/content.

The libraries can be several 10s of kB, and people can definitely include them and not use them properly. Some frameworks out there are trying to address that to some degree. The dojo framework provides a way to dynamically load just the libraries that are used on a page, rather than the whole API every time. Of course people can still misuse the technology. For now though I think it's too hard to use, so the people who won't use it properly probably won't use it at all, if that makes any sense.