The 4 States of Ajax Adoption
So the 4 states of Ajax adoption are as follows ...
1. Denial
Usually accompanied with an explanation like "Java Applets are better", or "Javascript makes your website inaccessible to blind people". (Generally I don't buy either argument although I can see a diminishing case for WebStart).
2. Progressive Enhancement
Means taking an existing JavaScript free website and adding some tweaks. It's a conservative approach that won't worry or annoy anyone, but it won't turn any heads either. The BBC, Wikipedia and EBay all use this approach because it's a safe thing to do with a big website.
3. Second Site
The problem with progressive enhancement is that it treats the minority noscript case first. The second site approach provides the best it can for the majority and for the minority too. Google, Yahoo and Amazon create far more advanced systems with this approach. It's likely to cost a bit more, but you're probably going to get a much better site out of it.
4. Accessible JavaScript
The full on approach tries to create accessible sites, but only when JavaScript is turned on. Microsoft's live.com, YouTube and some Google sites do this, and there are some UIs for which there is little choice. Anyone fancy creating office type functionallity without JavaScript?
You can work up the tree, starting out small and getting bigger, and the good news from a DWR point of view is that it can help you each step of the way. DWR is good for small tweaks and a more full on style.
What's your prefered approach?
2 articles on Reverse Ajax
I came across a nice intro to Reverse Ajax with a whole set of simple graphics to explain the interaction.
The blog entry is on the curiously named gmapsdotnetcontrol blog, and we go through the classic and Ajax models (JJG style) with polling and comet before getting to the piggyback model:
And finally the Full Monty Reverse Ajax
For me Reverse Ajax is not so much about the technology on how we get the message to the browser, but more about the programmers interface.
DWR gives you a dead simple set of APIs that dynamically generate Javascript and send the Javascript to one or many browsers asynchronously.
The DWR Chat example has to be the simplest code to do chat anywhere. The full source can be seen through fisheye, but the core goes like this:
WebContext wctx = WebContextFactory.get();
String currentPage = wctx.getCurrentPage();
// Find all the browsers on the current page:
Collection sessions = wctx.getScriptSessionsByPage(currentPage);
DwrUtil utilAll = new DwrUtil(sessions);
// Manipulate all the browsers to repopulate the message list
utilAll.removeAllOptions("chatlog");
utilAll.addOptions("chatlog", messages, "text");
Wikipedia
The other article is based on this one at Wikipedia and they are both based on Jon's original article.
