Managing state
As we discussed earlier:
If changes can be introduced into a web application without requiring a complete reconstruction of state and state display then updating client information becomes cheaper. The client and server can talk more often, regularly exchanging information. Servers can recognize, remember, and respond immediately to client desires, aided by reactive interfaces gathering user actions and reflecting the impact of those actions within a UI in near real time.
A very important question every application developer must ask is this one: where should state reside?
Of course, permanent data must ultimately reside in a persistent layer such as a server-side database. As well, transient-state data (such as which navigation item is highlighted in a UI) can happily exist in the client. However, if an application displays real bank records in a data grid within a browser, how do changes made to the canonical record (the database) synchronize with changes in client model...
