The Canonical Design Sketch

We’re having a TiddlyWeb fest tomorrow, and I explained one of the things I want to get out of it is a canonical design sketch.

Luke Hohman’s superb text, Beyond Software Architecture, explains how he comes into a project and asks people to draw the architecture. A great predictor of the project’s state is whether people come up with the same diagram. Put crudely, if they are all on the same page – if they all know module X is in the top-right and module Y is centre left – the project is onto a winner.

I’ve found similar things myself. I will work on a project for a while before someone puts up a poster depicting the emerging architecture. People will then find themselves congregating around the poster and building it up.

While some people are more visual than others, I believe most of us have good spatial abilities and a team has a lot to gain from a shared understanding of the architecture. This is even more so in the case of a framework like TiddlyWeb, where the community is disparate and connected much more loosely than a group of agile developers in a room together.

A good example of a design sketch is that by a project with some similarities to TiddlyWeb: CouchDB.

I like the fact it’s a sketch, not a boring old “formal” diagram. Diagrams that are too neat are also brittle, whereas simple sketches are resilient to change. Moreover, I like the fact it’s on the homepage. That makes a bold statement to the community. This is the canonical design sketch for the project, and any discussions around architecture will naturally be couched around this sketch and the entities within.

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.

Server-Centric versus Browser-Centric

James Strachan: Is Ajax gonna kill the web frameworks?:

So is the web application of the future going to be static HTML & JavaScript, served up by Apache with Ajax interacting with a bunch of XML based web services (maybe using SOAP, maybe just REST etc)? If so, do we really need a web framework thats focussed on HTTP and HTML, or are we just gonna end up developing a bunch of XML based web services and letting Ajax do all the templating, editing and viewing?

While I’ve kept [an open mind](http://ajaxpatterns.org/Ajax_Frameworks an open mind), pure separation is certainly the approach I’ve been using and advocating. Perhaps server-centric approaches can work okay for some intranet apps where the emphasis is on getting up and running, and where many developers want to focus on server-side concepts like messaging, DB, business logic, etc. But the bulk of applications are better off as browser-centric.

With tools like Dojo, Mochikit, Scriptaculous, Ajax Pages, you can quite happily get the whole UI encapsulated in JS. Amid all the Ruby uptake (and for good reason), JS has also come along nicely over the past twelve months. Not just libraries, but techniques for OO design, testing, etc.

In addition, as others have pointed out, the approach goes hand-in-hand with SOA: if you’re going to expose a clean REST API on your server anyway, it’s a no-brainer to proceed with a pure-browser UI. Testing becomes a lot easier too. Separating model and presentation has always been a difficult problem in software … when you have a solution as good as this, you have to put up a very strong argument against it.

So why are people still using server-centric frameworks? The biggest force of resistance seems to be the misplaced notion that JS is a hack and we must avoid working with it at all costs. Or maybe it’s less ideological than that, and because people just haven’t had time to learn it. Fair enough – it’s hard enough to keep up with server-side technologies. But a little time learning the basics of JS would certainly ease the pain of web development.