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.

But the other problem is in enterprise or business environments. Imagine some people with the need to have access to certain management systems ( e.g. for remote servers ) sharing one account. While it would be totally usable to simply write down a password and hide it in the office, this is quite time-consuming, each time someone compromises your secret place, you have to reset passwords and find a new place, communicate this new location etc.

So an online solution should be the way to go. Public-Key Infrastructures fulfill the requirement of security sufficiently, yet the usability sucks. A simple desktop application retrieving encrypted passwords and deciphering them locally would be enough. Change a password and publish this change is as simple as changing the password, everyone else would get his new password automatically if he is in the group with access to that password, so password changes are not a problem.

Avoiding showing the password onscreen is as simple. Just put it in the clipboard, and happiness would spread. But where is this simple approach?

I’m still a bit frustrated that there is nothing like a general file metadata format. While every OS nowadays has its own metadata-supplying filesystem, there doesn’t seem to be a way to exchange that information or reuse it. Neither to publish it online, in a useful manner. I was thinking about a format that enables one to store almost arbitrary information in for a file. Album art, MD5-hashes, Author information, keywords. Anything that helps to categorize a file. Thus, a download would start by clicking on the metadata file, a nice screen would popup showing the file type, the supplied information, giving you the ability to get a quick overview about a file.

This could help to prevent the download of malicious software etc.. And it would help to store files correctly without user interaction. As a teacher of mine noticed correctly, it’s impossible to store and organize files in a useful way using the old-school directory-filename scheme, plus the good old 3-char extension, e.g. avi or txt. Something more sophisticated is needed, and would add a bit more usability to this web.

This is once again just a rough idea, and I would love to hear your comments.

[nggallery id=3]

On the other hand, I guess that most people using really modern WebApps are nevertheless forced to use modern browsers. I don’t know, really not. A short yet true list of cons is presented here as well, and a rather radical point of view presented by nick cowie.

Browsers are not important to me. As long as they display the pages I want in the way they were intended to be displayed, I’m satisfied. Nothing more, Browsers just don’t impress me, they are simply a tool. And the best tool is easy to use, robust and supportive. Supportive also means that I expect a Browser to stay out of my way. I don’t want toolbars or widgets stuffing the screen. Just the content.

This leads to a question. What to expect from a Browser. Honestly, nowadays every major Browser supports Tabbed Browsing, Ad Blocking and some kind of Anti-Phising. Most Browsers also support Web Standards and large parts of CSS2.1, Internet Explorer 6 and 7 don’t. JavaScript or ECMAScript is another topic. Now all widely used, modern Browsers support XMLHttpRequest, Why is it even important to list those specs?

Well to show you that those differences in support for each standard, language or format do matter. Unfortunately, when doing something for the Web, live stops immediately being cool and easy. There is no guarantee whatsoever that your product will run or display correctly on every browser, even if you carefully follow the standards when implementing. That leads to a lot of workload just for testing, not the overall but browser-specific one. This could be totally avoidable. By browser manufacturers simply agreeing on a few standards, but unfortunately, still that fails as long as people are willing to use the well-known standards wrecking machine, Internet Explorer.

Designers and Programmers can’t ignore the fact that the majority of folks is still using IE to browse. Forcing them to change won’t work, it has never. And it stinks that every page expecting mainstream audience has to be customised accordingly. Just to workaround quirks. That’s well-spent time, that could be used to built great products or do something really useful.

So a good browser should be one we don’t talk about. One that just a good job. And everything else is, besides the fact that in our case “everything else” refers to “everything out there”, a wrong way, keeping developers from working on useful stuff and users from having a consistent browsing experience. And it should be in the best interest of browser manufacturers to ensure both.