Foundations of Ajax

Craig Maloney writes "You've no doubt heard about Ajax. Practically every new and exciting application on the web uses some form of Ajax. Google's suite of applications (GMail, Google Maps, etc.), Amazon's A9 search engine, and Netflix use Ajax interfaces to give the user a better browsing experience. By using some pretty basic innovations to current technology, browsers can now deliver content in ways unimaginable only a few short years ago. Foundations of Ajax provides developers who haven't taken the time to look into Ajax a hands-on guide for quickly leveraging these technologies in their own applications." Read on for Craig's review. Foundations of Ajax author Ryan Asleson and Nathaniel T. Schutta pages 273 publisher Apress rating 8/10 reviewer Craig Maloney ISBN summary A good first-look at Ajax and client-side development using JavaScript, HTML, and CSS.

Foundations of Ajax starts with a brief history of interactive web-applications, starting from the crudest CGI and Java Applets, and chronicling various interactive technologies (Javascript, Servelets, ASP, PHP, Flash, DHTML, and the various XML browser languages like XUL, XAMJ, etc.). Ajax seems like another acronym in a sea of acronyms, but the authors quickly point out why Ajax can help with the development cycle. Ajax allows the server to validate the user's input, without creating ugly and messy JavaScript validation rules, and it allows the server to use the same rules for input validation on both the client and the server. Unfortunately, Ajax does break some of the conventions users have grown accustomed to in using traditional web applications. XMLHTTPRequest requests aren't stored in the browser history, and it can be confusing to the user to determine what changed on the page after refresh. Issues aside, the book is very encouraging on the prospects of using Ajax in web applications, and invites the reader to use Ajax where it makes sense.

Chapter 2 talks about the request method that makes Ajax possible: XMLHTTPRequest (XHR). The XHR methods are explained with several examples that detail the fundamentals occurring with the request. The examples are very clear, and the entire process is laid out in careful detail, although the Dynamic Object Model (DOM) is mentioned, but not explained until the end of the chapter.

Chapter 3 delves into server communication. It's interesting to note that the authors haven't instantiated a server yet for their Ajax communication, and for the balance of chapter 3, the server is replaced by text files. It's not until the GET/POST examples that the authors start using Servelets. While it may seem strange for the authors to be talking about client/server programming without instantiating a server, it does allow the developer to get their proverbial feet wet without battling server configuration issues. The chapter starts by introducing innerHTML, but then moves to using XML DOM for data transfer from the client. From there, the authors demonstrate a few examples of the server sending XML to the client, and the client sending XML to the server. Happily, the authors weren't content to leave us parsing XML using JavaScript, instead they finish up the chapter by introducing the JSON framework with a few examples.

Chapter 4 is really where the book starts doing very interesting examples with Ajax. It's also, coincidentally, the largest chapter in the book, and the chapter readers will find the most useful reference examples. The book steps through the creation of examples of Simple date validation, Reading response headers for a simple ping application, Dynamically Loading List Boxes, Automatically Refreshing Pages, Progress bar (a personal favorite), Tool tips, Accessing Web Services using REST, and Auto complete. Each example is introduced with a real-world working application as an example (such as the auto complete feature of the Google search engine), and could easily be implemented in a developer's application. I found myself thinking of ways to enhance my code using these techniques.

Following chapter 4's examples, the chapters on creating a developer toolbox, testing scripts using JsUnit, and debugging Javascript seem a bit of a let-down. Chapter 5 outlines various packages for helping JavaScript coders to better spot errors in their code, and create documentation using the JavaDoc-like application JSDoc. There is also a mention of an application for crunching and compressing JavaScript code, as well as the excellent Web Developer Extension. Rounding out the chapter is a brief history of JavaScript, and some advanced JavaScript techniques. Chapter 6 introduces JsUnit and Unit Testing. Chapter 7 talks about JavaScript debuggers, such as Microsoft's Script Debugger, and the very powerful Venkman. The Venkman tutorial is very good, and would be a great starting point for anyone wanting more information on how to use this great tool.

Chapter 8 rounds out the book with the typical "for more information" sites to visit. However, in true Steve Jobs "One more thing" fashion, the authors not only plug their Ajax Framework, but also create a browser-based, Macintosh-like Dashboard application with four widgets. I was all set to finish the book, but the authors quietly slipped the best for last in the final pages of the book, bringing out a complete Mac OSX-like "Dashboard" windowed-environment in a browser complete with the drag-and-drop elements I've most associated with Ajax sites. This is by far the most complicated project in the book, and it make for an excellent ending to an already fine book.

Foundations of Ajax is a great starting point for developers wondering how they can incorporate Ajax into their own web-based projects. One minor gripe I had with this book was the examples looked pale in comparison with their real-world models, but design is hardly the focus of the book. Where Foundations of Ajax shines is it's no-nonsense introduction, implementation, and expansion of the basics of Ajax programming, leaving the reader confidently ready to utilize the concepts within. The authors have seen the potential of Ajax, and competently convey their expertise and enthusiasm for this technology."

You can purchase Foundations of Ajax from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Wow

[EraserMouseMan]

Not even one mention of "Web 2.0"!

Re:Wow

[Craig Maloney]

That was by design. I hate the term Web 2.0, and will personally spoon out the brains of anyone who uses the term with a straight face.

Re:Wow

[MPHellwig]

You've got my vote!

Re:Wow

[pHatidic]

Heh, I don't see why people have such a hatred of everything that can't be quantified. Just because it can't be measured, doesn't mean it doesn't exist.

Re:Wow

[Tumbleweed]

I hate the term Web 2.0, and will personally spoon out the brains of anyone who uses the term with a straight face.

Fantastic. What do you do to people who use the term Web 3.0?

Re:Wow

[Craig Maloney]

It's because it's used whenever the speaker wants to sound like they've got the inside track on whatever is new or exciting. Unfortunately it's been so overused when describing new and exciting things, it's lost all of it's novelty and excitement. Now, when I hear the term "Web 2.0", my "bullcrap" meter is engaged instinctively.

Re:Wow

[Misch]

I, for one, welcome our new brain spooning overlords...

Re:Wow

[jcgf]

They get the same spoon treatment, with the additional humiliation of being sodomized by a goblin.

Re:Wow

[Ingolfke]

Tim O'Reilly has the trademark on the phrase "Web 2.0".

Re:Wow

[Ingolfke]

I hate "Web 2.0" too. How can you simplify such a cross-section of intrensic and diversion paradigm shifts and technology consequence bubbles into a single simplistic phrase like "Web 2.0". Answer: you can't. We're at a major technoecosocial crossroads here... let's keep the plan flying, our eyes focused on the goal, and remember that doers do and winners win.

Re:Wow

[Anonymous Coward]

Need for clarification before you remove the spoon hanging on your nose:

Are you talking Web 2.0 as in:

1) Internet2
2) Google's project for a new Internet protocol
3) China's new Internet

We can't determine how much of a negative reinforcement your spoon happens to be until you make yourself clear.

Re:Wow

[hotfireball]

Goblin? You want to say _a troll_.

Re:Wow

[saltydogdesign]

Not even one mention of "Web 2.0"!

You can always count on slashdotters to shoot down anything that smacks of enthusiasm.

Re:Wow

[Sven The Space Monke]

Trolls can't sodomize. Their penises are too small.

Re:Wow

[hotfireball]

You're definitely mixing up goblins and trolls. Read the books of Tolkien. ;-) Trolls usually 6 meters high, powerfull and terrible. Goblins are small, green and funny.

Re:Wow

[Paradise Pete]

What do you do to people who use the term Web 3.0?

Obviously there won't be many, having had their brains scooped out during their Web 2.0 days and all.

Re:Wow

[jo42]

...that's because the people who are In are on Web 2007...

demo?

[Douglas Simmons]

could someone kindly link a page that demos ajax's features?

Re:demo?

[bryanthompson]

Google suggest is a simple one.

Re:demo?

[iluvcapra]

GMail and Google Maps are the obvious ones.

Re:demo?

[RoBorg]

Here ya go :D

World Airport and Airspace Database - Really cool if you like looking at aeroplanes and airports

GeoNews - News with geographical data - See global news feeds parsed for place data and plotted on a map.

Both these projects use Google Maps - the second one has a few special features added, like a custom zoom tool and locator beacons. I'm going to make the source available as soon as I neaten it up a bit and write some documentation.

Re:demo?

[Dionysus]

http://script.aculo.us/ has some interesting scripts (like drag-n-drop)

Re:demo?

[IAmTheDave]

To the author(s) of the book and everyone else - AJAX is an acronym, for Asynchronous JavaScript And XML (or more appropriately, Asynchronous JavaScript + XML). Unfortunately, the book does not recognize this.

More unfortunately, Adaptive Path, the coiners of the original term/acronym also do not.

Unless I'm missing something...

Re:demo?

[IAmTheDave]

Damn not previewing. My comment was meant to imply that BEING an acronym, AJAX should be in all caps, just like HTML, XML, etc. Not "Ajax".

Re:demo?

[Deinhard]

From a page on IBM Developer Works: "The phrase was coined by Jesse James Garrett of Adaptive Path ... and is, according to Jesse, not meant to be an acronym." (emphasis in the article).

Re:demo?

[shoolz]

Are you sure about it being an acronym? From the Adaptive Path site:

"Q. Why did you feel the need to give this a name?

A. I needed something shorter than "Asynchronous JavaScript+CSS+DOM+XMLHttpRequest" to use when discussing this approach with clients."

Re:demo?

[Anonymous Coward]

Any games here:
http://gamesbyemail.com/

In particular:
http://gamesbyemail.com/Games/Gambit/Preview
http://gamesbyemail.com/Games/WW2/Preview

Re:demo?

[IAmTheDave]

according to Jesse, not meant to be an acronym." (emphasis in the article).

It's nice if, in retrospect, you don't want a word to be an acronym, but as popular as certain words get, they are and will still be acronyms, like RADAR, which is often represented as "Radar" or "radar" in terms of capitalization in print media.

The fact is that AJAX (or Ajax) is in fact a direct derivation of the first letters of the words it represents, and thusly is, like it or not, an acronym. Further, I would think it improper to allow developers to use AJAX without understanding the actual underlying meaning. Many assume AJAX is just fun with DHTML, but it's not, and the fact that it is not is right in the acronym.

I guess since Jesse actually coined the term, he can turn around and say "nah, forget the acronym and just use the word" but it's a derivitive of the first letters of a phrase, and I'm pretty sure that's the basic definition of an acronym.

Re:demo?

[platos_beard]

If it was NOT meant to be an acronym, then where the hell did it come from?

Personally, I find Ajax just as annoying a term as Web 2.0.

Re:demo?

[70Bang]

Whatever is decided should probably be done in conjunction of the Ajax landsharks.

I'm surprised they haven't taken a stand on this and posted it on their web site.

Here's an example:

Hormel decided to decide how Spam and SPAM would be used +/- tolerated: SPAM Internet Site Terms.

Bottom line: Jesse may use one of this three wishes on this: (according to Jesse, not meant to be an acronym), but it may not come true.

Re:demo?

[Anonymous Coward]

How about this acronym? SYWAH: Shut your whining air hole.

Re:demo?

[shark72]

The journalspace fast media finder is yet another example. Start typing in the box, and watch what happens.

Re:demo?

[spells]

Further, I would think it improper to allow developers to use AJAX without understanding the actual underlying meaning.

Really? Improper? For a little perspective, we used to think that it would be improper to code in C if you couldn't write assembler. Suprisingly lots of people were successful at a higher level of abstraction without understanding the underlying structure.

Ajax is just a more recent example of the same phenomena. For now, it's important to understand the underlying technologies because the toolkits aren't robust enough yet, but eventually the majority of developers will simply use it as a basic tool without any understanding of the core technologies.

For the most part, they will be successful too.

Moving target

[fak3r]

While I appreciate this review, is the book really neccessary? AJAX moves very quickly, with new/better examples popping up everyday. Maybe it's me but I find less of a need for technical books and magazines since I can get all of my information from the internet. The personal example I'll use is Sys Admin; great magazine but I haven't leanred much from it during the last year. If I want to learn a specific server app or hack it's just easier and more up to date to grep it online.

Re:Moving target

[Stoolio]

Yeah, but reading from a book is easier than a laptop when you're on the toilet.

But you are right about how quickly books can become outdated.

Re:Moving target

[booch]

Call me an old fogie (I'm not THAT old!) but I prefer real books in a lot of circumstances. Especially when trying to get a full/complete understanding of a topic. Reading a few hundred pages on-screen gets to be painful on the eyes. And it's easier to take a book a lot of places - outside, on a plane during take-off, the toilet, on a date. ;)

Now if it were a reference manual, then I'd be more likely to agree. But even there, a lot of us like to lay the hard-copy book down on our desks while we program. Just last night at the local Ruby user group, the guy behind me pulled out his well-worn copies of the Ruby and Rails books. [Come to think of it, you were probably there -- I just don't know what you look like.] He even had good memory of where in the book and on the page the info he was looking for. Don't underestimate the mind's use of physical information.

Re:Moving target

[rs79]

"Call me an old fogie (I'm not THAT old!) but I prefer real books in a lot of circumstances.".

You're not old you just haven't gone paperless yet. It is difficult.

If you already know cgi programming and don't know ajax all you need is this:

Rasmus' 30 second AJAX tutorial.

It's just call back functions for the web; most good programmers could pick this up in an hour. I looked at the 30 second tutiorial and only needed to understand the syntax, it's obvious what it does. That took 11 seconds not 30.

Re:Moving target

[kimanaw]

As someone who's read the book (and previously commented on it here), this book is just what the title says, "Foundations". It is not a comprehensive analysis, nor does it attempt to lead the reader through graduate level UML and design pattern analysis like some other massive tomes. It delivers the basic concepts, shows a few nice examples, and provides lots of links to sites doing interesting things w/ AJAX.

So I'd say, yes, the book is neccesary. Rather than meandering all over the web trying to figure out "what this AJAX stuff is all about", you can grab this little book, have a nice quick afternoon's read, and then do a much more targeted browsing session to fill in the details. It certainly helped me bootstrap into developing AJAX applications.

Re:Moving target

[__aaclcg7560]

Some books are so quickly outdated that you can use them as toilet paper. Which is why I'm hesitant to spend $50 on toilet paper.

Re:Moving target

[Bogtha]

Please don't promote that awful tutorial. It makes two classic newbie mistakes: javascript: hrefs and browser detection. These are stupid and wrong. Yes, I know Rasmus is a hot shot PHP developer, but his Javascript sucks.

Re:Moving target

[booch]

I know Rasmus is a hot shot PHP developer

There's an understatement!

I don't find Rasmus' AJAX tutorial all that bad. His point is that it's not all that hard to do AJAX. I do agree that he's not up on the latest JavaScript best practices though, so he ends up doing JS things the wrong way sometimes.

Re:Moving target

[booch]

You're not old you just haven't gone paperless yet. It is difficult.

You make it sound like being paperless is the goal. I suppose that's a decent goal to have, in order to help the environment. But I have a bigger goal -- to read what I need/want, when and where I want, comfortably. And in many cases, books are still a lot better at meeting that goal. Granted, the Internet helps me achieve that goal a lot of the time, but not always. I'd consider going paperless a secondary goal for myself.

As far as Rasmus' AJAX tutorial, I think it's good for what it does. It shows you the very kernel of the AJAX idea, and shows you that it's not all that difficult. But a good book like the one reviewed (I've read about half of it) helps you explore more of the possibilities of AJAX. It covers different techniques you can use, pitfalls, best practices, many examples, use cases, etc. Comparing the 30-second tutorial to the book is rather simplistic.

Re:Moving target

[rs79]

Oh it's a shitty example. Maybe it's ad javascipt. That's ok I write terrible HTML. But it works. On all platforms in all browsers, even lynx.

It can't be that bad of a tutorial as I actually added Web 2.0 AJAX functionality leveraging legacy infrastructurte.

In other words I added a quick hack to an exising webware app of mine in under 5 minutes.

Sincerely,
Dilbert

Re:Moving target

[rs79]

"You make it sound like being paperless is the goal."

Well, it does save on ink.

When I learned this stuff (c/unix) there were no books, except the K+R books so I'm used to learing by hacking. I find books tedious and annoyingly slow. I can learn things faster by doing than reading and have been doing this long enough that I'm generally aware of common pitfalls.

Other than K+R 1st edition I did buy an O'reilly book once, for one page had some answers that at the time google could not produce.

I realize the book is probbaly great for a lot of people. AJAX seems to be the current buzzword in job ads.

Re:Moving target

[Bogtha]

These are hardly "latest best practices", they are well-established principles that have been around for the best part of a decade. For instance, here's a posting from 1997:

Ugh. Don't do that. Browser detection is a last resort. Always use object detection if possible.

Here's a posting from 2001:

Most experts recommend not using the pseudo-protocol "javascript:" for different reasons. There have been numerous discussions about this in this very NG

And another from 1999:

The practical side of the matter is that a page using that pseudo-URL in links fails miserably when JavaScript is disabled, and even on some JavaScript-enabled browsers which don't support that hack.

So it's best to use other approaches, such as a valid URL in HREF, with JavaScript code associated with ONCLICK and other event attributes.

I'm sure you can dig up more stuff, this kind of thing has been common knowledge since the mid-to-late 90s. Non-broken links and alternatives to browser detection aren't exactly breaking news, even if there are still plenty of people trailing far behind like Rasmus. His point that it's not all that hard to do Ajax is let down somewhat by him getting the absolute basics wrong.

Or, to put it into perspective: what's in his tutorial has been widely considered to be poor quality code since around the time that PHP/FI was just a couple of Perl scripts to do templates.

Re:Moving target

[Anonymous Coward]

but reading from a book is easier than a laptop when you're on the toilet.

You do your development while sitting on the toilet? Say, you don't work for Microsoft, do you?

So...

[Eightyford]

So, is there an IDE like Visual Studio for AJAX, or are we expected to wade through pages of HTML and Javascript like in the old days of the web? In my opinion, GUI applications are best developed inside GUI applications.

Re:So...

[Bovarchist]

Perhaps it is because I've been chained to MS technologies so much over the years, but my personal experience has been that GUI applications are best written by hand. HTML that is generated by the GUI in FrontPage is atrocious. DreamWeaver's code is much better, but still not as clean as what you can accomplish in VIM (or jEdit, notepad, etc.) And I've never seen anything that did better than DreamWeaver. I haven't had a chance to play with Atlas yet, but considering Microsoft's track record with HTML, I doubt it will produce clean code.

Re:So...

[Bogtha]

In my opinion, GUI applications are best developed inside GUI applications.

Ajax applications are not GUI applications. They are web applications, and the web isn't tied to a single type of interface.

People who pretend the web is GUI-only usually end up building things that are fragile and inaccessible, not just for the people who don't use GUIs, but power-users and people using alternative user-agents as well (e.g. search engines, UserJS/Greasemonkey scripts, etc).

Re:So...

[wjsteele]

Microsoft has a project called Atlas that does exactly that. Bill

Re:So...

[wjsteele]

Sorry, hit the damn Submit button instead of the Preview button.

The correct link is here: Atlas

Bill

Re:So...

[clydemaxwell]

Like visual studio? Thanks, I want to 1) understand my code and 2) have it work.
Ugh, fucking visual studio and fucking .NET programmers.

Re:So...

[killjoe]

An IDE for AJAX? Heavens no. Take the Ruby on rails approach. Try like hell to avoid javascript. ROR has it all nicely abstracted so you don't have to deal with javascript (mostly)

Re:So...

[MikeyTheK]

Yes, and it's called Morfik. You should join the Explorer's program and give it a try.

Re:So...

[Anonymous Coward]

Try TIBCO General Interface: http://ajaxian.com/archives/tibco-general-interfac e-version-31-professional-edition-released

It was developed using AJAX. It's the most cool AJAX application (Yes, I mean it's better than Google map).

I feel sorry for all the trees...

[helix_r]

I feel sorry for all the trees that have to be cut down needlessly so that developers can try to keep up with the latest crappy technology that will obsolete in less than 2 years.

On the bright side, at least its under 300 pages long.

Re:I feel sorry for all the trees...

[merreborn]

I feel sorry for all the trees that have to be cut down needlessly so that developers can try to keep up with the latest crappy technology that will obsolete in less than 2 years.

As if the 100 romance novels published every month are any more worthy...

Re:I feel sorry for all the trees...

[helix_r]

Romance novels...?

Yeah, but at least some people get off on romance novels. The same cannot be said for the computer-book-du-jour.

Re:I feel sorry for all the trees...

[merreborn]

Yeah, but at least some people get off on romance novels. The same cannot be said for the computer-book-du-jour.

Speak for yourself, you insensitive clod!

Re:I feel sorry for all the trees...

[revscat]

... and if they're getting off on romance books it's probably by themselves, which means they aren't breeding. Therefore romance novels are good for the environment.

Re:I feel sorry for all the trees...

[Anonymous Coward]

"Yeah, but at least some people get off on romance novels. The same cannot be said for the computer-book-du-jour."

Or can it? ;)

Re:I feel sorry for all the trees...

[hotdiggitydawg]

You must be new here.

Re:I feel sorry for all the trees...

[3mpire]

because once people have web apps that behave like client apps they'll decide "thats crappy" and go back to postbacks for every interaction with the server and all the developers who learned how to do things async will be kicking themselves. brilliant!

What level?

[danikar]

I know PHP/Javascript/HTML relitivly well. Do you think this book would be an easy read for me. Or would I really have to sit down and try. Heh, got the book for christmas and just looking for time to read it.

Re:What level?

[Craig Maloney]

I think the book may be more of a sit-down book for you, only because there's a bit of it that relies on Tomcat and JSPs. Outside of that hurdle, you'll likely find it pretty easy to work through. There's not that much to Ajax, all told, but this book will help you piece together the various parts to make it work better for you.

Hope this helps!

Re:What level?

[Parham]

I was in the same position as you... just read through online tutorials and you'll pick it up in a few hours. There's no need to sit through an entire book. With the tutorials you'll pick up the basics and then from there you can decide how much MORE you want to learn. I don't think most people want to get up to the google maps API level anyway.

see sig.

[SharpFang]

np

Re:see sig.

[Pollardito]

i've used that method and it will never be as popular as AJAX, because AJAX leverages everyone's love for XML. really it seems to work just the same, with the server sending javascript code and data structures instead of XML. be sure to add a random querystring value to the script call, or else you're going to get some monstrous caching issues :)

Re:see sig.

[ScottyH]

Interesting idea.

I'll be sure to give this a try.

Re:see sig.

[temojen]

or

doc = document.implementation.createDocument("","",null) ;
doc.onload = onload_function;
doc.onError = onerror_function;
doc.load("data/request.php?" + arguments + "&" + timestamp );

Which is the standards-compliant, non-crazy-scripty way of doing it. Also this method and yours SHOULD both respect the same-source rule. If it doesn't, it's a browser bug. Also, it won't display your data in the page by accident if you make a mistake in your stylesheet (class/name that's styled "position: absolute;" in your data).

Re:see sig.

[Bogtha]

Which is the standards-compliant, non-crazy-scripty way of doing it.

Actually, that's not true. The load() method was part of early DOM3LS drafts, but was taken out before the specification reached Recommendation status. As far as I'm aware, there's no non-draft specification describing load(), nor plans to write one.

XMLHttpRequest, on the other hand, is part of the draft "HTML 5" specification published by the WHATWG, and I expect it will remain there permanently.

Re:see sig.

[Anonymous Coward]

That should be "&", by the way, since you're banging on about standards.

Re:see sig.

[Vo0k]

And the "script injection" method IS standard-compilant as far as you believe in standards. Thing is "standards" don't equal to "perfection", standards have their own errors too.

Standard specifies you're allowed to insert any DOM element at will, and makes no special exceptions for "script." It makes lots of assertions about cross-window, cross-frame etc scripting, about limits of what can you do with elements inherited by inserted elements etc, but in normal conditions you're free to load a script from an arbitrary site, and there are no assertions making inserting DOM elements anything "not normal".

It's abusing a hole in the specs, because "script" elements should be treated differently than others and follow different rules when created upon document creation than when inserted through DOM methods - but there are no exceptions and inserting a script is just the same as inserting anything else. The browser support is there (MSIE requires "DEFER", but that's about all). Specs say "all elements" and make no exception. So let's live happily and use the godsent feature not caring that it's a bug.

Re:see sig.

[saltydogdesign]

Yeah, but no built in support for errors or callbacks.

Re:see sig.

[Anonymous Coward]

Assuming you meant to write "&" but screwed it up, you are wrong. Presumably you got told to escape your ampersands so that your HTML was valid at some point, but you failed to understand why.

Ampersands need to be escaped when they appear in HTML because the ampersand is a special character to HTML. The code above is not HTML. The code above is Javascript. You don't have to escape ampersands in Javascript.

If you actually escaped that ampersand like you suggest, you'd fuck up the code and it would break, because it would be asking for a non-existent resource. Please understand what it is you are talking about before trying to correct somebody.

Re:see sig.

[tbmcmullen]

The problem with using bugs.... is that bugs get fixed. (Sometimes)

Re:see sig.

[larry bagina]

depends if your javascript code is inlined or in a its own file. If it's inlined, the "proper" solution is to put it in a CDATA section.

Re:see sig.

[NickFitz]

It's

document.createElement("script")

There's no such method as

createNode

in DOM (which, contrary to what the reviewer says, stands for Document Object Model, not Dynamic Object Model).

Re:see sig.

[Bogtha]

And the "script injection" method IS standard-compilant as far as you believe in standards.

Um... as far as I believe in them? Is their existence in question?

It's abusing a hole in the specs, because "script" elements should be treated differently than others and follow different rules when created upon document creation than when inserted through DOM methods

That's your opinion. But how is it "abusing a hole in the specs" to do something according to spec and have it work according to spec? <script> elements contain Javascript that is parsed and executed, you add a <script> element and it is parsed and executed... seems fairly straightforward to me.

You might argue that it shouldn't do that, but the spec doesn't say that it shouldn't be done, you say that. And with all due respect, your opinion is hardly normative.

Specs say "all elements" and make no exception. So let's live happily and use the godsent feature not caring that it's a bug.

It works exactly as it's supposed to. That's not a bug.

Re:see sig.

[Vo0k]

Do you believe in Apocrypha? Apocrypha exist.

you add a script element and it is parsed and executed... seems fairly straightforward to me.
Except the specs came to lengths to prevent this kind of behaviour in cross-domain linking. You can't perform xmlHTTPRequest for a website other than the one the page is loaded from. You can't do shit to a DOM tree of a document in other frame/window. The specs' intention of preventing ability to dynamically load scripts from sites other than where the page comes from seems obvious. You can statically include a "foreign" script upon loading the webpage and then that's the end. You can't change src of existing script. (actually you can, but the new script won't load), you can't perform live request to download XML data. You can't access data or scripts in frames you've dynamically (or statically) loaded. There's a lot of safeguards against cross-domain scripting. But inserting a new "Script" element isn't protected in any way and you can do far more serious changes to the page (document, scripts, browser settings etc) using it, than you would if cross-site xmlHTTPRequest was legal.

It works exactly as it's supposed to. That's not a bug.
So disabling/limiting cross-frame scripting, cross-site scripting, preventing loading data from other sites, these all are bugs then? Because they stand in direct opposition of this idea. It's a gaping hole in what they try to prevent.

Re:see sig.

[Bogtha]

Do you believe in Apocrypha? Apocrypha exist.

Please be more clear. This is the second time you've skirted around what you are trying to say here without coming out and saying it.

Except the specs came to lengths to prevent this kind of behaviour in cross-domain linking. You can't perform xmlHTTPRequest for a website other than the one the page is loaded from. You can't do shit to a DOM tree of a document in other frame/window.

So? There's a huge difference between XMLHttpRequest, iframes, etc, and dynamically added Javascript - iframes, XMLHttpRequest, etc, can access content. You can post forms in iframes and with XMLHttpRequest, so you can take action on behalf of your visitor if cross-site scripting was allowed here. You can access whatever information your visitor can access if cross-site scripting was allowed for XMLHttpRequest and iframes.

Dynamically added <script> elements can't do either of these things. You might as well claim that dynamically added <img> elements are a mistake because they can access things on other domains.

you can do far more serious changes to the page (document, scripts, browser settings etc) using it

You've misunderstood the purpose of the specs in preventing cross-site scripting. It's not to protect the site that is doing the inclusion, it's to protect the visitor and the site that is being included. The fact that a script is able to include another script that can drastically alter the page is outside the scope of the cross-site scripting protection that the specs provide. It's a fundamentally different thing.

I fail to see why you are making the distinction between dynamically added <script> elements and static <script elements anyway. Either way, they've got to be added by the site owner, and either way they are just as powerful. It seems more like you are looking for an excuse to label dynamically added external scripts as wrong rather than anything else.

new and exciting apps on the web?!?!

[Anonymous Coward]

"Practically every new and exciting application on the web uses some form of Ajax"

There are new and exciting apps on the web? Wow must have missed them.

Chinese pee

['aspies' are retards]

Chinese pee tastes like math.

Re:Chinese pee

[Paradise Pete]

Chinese pee tastes like math.

So then what does Chinese Pi taste like?

If AJAX is so amazing...

[Anonymous Coward]

why doesn't Slashdot use it? Eh??

Re:If AJAX is so amazing...

[Perl-Pusher]

The slashdote code base is too old but, there closest competitor uses it! According to this digg has almost the same traffic as slashdot.

Re:If AJAX is so amazing...

[__aaclcg7560]

Because the Slashdot community already suffers from enough "bleeding edge" technology as it is. Besides, there's no Perl in AJAX. :P

Re:If AJAX is so amazing...

[SanityInAnarchy]

AJAX isn't bleeding edge, and even if it was, the slashdot site itself is the farthest thing from it. It's legacy.

And the server-side part of AJAX can certainly be Perl.

yep, its a good book

[DeveloperAdvantage]

I have actually read/worked through this book and indeed it was not only one of the first books on Ajax but also one of the better books on Ajax. Some of the portions are now a little outdated, like the discussion on frameworks, but these areas can easily be filled in with a little research on the Internet.

Ajax vs. Comet

[revery]

I personally, use Comet, but only because it has a cool song

Oh, that Ajax.

Nevermind...

Re:Ajax vs. Comet

[AnonymousPrick]

I've been trying to see if there was a website for the language, you know like Perl, PHP, etc.... This is what I found: A political site?

Re:Ajax vs. Comet

[Anonymous Coward]

I was initially thinking of Javex, but it could have been Borox (20 mule team). Instead we have Comet and Ajax. Cool, clean sparkling technology!

It's a conspiracy!

[AnonymousPrick]

The lumber industry, paper mills, and O'Reilly publishing are all it together! Create a new programming language and Presto! More revenue for all!

Re:It's a conspiracy!

[merreborn]

The lumber industry, paper mills, and O'Reilly publishing are all it together! Create a new programming language and Presto! More revenue for all!

That explains the book on slash...

Re:It's a conspiracy!

[__aaclcg7560]

Microsoft is the worst. When I was working at Atari, whenever a new XBox standards document was released, every person working on an XBox project printed them. Seems like every month we were going through 50 reams of paper until the document started coming out less frequently.

I totally agree.

[C10H14N2]

Like, this one, perhaps.

Re:I totally agree.

[ScottyH]

Correct link

Effective Ajax Using TG

[hauntedspaceship]

Some of you might be interested in a recent Presentation / Screencast given by Kevin Dangoor (creator of the TurboGears Python web framework) given at this year's Pycon. Although he does talk a bit about TurboGears, most of the talk is tips and examples on how to add functionality using Ajax without confusing users.

Re:Effective Ajax Using TG

[Anonymous Coward]

Forget AJAX, AJAJ is the future!!!

Only Web 2.0 Idiots...

[Anonymous Coward]

would say those pages use AJAX. Most of the people involved in coding the sites listed are probably not lame enough to use that term. They probably just call their collective code a "web site" just like the rest of us who are sane (or insane but still coherent enough to despise the terms AJAX and Web 2.0) would call it! That's what we get for letting mcse's become "programmers"... sigh. Welcome to IT Hell 2.0.

Save $5.60!

[Anonymous Coward]

Save yourself $5.60 by buying the book here: Foundations of Ajax. And if you use the "secret" A9.com discount, you can save an extra 1.57%!

Re:Save $5.60!

[fbg111]

Save yourself $5.60 by buying the book here: Foundations of Ajax [amazon.com].

Muchos gracias.

And if you use the "secret" A9.com discount [amazon.com], you can save an extra 1.57%!

Appreciated, but...

from A9: You can save an additional 1.57% (/2%) on virtually all your purchases at Amazon.com by simply becoming a regular user of our search engine at A9.com and on A9.com. Once you use A9.com for a few days you will be eligible for the A9 Instant Reward.

I'm not so easily bribed... at least not for a measily 1.57%. And even if I was, the patheticness factor of this 'marketing' scheme would outweigh the savings anyway.

Off Topic

[TubeSteak]

But is something going on with the moderator points? Or is it just a slow day (or three)?

I noticed all the stories have very few comments modded to 3 or above. And by few I mean 20. Just skip through any of the articles on the front page.

Did I not get the memo?

Re:Off Topic

[donnz]

I'd mod you up but this new AJAX interfac /. has adopted seems quite buggy ATM

Re:Off Topic

[PavementPizza]

I've been asked to meta-mod twice in three days. That's kind of strange.

Re:Off Topic

[supahdren]

I agree. It's really annoying, too.

Re:Off Topic

[PavementPizza]

OK, now it's the third time in three days that I've been asked to metamod. The earliest moderation that I was asked to review is from December 9th! Really weird...

Re:Off Topic

[PavementPizza]

Moderator purge in progress?

Too bad they didn't use Ruby on Rails...

[tcopeland]

...InstantRails makes it easy to get it up and running, and Rails definitely has AJAX support built in.

I'm using AJAX a fair bit (mostly on the admin pages) on getindi; it's very handy stuff!

Re:Too bad they didn't use Ruby on Rails...

[monsterzero2002]

InstaRails eh? But go follow the link at it says Windows only and linux etc. on the way? What kind of sick project starts with the Windows version first? Smell a rat...


"Anything worth doing is worth overdoing..." - Lord Chesterson

Combine both....

[k1980pc]

I would like to see an application that can work online and offline with same ease. We, at my firm, had tried an app using java which worked standalone when network was loaded and became online when there was less congestion. Our internal network was so slow that the application was standalone most of the time. That was India and year was 2000. Now Ajax looks like a good solution for a long forgotten problem.

that word, are you sure you are using it correctly

[pyrrho]

"... deliver content in ways unimaginable only a few short years ago"

but, but, I remember imagining it. I remember it all over the tech press... and those guys that wrote the technology, they -imagined- it! For GOD'S SAKE WE ALL IMAGINE THAT SHIT!!!!

coming soon?

[slo_learner]

There is supposedly going to be an eclipse plugin. http://www.eclipse.org/proposals/atf/

Ajax is suboptimal

[Anonymous Coward]

Posting anonymously since it's about my work; I've moved from doing Javascript in the late 90's early 2000's to working with Flash, and now recently back to mostly Javascript with the Ajax market boom. The reason I moved to Flash in the first place is more clear now than ever. The "Browser" ad hoc platform is horrible to develop for compared to Flash.

Inconsistent support for "Standards" across browsers, weak development tools, and worse support for Accessibility all make Ajax a freakshow. Flash is a bigger more consistent platform (more people have Flash than Ajax capable browsers) with good tools. There are Open Source Flash dev tools, but the Adobe ones are good enough to rapidly earn their cost back in productivity gains.

I understand that people are excited about Ajax, Google's apps are cool, but the fact that this excitement never translated to Flash, which has had similar cross-platform capabilities for about 5 years now shows that technological decisions aren't made on a technical basis alone.

Re:Ajax is suboptimal

[Craig Maloney]

I think there's two reasons why people are so excited about Ajax. The first reason people are so excited about Ajax is because it doesn't require anything extra to make it work. Flash requires not only the plugin (which admittedly is pretty ubiquitous out there), but also requires a development package that isn't cross platform (at least I'm not aware if there's a Linux version of the development tools). Ajax allows the neat features to come through without having to resort to Flash. The second reason Ajax has caught on is server-side validation rules can also work on the client. One set of rules = no more trying to wrestle Javascript to do proper validation. For me, that's a huge win, as I'm no fan of Javascript.

Re:Ajax is suboptimal

[Anonymous Coward]

The "it needs a plug-in" argument is moot to me, in part because of Flash's great ubiquity, and in part because a lot of Javascrpt is now focusing on Ajax and DHTML. (I've gone to more than one person's "cool Ajax website" and had it not work in my browser at all. Sometime's they're doing something IE specific, sometimes something Firefox specific. Pfeh)

Yeah, the professional Adobe development tools aren't on Linux, but the open source ones are. Also, I don't know of anyone who does professional client side web development that develops on anything except Windows or OS X. Server-side yes, client-side no. I'm sure there are people out there who do, but I've never met them.

Server side validation isn't unique to Ajax, as I mentioned in my original post, Flash has had the features that make Ajax be Ajax, instead of just Javascript, for 5 or 6 years now.

Also, while I'm ranting, I think the browser developers, Mozilla in particular actually, are acting irresponsibly and restarting the bad parts of the browser wars. They're starting to try and compete on features again, adding in non-standard optional elements. I think we've seen that this is a war we can't win while Microsoft controls the default browser for the majority of users. The loss will be felt by web developers, in the form of many many lost hours spent making their pages "cross browser compatible".

Re:Ajax is suboptimal

[Bogtha]

Your premise - that developing Ajax web applications is harder than developing Flash applications - doesn't support your conclusion - that Flash is technically better.

You are assuming that Ajax web applications and Flash applications are of a similar quality - they are not. Flash applications are essentially executables that you are handed, with no choice but to run them or not run them. Web applications are documents linked together, with stylesheets to suggest a presentation and script to suggest an interaction model.

These two approaches are totally different. As a user-agent not only understands the final product, but the individual components that a web application is comprised of, it has much better opportunity to work with those components. This means that browser features that users are used to and expect to work do not break. There's a wide range of browser features that are broken in Flash applications that are not (necessarily) broken in Ajax web applications:

• Opening links in new windows
• Opening link in new tabs
• Find and Find-as-you-type
• UserJS/Greasemonkey
• Printing (it was only a couple of hours ago I read a warning not to use my browser's Print button, but instead, the special Print command that Flash provides)
• Various Firefox extensions
• Right-click, "Search web for..."

If you think that it's easier to develop something in Flash, then fine. But don't pretend that what you end up with is of equal quality. You end up with something very different to a web application, so whether the quality is higher or lower depends on your particular circumstances, and cannot be generalised to the extent that you do.

Re:Ajax is suboptimal

[Anonymous Coward]

executables that you are handed, with no choice but to run them or not run them.

If Javascript isn't executable code what is it? I've seen exploits that use Javascript, but never one that uses Flash.

Almost all those features you list are things that could be broken in Ajax depending on how it's coded and could be allowed in Flash depending on how it's coded. (Someone could develop a Greasemonkey type tool for Flash, but no one has for example, and standard printing does work in Flash, but the app you were using probably had some special print formatting that the person wanted.)

Honestly, Javascript + HTML and Flash are very similar in structure, but Flash has more features, works better cross-platform, and has better development tools. Also, it can create lower-bandwidth content (there are many options for binary data transmission) and it has built in handling for MP3s, movie files, timed animation, and resolution independent display.

Having worked in both there are 3 arguments for Ajax 1)Cellphone development 2)Existing Skillsets [we already know Javascript] and 3) Dogmatic open standards talk. The dogmatic one is really hard to swallow anymore when everything Ajax is based on an ad hoc "non-standard" standard. (The everyone emulate Microsoft standard.)

Re:Ajax is suboptimal

[Bogtha]

If Javascript isn't executable code what is it?

Yes, and if web applications were made up of nothing but Javascript, then you might have a point. But they are not. Javascript is just one non-essential component.

I've seen exploits that use Javascript, but never one that uses Flash.

Flash vulnerabilities certainly exist.

It seems you've assumed that my problem with it being a chunk of executable code is one of security. This is not the case. Given executable code, you've really only got two options - run it or don't run it. Given a series of documents in a well-understood format, with a bit of executable code on top, you can do all sorts of things without having to execute the code.

Tim Berners-Lee described this as the Principle of Least Power, and he was spot on. When you decompose something into simpler pieces that can stand alone, you enable greater functionality. Separating the content from the presentation from the behaviour, like HTML, CSS and Javascript do, it means there's a very low barrier to entry for manipulating that content. When you bundle it all back up like Flash does, it means there's a much higher barrier to entry.

Almost all those features you list are things that could be broken in Ajax depending on how it's coded and could be allowed in Flash depending on how it's coded.

This is not true. All the things I list are browser features that work in Ajax web applications because they build on the browser's basic data formats. All the things I list break in Flash because Flash throws away the browser's basic data formats and uses its own.

You could replicate similar features in your Flash applications, and many people have made various attempts over the years, but they are always cheap knock-offs that never work quite right.

For example, when a link is clicked with the middle mouse button, what should your Flash emulation of my browser feature do? In Firefox on my workstation, that should open in a new window. In Safari on my laptop, that should open in a new tab. If I'm in Windows, it should switch on autoscrolling. What is your Flash application going to do? If it does anything, it's going to be wrong in two out of three cases, and if it does nothing, then it's going to be wrong in all cases. Meanwhile, an Ajax web application works perfectly because the link is a normal HTML link that the browser understands, rather than a viewport into an external application that it has no understanding of.

Yes, it's possible to break such things in Ajax web applications, but they work by default with no extra code. But it's impossible for Flash applications to work correctly in this way.

Someone could develop a Greasemonkey type tool for Flash

Yes, but my point is that Greasemonkey doesn't work. Greasemonkey works with Ajax applications because they are using the browser's native formats and objects, not ignoring them. And a thousand other extensions are exactly the same. And extensions that will be dreamt up next week and implemented a month from now will be the same. Are you going to anticipate all of these extensions and features and build them into your Flash application as well?

This isn't about one particular feature. This is about features in general being built to work with the web, and breaking because Flash ignores everything that has gone before it. It builds a slick little presentation layer into a viewport that is only accessible in a web browser because that's the most convenient way for Macromedia to deliver Flash applications to people.

Honestly,

Re:Ajax is suboptimal

[Anonymous Coward]

The reason the 'excitement' never translated is due to many issues:

1. it relies on a plugin; if you don't have the plugin, you don't have the flash.
2. in the world of limited download bandwith, it takes a heck of a lot longer to download flash-based content than the simple html with ajax.
3. initially the tools needed to develop for flash were only proprietary; anyone can be up and running w/ ajax without any upfront cost.

Had flash (plus it's basic development toolset) been open source from the get-go, ajax wouldn't have gotten off the ground and we'd probably all be looking at a flash-enabled slashdot.

Re:Ajax is suboptimal

[Anonymous Coward]

I think we're talking past each other on a few points here. For example, when I'm saying that HTML and Flash are similar, I'm saying that they're both tagged formats that use ECMAScript to manipulate a DOM. Flash is delivered as Binary (hence the lower bandwidth), whereas HTML is plain text.

HTML is really piss poor as a data format. It's been used more as a presentation layer and even with the XHTML + CSS approach data and presentation are effectivly bound. (Yes, people use semantic names for their XHTML elements, but it doesn't mean anything when people develop everything independently.) Ultimatly, we're seeing the data move to web services where it can be reliably be understood. If data is to be manipulated by end users this is where it should happen, not through interface hacks like Greasemonkey.

Also, I'm thinking you don't actually develop Ajax applications, do you? Opening a new window and new tab are broken by default in Ajax because all the links make Javascript function calls for XML transfer instead of opening new pages. Go to Gmail right now and try to right click on some of this blue underlined text items on the left. Can you open them in a new window or tab? I sure can't. They look like links but the behavior is broken. If you want to make right clicking and middle clicking work you would have to find a way to program it in.

Ajax is used to create rich interfaces. It has all the inherient problems that Flash has had in the past, but Flash has taken steps to fixed a large number of those problems. (Accesibility is the major one.) HTML is used a method for data display and Flash is used as a method of data display (it can consume web services, you know) and in almost every way I can think of Flash is a better choice.

Re:Ajax is suboptimal

[LordLucless]

Flash is pretty much a way of embedding an executable in a browser. AJAX is a buzzword for using javascript to manipulate the layout and contents of a page; the two are not directly interchangable.

If I were to be given a choice, I'd develop in Flash over "AJAX" any day. No issues with browser sniffing, cross-browser glitches, or the debugging hell that comes bundled with complex javascript apps. But there are some things you can do with javascript that you simply cannot do with Flash. And there are degrees of "AJAX" - in a number of my sites I've used a single call to XmlHTTPRequest to send data contained in a page to the server without changing the page the user is on. Trying to fulfil that requirement by redeveloping the whole site in Flash is overkill.

Re:Ajax is suboptimal

[Bogtha]

HTML is really piss poor as a data format. It's been used more as a presentation layer and even with the XHTML + CSS approach data and presentation are effectivly bound.

If this were true, then browsers like Lynx, JAWS and IBM Homepage Reader would be impossible. Content and presentation are clearly not bound together as tightly as you claim.

You might consider HTML to be a poor data format, but that doesn't change the fact that it's as close to a native format for the web as there is, with practically everything on the web hooking into it in some way. The same can not be said of Flash.

Yes, people use semantic names for their XHTML elements, but it doesn't mean anything when people develop everything independently.

That's so vague as to be meaningless. An HTML element means the same thing regardless of whether people develop everything independently or not. The meaning of HTML element types are defined in the HTML specifications. Can you clarify what you meant here?

Ultimatly, we're seeing the data move to web services where it can be reliably be understood. If data is to be manipulated by end users this is where it should happen, not through interface hacks like Greasemonkey.

This makes no sense. Web services are a way of accessing and manipulating data on the server. Greasemonkey is a method of accessing and manpulating the data in the browser. They are solutions to totally different problems. You can't do the things Greasemonkey does with web services and you can't do the things web services do with Greasemonkey.

Also, I'm thinking you don't actually develop Ajax applications, do you?

Wrong.

Opening a new window and new tab are broken by default in Ajax because all the links make Javascript function calls for XML transfer instead of opening new pages.

No, some web applications do that, because there are a lot of clueless web developers around. The problem isn't caused by Ajax, it's caused by web developers who don't know what they are doing.

When you say "all the links make Javascript function calls", that's simply not true. Ajax is a method for communicating with the server. Depending on the application, it might not involve links at all. Even if it does, the correct way of handling that is to provide a normal HTML link, and hook into the onlick handler. "Broken by default" is plain wrong because if there is such a thing as "default" with Ajax, it would be a plain HTML link.

Go to Gmail right now...

GMail sucks. Look through my posting history, you'll see I've posted your exact complaint about GMail's links before. Don't assume that because GMail is fucked up that everything using Ajax is fucked up too. Google are very good at interfaces, very good at server-side architecture, and astoundingly bad at writing HTML, CSS and Javascript. The problem you are seeing with GMail wasn't caused by Ajax, it was caused by a Google developer screwing up.

Like I said, with Ajax web applications it's possible that things can be broken (as with anything), but with Flash, it's a given.

If you want to make right clicking and middle clicking work you would have to find a way to program it in.

Simply wrong. Anybody the least bit familiar with Javascript knows that you just have to return true from the click handler to have the browser's default behaviour kick in. And you only have to do that if you hook up a click event in the first place.

Ajax is used to create rich interfaces. It has all the inherient problems that Flash has had in the past

No, it doesn't, because it work

Re:Ajax is suboptimal

[neuroinf]

As a user of Yahoo's mail beta, which seems to be based on Ajax, I was enthusiastic. But! such are the delays inherent in the current incarnation of the Web, that this approach is much hyped and absolutely doomed to failure. Contrast Google Earth with Ajax stuff. It is absolutely almost impossible to use. I gave up on it. Memo: the Internet is "best effort", which means that delays are unpredictable. You cannot put this in a GUI loop.

Re:Ajax is suboptimal

[Anonymous Coward]

Had flash (plus it's basic development toolset) been open source from the get-go, ajax wouldn't have gotten off the ground and we'd probably all be looking at a flash-enabled slashdot.

Probably not - we aren't looking at an AJAX enabled Slashdot.

Re:Ajax is suboptimal

[tbmcmullen]

...What? Google Earth is impossible to use? My 15 year old brother doesn't seem to have any problem using it quite fluidly. AJAX is doomed to failure? Its been in use for over 5 years... which is a pretty good chunk of time considering the age of the internet.

Re:Ajax is suboptimal

[larry bagina]

it doesn't require anything extra to make it work.

Except javascript, XMLHTTPRequest support and cross-platform scripting to handle IE DOM wackiness.

Sure, you can gracefully degrade, but Flash is just as ubiquitous and works the same everywhere.

Re:Ajax is suboptimal

[Anonymous Coward]

1. 97.7% of internet users have flash installed, more than have an ajax-enabled browser.
2. binary flash files can be (and often are) compressed and are generally smaller than a similar collection of html, css, javascript, and images.
3. Valid point (1 out of 3, at least you're not a total failure).

Yet Another Buzzword

[nganju]

All "Ajax" means is that Javascript now works. I used to accomplish the same tasks (i.e. asynchronously send/receive bits of data, dynamically update tables without refreshing the whole page) using hidden frames and javascript submits back in 1999. Javascript now has built-in functions to do this so it's less of a hack, but I don't think that it merits a whole new buzzword.

Then again, I guess it's something for new startups to tout and investors to latch on to, so maybe it's more of a business/marketing buzzword than a software/technology buzzword.

Re:Yet Another Buzzword

[tricorn]

Yeah, this was hardly "unimaginable" a few years ago. It was more like "what do you mean, none of this stuff really works the way it ought to?"

AJAX is just a hack on top of a kludge to try to make a stateless batch protocol into a persistent interactive "experience". HTTP works fine for what it was designed for, HTML works fine for what it was designed for, AJAX reminds me of the classic Yiddish joke about the tailor:

Schlumpf the tailor made a suit, but one sleeve was longer than the other. To the customer's complaint, he replied "Just pull your shoulder up a little, and then the sleeve will be okay." But when he pulled his shoulder up, the back of the suit hunched up a bit. The tailor said, "Just bend over a little to one side, it will be fine." So as the man walked away, two women observed him shuffling along, his shoulder and back hunched, bent, contorted. One said "Oh that poor man, but what a lovely suit!" The other replied, "Yes, it must have been made by Schlumpf the tailor, only he could make such a nice suit to fit a cripple like him."

Re:Yet Another Buzzword

[saltydogdesign]

Yeah, I was doing pages on paper way back in 1984, and now we've got to go calling it "the web." Goddamn buzzwords.

Seriously, everyone here clearly understands what is meant by Ajax, and it's less clunky than "asynchronously send/receive bits of data, dynamically update tables without refreshing the whole page," so I can't complain. You, however, are welcome to bitch until the cows come home.

"... deliver content in ways unimaginable only a"

[Anonymous Coward]

Someday we may even be able to open whole applications and graphically view them on a remote terminal!!!! The past is the future can you say X-windows?

I don't want to "leverage" it

[grasshoppa]

I want to use it.

Damn marketing driods

Re:I don't want to "leverage" it

[ukpyr]

while in spirit I agree with you, to me 'leverage' has a somewhat different meaning than to 'use'. Leverage implies that you are able to something faster/better/cheaper by using it, where as 'use' doesn't have that extra meaning. At the same time, I acknowledge that it doesn't really matter and saying 'leverage' all the time makes you sound like an overpaid consultant. Not that it's bad to be one.

I've read this book and...

[LaptopHeaven]

I picked this book up on my last trip to Vegas. I read it cover to cover. I found it to be on the elemtary side of the AJAX discussion. I was disappointed when I found most of the content, code examples and demos can be found online in different places. AJAX is just a hot topic right now, I find this book as an attempt to ride the coat tails of the AJAX phenom.

Re:I've read this book and...

[geekoid]

You went to Las Vegas, and rad a book, cover to cover?

No wonder hookers and strippers hate geek conventions.

Dude, what happens in Vegas stays in Vegas.

Re:I've read this book and...

[Anonymous Coward]

"Dude, what happens in Vegas stays in Vegas."

People who perpetuate lame marketing campaigns in daily conversatoin are fucking morons. I hate you.

Re:I've read this book and...

[larry bagina]

his name is KY Geek.

OK book

[wanorris]

I have this book. It's a pretty straightforward introduction to the topic. The central problem with it is that all the examples that use server-side components only use Java.

If you use Java, great. But the book title is misleading, and it should be called "Foundations of Ajax in JavaScript and Java."

The other caveat: the book is designed for people who want to use Ajax to spruce up an existing web page a little, not design new applications built from the ground up to use Ajax as the data transport mechanism. If this meets your needs, great. If you're looking to do bigger stuff, get "Ajax in Action" froom Manning.

Re:OK book

[lobohombre]

I completely agree! The book was NOT about foundations of ajax. It had more to do with firefox, java, and other utilities than it ever mentioned about ajax. Maybe the book would have been too small and the publishing company would not have published it. I think you could certainly learn what you needed to learn about ajax from the web and not this book.

Gecko DOM Reference

[Kozz]

I also recommend that you check out the Gecko DOM Reference. It's a great, handy online resource which I've consulted frequently as of late for many DHTML apps and functionality.

Re:Gecko DOM Reference

[AKAImBatman]

Well there's a bad idea. If you want your code to be cross platform, always go to the source for your information. Otherwise you're guaranteed to get burned. It's bad enough that Internet Exploder refuses to support DOM Events. Throwing stuff that may be Mozilla specific into the fray is a sure-fire way to make it that much worse.

"What is AJAX" for beginners

[Anonymous Coward]

Here is goes: AJAX is a techology, supported by some major sites (Mozilla, google, etc), which tries to counterpart Macromedia. Macromedia has been the best solution to dynamic content. It makes a GUI inside your browser. Netscape, google and a few others feel that Macromedia is becoming too powerful. So they are trying to come up with an alternative.

That's why AJAX was made (and hyped so much). In Reality (TM), AJAX is nothing new. It is based on the crap language called Javascript (which is a huge succes because it is supported by all web browsers and as a result it's the most PORTABLE language of all times). XML, the other hyped technolody which is just an inefficient way to transfer data (but this is counterparted by the amazing JSON innovation). And "Asynchronous". "Asynchronous" means that your browser sends data (files, passwords) to the internet without synchron.

Ever wondered why Mozilla doesn't have a "turn off all ads" button?
Because it can afford being the only browser which can support all these crazy extensions (Web2.0, AJAX, css2.0, XHTML7.5, ...), without competition. And thus you suck the ads. Keep up the hype.

Re:"What is AJAX" for beginners

[kiddygrinder]

I redeclare your name to be "Smacktard".

Hmm, what worries me

[Anonymous Coward]

How much does this book's approach to AJAX depend on writing Javascript? I have a good deal of experience with Javascript, and frankly, I'm sick of it. Javascript's constant browser incompatibilities are simply more than I can deal with. AJAX seems like it would allow one to avoid many of Javascript's problems by moving logic into the server, but it also seems like it is an invitation to have to write a program on the server side and then have to debug it at every step on four different browsers on two different operating systems. If AJAX suffers from the same compatibility hell I have seen with trying to write CGI with embedded javascript in the past, I am tempted to just wait to get into this AJAX thing until "rails" style libraries become robust enough that they generate browser-specific javascript for you.

I'm curious about this book, but to what extent must someone overcome crossbrowser javascript hell in this book's approach to AJAX? Is this material I would benefit from learning despite my acquired Javascript aversion?

Thanks.

Re:Hmm, what worries me

[ScienceofSpock]

I don't know about the book, but If you use DOM based javascript, the browser compatibility issues all but disappear. I'm writing an AJAX based multiplayer RPG using php and javascript, and, if I remember correctly, the ONLY bit of code I had to write for different browsers was for keypress events.

Incidentally, you are correct in that AJAX allows you to move a signifigant portion of your logic to the server and avoid some javascripts shortcomings.

AJAX? that some new thing?

[Theatetus]

Is it good or is it wack?

Re:AJAX? that some new thing?

[linguae]

Ajax is great! It cleans my hands, is tough on grime, and makes my dishes sparkling clean.

Over and over again...

[Anonymous Coward]

You've no doubt heard about Ajax. Practically every new and exciting application on the web uses some form of Ajax.

Not this bullshit again!

Mod Parent Off Topic

[Anonymous Coward]

Mods obviously have nothing better to do.

Re:Django vs TG vs RoR

[Anonymous Coward]

I'm thinking about investing a bit of time to learn one or two of these frameworks. Learning Ruby on Rails is pretty much a given just because of the mindshare it has. But I prefer Python over Ruby because of the vast array of libraries available for Python, so I also want to pick up a Python framework. Django and TurboGears seem to be the leading contenders. Can you tell me any reasons why I should pick one over the other? They both seem to be relativly new and under rapid development. Neither seems to be clearly ahead in the marketplace. Any reason to pick one over the other?

Too bad ...

[Kozz]

Too bad that "the source" is a very poorly structured website IMO where I can never find what I want. I guess I just didn't try hard enough, but I couldn't find a comparable page at W3 as the DOM index I linked at Mozilla.org. I don't want to know the fucking history, recommendations, all that bullshit. I want real information that I can take and use, right now. Where's the "pocket reference" pages?

Am I the only one who thinks it's difficult to use the W3 site as a general programmer's reference for anything at all? Whenever I think to myself, "Gee, I'd like to do this the right way, and conform to W3 'standards'", I get lost at W3 and go elsewhere for the Cliff's Notes version.

Re:Too bad ...

[tb3]

Yeah, seconded. I find myself going to www.w3schools.com to look up the stuff I've forgotten. The only thing worse than w3c.org is Sun's java.sun.com. That thing is a complete mess.

Re:Too bad ...

[AKAImBatman]

If you can't click on "DOM Level 2 Core" and then click on "ECMAScript Bindings", you've got problems.

As for those "Recommendations", that part just happens to tell you what's here already and what's still in the works. But go ahead and write five versions of your code. (IE, Mozilla, Opera, Konqueror, Safari) Less competition is a good thing for me. :-)

Unimaginable?

[hikerhat]

I think it is more like, when using AJAX, user interfaces are slowly creeping back up to where they were 10 years ago, before everything was crippled to work as a web form in the lowest common denominator browser. Web interfaces still have a hell of a long way to go before they are even close to the level of sophistication that rich clients were at 10+ years ago. Everything that is new was old once before.

I have been wondering that too

[badriram]

Even really busy threads like the Vista wont suck had really few comments modded up. I think it has been just the last couple days too

Simple samples with readable code

[wysiwia]

Some very simple samples but with understandable code, just go to

http://wyoguide.sourceforge.net/test/tree1.html
http://wyoguide.sourceforge.net/test/tree2.html
http://wyoguide.sourceforge.net/test/tree3.html
http://wyoguide.sourceforge.net/test/tree4.html

try them out and view the source. For more info go to http://dojotoolkit.org/

O. Wyss

shut the fuck up

[Anonymous Coward]

http://fuckweb2.com/

DOM

[tamnir]

Dynamic Object Model!?

Re:DOM

[Anonymous Coward]

All Ajax needs to be is dynamic. So, as they see fit, Documents are now dynamic.

Re:Off Topic (Mod Parent Up)

[BRSQUIRRL]

It is offtopic, but it is the first comment I've read wondering what is going on. I've noticed this as well. Have fewer users been given moderator status lately or something?

"New" and "exciting", eh?

[HorsePunchKid]

Practically every new and exciting application on the web uses some form of Ajax.

If by "new and exciting" you mean "redundant and obnoxious", then yes. Yes they do. So much for being able to browse information in a way that I dictate; now I'm subject to the whims of some insane application living inside my web browser.

If that's what it comes to, why not just stick with Flash? At least with Flash, it doesn't take a dozen images and pages of CSS to effect a rounded rectangle! (This may be an exaggeration!)

Re:"New" and "exciting", eh?

[saltydogdesign]

Ok, let's consider an example: Google Maps. Are you suggesting that Google Maps prevents you from browsing a map the way you dictate? What exactly was it about MapQuest that was so flexible? Look, Ajax at its worst is no better than Flash at its worst, but at its best it provides *more* options, not fewer. And without the performance hit of reloading a page header and a bunch of navigation over and over.

Me thinks his knee jerketh too much.

Re:"New" and "exciting", eh?

[HorsePunchKid]

Google Maps is a fantastic application of AJAX, most definitely. I wouldn't have written this map module for Gallery2 if it did not rock my tiny world.

Keep in mind, though, two things. First, Google Maps is the exception to the rule in terms of the tradeoff between usefulness and complexity (in the sense of lacking a reasonable degradability for browsers without the necessary functionality). Second, imagine how much better Google Maps would be if it didn't have to be crammed into a browser.

Re:"New" and "exciting", eh?

[saltydogdesign]

I have to disagree on a couple points. First, I don't think it's the exception at all. I'm not going to provide a list of great Ajax applications, as that's been done a million times on Slashdot. What I have *not* seen is a reasonable list of Ajax failures. I am inclined to believe that a lot of criticism of Ajax is merely theoretical.

As for Google Earth v Google Maps, sure Google Earth is an interesting app. Is it a better app? Well, not really in terms of usefulness. Most of the time if I'm looking for an address, it's much easier to go to a web address than it is to launch another app. Then too, if you want to talk about excess, how about the time you spend waiting for Google Earth to zoom in on a location? How about the degradability you value? Will GE run on a machine that won't support Firefox? (And I'd should point out that GE doesn't do maps, at least the OSX version doesn't. Nor does it do directions. And it doesn't have a nifty API that allows people to make their own variations.)

Quite frankly, pretty much any information could be better "if it didn't have to be crammed into a browser." I like reading a book or a magazine better than reading a screen. However, that magazine isn't available everywhere, on every computer, all the time. Try going down to your local library and installing Google Earth on their machines. Ain't gonna happen. The reason all this functionality is being added to the browser is because the browser is convenient. I don't buy the notion that the browser will become people's entire OS, but if you think of the internet as being a big computer, which, in a sense, it is, then the browser is the UI. And like any UI, it needs to be capable and flexible, which is what we're seeing here.

Re:"New" and "exciting", eh?

[HorsePunchKid]

My (unfortunately implicit and unobvious) point about Google Earth was that for the amount of effort they went to to make this gigantic, snazzy application (which you rightly point out will not run everywhere!), they could have made a smaller, slicker application that bested Google Maps on every front except possibly ubiquity.

Many of my concerns with AJAX are not inherent to it; they are problems inherent to any software development. Hence the analogy to Flash. As a specific example, Flash provides all sorts of features for accessibility: I should be able to use a well-written Flash app very easily; the app should integrate seamlessly with my browsing. However, this takes a lot of effort, and (in my experience) practically no developers are willing to make this effort.

Hence my concern (one of them, at least) that AJAX will turn into yet another platform for the development of unintuitive, inconsistent interfaces. I am curious if anyone is working on a decent set of libraries for performing standard AJAX tasks (along the lines of this, which has been making the rounds recently).

Re:"New" and "exciting", eh?

[greywire]

There's this: http://openrico.org/rico/home.page and this: http://script.aculo.us/ which are based on this: http://prototype.conio.net/. Neat stuff and easy to use..

Issues with AJAX

[Anonymous Coward]

AJAX is nice and very handy. But I have already seen problems. Especially with Gmail. I replied to an e-mail message and clicked send. At the same time my Gmail notifier told me that there was network problems and Gmail just sat there with the red message up in the top "sending". After 10 minutes of waiting I clicked stop on the web browser and refreshed my In-box. The message showed up in the in-box but the actual message was never send and the recipient never received the e-mail. But ofcoz if they used Forms and CGI then it might never worked right either. Network issues will always exists, but can AJAX notice this and fail when it should?

Re:Issues with AJAX

[larry bagina]

No... you could have a timeout error (I think gmail does), but you're not interacting at a low enough level to know if the data was received and processed. (in this case, if the email message was actually sent). That problem is the same with forms and cgi though.

Re:Off Topic (Mod Parent Up)

[TubeSteak]

It's funny that the Quote of the Day @ the bottom of /. is

Conway's Law: In any organization there will always be one person who knows what is going on. This person must be fired.

JsUnit and AJAX don't mix!

[Darkforge]

I had originally picked up a copy of this book because it appeared to be the only book on the market that spent any time discussing automated testing of AJAX components.

As I'm sure you all know, testing AJAX stuff in multiple browsers is really important if you want to guarantee cross-browser compatibility; it's also really tedious. JsUnit seemed like it would be a promising tool for AJAX automation.

In fact, I'm sad to say, JsUnit can't be used to validate AJAX components at all; in fact, it can't it be used to validate *any* command that requires a callback, including XmlHttpRequest, event handlers, pop-up windows, etc.

This is because browsers (IE/Firefox both) interpret JavaScript in a single thread, but actions you perform may have asynchronous side effects OUTSIDE of your own thread. So when you attempt one of those fancy asynchronous XmlHttpRequests, you can't just sleep/wait until your request finishes, because it will *never* finish until you completely return from your current thread. Only then will the interpreter begin working on the next item in the event queue.

That means, among other things, that it's impossible to wrap an AJAX request in a "try/catch" block:

try {
      doRequest();
      waitForRequestToFinish();
      assertRequestWasSuccessful
  } catch (e) { // do something }

Because this will never work, JsUnit's strategy of emulating JUnit or the other *Unit frameworks is fundamentally unsuitable for testing AJAX in multiple browsers.

If you *are* interested in testing AJAX applications in multiple browsers, I recommend looking into Selenium, which basically works around the problem by constantly scheduling timers to re-invoke itself every 10ms... that gives the interpreter enough time to do other work, and allows Selenium to implement a simple "pause" action that actually works.

Ajax is not always great!

[unholy1]

Sure, AJAX is great for certain applications and under certain conditions, but there are always a few downsides / problems. Check out the blog entry by Harry Fuecks for some links to good presentations describing the negative aspects of AJAX.

Annoying maybe...

[patiodragon]

...but, unlike Ajax, Web 2.0 is not STD (Stronger Than Dirt!).

Unimaginable?

[JacobO]

By using some pretty basic innovations to current technology, browsers can now deliver content in ways unimaginable only a few short years ago.

Wha? I happily admit that we've seen some pretty cool uses of the available technology in recent times, but I've personally been doing what is now known as Ajax for at least 5 years.

Would people please stop taking all the fun arcane stuff and wrapping up in media-friendly (and code monkey friendly) parcels?

Now a good chunk of my fun work will be replaced by some company's "Ajax Framework", just like web services and HTTP replaced roll-your-own network protocols, and Windows replaced custom GUIs.

Re:Django vs TG vs RoR

[Anonymous Coward]

I think that TG is all around more Pythonic than Django. It incorporates many different successful Python projects, whereas Django rolled their own (Templates, ORM, Controller, etc.). Not that that's a bad thing, but TG does enjoy quite a few benefits by building on other successful projects (more eyes looking over the code, more people interested, more developers). Also, the TurboGears development process was opened a lot earlier than Django, so there is more community involvement, more developers, and more activity, even though it has been around for less time.

Some of TG's key features like the Toolbox, Internationalization (adm18n), Model Designer / Browser, Identity, template plugins, etc. are a direct result of close community involvement. On the Django side, their "Magic Removal" branch is a result of late community involvement, which is only now "removing warts that Django has accumulated over the years". Similarly, Django devleopers have said their architecture is loosely coupled, but some things (e.g. the templating system) are still not easily swappable. TG definitely is designed to work closely with the main components, but some developers prefer different things, so there is a layer of support for different templates (Cheetah, Stan, ZPT, etc.), and recent work has been done to get an SQLAlchemy compatibility layer for people who don't like SQLObject.

Either way, 2006 will be the year of Python web frameworks (I would even go as far as saying that Python will leapfrog the RoR hype), with TG and Django both experiencing a lot of maturing as they reach 1.0 and beyond. Also, recent developments in WSGI and standardization between Python web frameworks means it will be easy to switch between Django/TG/etc and build apps out of reusable pieces, no matter what framework they were originally written in.