Everyone who has long programmed for both worlds, that is he has developed local applications and programmed for web, will tell you that web programming is very different from classical application development. And it's not just the programming language. You can develop both local and web applications using the same Java, Python or even C++. The difference lies in the medium of the web. It defines a much different deployment and runtime environment. It implements a different service model. It imposes different application architecture. It calls for a different programmer mentality because the very philosophy of the web is miles away from the traditional programming school. And here with the web programming paradigm we have something interesting to recognize. Very obvious actually but shadowed into the background by the march of the modern powerful programming paradigms and drowned by the fanfares of new and shining technologies and tools.

"What's that?" - will you ask.

Let us see.

We'll start by looking at the lifecycle of a typical local application and compare it with that of a typical web application. I will be using the term "lifecycle" to refer to a period of application activity, its runtime, not in the sense of the project lifecycle with its different development and maintenance stages.

What is the lifecycle of a typical local application like? A user starts the application, it gets loaded into memory and now it is running. It can react to user input, load files from disk or send some data over network. It can interact with the other software or hardware components, invoke other services or react to an external invocation. It can gather data, accumulate it and process it in some way. In short, all those things a local application would do while it's up and running.

How does the lifecycle of a typical web application look like? A user clicks a link in his browser. The browser sends a request to a web server, then receives a response and shows it back to the user. Quite simple actually. But the application is not running in the browser on the user machine. It's running on the web server. And there, the application is not running continuously. The server only briefly brings the application into life to accomplish the task of processing the request and preparing a reply. It happens in a blink of an eye. The application is not running between requests. It is invoked for a short time and shut down immediately after it's done with the request. And the application is not even entirely loaded into memory, only the parts of it really necessary for the task at hand. You could say a web application has an instantaneous lifecycle. Only its runtime environment that is the web server is running continuously. There are sure workarounds like session and data serialization to help keep data between the application lifetimes and to mimic the stateful operation like certain frameworks such as ASP.NET WebForms or JSF do, but still, these are just technical tricks and actually a story for another time. We shall focus on usual web applications focused around processing requests. And those web applications enjoy a very brief runtime existence.

For a development of a local application, a number of techniques would prove useful. Object-oriented approach to structure the problem domain and help deal with its complexity. Certain design patterns for an effective and an elegant solution. Layered architecture to split code responsibilities and minimize dependencies. These are all classical best practices which have proven efficient in development of local applications.

Using them in web development is a different story entirely. We actively use object-oriented approach to define a domain model, we adopt certain design patterns and we implement the layered architecture. They improve code quality, add reusability, structure the application in conceptual modules. It all works and belongs to the everyday routine. Even so, I can't often help but notice that these things seem to be redundant, an oversolution to really small problems. At times I just look at the smart and sophisticated code and catch myself on the random thought to be willing to strip it all away and just do things straight.

What's straight? Think of a typical routine as an application is processing a request. What happens there, in major steps? The application receives the user input, validates it, transforms it into a domain-specific format and passes it to an SQL code which puts it into the database. What happens next? The code reads some other data from the database, reformats it to be user-friendly then serves back a piece of HTML. That's it. That's what happens under the hood of most web applications. No fancy objects living their lives, sending and receiving messages and intelligently interacting among themselves to achieve a higher behavior. No, just some data travelling between the user and the database, back and forth. It's data-flow one-on-one. And the code that implements that is essentially performing as functional code, regardless of the style it was conceived to bear.

This discussion touches the subject: Is functional programming relevant to web development? As one user eloquently put it:

"Functional programming matches web apps very well. The web app receives a HTTP request and produces a HTML result. This could be considered a function from requests to pages."

And I would add the following. The code which implements this function bears essentially the functional style. Instead of true objects keeping the application state in memory and cooperating to implement the application logic, we've got a database to keep the state of the application and the entire code is basically a large and complex function that arranges for the specified dataflow to reach its destinations, either the database or the user.

What lesson can we take from this? It's not always good to fanatically force the object-oriented style and the complex architecture into web applications. They would not necessary profit from this approach but could instead get overcomplicated and inefficient in terms of performance and later maintenance. One must always weigh the pros and cons of this approach on a per-project basis.

And when a programmer codes a web application and suddenly it bears the imprint of a functional programming style, he should not get immediately criticized and ridiculed. Maybe he did it on purpose. Or maybe it was the unconscious manifestation of the subtle understanding that web programming is functional by nature.