Our beloved model-view-controller pattern seems to act as an excuse for every damn web-framework out there. Yet there is one problem. From my point of view, no framework to date has ever managed to slice a web application in a useful way. Really. Why?

First of all, it should be clear that patterns just like MVC can’t be adapted without major changes from desktop environments to the web. Why? Well, desktops are a safe harbor compared to every browser. The Operating System provides resources, screen estate, some kind of event handling and the promise that once you build your app around a certain system, it will work there. Of course this is the major drawback of desktop applications.

Web Applications are not built for just one system, they are mostly built with the target of total platform-independence. Including that nothing can be taken for granted, just like screen estate, resolution, browser software etc.

And then there is this huge limiting factor called HTTP. HTTP is a simple, beautiful protocol that does a great job for what it was designed. That is, delivering web pages, stateless, happiness. Which introduces just a new detail that clearly seperates desktop from the web, the web just doesn’t know anything about state. Once a server delivered a page to you, he just doesn’t care. Really. We introduced sessions and stuff, yet, there is this design-based limitation, and for the time being, we’re just working around this limitation, whereas desktop applications are stateful: ever heard of RAM?

So the problem we are actually facing is that all the well-engineered patterns of the desktop world just can’t be adapted. Sorry. There maybe certain areas where the impression of adaptability may occur, yet these impressions vanished as AJAX appeared.

Why? The traditional web-application, let’s call it Web 1.0, was based on that well-known request-response-leavemyalone cycle. Maybe some session sugar enabled a stateful behaviour, whatever. And we had a way to adapt MVC: put everything that is persistent or part of the “business logic” in a Model-Class ( aka bean ). Go ahead and search for your embedded html. Try to put in a seperate file, and tell all your geek-friends that it’s the view. And finally, the glue was the controller. And yes, it worked out really well. That was then.

Since the unfortunate launch of GMail everything has changed. There is no longer anything like “impossible”, since someone clearly demonstrated that virtually no restrictions in terms of usability and functionality exist.

Again, from my point of view, Google just didn’t reinvent the wheel, they just used available techniques in a new way.

So, with all this “new” technology, web application creators were forced to adapt, which led to a wide variety of 1) AJAX-Frameworks like Prototype and JQuery 2) Smart helper functions for server-side components to hide away the fact that none of them is able to encapsulate that new technology beyond some well-designed layer of abstraction.

Welcome to my world. I’m doing web stuff daily. Someone even pays me for doing it. But I’m really, really frustrated. There is simply no single well-designed framework, enabling me to really focus on what I want to do, not on how.

Today, business logic isn’t the problem. There are some very good approaches making it a breeze to brew out even complex logic.

But there is still too much code here ( in my repositories, maybe I’m just doing wrong ) that’s just dealing with requests. But the amount wouldn’t be a big deal, since the average linecount already dropped massively over the years. The problem is that there is absolutely no beauty. Nada. No language can hide, not even Ruby, that it’s ugly to deal with requests on a per-request level.

I don’t have a solution, though I’m thinking about it a looottt. And that’s just my opinion, expressed in some kind of english. And I’d really appreciate any single comment.