One of the problems of many internet applications is that they are constrained by the “command and control” approach of imperative programming. This results in a sequential, step driven behaviour that allows little freedom for the user to work efficiently. Contrast this with the declarative approach to programming which is very much user-behaviour driven.
Think of your on-line banking application. You want to pay a bill. Your natural behaviour may be “I want to make a payment from account to beneficary on or around date for the value of amount.” Yet typically this will be handled imperatively; a payment wizard forcing you down the route of account-beneficary-date-amount, with each step being a new page. I do not have the flexibility with such an approach to change my mind or to do things in a different order: “I want to make a payment for the value of amount on or around date from account to beneficary“.
Think of a spreadsheet; you would enter all the fields on the same sheet. Make changes to one field and other fields can be simultaneously updated. This would be impossible to achieve if your web application is linear and step driven.
The declarative approach to programming allows such flexibility being data or behaviour driven rather than process driven. With the constraints of implementation process removed we can build user interfaces that better address user goals and intentions. Rich Internet Applications (RIA) are an excellent example of the declarative approach. Ajax enables RIA to a degree, but Macromedia Flex and the opensource cousin Laszlo take it one step further. Take a look at this demo – a truly awesome (IMHO) flight checker application (click on the Search Now button to see the functionality).
The main issue with RIAs that are built in Laszlo or Flex (or indeed extensive Ajax) is those of compatibility and accesibility. By forcing users to have Flash downloaded are you likely to exclude users who don’t want, or can’t have Flash? And accesibility – I’m not sure to what extent this is addressed by them. However if resonable alternatives are provided (i.e. a “text only” version with little rich client side functionality) this ceases to be a problem.