Don't write your interactive Web application in custom Javascript! The Web's Declarative nature needn't be broken just because you want two-way dynamic data instead of one-way documents on your site.

Instead, write Declaratively to generic Javascripts, plugins and browser features such as Hijax, hInclude, XForms, SVG, XBL, etc.

This is the last of my XTech 2006-inspired articles. (I know: XTech was some weeks ago now, but I'm sure you'll have noticed that this is a 'contemporary article' blog, not a news blog!)

The theme for XTech 2006 was 'Building Web 2.0', and as a Web 2.0 Conference (don't tell O'Reilly), there was tons of Ajax... And as this is essentially an XML Conference, there was also a strong Declarative theme.

And the right way to do Ajax is Declaratively!

 

Ajax Lightning Demos

Simon Willison presided over this session. The demo that impressed me most was Hijax: Progressive Enhancement with Ajax, whose paper is here.

Hijax takes the view that you should design for no Ajax, then hijack the links, form posts and page construction in Ajax to speed it up, rather than designing for Ajax in the first place and excluding users without a capable browser. This is related to the AHAH idea.

So you don't build your application in Javascript, but simply enhance the existing Web model, running all the page's behaviour back on the server which owns it. Much more Declarative!

 

Web 2.0 On Speed

Mark Nottingham is one of those people whose blogs are top of my feed list. He currently works for Yahoo! This talk was about using some basic techniques to ensure Web 2.0 doesn't grind to a halt with all those dynamic and personalised pages. Simple fixes can get you very far: faster servers like lighttpd, various cacheing tricks, etc. Yahoo! should be implementing his ideas and insights on their sites (hopefully Mark will then go on to tell their API designers how to do REST...)

The main idea that interested me was using Ajax for client-side page construction (think client-side SiteMesh) and for inserting personalised URLs into the page.

It's a bit like Hijax, that I mentioned above. Mark says:

What I would like to see is for common JS functions like this to be sifted out and standardised as declarative markup...

This is good stuff (assuming you agree with us that Declarative is good!). See more in the summary and slides, and in Mark's hInclude proposal.

 

Ditching the database: XML and the PHP webapp

David Megginson basically said we should work in XML throughout our web apps: cache XML as your datastore, keeping all the little snippets that make up your pages - dynamic and static - cached in memory, then just send XML snippets from the server cache to the Ajax client to render, etc. This is rather like Mark Nottingham's tip above on client-side page assembly to achieve greater cacheability.

Paper here.

 

Introduction to XHTML2 and XForms

The flamboyant-looking and entertaining Steven Pemberton of the W3C presented a fast-paced and in-depth overview of XHTML2 and XForms.

Unless I missed something, it looks to me like XHTML2 has taken a perfect trajectory between backwards-compatible concepts, semantics and syntax and abstract idealism. XHTML2 appears to cleanly fix all the outstanding problems with HTML once and for all.

Now, part of XHTML2 is XForms. XForms does the same cleaning up job on HTML forms that XHTML2 does on HTML.

The important thing to know is that it works as an XML 'schema constraints engine'. That is, it returns to the server a fully-semantically-valid chunk of XML on a form submission. The 'schema' can include some static data pulled in from a separate URL to populate drop-downs, etc.

Yet it is more than this: I asked if it was Turing Complete, and Steven said yes. You can program an application using it.

And that application will be programmed Declaratively!

I can define the constraint that some output element be dependent on some input, then if the user changes the input, the output changes accordingly.

It's like Declarative Ajax. There were further talks on XForms which I cover just below.

Of course, I asked if it was RESTful, and it seems it was, mostly. The issue was that a URL may bring you in an editor XForms page, which then itself brings in some data underneath.

The editor XForms page is the bookmarkable thing but you don't see the URL of the populating data, so that's not bookmarkable. The page may change according to this data, but bookmarking what you see still only bookmarks the editor, not the editor plus the current visible data.

Also, even though XForms is amazingly programmable, it is still a forms system at heart. For example, you have explicit input and output elements; you can't get input events off the DOM and rewrite the DOM as output.

Slides here.

Read more about XHTML2 here.

Read more on XForms from Mark Birbeck (a Pemberton collaborator) starting here.

 

Building Rich, Encapsulated Widgets Using XBL, XForms and SVG

Mark Birbeck showed us how to create a Declarative client-side mash of Flickr. OK, there's a tiny bit of script in there, but I'm sure it's unnecessary, as it only does some simple DOM manipulation and event handling. Perhaps it can be replaced somehow, or made part of a generic library.

Paper here.

 

XForms: an alternative to Ajax?

Since XForms is so amazingly programmable, you can use it instead of Ajax.

Instead of coding a special script on top of an Ajax library, you can bring in a generic (Ajax) script that gives you XForms today, and write your application Declaratively on top of that.

Alternatively, you can do some pre-processing on the server, which is the approach Erik Bruchez explained here.

Paper here

 

The Power of Declarative Thinking

This talk was more from Steven Pemberton giving us a little history of his work and showing us how XForms can be used for Declarative programming.

Some good quotes from the slides:

.. a program that is 10 times longer is 32 times harder to write.

Or put another way: a program that is 10 times smaller needs only 3% of the effort.

And of course, the point is that Declarative programs are usually 10 times smaller.

.. no one writes applications except programmers.

Interesting exception: spreadsheets

Mostly because they use a declarative programming model.

The nice part about declarative programming is that the computer takes care of all the boring fiddly detail.

Now I'm as aware as anyone of the dangers of giving non-technical people the power to program. Spreadsheets are, let's say, a mixed blessing. There's probably a long way to go before we can give the business the reins over their own business rules.

But it will happen: it means splitting programmers into (Declarative) Business Analysts and (Imperative) Those That Enhance and Maintain The Underlying Processing Fabric. I can tell you now which group will get paid more.

 

Standardising Web Applications: Rich Web Clients at W3C

Dean Jackson gave a talk about what the W3C are doing to play catch-up with all the latest goings-on in the Wide World of Web 2.0.

Here's a quick list of things they're standardising: XMLHttpRequest, Networking, Timers, Client-Side Storage, File Upload, the Window class, DOM Level 3 Events and XPath, Drag'n'Drop, Remote Events for XML (REX); XBL2, XUL (possibly alongside XAML, MXML and LZX); Compound Document Formats.

Again, the magic word Declarative came up in the talk.

The Declarative aspects of Rich Web Clients centre around the DOM Level 3 work, Drag'n'Drop, Remote Events for XML (REX), XBL2 and XUL and Compound Document Formats. SVG is a common theme between many of these (once again, Sam Ruby is on the case).

The WHATWG is an independent collaboration of browser builders (Opera, Mozilla, Apple) that has its own initiatives in this space - including HTML 5 and Web Forms 2.0, the Canvas object, server-sent DOM events, network connections, client-side state, drag'n'drop, etc. They are happy to work with the W3C to ensure compatibility and W3C standardisation. Here is an article covering some of these WHATWG ideas.

 

Other Declarative Browser-Driving Work

When you look around outside of the Conference, you suddenly discover numerous further examples of Declarative browser-driving:

Tim Bray has been stitching pages together with Ajax.

Sam Ruby says Declarative is more mashable.

AHAH is 'Asychronous HTML and HTTP', an apparent attempt to make a big deal out of rewriting the DOM on receipt of an Ajax HTML response. Same ideas as above.

Jemplate looks like a similar kind of thing.

XAP (Extensible Ajax Platform) is an interesting project that was given by Nexaweb Technologies to Apache. Here's the elevator pitch:

  • Declarative rich user interface via XML;
  • Data binding for connecting UI to data;
  • Incremental update of web pages declaratively and programmatically;

Widgets intersect with this whole dynamic, client-side page-assembly space. There are now numerous examples of commercial Widget approaches. Some Widgets may be driven by a Web Feed, some may get their data from a Microformat or from a Web API.

Opera Widgets are DHTML packages that break free from the browser and run on the desktop. The WHATWG could even end up taking them as the basis of their play in this game.

Of course, we've already seen how to do Widgets right, in Mark Birbeck's talk above. In general, Compound Documents and dynamic, POSTable Microformats are the (Declarative) future of Widgets...

 

Declarative Meme

We need the 'Declarative' meme to consolidate and create a movement out of all this, otherwise apparently disparate, work. Once we have a meme to gather around, we gain collaborative and cognitive power from its mere existence. This could work in the same way that the label 'Ajax' itself consolidated (and launched into orbit) techniques that a large number of us had already been doing for months or years.

The 'Declarative' meme also includes and extrapolates the 'REST' meme. REST is Declarative, but not something you may normally associate with Ajax application programming. Yet programming a dynamic Web interface Declaratively goes hand-in-hand with the linkability, cacheability and mashability of a RESTful back-end interaction, as Mark Nottingham and others above have shown.

 

The Right Way to do Web Applications is Declaratively

Specialist client-side Javascripts are a mistake. They break the generic Web client model: hand-crafted thick clients are hard to make cross-browser compatible, they add to download times, they are tied to specific application servers, they break the browsing experience (bookmarking, linking, history) and miss the benefits of the Web's cacheing architecture.

We should be writing Declarative pages to exploit generic Javascripts and plugins or extensions (such as SVG, XForms and other Declarative technologies). These generic facilities will effectively extend the concept of the browser, from one that deals primarily with one-way static documents, to one that deals with two-way dynamic data.

After some time, the browsers themselves will be written to new standards that make those browser-redefining Javascripts and plugins irrelevant.

By a 'two-way dynamic data' browser, I mean a browser that constructs pages from several sources - several snippets, microcontents and widgets. It will show those pages updating in real-time as those sources update.

It will be aware of the user's key and mouse events on the visible DOM, and relay them back to the affected source, which may in turn update - for everyone viewing the page.

Programming the behaviour behind the data can be completely Declarative; rule-driven and event-driven. The programs will run both on the server, where the Resources are owned, as well as on the client, as in XForms.

I've shown many examples in this article that are heading in exactly this direction.

New Web (2.0) standards, that respect and extend Web architecture, can one day replace hand-crafted thick client scripts and generic scripts and browser extensions, allowing us to program our dynamic applications Declaratively - directly to a Web 2.0 browser.

Such a Web 2.0 architecture and platform will still be as scalable and interoperable as the current Web architecture - more so, in fact. And it will be much more fun to program for!