Love the Stateless Nature of the Web and Be Happy

Hi,

(This is a technical article about the history of web programming. It may prove interesting to a non-programmer, however.)

The stateless nature of the web is the key to happiness as a developer.

By stateless, I mean that one web page without effort on the part of the programmer (or effort on the part of the framework the programmer is using), does not remember or recall anything when you go to the next web page.

(HTTP is the foundation for web programming, not Framework A or Language B or Abstraction C)

Most programmers did not become programmers to do "plumbing" or "wiring". Most programmers have passions like solving deep technical problems or algorithms or just getting things to work. Most problems do not like solving trivial issues. "Hooking things up" for example, moving data from point A to point B is not why most programmers got degrees or experience or spend their hours late hacking away. But it is exactly the thing to embrace, to master and to be happy with for professional success and personal satisfaction.

And indeed, frameworks and platforms attempted to abstract away the plumbing and mundane tasks and impose a stateful model to increase programmer productivity and still do. For example, the ASP.NET Webforms technology abstracted away the nature of the web. It continued and continued and continued until Microsoft saw the light and created ASP.NET MVC. MVC isn't new pattern. It's been around for decades (or so I've been told). But Microsoft abandoned its page lifecycle model in favor for the loosely coupled MVC model because they finally saw the light.

Moving data from point A to point B is exactly the key to happiness as a (web) developer in every way. Accept the stateless nature of the web as the fundamental problem, and all the fun and wonderful things happen to your life and career.

Those who embraced the stateless nature of the web, and did so from top to bottom, faced success in the past fifteen years. Those who ignored the stateless web, suffered, unless they were lucky. One obvious example is MySpace versus Facebook. ASP.NET Webforms is great, and was good for its time. It allowed COBOL or C programmers to transition to web programming with very little effort or investment of time upfront to learn but more importantly accept the nature of the Internet.

(Courtesy of Google Trends)

But we all know what happened to MySpace. This is not a knock on Microsoft at all. I happen to like and love Microsoft, and like and love Linux as well. But, eventually Microsoft arrived to the same conclusion that everyone else did; that the stateless nature of the web can only be avoided so long until you pay the price.

No matter what frameworks come and go, no matter what technology comes and goes, the web will always be stateless. You've got a few choices.

• Fight this. Draw a line and refuse to accept this, much less like it. Ignore how the Web works and the Internet works. Use frameworks, use abstractions, use layers, use everything and anything to ignore the fact that you need data to move from point A to point B but more importantly understand how that works. One day, the world will catch up (if it hasn't already). Out of all the options, this is the only one which ultimately leads to failure 100%. Better to get another career.
• Fight this, but in an old fashioned way. This means mingling the client-side and server-side together to the point moving data from point A to point B is trivial. For example, avoiding strict Model-View separation and rendering everything all at once so everything is accessible to you all at once. An example of this is using technology which mingles the model and view, for example PHP, or the old ASP.NET Webforms. If you can handle spaghetti code or messy code, this is the way for you.
• Fight this, but in a modern way (2015). This means using modern or cutting edge techniques like client-side JavaScript applications (so-called single page JavaScript applications). Bring order to chaos with frameworks like Backbone.js to keep data squarely on the client side except when absolutely necessary. But eventually, you will need to move data to the server. The problem is just being pushed off until later.
• Accept this. Work the way the Web was intended. This can take several forms.
• Create a mini-framework to move data from point A to point B. This does not have to start from scratch. For example, you could make AJAX requests with jQuery instead of raw JavaScript (and should). The key point is to not depend on state when moving between webpages. The disadvantage of this approach is 
• Use someone else's gargantuan framework to move data from point A to point B. Use only the features you want, when you want them, and keep an eye on performance. However, the risk is one day the framework is obsolete, or the framework's designers or implementers don't have the same vision for you or your best interests at heart. 
• Work at a very fundamental level right with bare HTTP. Become a master at DOM manipulation, become a master at JavaScript and learn the cross-browser differences (or at the least have caniuse.com handy). Working at this level, you will never become dated or obsolete. The problem with working at this level is speed. Can you create deliverables as fast as the guy who uses Framework of the Day to crap things out faster than you can blink? 

So, there are many choices available for those who want to develop for the web. Which one will you choose? Which one will make you happy? That is a question only you can decide.