Ajax in Action

Simon P. Chappell writes "There's always a danger when a new technology buzzword hits the ground running. The danger is that when it finally slows down enough for us to take a good look at, it'll be found to be empty hype with less value than a mime performance on a radio show. This time the buzzword is Ajax and it's moving so fast that you can almost hear the sonic boom. The authors of Manning's new Ajax in Action have managed to catch up with Ajax long enough to take a look at it for us. Their book explains what Ajax is, how to use it and how, for once, the hype may be underselling the prospects for this new buzzword." Read on for Simon's review. Ajax In Action author Crane, Pascarello with James pages 650 (16 page index) publisher Manning rating 9/10 reviewer Simon P. Chappell ISBN 1932394613 summary If you want to create dynamic web applications, get this book.

The majority of the book is for programmers engaged in the development of web applications; especially those who are interested in taking their applications beyond the traditional ``click and wait for the response from the server'' model that we've become accustomed too.

The first section, and particularly the first chapter, would be suitable for anyone who is curious about Ajax. The first chapter answers the questions of what it is, and why it deserves all of the positive press that it's received. If you're introducing Ajax at work, this might be the chapter of recommended reading for your managers and software architects.

Alright, enough introducing the book, now let's take a look at just what Ajax is. Ajax itself is an acronym created by Jesse James Garrett in his, now classic, article Ajax: A New Approach to Web Applications. Ajax, we are told, means Asynchronous JavaScript and XML. This is our first clue that Ajax is not a single, new thing. Ajax actually turns out to be a combination of existing technologies mixed up in a fairly new way.

The fundamental ingredients in Ajax are in-browser JavaScript, Cascading Style Sheets, the browser's internal DOM model and asynchronous HTTP requests. Ajax, the technology, is the amalgam of these individual technologies. Thus, Ajax is both new and well proven at the same time.

Perhaps it's also possible to view Ajax as the natural resting place of the pendulum of application development. Programmers, since the beginning of application development have been trying to balance user experience and ease of installation and maintenance. First we had mainframes with their centralized usage model. Next we got the PC with it's entirely disconnected usage model. This was followed by the Client/Server model that tried to be connected yet offloaded it's processing to the client. The world wide web came next and browsers as the ultimate thin clients forced all of the processing back onto the server again. Finally now, with Ajax, we have what seems like a good balance of server side processing, with responsive clients that provide the rich user interface that users want. The pendulum of centralized versus decentralized has found it's rest point.

The structure of the book is fairly standard. The first section, three chapters, concentrates on imparting the concept of Ajax to the reader. The first chapter begins with the concepts, chapter two takes the reader through some very simple first steps, while chapter three explores how the Model View Controller pattern (MVC to it's friends) applies in the Ajax world and looks at third party, free and open-source Ajax libraries available today.

Part two of the book explores the core techniques of Ajax. Chapter four explores the difference between a web application and a desktop or Ajax application, that of a single page being the entire application. Chapter five explores the role of the server, looking at what resources are available for the server-side coding, including available languages and frameworks as well as ways and means of exchanging data with the server.

Part three looks at what the authors call ``Professional Ajax'', the techniques that make a difference when creating real world applications. Chapter six covers the design of the user experience. The user experience for a major application basically is the application for the user and so getting this right is of fundamental importance. Chapter seven explores security and some of the actions that the developer can take to both ensure access control and protect confidential data. Once the basics of Ajax are mastered, this may well be the most important chapter in the book. Chapter eight covers performance and what can be done to assist application speed and resource usage in practical use. Perhaps the most important measure for an Ajax application is the perceived speed and responsiveness that it delivers. The asynchronous processing is a huge factor in achieving these user perceptions.

Part four shows Ajax by example, with four chapters of example applications and a fifth chapter addressing building stand-alone applications using Ajax.

There is much to like about this book, but top of the fold for me is the clear and concise explanation of just what exactly Ajax is and why it has the power to make a difference in the web application arena. At a time when more people speak of Ajax than actually understand it, this book has the power to bring forth understanding.

This is a very dedicated book. It takes no time to teach the reader the individual technologies that compose Ajax, rather it concentrates on using those technologies. If you do not know JavaScript, or Cascading Style Sheets or do not understand the W3C's DOM model or asynchronous messaging then you would be better served at this time by learning the individual technologies and saving this book for after you've mastered them.

Other than the standard book page over at the Manning website, there is no dedicated book website. This is perhaps unusual, but 30 seconds on your search engine of choice should get you started. Failing that there is a good Ajax page available at Wikipedia.

This is a magnificent book. Not because it's well written and has good example code in it, although it is and it does. Rather, it is magnificent because of the high speed target that they have accurately hit and described in a clear and hype-free fashion; for this the authors are to be commended. If you want to create dynamic web applications, get this book."

You can purchase Ajax in Action 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

AJAX explained...

[nother_nix_hacker]

No need to buy this book. Just consume one of these and you will awake the next morning know how to use javascript and XML in unison to produce yet another del.icios.us clone!

http://www.cleansweepsupply.com/pages/skugroup1068 .html

I think I buy into this "ajax" thing

[gtrubetskoy]

Paul Graham's got an opinion on Ajax in his Web 2.0 essay.

I too initially thought "What's the big deal, it's just JavaScript". But I'm now actually reading the "Ajax in Action" book, and it looks like there is something to it. It's not so much about the tools you use (which are indeed JavaScript and CSS pretty much), it's more about the architectural view of the application, where you think of the browser hosting your application rather than content and the server produces data rather than content and how Ajax coding is not just get-the-javascript-to-work-and-move-on like in the old days, but rather not unlike any other language, requiring same level of discipline.

Anyhow, the book explains it better, I recommend it.

Re:I think I buy into this "ajax" thing

[AKAImBatman]

I too initially thought "What's the big deal, it's just JavaScript". But I'm now actually reading the "Ajax in Action" book, and it looks like there is something to it. Anyhow, the book explains it better, I recommend it.

You make it sound so new and mysterious.

AJAX is simple. We now have a cross-browser method for making server requests in an asynchronous fashion. Combined with the fact that the demise of Netscape 4 means that we can finally code for the DOM, and you've got a recipe for success. It's not anything magical or mysterious. In fact, you could do it with hidden IFrames long before AJAX even became a buzzword. The key is that it's useful and semi-standard. Which means that we can finally deploy all those cool web apps we've wanted to deploy for years but couldn't.

Re:I think I buy into this "ajax" thing

[OakDragon]

One of the nice things about AJAX is that it just absolutely blows people away. The click, they expect a page load or a refresh. But it's just there. It really breaks the user's image of what is about to happen. It allows web applications to transcend the "toy" level, just a little.

Imagine Slashdot never re-loading a page. We could watch as posts spring into existence in real time. A little spooky, if you ask me. :)

Re:I think I buy into this "ajax" thing

[arkanes]

where you think of the browser hosting your application rather than content

And this is where you go wrong, and why AJAX sucks, and will continue to suck - web browers are (fundamentally) shitty application platforms, for very important reasons that will not go away. The future of web applications, the future where they don't totally suck and aren't jury rigged one-of inconsistent half-assed things, is in specialized thin clients.

Re:I think I buy into this "ajax" thing

[CastrTroy]

This is what bothers me a little bit. Sometimes when I'm at a web page that uses Ajax, I'm expecting the page to refresh, or do something else when I, say, click on button. Sometimes you don't even notice stuff happening, and you're sitting there waiting for some page to load, that is never going to load. I know how the web works, so I expect things to happen a certain way. When pages use AJAX, they change the way things are done, and start to confuse those that really know what's going on.

Re:I think I buy into this "ajax" thing

[arkanes]

Netscape didn't believe that,

And they were wrong, too, and so was Microsoft. They were worried that Java appletts, of all things, were going to kill the desktop OS. Wake me up when that starts happening - and it had a much better chance than AJAX does.

Google doesn't seem to believe that it's a terrible platform either.

Thats why Google Earth is an AJAX application, right? Except it's not. And Googles applications, while good and certainly groundbreaking in terms of web applications are nothing compared to the state of client applications, even years ago. The UI features Maps and GMail lack are too many list here - and they are extremely suited for deployment on the web. Spreadsheets, and even word processing, not so much.

So..

[PhrostyMcByte]

I guess we are in for a much cleaner internet?

Re:So..

[Tumbleweed]

I guess we are in for a much cleaner internet?

Yeah, but it's gonna smell like a hospital.

Intersting book site

[smittyoneeach]

My only disappointment was that the popup on mouse-over didn't say "Hello, world", which would've been funny on a couple of levels, and opted for something practical like telling you how to BTFM.

Feyenoord Ajax

[Anonymous Coward]

I have used this idea Ajax and I found the alternative Feyenoord to be superior in every department. However there is worse to be found on the market, after trying out PSV Eindhoven I demanded my money back.

Can AJAX finally bring us "push technology"

[DeadSea]

Could we finally get push technology with AJAX?

I'd like to have the following, all of which have been cumbersome and refreshy to implement in a web browser so far:

• A news page that I can leave open and automatically gets new stories added to it without refreshing. (CNN that I can leave open and know that stories will apper within a minute of them being posted)
• A stock ticker that is always up to date. (Yahoo finance that I don't have to refresh)
• Weather forcast and current conditions that change in real time.
• Some way to glue all of them together into the same page ala RSS

Re:Can AJAX finally bring us "push technology"

[arkanes]

No. AJAX, for all it's hype and buzz and crapola, does not fundamentally change the client/server nature of HTTP and the web. AJAX applications that load data do it by polling, exactly the same as meta refresh tags and timer-based javascript refreshes have been for 10 years.

Re:Can AJAX finally bring us "push technology"

[CastrTroy]

You really can't do "push" with webpages, or their data. You could make something that looked like push, but in reality is actually just polling. The problem with this is that AJAX is supposed to reduce the amount of traffic to a website. If you have users constantly polling you for information, you're going to increase your load. I guess it would be better than polling and getting an entire page every time. We'd need to change the way AJAX works in order to get something that was truly "push".

Re:Can AJAX finally bring us "push technology"

[jd142]

I think you can do all of these things since you can have javascript in a while loop/sleep or whatever and then every x number of seconds have the javascript call the function to update the page. I don't do a lot of client side programming, precisely because I can't guarantee what's on the client, but javascript should be able to do that.

The examples you have here though can also be handled by a meta-refresh. Unless you wanted different sections of the page to update at different intervals. So that the stock is updated every second, the news every 30 minutes, the weather every 15. Then unless you set the meta-refresh to the lower time, ajax would work for these things.

You could also be really old school and use frames with meta-refresh.

Although I will confess that I have only started with ajax, it seems to me that it is better suited to apps that are also passing client side input or changes.

But I could easily be wrong.

Re:Can AJAX finally bring us "push technology"

[_xeno_]

Nope. Push is dead, NAT killed it. (Well, a whole bunch of things killed it, but essentially you can't connect back to a client any more, and there are a whole host of reasons why you generally don't want to leave connections open.)

However, you can do what email clients have done for ages: poll. And that's what things that emulate what you're talking about essentially do.

Essentially, with AJAX, you'll have some JavaScript program that uses the good ol' window.setInterval to poll the server every five minutes or so. It gets back an XML document that contains a list of changes, if any, to the page you're looking at. If the data has changed, it then uses the DOM to alter the page to display the new information.

Effectively, though, it's just a page that refreshes automatically via JavaScript. Because it can pull back an XML document, it doesn't have to download ALL the HTML stuff to get the data. Because it's in the background, it doesn't have to "destroy" the page to load the new information, allowing it to be added to an existing page in a seamless manner.

It's really nothing new, exactly, it's just that the most popular browsers (Internet Explorer, Firefox, Opera, and Safari) all support XMLHttpRequest in some form now, making it feasible to use it without cutting out some section of your user base. It's just message passing in JavaScript.

Re:Can AJAX finally bring us "push technology"

[TheRaven64]

NAT didn't kill push. Push technology is very possible using XMPP, rather than HTTP as the presentation layer. You build something like XMPP Publish-Subscribe on top of it, and then plug in a browser. The browser sends your JID to the server (or a proxy JID if you want anonymity) and subscribes to the pub-sub node relating to the page / web app. Every time the server wants to send to some information, it can. You keep a TCP/IP connection to your XMPP server open while you are online, and the web server can connect to this and send you data in the form of XML stanzas. Then all you need is a Javascript (or whatever) onXMLRecieved() function that takes the new XML and applies it to the DOM.

I saw a proof-of-concept demo of this over a year ago. It would be nice to see it integrated into Mozilla...

Re:Can AJAX finally bring us "push technology"

[doublec]

Yes and No. One approach is to use have the client initiate an AJAX request to the server but the server does not send data immediately. It delays until there is stuff to push. It can either continue to push as needed (I send Java which gets evaled by the client) or it can close the connection and have the client re-connect. It then goes back to the delayed response.

This is better than client polling in that it's not so bandwidth unfriendly. It has the downside that browsers only have a limited number of connections that it uses and this eats one of them up (Some versions of IE only use 2 connections). This could prevent other AJAX or normal HTTP requests from occurring.

The same problem exists with the 'hidden IFRAME' approach. One interesting workaround is to have a hidden flash applet on the page whose sole purpose is to create a persistent connection to the server. The server can send data to the flash applet which then calls javascript callbacks on the web page. This does not eat up a browser connection as flash has its own connection pool. As it's a normal socket you can also use any protocol for the events you want. The downside is that if the user goes through a strict firewall that only allows outgoing http traffic on port 80 you're stuck.

I describe some of the options here: More on Ajax and Server Push

Paul Colton, the author of the AFLAX library, implemented the persistent socket idea here: AFLAX and Persistent Connections. It uses AFLAX which allows easy communication from Javascript to an embedded flash applet.

The approach I've gone for is to use the flash idea, falling back to a delayed AJAX call response, then to a hidden IFRAME depending on browser support. This approach does what you want - allowing the server to push to the client.

Re:Can AJAX finally bring us "push technology"

[John Hurliman]

That whole technology relies "You keep a TCP/IP connection to your XMPP server open while you are online", which is already doable with HTTP. The client makes an AJAX call to the server, and if the server has data to return it sends it back immediately, otherwise it waits and holds the connection open until $TIMEOUT. If $TIMEOUT is hit it sends a "no data" message to the client, and the client reconnects again each time. This is how http://www.meebo.com/ implements pseudo-push to create the webgaim bridge, and apparently it scales up to the tens of thousands with a few decent servers, but not sure how many users each machine can effectively support.

One day IPv6 will solve all this, and I can have news pushed to my browser in my flying car. Until then polling and pseudo-push seem to work all right.

The book

[dantheman82]

I ordered it recently from Bookpool.com and although they claim that it's out of stock, I still ordered it and recevied it not too long after. Otherwise, if you'd rather get it a little sooner, try out Amazon.

Also, a very interesting resource is available through Pragmatic Programmer, a beta book which means you can get PDF updates as they are written until it is shipped in hard copy in Feb. 2006. Already a book of 160+ pages, they already had a section on creating your own version of Google Maps (and more relating to SAJAX and other PHP implementations). The beta book, while only a little extra, is highly recommended!

Free AJAX T-Shirt!

[ChaserPnk]

OK, I know this isn't much of a deal, but it's still good if you buy a lot of books. If you buy AJAX in Action and another Manning book from major bookstores, you'll get a free AJAX T-shirt. A list of bookstores has been posted.

I don't work for Manning, but I'm so in love with their books. The Java GUI programming book alone is worth a million to me. I refer to it almost everyday. I've looked at similar O'Reilly books and they don't even come close! I'm about to purchase Manning's .NET book pretty soon as well.

Happy reading.

Read the FAQ

[nizo]

...mime performance on a radio show...

If you are having mime problems perhaps this will help?

Re:Good read so far

[RetroGeek]

The central idea behind Ajax is pretty good IMHO- moving as much of the presentation-tier processing as possible to the client system.

Which to me sounds like a stab at re-inventing Java applets.

All the problems you describe (name spaces, libraries, etc) are already solved in Java. In addition, you are not at the mercy of browser JavaScript bugs.

The only downside is the initial startup time for the Java applet, as the local JVM must be loaded, THEN the applet.

As for the JVM version, you can check for this in your applet before you start the dependant code, and you can ask the user to d/w the JVM.

The technology Java Web Start provides an easy to use framework.

Javascript namespaces

[brunes69]

"Namespaces in Javascript are dead simple, because of function scoping:

window.MyNamespace = new Object() {
function NamespaceMethodA() {
// alert('hi');
}

function NamespaceMethodB() {
// do b code...
}
}

NamespaceMethodA() // Causes exception

MyNamespace.NamespaceMethodA() // works.

Want to "import" a namespace? Include this function in one of your base .js files

function import( namespace ) {
for( i in namespace )
window[i] = namespace[i];
}

You can now do import(MyNamespace) and all it's members will be locally scoped.

The problem in Javascript is not namespaces - it is the fact that there's no way to mark a method/variable as protected/private. So you need to resort to old C-style crap like appending _ to private members if you want to enforce your contracts.

Compatibility

[kstumpf]

AJAX represents a new paradigm in UI design for web applications. I don't think there's much question about AJAX's value. You will see two problems though: 1) browser compatibility, and 2) bad code and interface design.

You have to think hard when deciding if your client base is ready for it. The same browser issues exist with AJAX that exist for any other "new" client-side technology. By relying on it, you will exclude visitors.

As for my second point, get ready for a lot of bad AJAX. People have a hard enough time designing interfaces as it is (think of all the bad ones out there), and building dynamic ones that work like people expect them to will be that more complicated.

See it in action on Yahoo Mail Beta

[gasmonso]

If you're fortunate enough to see it in action on Yahoos's new email, you will be impressed. You can take a look here http://www.ajaxian.com/archives/2005/09/yahoo_mail _beta_1.html.

gasmonso http://religiousfreaks.com/

Re:Good read so far

[TWooster]

Well, if you're running web applications, a good bit of IP is in the code, which is client visible. I suspect the best way around all of this is to develop a strongly typed language which compiles down into javascript. Javascript then becomes the intermediate language rather than first-crack. Additionally, the compiler can name variables and functions things that have no relation to the underlying logic of the code, making it much more painful to reverse engineer. (Much like reverse engineering a .NET program, except skipping the translation into human readability.)

Additionally, you could compile with optimizations to meet the capabilities of different browsers. Hell, toss in a little bit of encapsulation in the language "libraries" to avoid all of those layer/div issues. Etc, etc.

Javascript is good at what it does, it just wasn't meant to do quite that much.

Also, anyone wonder why there isn't a "valid CSS" to "IE broken CSS box model" translator? Maybe I ought to write that...

Real-world usage

[m2pc]

I am a developer for a huge PHP/SQL project and we are creating our 2nd generation system using AJAX. As a server/client developer this technology is allowing us to create a much better user experience.

I agree that AJAX has its downfalls ("back button" breaking, JavaScript usage, etc.) but most of these issues are present in "web sites" not "web applications". With a real Web Application, you have more control over the user in terms of requirements, etc. than a public web page.

To get around state change issues, we designed the system to load initial state values on page-load, then update page elements dynamically with AJAX. This cuts down on travel time to/from the server, and if the user hits the "Refresh" button, the state isn't broken.

Re:Good read so far

[jenkin sear]

Right- that's my point, actually.

Your cold fusion code is now acting an application tier language- it receives a simple query (give me the answer to my FAQ question number 3), and it queries the DB, formats the result as XML, and goes back to sleep.

However, a classic cold fusion site handles the page layout, loads in whatever resources are appropriate for that locale (english, german, japanese, whatever), queries the database, formats the results as a bunch of table tags, and outputs everything.

So you've effectively split your tasks into three tiers- presentation tier (in javascript), application tier (in cold fusion), and data tier (mysql or whatever). You're using cold fusion as middleware- I'd suggest that this is a fine strategy for a one or two developer site, but that you may wish to look to a more maintainable / suitable language for middle tier development- but that's just my $.02.

If it doesn't focus on the technologies being used

[Tetravus]

it's useless.
AJAX is a simple concept. Really, it is. Getting three different coding paradigms to work together harmoniously is not so simple. Throw in available AJAX libraries, JSPs and Atlas pages and you've got layers upon layers of coding cruft that need to be understood before a functional, stable, web-app can be built.

If this book stays at the architecture astronaut level without ever delving into the why of the code structure of the example programs, then it may serve as a cookbook but certainly not as an informative manual that can provide a baseline from which coders can build their skills.

Perhaps the book is better than the reviewer makes it out to be, but he offers no real justification of the 9/10 score awarded, so it's hard to say. Just for giggles, I should note that when Richard Stevens' seminal Advanced Programming in the Unix Environment, 2nd Ed. (being possibly the most comprehensive and useful programming book I've ever read) was reviewed it also received a 9. How do these two books compare?

A Shorter, More Direct Alternative

[kimanaw]

I read the sample chapters of the reviewed book and was underwhelmed. Chapter 4 spent way too much time trying to sound "impressive", with lots of UML diagrams and Design Patterns references. Plus, 615 pages for AJAX ? Unless 400 of those pages are weblinks to online references, I'm afraid its just killing a lot of trees.

I just picked up Foundations of Ajax, and its a good, focused 273 pages, of which nearly half is resources and tools for implementing. I haven't had a chance to download and try out the examples, but the reference links all look like great resources. While I wish they'd skipped the usual Chapter 1 "Here's the history of the web" that any reader of the subject matter already knows, all in all, its a great way to cut thru the BS and get rolling with the AJAX concepts.

In summary:

• If you want to learn UML, buy a UML book
• If you want to learn Design Patterns, buy the GangofFour book.
• If you already know how to put together a webpage, write some Javascript, and maybe a little CSS, and just want to understand how it all to hangs together in AJAX, then Foundations of Ajax is probably a better choice than "Ajax in Action".

Re:Good read so far

[JulesLt]

Mozilla hace already started implementing some parts of the next version of the ECMAScript spec into JavaScript, and it looks like ActionScript 3.0 has actually gone from being behind JavaScript to being ahead (support of packages and namespaces). The issue, of course, is with what IE and jScript bothers to do (probably nothing if it undermines the XAML/Windows Presentation layer thingy). I still have that same alarm bell ringing, in that you're definitely using a spoon to slice a steak. The browser was never really designed for running dynamic applications, but we've ended up with a set of tools that just about allow it, and enough customer demand to make it worth the effort, but that still doesn't make it the right tool - it's just one millions of people already have. The main plus-side, of course, is that point of 'no installation'. Then again, some Ajax pages are becoming absolute monsters to download that they may as well be apps. So that makes me think of what else is out there that is better at dynamic applications - i.e. actually designed for developing them - and I ended up wondering how long it will be before we rediscover the Java Applet - there's got to be a good reason why Google are pushing rollout of the Sun JVM with the toolbar . . .

AJAX inthe Real World

[Heembo]

In may ways, that book is out-of-date. Here is what is working for me *today*. There are many possibiliites, but my focus is Rapid Application Development - and these tools help me rock and roll, fast.

Last week I was tasked to replace several standard (but sometimes complex) HTML business forms with an AJAX solution. Here are the best tools I found after lots of research time. This is bleeding edge; but functional in Opera, Safari, IE XP, FF XP, FF OSX, no small feat.

1) AJFORM - submit a form via Javascript using HTTP post or get without refreshing the page. (next release in a few days, keep an eye on it, its brilliant and easy to use) http://redredmusic.com/brendon/ajform/ 2) YOUR SERVER CODE - I use Java, but anything including ASP, CF, PHP - its all works. (Standard HTTP). Just needs to spit out XML, easy feat. 3) GOOGLES XPATH LIB - those of you who use Sarissa, drop it - she does not support Safari. Google's XPATH lib does, well, on all browsers you need. http://goog-ajaxslt.sourceforge.net/ - this is the best and easiest way to "search into" XML data. You can use native DOM calls, but it takes about 10x as much time to get it right.

With AJFORM and Googles XPATH lib on the client, I was able to quickly and effectively start making business forms in AJAX that were "scarry fast" and WOW'ed all the folks who are paying the bills! YAY!

Whats your architecture for AJAX?

Poll and Pull slowly

[jhliptak]

You can only do one thing with AJAX: change a section of a screen with data from a server without reloading the entire page.

What does that mean for push? It means that you can't do it. There is no real way to establish a connection from server back to the client.

So then what's the excitement all about? There are two things you can do with AJAX that a "normal" web app can't do:

• You can poll a server and update a portion of your web page. This method of polling can provide all four of your requests. The downside is that your polling and making requests you don't need.
• You can pull slowly. This is a technique where you make a request and you don't expect to get a reply until there is new data. So you draw your page, make a request for newer information and when it becomes available, the server will finally reply. The downside here is that there is a limited number of unresolved requests that most web browsers will allow and your server needs to be very smart about thread and socket allocation.

Reminder about browser abilities.

[dghcasp]

Don't get me wrong, AJAX is really cool. But if you develop your site using it, you'll be making your site inaccessable to anyone using MacOS9 or older browsers on Windows or *nix.

From the records of the site I maintain, about 6% of all accesses are from browsers that can't handle AJAX.

Incidently, from my over-optimistic decision to do all the layout for the site in CSS, those 6% also took 75% of the time and are responsible for 1/2 of the .css file being "hacks." Never again. Tables rule.

Re:Reminder about browser abilities.

[Bogtha]

Don't get me wrong, AJAX is really cool. But if you develop your site using it, you'll be making your site inaccessable to anyone using MacOS9 or older browsers on Windows or *nix.

Nonsense.

Best practice with Javascript is to develop a site that doesn't use Javascript, and then add the Javascript in such a way as to be backwards compatible. AJAX, being a form of Javascript, is exactly like this.

Some developers cut corners and write code that isn't backwards compatible. That's their decision, but it's got no bearing on whether or not AJAX itself is backwards compatible. AJAX is definitely backwards compatible. Visit Google Suggest in Lynx. It works fine. If you visit a site that uses AJAX and is not backwards compatible, then it is the fault of the site developers for misusing AJAX. It's not an intrinsic limitation of AJAX.

All you are doing by saying that AJAX is not backwards compatible is scaring some people off AJAX, and making others give up on backwards compatibility. The former will result in less usable websites, and the latter will result in less compatible websites. Neither of these are good things. Please refrain from saying that AJAX is not backwards compatible. It is. You don't have to choose between AJAX and backwards compatibility, so don't mislead people into thinking that they do.

Ajax Killed Himself

[laoc00n]

Take a reliable, stateful transport protocol (TCP) and lobotomize it so that connection state gets thrown away. This is http. Take a platform-independent object technology (Java) and lobotomize it so that dumb xml data structures get passed to "stateless" objects (in other words, procedures), and all processing must happen at one end of the connection. This is Web applications. Take gui technology and lobotomize it so that screens must refresh one page at a time. This is a browser. So: having gone from a world of functional, stateful, distributed applications engineered to a true software model, we are now back (despite all the self-congratulatory rhetoric about "objects") to procedural programming and dumb terminals (meaning Web browsers). In other words, 1970s technology with pictures. Any half-wit can see that this situation is broken. How do we fix it? The Ajax answer is to keep all of the lobotomized bits and build increasingly Byzantine layers on top of the existing mess in order to re-introduce the capabilities that were hacked off in the first place. Brilliant.

Re:Ajax Killed Himself

[dasil003]

Take a reliable, stateful transport protocol (TCP) and lobotomize it so that connection state gets thrown away. This is http. Take a platform-independent object technology (Java) and lobotomize it so that dumb xml data structures get passed to "stateless" objects (in other words, procedures), and all processing must happen at one end of the connection. This is Web applications. Take gui technology and lobotomize it so that screens must refresh one page at a time. This is a browser. So: having gone from a world of functional, stateful, distributed applications engineered to a true software model, we are now back (despite all the self-congratulatory rhetoric about "objects") to procedural programming and dumb terminals (meaning Web browsers). In other words, 1970s technology with pictures. Any half-wit can see that this situation is broken. How do we fix it? The Ajax answer is to keep all of the lobotomized bits and build increasingly Byzantine layers on top of the existing mess in order to re-introduce the capabilities that were hacked off in the first place. Brilliant.

Oh please, not this tired argument again! What you software engineering nazis are forgetting is that HTTP and HTML were designed to transmit static content. In that regard the protocol and the markup language are a tremendous success. HTML and HTTP are incredibly scalable and easy to use, which means getting more done in far less time. Remember that most of the web is static information. In fact, web infrastructure was so dead simple and easy to work with that web applications have flourished. It's not like there weren't competing technologies, and if they were the panacaea you seem to think, no doubt they would have done better in the marketplace.

The real problem here is your inability to think outside your own comfort zone.

Take a platform-independent object technology (Java) and lobotomize it so that dumb xml data structures get passed to "stateless" objects (in other words, procedures), and all processing must happen at one end of the connection. This is Web applications.

This sentence is complete gibberish. Java is platform independent? Pretty close maybe, but you still have to test it for every target platform. There are advantages to having your application running on your server. Dumb XML data structures? No, we pass view data to the browser... maybe XML to be processed via JavaScript, maybe HTML/CSS for raw output, maybe an image, maybe a string. Why pass bloated objects and more code to be tested on every target platform when we can just pass the data we want the user to see? "stateless" objects? Just because HTTP is stateless doesn't mean web applications are. This is a separate issue from object-orientedness, which also has nothing to do with underlying protocols. all processing must happen at one end of the connection? View processing can be done client-side via Javascript which is very much optimized for that type of code. Meanwhile the bulk of your application code stays on the server in a controlled environment where it is secure. Don't underestimate the value of running your code in only one place.

You seem to think being able to pass Java objects to a remote computer would be some kind of revolution in web development, but it would introduce a whole slew of issues, and for what? Not much we can't do just as easily now (unless you only know Java).

Take gui technology and lobotomize it so that screens must refresh one page at a time. This is a browser.

HTML + CSS is orders of magnitude simpler than presenting typical content through a GUI. Remember, the web is first and foremost about content. Name one other format that you can edit in a text editor and get anywhere near the power of HTML and CSS. Not PDF, Not Word Docs, Not Illustrator Files, Not Quark Files. Web browsers are not GUI technology. The fact that people can use it as a suitable replacement for GUI technology is a testament to

Re:Ajax Killed Himself

[legirons]

The Ajax answer is to keep all of the lobotomized bits and build increasingly Byzantine layers on top of the existing mess in order to re-introduce the capabilities that were hacked off in the first place. Brilliant.

I suppose the reason is, who do you trust?

e.g. I look at xmlHTTPobject (or whatever it's called) and wonder, "how can they allow that, after all the fuss about ensuring that cookies aren't cross-domain"

As I see it, AJAX is competing against things like Java, .NET, and ActiveX. Basically, the alternative is a popup window saying "Do you trust 123technologies to run this program? [Yes] [No]".

And the population here is divided into (a) people who wouldn't install untrusted software if it were recommended by Gabriel Himself, and (b) people whose computers won't run because they're clogged-up with spyware.

As you say, there are loads of better technologies if you trust the application writers. But who does?

This breaking news just in: Franco is still dead!

[uxo]

"The majority of the book is for programmers engaged in the development of web applications..."

Well, yeah, because if your application doesn't involve a web browser then AJAX will be about as useful as a screendoor on a submarine.

Re:Is AJAX secure (https)?

[Heembo]

I forced the URL to HTTPS and it worked just fine. The browsers already support HTTPS and that translates directly to JavaScript.

I make sure the initial page it HTTPS to start with. I do not know how to have a HTTP page, and a HTTPS Javascript transaction.

Here is another link that talks about the same issue. http://www.experts-exchange.com/Web/Web_Languages/ JavaScript/Q_21636735.html

PS: GREAT QUESTION! VIVA SECURE SOLUTIONS! :)

You don't know (A)JAX sh*t.

[dbdweeb]

How many replied without even reading the book? I started it a month ago with the pre-release PDF made available before the book was published. (This book was the number 1 seller on Amazon just last week.)

My complaint is that the book is LONG on theory and SHORT on small, reproduceable code snippets. It's not until chapter 9 that you get into meaningful code and most of that is dependent on technologies you may not care about like SquealServer and VisualBasic. The last thing I want to have to do is install half a dozen things in order to get some sample code going. It seems the book is not so much about AJAX as it about "The software development process." It drones on about design patterns and MVC. The book is also very verbose saying in 100 words what could be said in 10. Good software engineering discipline is needed of course (especially with Javascript), but this book beats it to death where it should just relate it to AJAX and move on.

All the excitement about AJAX is warranted considering the stupidity of webapp development heretofore. It's really dumb to have to regenerate an entire web page when you just want to return some additional data or reflect a state change. How many production, revenue generating web pages have I seen where the mere click of an HTML select input causes the entire page to be redisplayed? Zillions. This stupidity is overcome by asynchronous part of AJAX. Do you know asynchronous JAX shit? That's the salient improvement over mere DHTML. There's a ton of websites desperately needing richer UI's and people who know asynchronous JAX shit will be in demand.

OMFG Client Server Apps

[Bobbysmith007]

AJAX... Woo!! After 20 years of toil and effort we have managed to recreate the Client Server application model that held us strong all through the days before the PC. Cool. I love the hype around the reinvention of 30 year old tech, on a new platform

ajax ajax ajax.....

[shrewd]

it's all i'm hearing about lately... here in Australia (i don't know about ca us or uk) ajax is a cleaning product with some sort of grit in it to make cleaning easier.... i'm having trouble disassociating the word with this powerful cleaning agent....

this book is unnecessary

[illuminatedwax]

You want to learn the secret of AJAX? Here's everything you'll need to know without buying some technology-of-the-month (year?) book:

THE XMLHTTPRequest FUNCTION IN JAVASCRIPT DOWNLOADS SHIT

The rest should be obvious if you are a competent programmer.

A"HAX"

[XBL]

AJaX (Asychronous JavaScript for XML) is a Microsoft-originated hack to basically hang open a HTTP connection that receives events containing XML. It is a hack MS invented for web-based Outlook. Unfortunately it is now the hot new thing.

It takes very smart people at MS, Yahoo, Google, etc to make complex AJaX applications actually work well. It takes only a kiddie to get simple AJaX to work. The middle ground where there are mediocre programmers/web developers building medium-sized AJaX applications is where this will all fail in the end. The only saving grace would be some very smart and solid libraries built into web-apps, but I still have my doubts over the long term.

Mozilla and Apple worked together to create a element for doing bitmap drawing into web pages. I would suggest that they work together again to create something far beyond what AJaX can do. I am talking about something on the scale of melding Jabber IM, HTTP server (Apache of course), and the web browser together into a smart, extendable, standardized (Jabber is IETF), and revolutionary framework. Apple even supports Jabber already in their OS X Server and clients so they believe in half of the technology that I am proposing already.

For example, imagine if you logged into Slashdot and the account behind it all was Jabber. The resource would be the web session. You can go across pages and it doesn't matter on what "page" an open socket is created because it's existing at a lower level. Events are sent back to the browser and the browser determines from the XML on what to do with the data. It could update a section of the page to post a new story, a new comment could be added dynamically, a sidebar could be updated, etc. Your account could also integrate with Jabber clients so Slashdot users can IM each other via the same account, just a different resource. That is only a small, simple example of what would be possible.

Yet, 90% of browsers are still IE. However, don't killer apps fix problems such as this? I believe the web browser + Jabber could be a killer app.

P.S. It's time for HTML to be upgraded or replaced to make rich web interfaces easier and accessible. How about XUL? About about WhatWG? These things would make our life much easier as developers and users. JavaScript too, needs a kick in the butt. It's time to make some awesome web sites that say "This website requires something other than IE. Here are your options..." Make the tide turn.

P.P.S. To accomplish the above goals, we may need to think beyond what we know as a website with web pages. Maybe something better thought of as a "web experience".

Eric