Does the lack of states on HTTP make the protocol unfit for modern applications? [closed]

Question

I changed from PHP to ASP.NET, now I’m working with webforms in a somewhat large company. I given some though and research to back my impressions on ASP.NET webforms and I came to the conclusion that Webforms is an attempt to make web applications easier to write for those who came from the "desktop programming" world.

But before shunning WebForms I decided to analyze the needs of the software we write and bumped on the issue of maintaining application states on the Web.

I understand that HTTP is a stateless protocol, and ASP.NET tries to simulate states with session variables , hiddenfields and viewstates, it is in my understanding also that all of the above cited have flaws and are not perfect ways to keep the state in my application, But I also understand the need to keep a state on my app.

Which raises the questions, is the HTTP really fit for this type of job (making applications that require state)? Are the tools currently available to webdevelopers enough? Are the new tools available with HTML5 effective at the job or are they just workarounds for the limitations to HTTP.

I love developing for the web, and I’m much more familiar with the web than with the desktop, I just been wondering about this HTTP statelessness thing for some time and i want to understand if I’m missing some point or if I’m right on my notions.

Answer 1

The protocol may be stateless, but the app you write could maintain any state :)

Answer 2

HTTP is certainly an older technology that has become quite ubiquitous as the web became so. As a result people are extending this technology to do many things now with modern web apps were it can appear the statelessness of HTTP is an issue. Hence you see a lot of conveniences like viewstates.

However it is also possible to code modern web apps in a stateless way and this is often preferred, RESTful web development is based on this idea. Many web API's that form the basis for modern web apps are truly stateless and should be. It is a different way to think and architect. Your needs may vary depending on what you are doing.

Answer 3

Many protocols are stateless when you get down to the raw protocol layer. Statefulness is not the primary obstacle to Web Development. The primary obstacle is that HTTP by default is Sessionless. That is, by default a series of requests by a browser to a server are unrelated to each other.

We get around this by using cookies to denote a session. The ASP.NET server gives a cookie to the browser, who then returns it on subsequent request. Behind the scenes ASP.NET looks for that cookie and connects it to the Session that it has cached (assuming the session hasn't timed out).

From there, other data can be associated with the session and used to create a customized experience for each user. Web Servers and frameworks have become so good at this that rich clients can be built on top of the HTTP protocol. Case in point, Twitter clients use http for everything from retrieving a list of friends and tweets, to sending direct messages to other users. (I'm simplifying somewhat, there is a fully connected, TCP streaming protocol available through twitter, but for the most part, HTTP is at the core of everything.

HTML to a degree has reached its limits as an adequate display technology, but the HTML 5 standard along with JavaScript and CSS 3 have made it possible to create rich UIs that rival what's possible with native clients. In fact, HTML 5 has come so far, it is supported as a native technology for Windows 8 apps. With libraries such as JQuery for the client and NodeJS for the server, one can create an application that uses JavaScript for it's logic on the client and server and HTML for the display and pure HTTP for communications.

So, while the argument in the past that HTML/HTTP has reached its limit might have had some merit, it's just not the case anymore.