1. Carrying State Is Critical
The chief problem with Web applicationsand the one issue that consistently troubles new Web developersis that they are stateless. Dynamic Web sites do not carry state from page to page; each instance of each page is displayed independently of what happened in the past. In other words, there is no way to tell how one page carries to the next. Because there is no way to "trigger" a dynamic page by itself, developers can only be sure they are viewing or testing the right page by ensuring their state variables are properly configured for each page. Unfortunately, configuring state variables for Web pages is a tedious and time-consuming task.
I discovered this first hand while building a dynamic Web site. Our developers struggled to connect the pages into a consistent application but failed because they neglected to consider that each page had its own state. It didn't take long to see that the developers were chasing their tails trying to figure out how to connect the pages.
The code itself was complicated and convolutedfull of state variables for which nobody knew the values.
Then came the biggest clue to the nature of the problem. When the developers ran the code for the back-end applications, they encountered bugs that arose from going through multiple paths and ending up on the same page from different directions. Because they couldn't control the state variables, the developers were invariably ending up with the wrong versions of pages, making it impossible to debug the application. The only available solution was to re-write the code for the entire project.
Object-oriented developers, too, must make earnest efforts to understand how state is recorded as they shift to Web development. Each interaction with a Web page has to be handled independently, without regard for what events occurred in the past. Even dynamic pages cannot keep track of state; each time you travel from one page to the next, you can only carry the state by using state variables. In other words, you have written code for the page itself, but part of the information for the page is stored outside the page in the state variables.
In principle, storing information in state variables breaks the object-oriented paradigm. A fundamental principle of object-oriented programming is that all necessary information is encapsulated inside the objects. Objects have to carry state information throughout the application, and as the information is modified, the object is "morphed" accordingly. But in Web development, objects don't carry from one page to the next. A page is created and represented by objects, but then the objects die as the page disappears. The most important information from the objects can be stored in state variables and re-created. However, every time an object is re-created, it is inevitably a new, slightly different instance. This re-creation violates the fundamental object-oriented concept of flow throughout the application. So while the Web paradigm can seem object-oriented on a small scale, the object-oriented paradigm is broken on a larger scale.
Developers who are trained in object-oriented programming often enter Web development with the assumption that if they have the variables stored in their objects, they will be ready to apply to the new page. It is surprising for them to find that the variables are not, in fact, carried over. To master dynamic Web development, these developers need to switch their thinking. Ironically, they can gain a better understanding of Web development if they just think back to the old rules of FORTRAN programming. In FORTRAN, there were external variables that carried information between functions and subroutines. The functions and subroutines executed tasks on their own, out of the developer's sight.