For quite a long time I have been thinking about recent developments in the development of Web Applications. About the different paradigms and technologies that are currently arising, partially transforming how we think of the Web in general and Web Applications in particular.

So I decided to write some thoughts down, that have been hovering in my head for a while. This should be a series of three articles, this one being the first and dealing with

Choosing your weapons

Platforms, Programming Languages, Frameworks and all the other stuff that you really don't wanna know about but can't stop reading in all that tech blogs.

Ok. First things first. Talking about Platforms is really not necessary. One of the fields where we can truly stick to is that no application in this world needs a specific OS to perform well. There are other reasons, such as scalability, security or existing environments to choose platforms wisely, but don't believe anyone who wants to convince you that you can only build great applications using, let's say, BeOS. Those days are over.

So assuming you found your environment of choice (I hear techies in our office argue for different Linux distros every day, so the paradox of choice definitely pplies), you can focus on the other parts of the mixture. But how to decide on those parts? Well, the term "mixture" seems highly appropriate. You want it to taste well, you want every single ingredient to be in place, leading to a simple yet elegant and matchless taste. In other words: you want it to work.

I wrote somewhere else about the recent hype around Ruby on Rails, a classic Web Application Framework and came to think what criteria such a mixture would involve. Not an easy one. (Nota bene: I won't talk about databases or datastorage here. There are others that can write a lot more and better about that topic.)

We here at Knallgrau use Helma every day, for several reasons, but wait, we said first things first. The question in my head was: "What would one search if she/he had to choose a application framework for a specific task?". And I think that the following criterias work for both, programming languages as well as whole application frameworks. Some points apply to both, where necessary I will make some distinctions.

Here are my considerations, others are (as always) very welcome:

1. Popularity: Sure, you don't want to use something nobody uses. Using a programming language like Whitespace may be fun first, but as soon as you want to move your personal boundaries you might run into problems. We humans tend to learn by imitation (at least half of the time), by just copying things of others that help us to understand how the whole thing works. We have to nearly "touch" it, to grasp its nature.
   So that is one reason why popular things get more popular and unpopular things stay unpopular. Because imitation is what we are designed to do.
   But don't underestimate the Geek Factor. No matter if you are a techno Geek or a English literature Geek, there will always be people that prefer using some unpopular language, just because they can. Just to be different.
2. Ease of Use: Having to download 10 libraries, unpack and compile is in most cases not considered ease of use. You want to start quickly, understand quickly and get quick results. Why? Because if this is not the case, then this is considered work. If you get into something quickly, you impose it is fun, because you get positive feedback early on.
   Of course there are exceptions to every rule. Who ever tried to use Oracle and wondered how complicated SQL can get might agree on that. But in this case almost always one of the other points mentioned clarifies the why.
3. Adequate to your task: Trying to develop a large enterprise application with numerous connections to other systems and a complex architecture in, let's say, Perl would be pretty inaccurate. Sure, it would probably work in the end and I am sure that there are some applications out there that come close to this connection, but you won't consciously do that.
   Many issues support that viewpoint, from bugfixing to the ongoing support and changes you will have to make.
4. Powerful: No matter if you think of programming languages or frameworks, you'll almost always would want to have a powerful tool. Something that eases the tasks you have to perform. Be it the object relational mapping of Helma or Ruby on Rails. Or the special mysql functions that PHP provides. Power is relative to your task, but you definitely want it.
5. Maximum Overview: Also no matter if it is a framework or a language you have to choose, you want a maximum of overview about the architecture and the individual code. Why? Because you want maximum control over it. Thats one of my objections against Ruby or Perl or Haskell and a point for Java, Javascript or PHP. If you read a little bit of source code you'll grasp the what in a minute. Sure, one can argue after a little bit of programming you'll know the language anyway, but I suppose that this doesn't count as ease of use having to use something for a while, or reading through manuals for hours, just to grasp what it does. I managed to use PHP within days in a productive matter without great skills in programming a few years ago. I would say my skills haven't radically improved, but reading PHP or Java code is definitely easier than reading Ruby or Rebol.

So what is this all about finally? It is about choosing the right environment for a Web Application, getting the state of the art. So probably you would choose to use Ruby or Phyton or PHP. Probably you would use a ported version like Jython. You might also get into a framework like Rails, Seagull, Twisted, Django or Helma.

So far for the first part. What I still want to write down in more detail is the question, how modern web applications should work at the interface. What technologies to incorporate and what to leave aside.