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.

Got Captcha? Antispam on AjaxPatterns

I’ve been blabbing on about how I’m going to open up the AjaxPatterns wiki for as long as it’s been online (about a year), blah blah, talk is cheap. Anyway, it’s a few steps closer now. The main issue has been protection against spam – some entrepeneurial folks behind numerous proxies have discovered there’s a good niche market among Ajax developers for fake watches and cheap pharmaceuticals, and AjaxPatterns is just the thing for their cunning Long Tail marketing strategy. I wish these measures weren’t necessary, and they certainly won’t be foolproof, but hopefully they’ll let us grow a bunch of useful Ajax content without too much interruption. After The Ajax Experience, I realised how much more there is left to document and how much people want to hear and say.

So these are a few things you’ll see at AjaxPatterns.

  • Captcha – just implemented. Let me know if you have any problems. Unfortunately, it does go against accessibility, but contributors who have difficulty with it could always mail me contributions. Hopefully, mediawiki will incorporate captcha at some point, the kind of project where the resources for a more accessible solution would make sense. Mail me if you want more info on the implementation.
  • Links to book version Implemented, but not live. Each pattern page will link to the corresponding book version (well, a close-to-complete draft). Even if a spammer messes with the pattern description for a short time, there will be a permanent link to the corresponding description in the book.
  • Word/URL BlackList Based on Spam Blacklist. Sorry, no examples involving discount Rolexes.
  • Backup strategy Another measure is frequent snapshots of the whole thing (that’s always been there) .

Ajax Patterns Tutorial – Updated Docs

As just mentioned, I’ve posted code for the AjaxPatterns demos and the tutorial. You can run the tutorial here. The interesting thing here is it’s all designed to be hand-coded, so you can see how an Ajax app can easily be built up from first principles, good for learning. The final demo then uses an external library, to make the point that you don’t need to hand-code in the real world.

The Ajaxagram demo, with its various refactorings, is a useful way to introduce the patterns, and I covered it in Ajax Experience presentation. I’ve edited the overview page to help explain what value each refactoring is adding:

Ajaxagram: A Conventional Web App
No Ajax yet.

Ajaxifying Ajaxagram
Ajax version - runs in a single page without refresh. Basically the same user exeperience as before, but better for your resume and ready for the nice Ajax enhancements to come.

Enhancing Functionality and Usability
Now we’re actually seeing the benefits of Ajax. Three Functionality and Usability patterns are introduced to enhance the user experience – Live Search, Progress Indicator, One-Second Spotlight.

Streamlining Performance
Ooops, although it looks prettier and feels smoother, our app now has some technical issues. That’s a little side effect of most UI enhancements. Firstly, there’s a bug – if you type too quickly, you’ll see results for more than one search appear. Secondly, it’s too slow – we’re going back to the server every single keystroke. The Ajax patterns include Programming patterns to complement the Functionality and Usability patterns, and in this case, we remedy the situation with Submission Throttling.

Using An External Library
This final refactoring appears the same to users, but underneath the covers, we’ve introduced the ajaxCaller library to handle remoting. The point is to illustrate that Ajax Patterns don’t have to be hand-coded – many are easier to introduce with appropriate Ajax Frameworks and Libraries. There’s no shame in reusing reliable third-party code – it’s something to be proud of!

Ajax Patterns Code Now Available

All code for the Ajax Patterns demos is now available. This is the code used as examples for many of the patterns at AjaxPatterns.org, as well as the Pattern-Led Tutorial that forms Chapter 2 of the “Ajax Design Patterns” book to be published next month.

Download the code – ajaxdemos.zip.

Read the installation notes. Basically, you need PHP and Apache, and optionally MySQL is required for the wiki demos. The install should be pretty basic, as the notes indicate:

* Unzip the package to a temporary location and copy
  run/, tutorial/, and records/ to the apache document root.
  Assuming the doc root is /apache/document/root:

cp run tutorial records /apache/document/root.

(Alternatively, if you have sufficient access, set up a new virtual host in apache's httpd.conf and point it to the root of the unzipped directory, ajaxdemos/).

  • Ensure the server can write to (the initially empty) records/ directory. The easiest (though not the most secure) way is:

    chmod 777 apache/document/root/records

  • Open up run/.htaccess and follow instructions there to set the library path.

  • Finished!

You might wonder why the server-side uses PHP, when I’m more of a Java+Ruby kind of guy. Realistically, the choice was Java versus PHP due to popularity. PHP was chosen because the code needs to be easy to install, and LAMP is a lot more ubiquitous and easier to work with than integrating Java+Tomcat+MySQL together. I understand Java is at least shipping with Debian at some point, but right now, there’s few things easier than getting a LAMP setup running, especially with all the one-click installers around (http://www.apachefriends.org/en/xampp.html).

From a development perspective, I also found PHP more productive for the experimental style of development that went into the Ajax demos. The usual drivers for Java – maintainability, security, etc. – weren’t a factor. PHP also has the sort-of-merit of being the Switzerland of server-side languages. Use Perl, Java, C#, or Rails, and you’re going to be flamed loudly from some contingent. But use PHP and most non-PHP coders will say something about it would have been nice if you’d used Java/etc but I can see your point and shrug their shoulders a bit. As it happens, only a few patterns (need to) delve into server-side details, so the only real impact of using PHP is if people want to hack the code or look further into the details of implementing a pattern.

State of Ajax Patterns

Here’s what’s going on with AjaxPatterns.org and the O’Reilly Ajax Design Patterns book. Many of you have mailed about this and many others asked at the conference, so this post is probably long overdue.

State of the Ajax Design Patterns Book

I finished the book a few months ago, and it’s available for sale now in Rough Cut form. It was originally planned to be an “Animal” book, hence the bird dude depcited below, but because it has a fairly unique look and feel, it will now be part of the Theory In Practice series. So enjoy the birdie while it lasts.

People at the Ajax Experience were asking about the book, conspicuously absent on the book stand, and the fact is it’s taking a while to get into physical form for several reasons. Most importantly, I’m firmly committed to the idea that any physical pattern book needs to be highly visual – people should be able to flip through the book and see what the patterns mean in a blink. So there’s a huge amount of diagrams and screenshots that the creative people at O’Reilly are working on, and I’m really happy with what they’re outputting:

The electronic Rough Cut edition contains my extremely “rough” diagrams, which serve as instructions for the illustrator and will eventually make a nice historical manuscript.

State of AjaxPatterns.org

I’m pulling it down so the book sells well.

But if I can be serious for a moment, the site will remain online with all content intact. It has always been, and remains Creative Commons, and if I had to choose between the wiki and the book, I’d take the wiki every time. It’s staying online for the long haul, and I want to make it better than ever. These are my plans, let me know what you think:

  • Move to a faster, more reliable, host. Dreamhost is great for hosting my blog, but DB-wise, is not up to the task of managing AjaxPatterns. I’m moving it to a Virtual Private Server (VPS) host, which is something I need for other projects anyway.
  • Open up for general editing. Too many people came up to me at the conference and said “I have this pattern, what do you think?”. What I think matters much less than what the Ajax community thinks, so I’d rather let people slap it on the wiki and let everyone judge it for themselves. I’d like to let people edit and enhance the patterns, provide examples, and so on. And add new kinds of content.
  • Opening up the wiki obviously has huge risks involved, and there’s been plenty of spambots already, capable of wiping out the wiki in a single execution. There’s a strategy in place to help prevent, and also recover from, situations like this, but Mediawiki isn’t fantastic here as there’s no built-in Captcha support. I’m also sensitive to the charge that allowing open changes is a cynical way to make the content weaker, or more messy, and thus make the case stronger for buying the book. So my plan is to hack the Mediawiki template so as to ensure the current version (the one that’s there today) is always linked from each wiki page. How would you feel about that?
  • Upgrade the standard theme. You’ll know why when you see it.
  • Add more content. What Ajax info would you like to see? I’ve already begun work on a section for Ajax Tools, this is exactly the kind of thing I’d like to open up for public editing. I also have plans for a whole new category of pattern, will get to it once all the other stuff’s done.
  • Mashable patterns. As I mentioned in my previous post, Bill Scott of Yahoo! is looking at a JSON/JSONP format for distributing the patterns. Once the format has been fleshed out, I’ll set it up. The caveat will be that things might go a bit wrong sometimes with the wiki being openly editable (we’ll need to do some cleansing to at least ensure no risk of XSS, though mediawiki is probably doing this anyway), but at least people will always get the latest info real time.
  • Release code for demos.
  • ???
  • Your thoughts and suggestions?

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.

“So, Jesse, Is Ajax a Pattern?”

… That’s the question I finally got to ask the man who gave Ajax its name, following Jesse James Garrett’s keynote last week at The Ajax Experience. I consider Ajax a very standard, uncontroversial, example of a pattern, so I’ve wondered why it wasn’t introduced as such, in the original Ajax paper.

Jesse said he’s asked the question quite a bit. He didn’t answer the question directly – there wasn’t a “Yes” or a “No”. Essentially, he just made the point that patterns mean different things to different people, everyone has their own idea, etc. In other words, I think he either doesn’t want to get bogged down in the debate or doesn’t consider it important.

At first, that seemed rather anticlimatic, but on reflection, I can see his point. He mentioned in his talk how people (of a certain kind, I guess) mail him saying “I wrote this app in 2000, it uses IFrame yadda yadda … Is it Ajax?”. So he probably has enough trouble with the definition of Ajax to worry about the definition of patterns as well. Moreover, he’s a consultant, and probably talks to high-level managers who wouldn’t know a pattern from a shell script.

So it’s understandable from a pragmatic perspective why “pattern” isn’t used in the original definition of Ajax, even though Ajax fits the mould perfectly. However, it is a shame for software, and industry at large, that patterns aren’t the standard way people think about designs and processes. Framed as a pattern, a high-level architectural style like Ajax can evolve quickly, as people begin to consider examples, forces, rationale, and all the other standard attributes of a pattern. Furthermore, people can ask about the role of this pattern in the entire ecosystem of patterns. What are its alternatives and how does it stack up? What are the lower-level patterns that should be solve questions opened up by applying the high-level pattern?

That many managers don’t get patterns leaves a lot of potential for improvement within organisations. An open wiki of interlinked organisational, technical, usability, etc patterns should be an asset to any company. As explained in this visionary paper by Jed Harris and Austin Henderson. The 2020 scenario suggests how patterns might be navigated in the future.

Then she puts a probe into the guise and begins looking for the patterns that the guise uses to model market response to Heavy Metal.* Her office shows her the internal organization of the guise as a network of nodes whose size and clustering reflect how much they contribute to the guise’s current display. Each of the nodes is a small view of the associated pattern, showing its current state; if she focuses on a single node, she can usually tell how it is contributing to the display. Olivia thinks of this display as a “sea of nodes” because the ripples and swirls remind her of flowing water. She swims through the sea, getting a feeling for how Fred has put the guise together, and how the guise itself is interpreting the current behavior of Heavy Metal’s customers. After a little while she zeros in on the service and support patterns. By suppressing the contribution of some patterns and looking at what changes in the display, she eventually finds a pattern— Service is a Feature— that seems to be most involved with the aspects that have been bothering her.

134 Ajax Frameworks and Counting

I’m here in SF for The Ajax Experience, talking about design principles and patterns for Ajax (big surprise!), and one of the things my presentation will point out is the importance of libraries and frameworks in implementing Ajax patterns. Ahead of the talk, I just did a quick count of frameworks and libraries on the wiki. Turns out there are 58 in pure Javascript and another 76 with back-end support in PHP, Java, or whatever. This includes 13 for .Net, and no less than 22 for each of PHP and Java.

Overall, that’s 134 Ajax frameworks and libraries out there, many of them under a year old! It’s true that a few of the pure Javascript libraries are things like Drag-And-Drop that have been around a few years, but only a few of those. The rest are all-encompassing, like Dojo, or related to remoting, like ACE, or related to XML and DOM manipulation in a manner closely associated with Ajax, like logging and effects libraries.

When I transcribed the frameworks to form an appendix for the book, there were about 90 patterns. That was in December. So roughly 45 new frameworks since then, about one every three days. Nice going! Stuff like this makes life a lot easier for developers, no matter what they’re approach to Ajax architecture. Even if a developer doesn’t want to go near Javascript with a ten-foot pole, they’re still going to reap the benefits from a server-side framework (Rails etc). Furthermore, the server-side framework is going to reap the benefits of all these pure Javascript libraries – a number of server-side frameworks make use of Dojo, Scriptaculous, and Mochikit.

Patterns and frameworks go hand in hand. It’s not that a framework “makes patterns”, as some sales reps like to imply, but frameworks do support particular patterns. Most GUI toolkits, for example, are based closely on the Observer pattern. Java’s IO library is based on Decorator. In the case of Ajax, there are libraries like Scriptaculous which map closely to particular patterns, like One-Second Spotlight. The best reference on this stuff is Ralph Johnson’s visionary 1997 paper, Frameworks = Components + Patterns (Comms of the ACM, October, 1997).

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.