Ajax Programming Patterns – Podcast 2 of 4: Browser-Server Dialogue Patterns

Continuing from the previous podcast (cough 12 weeks ago), more programming patterns. Unfortunately, this recording (and the next one) went pear-shaped. Sorry. I do, however, recommend them to those of you who’ve been wondering what an Ajax talk would have sounded like in crackly 1930s recording technology, and one in which the speaker has a severe cold. FYI The level was too low and it didn’t correct very well…maybe one day, I’ll re-record, but for now I’d prefer to just get them out there as they have been sitting in the libsyn archive for many weeks.

The 40-minute podcast covers the following patterns:

  • Call Tracking Accommodate busy user behaviour by allocating a new XMLHttpRequest object for each request. See Richard Schwartz’s blog entry.Note: Pending some rewrite to take into account request-locking etc.
  • Periodic Refresh The browser refreshs volatile information by periodically polling the server.
  • Submission Throttling Instead of submitting upon each Javascript event, retain the data in a local buffer and upload it periodically.
  • Explicit Submission Instead of submitting upon each Javascript event, require the user to explicitly request it, e.g. submit upon clicking a button.
  • Distributed Events Keep objects synchronised with an event mechanism.
  • Cross-Domain Proxy Allow the browser to communicate with other domains by server-based mediation.

Click to download the Podcast. You can also subscribe to the
feed if you want future podcasts automatically downloaded - check out the
podcast FAQ at http://podca.st.

This podcast covers six patterns on Browser-Server Dialogue: Call Tracking, Periodic Refresh, Submission Throttling, Explicit Submission, Distributed Events,

Thanks for your feedback since last time. Good, bad, or ugly, it’s all welcome – in the comments for this podcast or [email protected]

Pseudo-Threading: Multithreading in the Browser

You know AjaxPatterns? It’s a wiki about Ajax. Anyway, it’s now fully open for editing, but I’ll post more about that later. Right now, this post covers a particular pattern that’s been sitting in eXtreme Stub mode for some time, and has now got a little flesh to it.

Pseudo-Multithreading (mmmm…just rolls off the tongue) is a Performance Optimisation pattern to make input smoother. Now that the wiki’s open, you could even contribute some info if you’ve used it.

(The links below don’t work as it’s a straight HTML copy.)


Forces

  • Ajax Apps are single-threaded. Browsers don’t allow scripts to multithread, and nor does Javascript have any built-in support for it.
  • Most Ajax Apps accept user input.
  • Some Ajax Apps require complex processing in the browser. If the thread of execution is busy performing such processing, users won’t be able to perform input.

Solution

Using Scheduling, a processing function is called once in a while, incrementally processes a bit more of the problem, before yielding. Instead of solving the entire problem at once and returning, the function maintains a “blackboard” object and continuously works on it until the problem has been solved. This “blackboard” object is optional and may be something that forms the eventual solution, or just a copy of the original problem and an indication of what to do next.

For example, imagine you’re implementing a Portlet, a real estate advertisement providing a mortgage rate calculation. The calculation requires you to run a simulation, calculating the value at the end of each day for a year – a loop of 365 calculations. If you do it all at once, the user won’t be able to do anything during that long period. So instead, you break it into chunks of 10 days at a time. At the end of the first chunk, the blackboard indicates the situation after 10 days. At the end of the second chunk, the blackboard indicates the situation after 20 days. At some point, it will reach its target, 365 days, at which point it will probably call a callback function or just handle the result directly, e.g. paint the result on the user-interface.

It’s convenient to handle this in an object-oriented fashion, where the blackboard data and the processing function belong to the same object. The object is basically a Strategy or Command object (Gamma et al) – it has a “run()” method that does a little bit of processing, and sets values as attributes of itself. In the above example, we have a Calculator object with a run() function that performs the 10-day simulation. calculator.run() begins by reading the daysSoFar attribute, calculator.daysSoFar and the valueSoFar value, calculator.valueSoFar. It then simulates the next 10 days, and updates those attributes. Calculator might also include additional attributes too, such as: the number of days to simulate per run() invocation; the completion condition (which could be a function itself, or just a value such as number of days); a callback function to call upon completion.

Alternatives

Thin Client

“Thin Client” Ajax Apps delegate any complex processing to the server. Probably more network and server overhead, but less CPU cycles devoted to processing and more to user input.

Related Patterns

(TODO Patterns like Live Search, Portlet, and Live Form should point here.)

Real-World Examples

NumSum

The Ajax spreadsheet NumSum, continuously recalculates cell values, using Pseudo-Multithreading.

The Ajax Experience, May, 2006 (SF) Wrapup

Okay, for those watching my live blogging at Ajaxian, you know I’ve just been to San Francisco for the Ajax Experience. San Francisco is always a fine place to be for work or a conference, we’re fortunate it turned out to be such an important place for our industry. I’m back home in London now and now it’s time for a big braindump, where I’ll do everything in my power to forget as many people and events as possible. Wish me luck!

Me, Me, Me: Ajax Design Principles and Patterns Talk

I’ll get the plug out of the way, lest these links get buried in the rest of the text below. You can find the slides to my talk here:

Video and audio should be available at some point. (I’m sure that camera had a purpose.)

If you saw my talk (or you end up catching the audio/video), I’D BE REALLY GRATEFUL FOR ANY FEEDBACK – positive or negative (other than stop shouting at me from your blog) – as comments in this blog or to [email protected] Thanks!

The 90 minute talk covers:

  • How patterns help accelerate Ajax. You’ll still make mistakes, but they’re the ones workth making, not the ones others have already made.
  • Design principles for Ajax. I think people will perceive this as the dominant part of the talk.
  • Intro and overview of the patterns, including Walkthrough of the Ajax tutorial.
  • Ajax Patterns Smackdown. An overview of competing patterns that is at once fun and informative, sharp and objective, fast and comparative, real and subjective. We take a single goal – e.g. “What format do I use to download data” – and we walk through two patterns that achieve it. At the end, I ask the audience who’s using what, the results of which were interesting. I mostly stated them out loud for the sake of the recording, so I should be able to blog this informal poll when the audio’s out.

I got all WebTwo-y and used s5 for the first time. Admittedly, I know a lot more CSS than last time I tried it, which sure helped, but I have to say it worked out really well. Resizing (which you have to do at conferences due to the projector – downscaled to 1024×768) was seamless.

I also appeared on the second night panel, where we had a range of memorable questions. (Video and audio also pending.) There’s no live blog, and I won’t pretend to remember what others said, but here’s a couple of points I recall making.

Asked if Ajax means we’re on the dawn of a new era of enlightenment (or something like that), I explained that if we are, it will take more than Ajax. As it happens, I do believe we are at such an age (though I wasn’t going to go into it there), and I believe that Ajax is one brick in the wall. Can a UI technology cause such a profound change? It seems a bit cringeful, but one point I did make, where I do think Ajax is quite profound, is the ability to collaborate. As an application delivery platform (Douglas Crockford’s term), we can tell 50 people a URL and using technologies like Periodic Refresh (Polling) or HTTP Streaming (Comet), we can rely on most or all of them being able to collaborate together in real time. In contrast, these 50 people would end up fragmented in the desktop environment – they’d be using different OSs, different applications, and be subject to different security controls.

We were also asked the obligatory (at this conference) and very important question on accessibility. My response here was that we really need to reframe the question – people, in my view, are often overly negative about this. How about we take our new, poweful, abilities, and see how we can make things even better than we could in the past. I talked about customisation in my presentation – Ajax makes customisation a lot easier than in the past (compare NetVibes to Excite). Customisation is a seriously important aspect of accessibility. Ergo, in some areas at least, Ajax already gives us the ability to do better than before. (Thankfully I didn’t utter the word “Ergo”. Crikey, I rarely even write it.)

Thanks

The most important thing is to say thanks to Jay, Dion, Ben, Rochelle, Chris, Karsten, and everyone else involved in organising the conference and inviting me along. You guys pulled off a great conference where people were able to get a lot out of it, no matter how Ajaxperienced. Thanks also to all the speakers for educating me on Ajax and certain others for educating me on SF :-).

Meeting People

It was cool to meet so many Ajax people, almost all for the first time in the flesh. Fellow Ajaxians Dion and Ben, who work together so well in various talks and moderation sessions. It was also good to catch up with fellow Ajaxian Rob Sanheim, who I hope does a presentation next time on his Rails and PHP experiences.

Brent Ashley, resplendent in Ajax (football club) tracksuit and cap, with custom-made Javascript-style cleaning ad T-shirt, has a fantastic attitude to the whole movement and offered many insights into its evolution. Remember, this guy was doing remoting in the last century. You know the Java-inspired joke about “Must have 6 years Ajax experience”? Brent and I discussed how the existence of people like him (and probably others at the conference) kind of invalidates it :-). Brent deserves a special mention as he’s the guy who originally promoted Ajax Patterns to the initial Ajax Summit (which oddly enough wasn’t mentioned at the conference) and in his blog.

As just blogged, I briefly met the “father of Ajax”, Jesse James Garrett. His talk was probably interesting to many, but in my case I’ve heard various elements before, so less new info for me. (Indeed I’ve transcribed and blogged about a couple of podcasts he’s appeared on, so I know way too much about this story). One especially cool thing was how he very explicitly made the point, wich will probably be ignored by all the dogmatic pedants out there, that Ajax is not just XMLHttpRequest. These people really should be relying on community conventions to work out what a name means (language evolves BTW, and words can only mean whatever people collectively use them to mean). However, if they retentively insist on idolising the Ajax Guru, at least they might consider listening to what he says in talks like this. It reminds me of the scene in Fight Club where “Jack” (Ed Norton) admonishes the crew – “This guy has a name. His name is Robert Pawson”. The sentiment is lost on the crew, who simply want to be told what to do from their Fight Club Guru and start chanting “His name is Robert Pawson. His name is Robert Pawson.” My point? If you find it so difficult to think for yourself that you must have a Guru, at least follow what he says. (If I seem “emotionally committed” to this point, read the Wikipedia Discussion on Ajax, where you’ll discover any number of AjaxA.J.A.X. authorities who revel in equating the concept with “Here’s what we can do with XMLHttpRequest”.

I also met The Grandmother of Ajax. For real. I’m referring to Jesse James Garrett’s mum, who took a few pics of her son at the end (and presumably during the talk). The “Grandmother of Ajax” label comes from Brent Ashley, who uses colourful language to describe his own role, and that of Adam Bosworth, relative to JJG’s “father”.

I was looking forward to Bill Scott‘s talk on Yahoo’s usability patterns effort all along and he didn’t disappoint (My notes on Bill’s talk). He gave plenty of examples and I especially liked his screencasts. I learned a few things about Yahoo’s approach and also some interesting ways to present pattern material. Whereas I separated out principles from patterns, Bill explained a principle and outlined several related patterns. As Bill mentioned in his talk, he’s spearheading an effort to help people mashup the patterns. I’ve already demo’d a couple of examples of this, using only the AjaxPatterns: The AjaxPatterns Reader and the AjaxPatterns Portal Demo. Bill’s plan is for all of us (Yahoo, AjaxPatterns, and other collections) to expose pattern data as JSON (most likely, JSON-P), so people can combine them how they please. Writing some JS code, you’ll be able to say “Give me the HTML for the solution of Cross-Domain Proxy”.

Alex Russell and Stuart Halloway were two of the speakers I met, both of whom have extremely deep knowledge about this stuff and know how to convey it. In both cases, doing plenty of coding on the fly. I’m more pumped than ever to get into Dojo. I only wish, like others have said, they’d have more doco, as the lack thereof has killed many a worthy open-source project. Already, I think Prototype and Scriptaculous are kicking Dojo’s butt, in terms of developer numbers, and the documentation for them (esp Prototype) isn’t especially abundant anyway. Doco isn’t just important for developers, but also other library manufacturers. Mochikit, for example, takes advantage of Dojo’s packaging structure, and with the right doco in place targeting toolkit authors, the packaging structure has a great chance of becoming a de facto industry standard. This would be a good thing for everyone – the greatest benefit is faster downloads. (In his talk, Alex explained how the basic bootstrapping requires just 5kb of compressed Javascript, so any library could feasibly benefit from this approach, even Prototype/Scriptaculous!).

I met many others, including Andre Charland of E-Business, with whom I’ve communicated with several times via our blogs, and Rob Gonda of iChameleon. Andre was, AFAICT, the only person who attended both conferences I was at – The Ajax Experience and DCamp (another post about DCamp at some point).

I also met many other attendees who I won’t mention here. It was especially cool to meet people from one website which I used in some of the examples for AjaxPatterns. I distinctly remembered some of the things in their source code (trust me, it’s memorable), where it was cool to get the background on.

Some people I never got a chance to meet, hopefully next time. Eric Pascarello and Douglas Crockford, for instance.

And I promised I’d forget to mention lots of people too, so I’d better leave it here as I’d hate to disappoint.

Main Themes

Every conference has special, unplanned, themes.

Just about every session mentioned the importance of using libraries. I blogged earlier on that there are now 134 libraries and frameworks out there. A straw poll in the panel indicated many people are still rolling their own, so the message was a worthy one.

Every panel had the obligatory question on Ajax and accessibility. I already explained my own attitude above. Bill Scott mentioned that Yahoo! has a specialist looking at all their stuff from an accessibility point of view, and I think he also mentioned there’s a Flash specialist taking that into account as well.

With a keynote from Brendan Eich and a panel with himself and Laurel of IE present, browser and JS enhancements were a big part of Day 3. Seeing Brendan talk about what’s coming with JS 2.0, there’s something God-like going on. It’s like this guy’s defining your new powers, your new constraints, the laws of gravity that you’ll be spending every day living under when you develop web apps. That’s the nature of web development – you can play with back-end environments all you want, but at the end of the day, you’re bound to whatever the people at the front of the room decide to give you. And then you sit back and go “it was all a dream” as it suddenly occurs that you’re stuck supporting the current batch of browsers for the next few years, and who knows if IE and others will implement half of this stuff anyway. It was cool to see Stuart Halloway, Alex Russell, and Douglas Crockford up there on the panel with Brendan and Laurel – they provided a good counterpoint as champions for the developers and the tool makers.

Speaking of Douglas Crockford, a few people mentioned his JSONRequest spec, which I blogged a couple of months back on Ajaxian. This is gaining momentum – Brendan is bullish and mentioned that it’s trivial to implement – though Laurel (IE) didn’t say too much. Hey, even if it’s only in Firefox, we’re going to see some cool apps come out of it. The basic idea is a safe cross-domain caller (no cookie transfer).

I’d expected Comet to be a big buzzword at this conference, but it seems most people are still getting to grips with Ajax 1.0. I did, however, come across a new term for Comet/Streaming/Polling- “Reverse Ajax”, which I believe DWR uses among others. Do I like the term? No, because I don’t like the term Ajax to describe just remoting. But I think we’re going to be stuck with it.

Filthy Rich Clients

Starting to hear more about filthy rich clients, which I guess came from this presentation at JavaOne, by Christopher Campbell, Romain Guy, Chet Haase, and Kenneth Russell.

Animation and whizzy graphical effects can be totally gratuitous, but they can also be used to make applications more effective and users more productive. This session examines fundamentals of timing and animation and shows techniques for implementing cool effects on Swing components. It also discusses recent advances in combining 2-D and 3-D effects in the Javaâ„¢ Platform, Special Edition (Java SE) 6 (“Mustang”) release.

Richer desktop clients is one likely, positive, consequence of Ajax going mainstream.

If you’re the leader in desktop apps, think even harder. Regarding Office vs Writely and others, MS’s best bet is to fully embrace Ajax and at the same time exploit the full power of the desktop for the standard version. That’s costly maintaining both versions, but if they don’t follow a dual strategy, they really have no case over a decent Ajax offering.

The same could be said of Sun wrt Swing, and anyone else with a stake in the desktop. What sort of things should Filthy Rich Clients do? Clearly, they need to attack Ajax and the web where they are weakest, which comes back to the What Ajax Can’t Do post. The post was interpreted by some as saying “What we still need to implement in browsers”, but that’s only part of the story. It’s also about deciding where and how to deploy applications.

Clearly, the desktop hasn’t changed much over the past couple of decades. In particular, the hardware setup is virtually identical. A now-commonplace joke in HCI is that the average public urinal/toilet/basin knows more about your location than your PC (leading to some interesting usability issues). Most people carry phones, IPods, and other gadgets, but only the geekerati bother to hook them up. So in aiming for filthy rich clients, the whole hardware setup needs to be examined. Hopefully the Nintendo Wii, with its commercialisation of Revolutionary input devices that track location and angle, will inspire. There are clearly some fun, and still very practical, applications of such devices. Minority Report data mining!

How about the software? What could desktop software do that Ajax can’t? Clearly, rich graphics has a long way to go. Even Flash can’t come close to what you see in the latest 3D games. I hope mainstream software will (continue to) take inspiration from gaming paradigms, since that’s where a lot of the innovation happens. The whole idea of “Second Life” and friends as a platform, rather than a “game”, offers a lot of potential. I’m seeing it as a higher-bandwidth way to express yourself, especially for non-programmers to articulate fairly complex software concepts. And it will be interesting once combined with VR-like hardware devices. In more immediate terms, the best innovation for most software right now would be to act as a faithful sidekick. That is, to shut up, sit in the background, watch what’s going on, and quietly gather information, ready to be called upon at any time. To take on Ajax and the flight to the web, now is the time for the desktop to embrace intelligent agents.

Mix ’06 and Ajax Design Principles

‘Tis Goud reports from Mix ’06, Microsoft’s web bash currently happening in Vegas. One of the presentations focused on the most important thing about Ajax: Usability.

The session started with referencing two sites with information on:

Thomas’s guidelines were the first serious look at Ajax usability and a big inspiration for the Ajax Patterns.

The patterns and the principles were apparently distilled to this list:

  • Feedback
  • Predict
  • Preserve
  • Share
  • Controls
  • Separate

If anyone has more detailed info on this discussion, please let me know!

As it happens, the third chapter of “Ajax Design Patterns”, the overview to the patterns themselves, explicitly identifies principles on which the patterns were based. Principles and patterns go hand-in-hand, so any pattern language I’ve worked on always comes with a set of principles, an explicit reference point for people to grasp where the patterns are coming from. You can even (with some energetic hand-waving) look at the patterns as being defined around the principles: “These patterns are written such that if you follow them, your system will adhere to these principles”.

Anyways, the principles are broken into two groups: Usability Principles and Software Design Principles. Maybe I ought to podcast them sometime.

These are the Usability Principles for Ajax.

  • Follow Web Standards
  • The Browser is Not a Desktop
  • If it’s Different, Make it Really Different
  • Provide Affordances
  • Smooth, Continuous, Interaction
  • Customisation
  • Make it Fun

These are the Software Design Principles for Ajax.

  • Embrace Javascript
  • Accept Workarounds Where Necessary
  • Tame Asynchrony
  • Develop for Compatibility
  • Reduce Bandwidth
  • Deal with Latency
  • Partition into Multiple Tiers
  • Go Easy on the Browser
  • Practice Graceful Degradation

It’s funny. The very first thing I think of when I see stuff like this is along the lines “SHOW ME THE PATTERNS!!!!”. I’ve got no patience for motherhood statements like ‘Tame Asynchrony’. But the reason for this annoyance is because you usually see these kind of principles in the absence of any explanations, examples, or patterns. Once it’s apparent that the principles are merely a background to more concrete advice, their presence has been justified.

Who’s Your Coding Hero?

Jeff Attwood asks, “Who’s Your Coding Hero?”. Not everyone has one, but you’re lucky if you do. For me, there’s no question about it: Philip and Alex rule. After seeing him speak (to an audience of perhaps 30-40 people!), I realised how much more there was to the web. The things you hear about Web 2.0 today, he was on to a decade earlier.

Here was a presentation where the form really did matter. Why? Because he delivered it using WimpyPoint, his own online presentation manager (familiar idea?). So what’s WimpyPoint all about?

WimpyPoint is a replacement for desktop bloatware such as Microsoft PowerPoint. You can build a slide presentation in WimpyPoint from any Web browser anywhere in the world. WimpyPoint will hold onto your presentation in a professional maintained and backed up relational database management system (Oracle 8 ). You can forget your laptop. You can drop your laptop. You will still be able to give your presentation anywhere in the world that you can find a Web browser.

That’s the thing I remember the most about his presentation. His quick dismissal of a desktop solution for presentations, as if it was the most insane thing anyone could think of doing. He also created the first well-known mashup, the Bill Gates Wealth Clock, and saw the point of publishing a book online. One of my favourite bits of tech writing ever is his intro to HTML:

[Y]ou already know how to write legal HTML:

My Samoyed is really hairy.

That is a perfectly acceptable HTML document. Type it up in a text editor, save it as index.html, and put it on your Web server. A Web server can serve it. A user with Netscape Navigator can view it. A search engine can index it.

On Java and Flash:

Maybe you have infinite money and can buy the book plus a raft of multimedia authors. It still might be worth remembering what brought users to the Web in the first place: control and depth. Software such as Java and Flash enables you to lead users around by the nose. Flash them a graphic here, play them a sound there, roll the credits, and so on. But is that really why they came to your site? If they want to be passive, how come they aren’t watching TV or going to a lecture?

It’s not surprising, then, that Joel Spolsky has cited Greenspun as a major influence. I feel extremely fortunate that people like Greenspun and Spolsky, who can certainly walk the walk, are willing and able to talk the talk.

Basics of Ajax 3 of 3: Events and Much More (Podcast)

Ajax Basics 3 of 3

This is the final of three podcasts on the basic Ajax patterns.

  • Podcast 1: Display Patterns and the DOM.
  • Podcast 2: Web Remoting – XMLHttpRequest, IFrame Call, HTTP Streaming.
  • Podcast 3: Dynamic Behaviour – User Actions (Events), Timing, Ajax App, Web Service, On-Demand Javascript, Richer Plugin

Podcast 3: User Actions (Events), Timing, Ajax App, Web Service, On-Demand Javascript, Richer Plugin

Click to download the Podcast. You can also subscribe to the
feed if you want future podcasts automatically downloaded - check out the
podcast FAQ at http://podca.st.

This 77 minute podcast covers all the foundational technologies not yet covered in previous podcasts. Due to some reshuffling as the book was being edited, there are now four more patterns here than previously announced:

  • User Action Using the DOM’s event mechanism to deal with user actions such as mouse clicks (02:05)
  • Scheduling Schedule one-off or continuous events – Javascript code to run in the future (15:55)
  • Ajax_App The root of all Ajax (Note: The wiki version is empty at this time). Discussion of [Ajax Deluxe versus Ajax Lite]((http://www.softwareas.com/ajax-lite-versus-ajax-deluxe). (22:10)
  • Web Service The thing what sits on your server and gets called by the browser ‘n’ stuff (Note: The wiki version is empty at this time) (31:30)
  • On-Demand Javascript Remoting via Javascript – allows cross-domain remoting and lazy loading of modules (34:35).
  • Richer Plugin “Richer Plugin is an acknowledgement that Ajax alone is not always enough” (This pattern was the subject of the recent “What Ajax Can’t Do” debacle – Quote from Digg user: “This article is total crap.”) (48:20)

Featuring Ruby music by Why.

That completes the Basics series. Once the book is out of the way (Real Soon Now), expect to hear more Ajax pattern podcasts!

As always, feedback is welcome – [email protected]

Basics of Ajax 3 of 3: Events and Much More (Podcast)

Ajax Basics 3 of 3

This is the final of three podcasts on the basic Ajax patterns.

  • Podcast 1: Display Patterns and the DOM.
  • Podcast 2: Web Remoting – XMLHttpRequest, IFrame Call, HTTP Streaming.
  • Podcast 3: Dynamic Behaviour – User Actions (Events), Timing, Ajax App, Web Service, On-Demand Javascript, Richer Plugin

Podcast 3: User Actions (Events), Timing, Ajax App, Web Service, On-Demand Javascript, Richer Plugin

Click to download the Podcast. You can also subscribe to the
feed if you want future podcasts automatically downloaded - check out the
podcast FAQ at http://podca.st.

This 77 minute podcast covers all the foundational technologies not yet covered in previous podcasts. Due to some reshuffling as the book was being edited, there are now four more patterns here than previously announced:

  • User Action Using the DOM’s event mechanism to deal with user actions such as mouse clicks (02:05)
  • Scheduling Schedule one-off or continuous events – Javascript code to run in the future (15:55)
  • Ajax_App The root of all Ajax (Note: The wiki version is empty at this time). Discussion of [Ajax Deluxe versus Ajax Lite]((http://www.softwareas.com/ajax-lite-versus-ajax-deluxe). (22:10)
  • Web Service The thing what sits on your server and gets called by the browser ‘n’ stuff (Note: The wiki version is empty at this time) (31:30)
  • On-Demand Javascript Remoting via Javascript – allows cross-domain remoting and lazy loading of modules (34:35).
  • Richer Plugin “Richer Plugin is an acknowledgement that Ajax alone is not always enough” (This pattern was the subject of the recent “What Ajax Can’t Do” debacle – Quote from Digg user: “This article is total crap.”) (48:20)

Featuring Ruby music by Why.

That completes the Basics series. Once the book is out of the way (Real Soon Now), expect to hear more Ajax pattern podcasts!

As always, feedback is welcome – [email protected]

Ajax Lite Versus Ajax Deluxe

Harry Fuecks suggests there are two types of Ajax apps: HTML++ and Client/SOA. This is something I’ve noticed too, and it cuts right across the Ajax architecture, impacting on the user-interface, the physical architecture (browser-server separation) and the abilities of the developers involved.

The “Ajax App” pattern addresses this as a decision. It’s the root pattern for the entire Ajax Patterns language (Ajax App is not yet on the AjaxPatterns wiki). As you might know, each pattern has a “Decisions” section, identifying the decisions you’ll have to make if you go with the pattern. In the case of Ajax App, a big decision is how far along the spectrum you go. I’ve termed them differently to Harry, but the distinction is essentially the same (there’s now a footnote to his article). Extract from the “Ajax Design Patterns” draft:

Will your application be “Ajax Deluxe” or “Ajax Lite”?

There are two archetypal architectures for Ajax, and all applications lie somewhere along the spectrum between these extremities:

Ajax Deluxe

Ajax Deluxe uses Ajax to the max: applications feel similar to a desktop in that the browser is driving the interaction – it mediates all interaction between the user and server, so there are no – or few – direct page refreshes. Similarly, there’s no – or little – session tracking in the server, because all relevant state can be managed inside the browser. The server may not know about HTML at all, and just offer generic web services. An example is the Ajax word processor, Writely.

Ajax Lite

An Ajax Lite App feels more like a conventional web app overall, but one that’s been sprinkled with Ajax here and there. For instance, Ajax might be used to validate a form before it’s submitted using standard form submission, or to reveal some instructions on the page when a user requests help. An example is Delicious, which works fine on legacy browsers, but offers Ajax Suggestions for the many browsers that support it.

Which will you use? The Deluxe approach suits a development team with more advanced web programming knowledge and access to relevant tools and cross-browser libraries, and it will generally lead to a nicer, more effective, user-interface. It also facilitates a well-partitioned architecture, since the presentation logic can be isolated inside the browser and the business logic isolated in the server. However, Deluxe applications may place a strain on the browser and network capabilities, and might not even be possible if the browser is outdated. Ajax Lite is a better answer for older browsers, since the Ajax features can usually be “turned off” to support graceful degradation.

Epilogue:Another nice way to say this: “Ajax Deluxe” (or Client/SOA) == “Ajax Application”, “Ajax Lite” (or HTML++) == “Ajax Website”. The “Application” versus “Website” terminology was mentioned by Craig in the latest Polymorphic Podcast, Architecting Ajax Applications. If you want to hear more about the Ajax patterns (and since I’m so slow to complete my own podcasts on the topic, but I promise it will happen eventually!), check out this podcast, which is mostly about Craig’s take on Ajax Patterns. He’s not just regurgitating the patterns either, as he offers many fresh ideas and examples.

Ajax Lite Versus Ajax Deluxe

Harry Fuecks suggests there are two types of Ajax apps: HTML++ and Client/SOA. This is something I’ve noticed too, and it cuts right across the Ajax architecture, impacting on the user-interface, the physical architecture (browser-server separation) and the abilities of the developers involved.

The “Ajax App” pattern addresses this as a decision. It’s the root pattern for the entire Ajax Patterns language (Ajax App is not yet on the AjaxPatterns wiki). As you might know, each pattern has a “Decisions” section, identifying the decisions you’ll have to make if you go with the pattern. In the case of Ajax App, a big decision is how far along the spectrum you go. I’ve termed them differently to Harry, but the distinction is essentially the same (there’s now a footnote to his article). Extract from the “Ajax Design Patterns” draft:

Will your application be “Ajax Deluxe” or “Ajax Lite”?

There are two archetypal architectures for Ajax, and all applications lie somewhere along the spectrum between these extremities:

Ajax Deluxe

Ajax Deluxe uses Ajax to the max: applications feel similar to a desktop in that the browser is driving the interaction – it mediates all interaction between the user and server, so there are no – or few – direct page refreshes. Similarly, there’s no – or little – session tracking in the server, because all relevant state can be managed inside the browser. The server may not know about HTML at all, and just offer generic web services. An example is the Ajax word processor, Writely.

Ajax Lite

An Ajax Lite App feels more like a conventional web app overall, but one that’s been sprinkled with Ajax here and there. For instance, Ajax might be used to validate a form before it’s submitted using standard form submission, or to reveal some instructions on the page when a user requests help. An example is Delicious, which works fine on legacy browsers, but offers Ajax Suggestions for the many browsers that support it.

Which will you use? The Deluxe approach suits a development team with more advanced web programming knowledge and access to relevant tools and cross-browser libraries, and it will generally lead to a nicer, more effective, user-interface. It also facilitates a well-partitioned architecture, since the presentation logic can be isolated inside the browser and the business logic isolated in the server. However, Deluxe applications may place a strain on the browser and network capabilities, and might not even be possible if the browser is outdated. Ajax Lite is a better answer for older browsers, since the Ajax features can usually be “turned off” to support graceful degradation.

Epilogue:Another nice way to say this: “Ajax Deluxe” (or Client/SOA) == “Ajax Application”, “Ajax Lite” (or HTML++) == “Ajax Website”. The “Application” versus “Website” terminology was mentioned by Craig in the latest Polymorphic Podcast, Architecting Ajax Applications. If you want to hear more about the Ajax patterns (and since I’m so slow to complete my own podcasts on the topic, but I promise it will happen eventually!), check out this podcast, which is mostly about Craig’s take on Ajax Patterns. He’s not just regurgitating the patterns either, as he offers many fresh ideas and examples.