The perfect web application technology, part 1: Motivation

This will be a big quest: search, understand, test and evaluate all major web technologies available today. In this first post I will try to summarize the motivations for this little project.

I will post subsequent entries for each major technology that can be used to build a web application, including source code. You are invited to participate: tell me what technology I’m missing, send me patches or fixes, or… whatever you may like to do.

Motivation

For most of my programming life, I’ve never considered myself a web developer. You may got answered the “perfect web application technology” question many years ago, but that’s not my case. Well, actually I have done real web programming many times, among many many other things. By real web programming, I mean applications that were or are in use and I get paid for, not just something for myself or some toy experiment.

The problem that keep’s me avoiding web development is that current web is a big, big success… but the underlying technology is a big, big mess. Current “Web 2.0″ (and “normal web” too) have been used for something it was never designed, neither predicted.

It all started as a simple way to share information, mostly text and sporadicly an image over there. That’s where the term “web page” comes from: it was an electronic analogy of paper based documentation. There was a server and a client. The client requested a web page, and the browser served a file. You were able to interconnect one web page to another by putting links. HTTP and HTML were born under the “hypertext” name: just tag your text and your documents will be displayed as an “interactive” web page. And it scaled very well, because there was no central database or system; just a missing (404) link if something went wrong.

Then, the madness began. Browsers wars and incompatibilities (imagine your gnome program doesn’t work as expected or does not look the same in different Linux distributions), mixing presentation with code (argh! I hated every template I’ve seen), data conversion mega-problems (like & when it should be &, and not to mention all the problems at all levels when your language is not english). Today, we have a mix of disparate usage and technologies, all of them running over the same “hypertext web page” system: wiki’s, blogs, search engines, JavaScript, tag clouds, DOM, XML, JSON, RSS, Web Services, REST…. including desktop class applications, like gmail.

So, all of this is running on requesting/response of a page. Does it make sense? Nope. Does it work? Sort of, and painfully. In my opinion, the web is far away of the “it just works” phrase.

And that’s the reason why it is so difficult to build a web application: it is not natural. And because it’s so difficult to do it, it’s harder to find projects that did it well. I think nearly all current web applications have at least one or more problems because it’s so difficult to do, that all developers just get to the point when “it works for me”, not considering all the implications of simulating a real desktop class application with a request/response webpage model.

So, that’s the story: it’s difficult because it wasn’t mean to be, it’s wrong because it so difficult that is nearly impossible to cover all the caveats.

And so, I never liked it. But now, I really want to solve this problem, at least for me. Partly, to make the web a little better. Partly, because I think developers are not aware of any of this. And well, it’s fun to compare and learn technology.

I will look for technologies that have managed or solver almost all of the common problems derived from this wrong model of making applications. Watch out, because my requirements will probably make your current web technology look like crap.