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).

An Ajax Framework a Day!

Today’s Ajax framework is JsRia. Yesterday’s was ZK, with the Backbase entries updated too. In the past week, there were Smartclient, Ajax JSP Taglib, Ajax JSF Framework, Cajax. Here’s the diff. The week prior to that saw introduction of XOAD, Rialto, and Lotus Notes info.

Have the Ajax frameworks entered the enlightened age of singularity? (I’ve been listening to a lot of Ray Kurzweil podcasts lately, forgive me.) To some extent, yes, there is some pretty explosive growth here, because several of these frameworks really have been released in the past couple of weeks, as far as I can tell. In addition, many of the project owners and users have presumably become aware of the page, and seek to add their project or update my original description.

So I’m thinking the frameworks page needs to be split before it bursts at the seams, what do you reckon? I wish there was a way to keep them all on the same page, with a bit more Ajaxy dynamism, to let you manage and personalise things better. As I alluded to yesterday on Ajaxian, of all the Ajax projects being announced – wikis are somewhat lacking. Surprising to me, since it was one of the most obvious Ajax examples to me – one I mentioned in the original Ajax Podcast, and one of the first proof-of-concept demos I created for the patterns. One thing I’d like to see is wikis take more of a web service approach – let a thousand Ajax/Flash/Desktop wikipedia clients bloom. Sure, there are mashups now, but they’re mostly read-only, and require manual scraping. The idea I had with the Ajax Patterns Reader was to eventually let people leave feedback. There’s another demo – the portal, which grabs content from ajaxpatterns.org, and there will be a further demo coming soon. To do all that properly, I’ll likely create a web service to expose the wiki content as an RESTful API.

In closing off this tangent, here’s a question: How would it be creating a wiki from the ground up, with no UI? Just a collection of web services for managing content. I’ve found MoinMoin is more configurable and pluggable than most, but it still starts with the unnecessary premise that the UI lives in the same process as the content.

An Ajax Framework a Day!

Today’s Ajax framework is JsRia. Yesterday’s was ZK, with the Backbase entries updated too. In the past week, there were Smartclient, Ajax JSP Taglib, Ajax JSF Framework, Cajax. Here’s the diff. The week prior to that saw introduction of XOAD, Rialto, and Lotus Notes info.

Have the Ajax frameworks entered the enlightened age of singularity? (I’ve been listening to a lot of Ray Kurzweil podcasts lately, forgive me.) To some extent, yes, there is some pretty explosive growth here, because several of these frameworks really have been released in the past couple of weeks, as far as I can tell. In addition, many of the project owners and users have presumably become aware of the page, and seek to add their project or update my original description.

So I’m thinking the frameworks page needs to be split before it bursts at the seams, what do you reckon? I wish there was a way to keep them all on the same page, with a bit more Ajaxy dynamism, to let you manage and personalise things better. As I alluded to yesterday on Ajaxian, of all the Ajax projects being announced – wikis are somewhat lacking. Surprising to me, since it was one of the most obvious Ajax examples to me – one I mentioned in the original Ajax Podcast, and one of the first proof-of-concept demos I created for the patterns. One thing I’d like to see is wikis take more of a web service approach – let a thousand Ajax/Flash/Desktop wikipedia clients bloom. Sure, there are mashups now, but they’re mostly read-only, and require manual scraping. The idea I had with the Ajax Patterns Reader was to eventually let people leave feedback. There’s another demo – the portal, which grabs content from ajaxpatterns.org, and there will be a further demo coming soon. To do all that properly, I’ll likely create a web service to expose the wiki content as an RESTful API.

In closing off this tangent, here’s a question: How would it be creating a wiki from the ground up, with no UI? Just a collection of web services for managing content. I’ve found MoinMoin is more configurable and pluggable than most, but it still starts with the unnecessary premise that the UI lives in the same process as the content.

Advanced Feature Wishlist for Ajax Frameworks

Looking at the best practice/process patterns gave me some ideas for Ajax frameworks. Here’s a few thoughts. I know some frameworks already do some of these things, though most don’t, and none do all of them.

Logging frameworks should provide a sensible default, ie log to a div, but allow for more flexiblity on the logging strategy, as in log4j. For example, it would be nice to hook into a local storage solution like AMASS. I know we can all “spy on users”, but a local storage solution lets you amass lots more data, helps solve some privacy issues, and will survive network problems … could even help restore lots data. I’m obviously thinking more of intranets than public internet apps.

Mock object frameworks should, um ,exist. As I mentioned last week, there’s definitely a good case for a JS mock object library like JMock.

Web Remoting frameworks should:

  • Provide a high-level, technology-free, interface, and then implement it in as many ways necessary to support the greatest amount of browsers possible. Gloves off – IFrames, Images, Stylesheets … whatever works.
  • Make access to 3rd-party domains virtually transparent. e.g. CPaint does this by allowing a proxy option, which points to a proxy running on your server. That aside, calls are same as normal.
  • Support simulation. Let a caller prep the remoting framework with the response it should provide to a given query. Testing in that way, I could see very little reason to ever go back to the real server if you could do this.
  • Support logging. Rather flabbergasted that I couldn’t find a framework that supports logging of remote calls. The new Network Sniffing pattern describes other tricks for logging browser-server traffic, but the JS remoting frameworks ought to take care of it.
  • Support mocking. In addition to prepping with the response, the caller should be able to say “throw an exception if you don’t get this query”. Note that this wouldn’t need to be the responsibility of the remoting framework if there was a general-purpose mocking framework available.