NOLOH's Statefulness is a Big Boon to Developers
It's no secret or surprise to regular readers of my blog that I have become a huge fan of NOLOH. I've decided to undertake a few demonstration projects on my blog to explain why I feel this way and to make it easier for my programming friends to understand this foray into the otherwise cruel and unusual punishment that goes by the self-reflexive acronym PHP. One of the most interesting -- and at the same time distressing -- features of the Web has been its statelessness. Each interaction between the client browser and the HTTP server is an isolated event. Information is not automatically preserved between such interactions; rather the Web developer must spend some considerable time and effort both planning and managing the flow and preservation of data throughout a Web transaction. This was a major feature of the Web in its earliest days because it allowed for tremendous efficiency on the server side; the server essentially opened a socket for an event, processed the event, sent something back to the client and closed the socket. This enabled relatively low-powered systems to act as servers because they could have a limited capacity for simultaneous open connections without breaking the sense of interactivity the user would experience. One consequence of this design was that when a browser sent a server an event that required that some portion of the browser display be modified, the entire window content (which roughly corresponded to a page) would have to be refreshed because nobody was maintaining the state of the page between messages. This resulted in a fairly herky-jerky kind of experience but users quickly became accustomed to it and increased speed of hardware and software on both ends of the exchange as well as of the network linkages made the experience seem a tad less discontinuous than it was in reality. Still, the programming problem of maintaining state remained. And as Web pages and sites gave way to a desire or a need for Web applications, the problem became acute. NOLOH solves that whole problem with what I think is a unique approach. It maintains user state between interactions completely transparently to the programmer. Let me be clear here: user state management is completely automatic. The programmer needs to do nothing to make a stateful application work like a desktop application. You can read here about how NOLOH does this but the fact is, as a programmer all you really have to know is that all of the effort and code that now go into creating a more fluid user experience despite a stateless protocol can now be spent making the app behave better, more smoothly and more intelligently. In my first published NOLOH project here, I'll reproduce my now-famous Counter application in NOLOH and you'll get a chance to see how this benefits you as a developer.Stay tuned.
