Hypertext is a terrible platform for some types of web applications.

Consider an e-commerce web site. The browsing/shopping part of an online store fits rather well with the hypertext model but the checkout/payment part does not. For example, the checkout portion probably shouldn’t run the credit card transaction until after the customer has confirmed her order.

Many applications, even well-behaved non-modal event-driven applications, have some notion of workflow or an ordering of actions where task Y shouldn’t be available unless task X has been completed. Workflow-based constraints are at odds with the non-linear nature of hypertext.

Here’s a diagram with circles and arrows:

Consider this a state diagram. The circles represent states and the arrows represent state transitions. With A as a starting point there are two paths through this hypothetical application to reach state D: ‘ABD’ and ‘ABCD’. It should not be possible to reach D without traversing one of these two paths.

The workflow constraints this state diagram represents could be considered in procedural terms (step A must be followed by step B) or in temporal terms (event B can not be initiated until event A completes).

If this is a web application it could be built as a series of HTML pages. The relations between pages in a web application can be represented as a directed graph where pages and other resources addressable by URL are nodes, and links and transfers are edges. Here’s a page diagram for the hypothetical application:

Bears a striking resemblance to the state diagram, doesn’t it?

If an application has workflow constraints then it has a state machine. The state machine may not be explicit in the application’s architecture. It may only be implicit, arising from the relations between pages.

Now I’ll add the obligatory network cloud:

Oops! Since all URLs have equal visibility, a user can jump directly to any state/page if she knows (or guesses) the URL. Purely in terms of hypertext, this is a feature. But it’s a feature that the Web application developer will need to compensate for. The hypertext model is fundamentally working against the application.

There are three broad strategies for dealing with the “hypertext/workflow impedance mismatch”:

Design the application to detect out-of-order page requests and enforce the workflow model.
There is no sense in allowing a user to jump into a broken fragment of an application. URLs are effectively APIs. Taking it further, if a web application can be thought of as an object and its URLs as its methods then the methods should enforce the application’s invariants and do something reasonable with error conditions.
Redesign or re-envision the application to either eliminate the workflow constraints or move the constraints out of application scope and down to the level of a single page.
Design the application to use a single URL; i.e. create a single page or single node application.

It’s possible to build a single page text pump type of application but a more popularized approach is to push some or all of the application logic down to the web browser client. The client-side code then depends on a service layer of URLs but the service layer can be stateless and/or protected.

In the past ‘single page with client-side app logic’ applications might have used Java Applets, or ActiveX controls, or DHTML. Currently there is a single page application renaissance driven by the buzz around AJAX.